3 ms·

> Coding a function in the expression-oriented syntax of functional languages has a higher cognitive load than coding that same computation as a sequence of st

> Coding a function in the expression-oriented syntax of functional languages has a higher cognitive load than coding that same computation as a sequence of statements. I don't know what fp's you've been using but the most common modern ones have basically all adopted the pipe operator, which make the representation of data transformation as a "sequence of statements" painfully obvious. "Take this data" "Transform it with this function" "Get this integer list out from that" "Multiply those integers by two" "Sum them up"

jasperry 5y ago
Thanks for bringing that up. The shift to using the pipe operator has been an intriguing development in the community, and I've given some thought to what it implies about the difficulty of programming in functional syntax. The pipe operator helps if you have a clean sequence of steps and each function returns only the needed input for the next step. The code becomes just as unwieldy if an argument isn't in the right position, so you have to splice in a lambda, or you have to split cases on the result, in which case you have to do something monadic if you want to avoid deeper nesting. All of which looks like unnecessary friction when I know perfectly well in my head what the computation needs to do after each step. Also, when you have the pipe operator in your toolbox you now have a decision between two styles of coding that are basically inside-out from each other.
- dnautics 5y ago
  > The code becomes just as unwieldy if an argument isn't in the right position, so you have to splice in a lambda, or you have to split cases on the result I disagree. This is pretty clear even though it does exactlywhat you claim is terrible, and it is far, far clearer than the corresponding imperative code: https://twitter.com/DNAutics/status/1421465090856005633?s=19 https://twitter.com/DNAutics/status/1421465090856005633?s=19 Clarity in important when you're doing code reviews or fixing a bug, in anger.

jasperry 5y ago

Thanks for bringing that up. The shift to using the pipe operator has been an intriguing development in the community, and I've given some thought to what it implies about the difficulty of programming in functional syntax. The pipe operator helps if you have a clean sequence of steps and each function returns only the needed input for the next step. The code becomes just as unwieldy if an argument isn't in the right position, so you have to splice in a lambda, or you have to split cases on the result, in which case you have to do something monadic if you want to avoid deeper nesting. All of which looks like unnecessary friction when I know perfectly well in my head what the computation needs to do after each step. Also, when you have the pipe operator in your toolbox you now have a decision between two styles of coding that are basically inside-out from each other.

dnautics 5y ago
> The code becomes just as unwieldy if an argument isn't in the right position, so you have to splice in a lambda, or you have to split cases on the result I disagree. This is pretty clear even though it does exactlywhat you claim is terrible, and it is far, far clearer than the corresponding imperative code: https://twitter.com/DNAutics/status/1421465090856005633?s=19 https://twitter.com/DNAutics/status/1421465090856005633?s=19 Clarity in important when you're doing code reviews or fixing a bug, in anger.