FP has its pitfalls, it is almost too easy to decompose, compose and build abstractions in the FP idiom. We often only praise the power and expressiveness of that property and act as if most of us are capable of making the right decisions all the time, which is quite obviously not the case.
(This is especially true if we add stuff like macros and homoiconicity to the language. The Lisp Curse has been discussed to death.)
I think the best approach here is a disciplined/pragmatic focus on readability as you are implying, without neglecting advanced FP techniques in the places where they actually solve a problem well.
Currying is in a sense one way of doing dependency injection in the FP paradigm. But more often than not, when I'm looking at a function that can/should be curried there is something wrong with the data/data-structures and not with the function.
And instead of bending the function(s) in an 'advanced' (read: complicated/complected) way, we can often transform or even re-model the data itself to make our code clearer and more robust.
The toy examples in the blog post can't be used to illustrate this well, which is fine, because the author just showcases the technique basics.
In the end, it just shows you can do this with Go, which is really all I wanted to do :)
Somewhere in the post I also hinted that there are other solutions, but I wanted to keep the post concise and chose currying as the topic.
Clever programming is about readable and maintainable code, in Go that might mean that (usually) currying is a bad idea. :)
https://www.haskell.org/tutorial/functions.html
In languages like Go, you'll write much more "composable" software by sticking to what the language gives you instead of trying to force this in.
A struct to collect random parameters, as suggested by other posts, is just brushing this under the carpet.
I'd much rather have func test(data){ return 'The ' + data.type + ' is ' + data.value + ' and the sum is ' + data.value1 + data.value2; }
I can easily validate data in the json object or multi-dimensional array or hash or w/e the language I'm working in calls it, and call it a day.
If I need to make it 'understandable' by other devs I'll add a detailed comment section on what all the 'required' data properties are and what not.
1. Named parameters (esp useful for literal number or bool arguments) 2. Optional parameters 3. Forwards compatibility as long as new args are optional
By contrast, if you're programming in Haskell and you're not taking advantage of the currying, you're missing something. But in that language, you don't manually define a ton of closures, and break the normal convention for calling functions in the language, and break the reflection support, and make the godoc look terrible and confusing, etc. etc., you're using the language as designed. Closure handling is built in and automatic, you're not shoveling out a ton of syntax because it's the default behavior anyhow, it's the only convention in the language, the documentation is designed to handle it, etc.