Hacker News Reader

Comment by stolenmerch | Hacker News Reader

"Auto-curried function style (reversed arg) wrappers"

https://twitter.com/jdalton/status/1571870137690591236

Calling these "FP wrappers" is doing quite a disservice to functional programming, which by no means necessitates that functions are curried, and which is basically the idiomatic way of writing javascript / typescript these days. You don't need (and probably shouldn't use) wrappers of any kind to write perfectly ordinary FP-style code in javascript / typescript. I'd hope people wouldn't associate such wrappers with FP, because what they accomplish is something relatively orthogonal to FP.

Absolutely. I use Haskell as my main language for personal projects, and I like FP a lot — but I’ve seen some really horrible stuff marketed as ‘FP’ lately, especially in languages like JavaScript.

And what is that?

Specifically I don’t know, though I do know what currying is. This auto-currying thing sounds like a reaction against some parts of JavaScript where you can get burned by default arguments.

A curried function is like a partial application for each argument. If mul:=(a,b)=>a*b then currying would be being able to say double:=mul(2). Currying everything and requiring all function calls to have one parameter per call — six:=mul(2)(3) — might have some benefit in avoiding bugs.

Generally speaking though my hunch is that the lodash author grew tired of the project’s focus on meta programming: noodling around with JavaScript using programming paradigms that hinder rather than help its users. Dropping the noodling and focusing on features is a “back to basics” moment, if you will.

https://github.com/lodash/lodash/wiki/FP-Guide

Basically flipping around the args in a function and returning a "curried" function call. So instead of

    _.map(["1"], parseInt)

it's the other way around,

    _.map(parseInt, ["1"])

That way you can do something like

    const parseArrayFunc = _.map(parseInt)
    const parsed = parseArrayFunc(["1"])

This pattern is called currying in functional programming.

The complaint, I would think, being with the machinery to make _.map return a function or a value depending on the number of args, not with the flipping/arg order stuff?

Yeah I’d think so too. FP languages like Haskell or F# has partial application as part of the language itself and you get it for free by just ordering the parameters that way.

Partial application makes sense to me as a useful computer science concept. Reasoning about functions when they always have 1-arity makes proofs possible.

In software though, it just seems like code golf for people who can’t or won’t write a function as a way of sharing code between call sites:

  def serialize(fn, data, path):
    …

  yamlize = partial(
    serialize,
    yaml.dump
  )

  jsonize = partial(
    serialize,
    json.dumps
  )

Presumably some of these people wake up in a cold sweat about the shame of typing “partial(serialize, …)” twice and do this:

  def serialize(fn, data, path):
    …

  a = lambda f: partial(serialize, f)
  yamlize = a(yaml.dump)
  jsonize = a(json.dumps)

A good example of Don’t Repeat Yourself mutating into Never Repeat Yourself with ill effect, because the developer has self flagellated so much that the following code is deemed to have too much repetition in it:

  def write(data, path):
    …

  def write_yaml(data, path):
    write(yaml.dump(data), path)

  def write_json(data, path):
    write(json.dumps(data), path)

As an illustration, I wrote a Sokoban game in that style (no mutation, no side effects, partial application everywhere). See https://github.com/Michael-Zinn/fpsokobanjs/blob/master/game...

Functional programming wrappers? I recently discovered Ramda JS as an alternative to Lodash / Underscore and it's surprisingly fresh to write in. It can get a bit complicated sometimes, but that's when GPT-4 comes to the rescue...

Reply on news.ycombinator.com