[pixel_tracing]

While I find these topics esoteric and very interesting in normal day to day code during a code review I’d probably say make it less complex, because majority of the time spent is reading code this makes code harder to read

[kmill]

Currying is pretty much just a convenient way to write a one-constructor one-method class. It's a parameterized version of the command pattern.

That said, if you're using a language with classes you may as well stick with those and omit the syntactic sugar from your diet.

I find functional programming useful though because it can shorten code in a way where you can get a better view of the big picture and easily make sweeping changes. But it's also easy to write in a way that's too "perfect" (i.e. resistant to change) and incomprehensible. Though I'm not sure the total incomprehensibility is generally any worse than an enterprise Java codebase -- local readability might only give you the illusion that the whole system is understandable. Still, if you don't enjoy reading code in a certain style it makes for hard reading!

[mumblemumble]

It's also nice for making certain kinds of code more readable and maintainable in a way that isn't perfectly emulated by anything in OOP.

Here's a nice talk on the subject: https://www.youtube.com/watch?v=sfYA0HCWgqQ

and slides: https://fsharpforfunandprofit.com/pipeline/

This "looser" way of doing things tends to be more popular in the F# community, which isn't terribly fond of those rigid crystalline structures that you get in other corners of the FP community. Though I'd also point out that, even in Haskell, ways of programming that lead to incomprehensible and resistant-to-change code are often viewed as a sign of inexperience by more seasoned developers. There's a lot of truth in this joke: http://pages.cpsc.ucalgary.ca/~robin/class/449/Evolution.htm

[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.

[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

[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.

[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.

[playday]

I don’t think currying is esoteric at all, and if someone told me in a code review that it’s “too complex” I’d start looking for a new job immediately, since it’s a career dead end if the reviewer doesn’t even understand simple functional programming.

That said sadly these days I’m working on smart contracts in Solidity which is object oriented, and the primary functional alternative Vyper has had major problems while Rust has proven to be slower to develop in, at least for cosmwasm chains (I still hold out hope for Rust). So you could have a point lol.

[sfn42]

I think this illustrates well an issue I have with the whole clean code thing. Utilizing slightly obscure language features isn't unclean, some times they're the cleanest solution.

Some people may not know what currying is and be confused by the code, that's okay. They can ask or Google it and then they understand.

The important thing is that the system itself is clean, that code is organized in a way that makes sense so that everything has a natural place to be etc. Loose coupling is a big one.

People talk too much about shot that doesn't really matter like names or whatever. Sure they're important but that's like saying conditional statements are important in programming. Yes they're important but it's week 1 stuff. Learning to do good work takes years, we're way past naming and stuff.