I think the fact that this (and all macros with `babel-plugin-macros`) requires an explicit import helps keep it out of magic territory. You do have to become aware that the symbols transform the function/argument they're a part of, but this is only really new to JS devs. It's familiar in a bunch of other languages.

I documented how they work in this part[0] of the readme.

[0]: https://github.com/citycide/param.macro#differences-between-...

The import tells you that some of the expressions in a file might be functions, but not which ones. For each definition, you have to read the entire expression to tell whether it's a function or evaluated immediately, and what its arity is. No thanks! Reading the entire file just to find out its API is no fun.

I like the direction typescript is going, where you can easily see not only the arity but the type of each parameter, without reading the function body. This is more skimmable.

I upvoted you because I want an honest answer from somebody.

It's like if mountain-climbing caused more mountains to rise up above you. This is great if you love climbing mountains but terrible if you actually want to reach the top.

We keep "improving" our languages but very few of us take the time to measure our real productivity.

What is the business value case for not using Elm-lang?

At some point, if we are "doing it right" the total amount of code in the world (modulus copies) should be contracting.