Currying

Original Article ↗ Hacker News Discussion ↗

Currying—treating multi-argument functions as chains of single-argument functions—provokes strong reactions among programmers, especially when used heavily in JavaScript codebases via libraries like Ramda. Many commenters argue that while currying is natural and powerful in languages like Haskell, it often hurts readability, tooling support, and maintainability in typical “enterprise” or mixed-ability teams, where explicit functions and simpler patterns are preferred. The thread also explores related concepts such as partial application, point-free style, and labeled arguments, with a recurring theme that advanced functional techniques are best used sparingly and in contexts where the team and language ecosystem are well-aligned with them.

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.