[drekipus]

Depends on the example. Going off the blurb:

> it’s a way of breaking down a complex function into smaller, simpler functions that can be composed together to achieve the same result.

And you could almost see it as analogous to the "fluent" pattern like:

    GetObject()
    .add(3)
    .applyGradient()
    .giveFish()

Etc. On the side: I really hate the "make it less complex" PR comments because it's not complex, it's just hard to read, and that's usually because the reader doesn't know about them.

I have one guy in our company who wants to unravel any list comprehension or map/generators functions (python) because he doesn't know anything except "for X in Y"

[jghn]

I always think of Rich Hickey's "Simple Made Easy" [1]

At the time I had a coworker who was militant about "simple code" and anti "complexity". I used to argue that the code they preferred was more of a pain in the butt due to avoiding anything beyond the most basic of constructs. They saw that this was a talk, suggested our team watch it, and then became upset because it turned out they hadn't actually watched it and assumed based on the title that it'd back up their viewpoints.

Lowest common denominator coding isn't the same thing as avoiding complexity.

[drekipus]

That's hilarious.

The thing is, complexity & complications come from known-unknowns and unknown-unknowns.

Semantics of language use doesn't fit in there unless it's undefined behaviour. Things can be hard to read, but that's seperate from complexity.

And often the "simple, trivial code" is the slowest performance (which is a big deal in python)

[pixel_tracing]

It _is_ literally increasing complexity. Because now the call stack has added layers of indirection:

[0] abort() [1] curry call site [2] partial closure 1 [3] partial closure 2 [4] partial closure 3 [5] partial closure 4 [6] <actual place of issue> [7] partial closure 5 [8] partial closure 6

Compare this to something isn’t using currying:

[0] abort() [1] call-site 1 [2] call-site 2 <actual place of issue> [3] call-site 3

Dealt with this enough at a previous company I’m glad on my team at FAANG people are reasonable and don’t just shoehorn functional paradigms unnecessarily

[Clamchop]

The curried example actually could only ever add one to the call stack, no matter how many times you do it.

And another thing, currying is one way of decomposing functions. Either your first example is decomposed too much or your second too little.

But I also am less comfortable working in a functional style.

[noelwelsh]

You're only looking at one dimension of complexity. There are tradeoffs.

[oofbey]

Complexity and understandability are very difficult to separate. If a coding style is unknown / bizarre to most coders on a team, but beautifully simple to a few who know the technique, which is it?

There should be a balance between teaching new ideas, and acknowledging the truth of what people are comfortable with.

[ignoramous]

I guess every language needs a variant of JavaScript: The Good Parts. Believe Go, despite its many shortcomings, gets readability better than most languages: https://go.dev/talks/2012/splash.article#TOC_4.

On the topic of Kotlin, it is really one is the better (perhaps the best?) JVM languages out there.

[delusional]

> I have one guy in our company who wants to unravel any list comprehension or map/generators functions (python) because he doesn't know anything except "for X in Y"

I'm that guy at my current place of work. Incidentally, I'm also always the guy called in to work out why something doesn't work when the guy who made it (and loved streams and CompletionStage) has moved on to a different job.

I can read and write generators and maps just fine (I do it all the time when writing little one off scripts), but debugging in that mess is a hell. When I write something that will outlive my tenure at an organization, I reach for what everyone knows. I write in a dialect that even somebody right out of programming 101 can understand, because god knows what sort of clown they're going to hire after me.

[drekipus]

That doesn't fly in all production environments though.

Sometimes doing 10,000 function calls is a hell of a lot more expensive than sending a 10,000 sized array to one function call.

I'm all for simplifying code, but not to the point of "start at date 0000-00-00 and increment upwards, so what, computers are fast" level (which is close to the type of person I'm taking about)

There's a certain threshold that I would imagine is different for different domains within different companies and perhaps different teams.

I'm fine with people who come out of programming 101 and want to continue to learn new programming ideas, not someone who's going to say my code is wrong because they didn't cover it in their 101 class.

[nvm0n2]

That's partly a Java issue though, due to how streams are implemented. The same code in Kotlin is easy to debug.

[watwut]

These are great when the methods are simple configuration, but it indeed sux whenever you are debugging something. Or when it gets just a little bit more complicated.