Currying

Currying in Real-World Codebases

• Several commenters describe currying-heavy JavaScript (e.g., Ramda) as unreadable and fragile.
• Rewrites to more conventional, explicit styles (e.g., lodash, simple helpers) reportedly reduced cognitive load and bugs, without performance or business impact.
• This is framed as a mismatch between “astronaut” code and everyday business/CRUD needs, where maintainability and clarity matter most.

Language Fit: Haskell vs JavaScript

• In Haskell/ML-style languages, curried functions are the default and integrate smoothly with syntax, type system, and idioms.
• In JavaScript/TypeScript, functions have variable arity, dynamic typing is common, and currying often relies on libraries, making it feel bolted-on and error-prone.
• Example issues: passing bare callbacks like array.map(f) can subtly break if f’s arity changes; using Number.parseInt with map is cited as a classic pitfall.

Currying vs Partial Application (Terminology Disputes)

• Long subthreads debate definitions:
  • Currying = transforming an n-argument function into nested unary functions.
  • Partial application = supplying some arguments to get a new function with fewer parameters.
• Some argue these are distinct operations; others treat currying as enabling partial application and speak loosely.
• Meta-discussion arises about pedantry vs effective communication and reading charitably.

Readability, Point-Free Style, and Cognitive Load

• Many argue implicit currying and point-free/tacit style obscure data flow, especially for non-experts and large codebases.
• Concerns: harder to distinguish arguments vs returns, overreliance on argument order, and need to mentally “decompile” chains of compositions.
• Others counter that in Haskell-like ecosystems, point-free, curried style becomes natural and concise, and over-naming can also harm readability.
• There is broad agreement that overuse of point-free style—even in Haskell—is disliked and has limits.

Error Handling and Types

• Critics worry about accidentally omitting arguments, returning a function instead of a value, and only discovering it far away.
• Supporters respond that explicit type signatures and strong static checking make such mistakes easy to catch, and these issues are often worse in untyped JavaScript.

Alternatives and Variants

• Many prefer explicit partial application via lambdas or utilities (functools.partial, bind), sometimes with labeled/named arguments or records to avoid positional traps.
• Object-oriented patterns (constructors capturing some data, methods taking the rest) are compared to partial application, though some see this as only loosely analogous.

Use Cases and Scope

• Some see currying and functional techniques as great for rapid prototyping, math/physics modeling, or puzzles, but excessive for mainstream enterprise code.
• Others report productive use in FP-focused languages (Haskell, Elm, PureScript, Gleam, OCaml), while still acknowledging a trade-off between cleverness and approachability.