[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

[kmill]

I use Lean 4 quite a lot these days, and I appreciate how the developers embrace syntax extension and metaprogramming solutions rather than trying to encode complicated control flow using ascii art operators (it's like Lisp meets the ML family). I suppose programming with dependent types is enough of a challenge, so why make it even harder? They've got a sophisticated "do" notation with imperative constructs, mutable variables (that are translated into something StateT-like), and pretty seamless monad lifting. They've also got pipeline operators, including things like `x |>.foo a b c` for `X.foo x a b c` if `x` has type `X` (type-directed field notation is wonderful).

Many times you don't even use currying, since it's not always worth the effort making a particular argument be the last one. Instead you might write `xs.map (f · x)`, where `(f · x)` is short for `fun a => f a x`.

The language also has an interesting GC that lets you write functional algorithms that have good memory performance -- objects with exactly one reference can be mutated (using so-called FBIP, "functional but in-place"). There's an Array type whose theoretical representation is a linked list but whose run-time representation is a dense array with O(1) pushing, popping, and writing. Makes it easy to write performant code without resorting to sophisticated functional data structures.

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

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