When is a curried, point-free style worth adopting across a JavaScript codebase, and what concrete costs would you weigh against it?

## The decision is about a codebase, not a technique Currying and partial application are unambiguously useful *locally*. The principal-level question is whether to make them a house style, because that choice binds every future reader of the code. Judge it on three axes: does the domain fit, is the argument order right, and can the team pay the debugging tax. ## Where it genuinely pays - **Repeated specialisation of the same operation.** If a validator, formatter, or selector is configured once and applied to thousands of items, `const formatUsd = formatMoney('USD')` reads better than a wrapper arrow at every call site. - **A stable data-last signature.** Currying only fixes arguments from the left, so the pattern pays off only when the varying data is the last parameter. If the existing API is data-first, adopting the style means redesigning signatures — a much larger change than it looks. - **Uniform data in a narrow layer.** Transformation pipelines over homogeneous records are the sweet spot. Heterogeneous business logic full of branching is not. ## The costs, stated concretely **Arity errors are silent.** JavaScript checks nothing about argument counts. Supply one argument too few to a curried helper and you get a *function* where a value was expected. That function then travels: template interpolation renders its source text into the UI, arithmetic produces `NaN`, and `JSON.stringify` drops it entirely — functions are skipped as object property values. The exception, if any, lands far from the mistake. ```js const total = curry((rate, qty, price) => rate * qty * price); const line = total(1.2)(3); // still a function console.log(`Total: ${line}`); // "Total: (...rest) => ..." ``` **Diagnostics degrade.** Each partial is a fresh anonymous arrow, so stack traces show frames with no meaningful name; `bind`-based partials at least report `bound f`. A debugger stepping into a curried call walks the collection machinery before it reaches any domain logic, and a breakpoint in the target hits with a call stack that says nothing about which specialisation was in play. **Search and navigation weaken.** Point-free code removes the parameter names that grep and readers rely on. "Where is the tax rate applied?" is answerable by searching for a named parameter; it is much harder when the value is threaded through anonymous partials. **Cost per partial.** Every partial application allocates a closure and, in loose helpers, a fresh arguments array. Irrelevant at normal call rates; measurable inside a hot loop, where hoisting the specialisation out of the loop is the obvious mitigation. **Interaction with callback APIs.** Curried helpers handed to APIs that pass extra arguments complete earlier than intended, because the arity test sees three arguments where the author imagined one. That trap is invisible in review and needs an explicit wrapper. **Onboarding.** The style is unfamiliar to a large share of working JavaScript developers. Adopting it means every new joiner learns the vocabulary before they can read the module — a real, recurring cost that must be earned back by the value the style delivers. ## A workable middle position Most teams get the benefit without the tax by drawing a boundary: - Keep curried helpers **inside one module** with a small, documented set of operations. - **Name the specialisations** at the boundary — export `formatUsd`, not `formatMoney('USD')` inline at fifty call sites. Named partials restore searchability and give stack traces something to say. - **Use plain arrows in application code.** `(x) => format(x, 'USD')` is a few characters longer than the point-free version and vastly more obvious to a reader who has never met currying. - **Add a test on intermediate shapes** wherever completion depends on declared arity, so an accidental early or late invocation fails a build rather than corrupting output. ## Answering this in an interview The weak answer argues taste — "it is cleaner", "it is functional". The strong answer names a specific failure mode the style introduces into JavaScript specifically (a value silently remaining a function, because the language never checks arity), states what it costs to diagnose, and then defines the boundary at which the benefit still outweighs it. Owning the tradeoff, rather than advocating for one side, is what the level looks for.