08 / 09

How is currying different from partial application/function?

Currying is a concept from lambda calculus

  1. 1

    Partial application takes a function and from it builds a function that takes fewer arguments

  2. 2

    Currying builds functions that take multiple arguments by composition of functions which each take a single argument.

Difficulty: 5/10
Topics: currying, partial application, function composition

Scenario Questions

0-2 years experience
  1. 1

    Write a simple function add(a, b) and then create a curried version of it. How would you call the curried function to add 2 and 3?

  2. 2

    Given a function multiply(x, y, z), show how you could use partial application to fix the first argument to 5 and later supply the remaining two arguments.

2-5 years experience
  1. 1

    Our UI component library uses a higher‑order function to inject theme values. We tried to replace it with a curried helper but the component stopped receiving the correct props. Walk me through how you would debug the difference between the curried version and the original partial‑application version.

  2. 2

    We have a logging utility log(level, message) that we want to pre‑configure with a level for a specific module. Explain why using currying versus partial application might affect the ability to change the level at runtime, and which you would choose.

5-8 years experience
  1. 1

    In a large codebase we introduced a generic fetchData(endpoint, method, headers) helper. To reduce repetition we refactored it with currying, but the build size grew and tree‑shaking failed for some endpoints. Discuss the trade‑offs of using currying at this scale and alternative patterns.

  2. 2

    Our serverless functions share a common authentication wrapper that is currently implemented via partial application. If we switch to a curried version, what impact could it have on cold‑start latency and testability? How would you measure and mitigate any issues?

8+ years experience
  1. 1

    Our organization is migrating a legacy monolith to a micro‑frontend architecture. Several modules expose APIs that were originally built with curried functions for configurability. Some teams prefer partial application for clearer intent. How would you decide which pattern to standardize across teams, considering bundle size, onboarding, and cross‑language interoperability?

  2. 2

    We need to design a plugin system where plugins can declare configuration steps that may be composed at runtime. Explain how you would architect the API using currying versus partial application to support both static type checking and dynamic loading, and what long‑term maintenance implications each choice brings.

Follow-up Questions

  • Can you give a concrete scenario where one technique is clearly better than the other?
  • How do these patterns affect debugging and stack traces in V8?
  • What trade‑offs do they introduce for bundle size or tree‑shaking?