Sometimes, I spend a lot of time creating very good abstractions only to find that nothing will make use of it for next 10 years. You'd be better off duplicating some 8 lines of code. It is not ideal but you could be spending your energy elsewhere where it matters and abstractions do actually pay off.

It's also possible that we try to hard to generalise things and for a handful of lines of code it's just as valid to provide different implementations for each rather than spending time evaluating an abstraction that's as likely to only be identical in implementation due to incomplete use case or just the product of the sheer coincidences that appear in immature code.

I think it's worth noting that the examples in the article are the way they are for the sake of demonstration. In that context, I very much appreciated the explanations even as a fairly seasoned programmer; I knew more or less how to do these transformations, but not what they were called and how I might explain in words why I'm doing them.

Author here: Indeed, this could be an option right before "Configuration" on the spectrum I shared. For that specific example, I don't think it would make sense to do, but in many cases it can be valid.

I hope the point of the essay came through, that there is an abstraction spectrum, and where certain ideas fall onto that spectrum.

Thanks for reading!

I really disagree that composition is error prone. It makes it easier to test and isolate errors by easily allowing different implementations along the pipeline. You get abstraction and it's less error-prone. Abstraction usually is a win for reliability, because abstraction means less information and less entropy.

Notice that the post is written in Javascript.

Abstraction and composition are great to surface the main characteristics of your algorithm. A compiler then can take those characteristics and verify if they make sense. Different compilers can do that in different amounts, and the Javascript one does the absolute minimum possible. On this case, you get no safety, just more complex code.

Go ask a Haskell developer and the first reaction you will get is probably "wait, you were running getData inside the original function?!"

> Go ask a Haskell developer and the first reaction you will get is probably "wait, you were running getData inside the original function?!"

Haskell developer here, this was indeed my first reaction :P

It would be more interesting to see these things in multiple languages so it shows how it would be done (best) in those. Learning things js centered is is not good for everyone.

Hey team, author here:

I agree with the statement that composition won't make the code unreliable.

When I wrote mistake, the kind of mistake I was referring too was a mistake in abstraction boundaries, rather than execution. (for an extreme case consider a DSL: if you abstract a DSL from only one example, you'd likely get the core abstractions wrong)

He used javascript so he's probably talking about composition without type checking.

But yes more important then just composition is to use combinators and segregate your combinators from IO.

Small typo in the second example. Trying to save the Jason object into the CSV file.

Thanks xypybd! Mind giving me a snippet? (not quite sure where)

Second code example:

  fileURL = saveFile("export.csv", jsonStr);

(you should be writing csvStr to the file, not jsonStr)

Updated, thanks team! (should show up in a few mins)

Keeping it simple until it is needed to expand is the best way forward, and have a little bit of resistance to the expansion.

One issue that comes up is the function arguments can evolve to be a mess over time with this method.

I like to always use a prop object as function arguments, even when it is simple.

function calculateArea({x, y}) rather than (x, y).

This makes it so things can be added, and be optional, and the calling function clearly can see what those values are being assigned to.

This means that the 100 times you called that function don't need to be rewritten with a new parameter added, and you don't have to have a bunch of null values set for unused cases.

I think they missed Idea 0: just copy-paste it if you need only json and csv.

For example, Go is leaning towards such approaches, and I think should be default for the beginning.

Refactor later, when you will see more cases.

Fantastic post. Really good to see content aimed not at this topic

It would be good to have the inversion example for a type-based dispatch language/style, rather than the functional style.

Weird error. Page loads, but then gets replaced by:

C(...).replace(...).replace(...).replace(...).replace(...).trimStart is not a function