I'm not a huge fan of this post - I feel like it adds to the confusion where it tries to enlighten.
First, a pedantic point - a proper pure functional language will not have "side effects", it will have "effects" (either through algebraic effects or through monads or something) - nothing "side" about them. Side effects are effects that happen in addition to the main value of doing something (this medicine has side effects). Effects are just things that you want to happen in the world, and many functional languages reason about them as first class objects instead of implicit behaviors. That is, a function has an IO effect or returns a value in the IO monad instead of being a C function that can arbitrarily write to the file system.
Second, the main point of the post seems to be that functional programming will not make concurrency happening outside of the language (say, when talking to databases) safe, but that's a pretty simple point that's not stated as clearly as it could be.
Hopefully I'm not being too harsh - I might have misunderstood something, and the core point that functional programming doesn't magically fix everything is true - but it's that very confusion that I think makes this post unhelpful.
The post is entirely useless from any technical perspective. It talks about pure FP languages. Then about OCaml and concurrency without much detail or distinction.
The only useful thing it almost says clearly is that FP doesn't have to be magic and can be used effectively by normal folks, but instead flips the title (for clicks) to imply it's not as good as they say.
Functional programming is not about "no side effects", but how to separate pure functions and side effects. Additionally FP is also about how to separate data and logic.
> What else is the turbofish other than an arcane rune for magical purposes?
I'm reminded of the Codeless Code short story where the young acolyte visits a Haskell monastery, looks upon an engraving of the monad definition, and wonders "and this mystical inscription - this is code?"
I dunno if I'd say that. At least using recent versions of Java and some F#, I find the latter much nicer, but don't do things so extremely differently. It's just more concise and less keyboard typing when refactoring.
Having worked with Rails codebases I tend to avoid magic when not needed.
The best effect is using FP, then going back to what you used before and adopting more FP style: single assignment to local vars, immutable datastructures, less imperative control flow, etc.
On the whole, the type safety guarantees of something like StandardML over something like Golang are at least as valuable as many of the more traditional "functional" aspects.
conflating FP with immutable data structures or with referential transparency and then bashing FP seems pointless.
No one says FP is panacea. Why are you refuting words you put into imaginary novices mouths. Engage with good ideas instead of shooting down bad ideas no one holds.
> what I call FPF ... emanates from people who’ve recently discovered FP ... and have yet to realize that — like all programming innovations since the 1940s — it doesn’t actually solve all the problems for us.
Most rank and file business and administrative apps don't need "direct" concurrency. The web server and database provide it more or less automatically most of the time, if you don't do anything "odd". If you disagree, I'd like to exam a relatively common scenario.
This guy is spamming Medium everyday. Has been banned on a few occasions, but creates a new account, writes nonsense and then shares it on HN and Reddit
miloignis|3 years ago
First, a pedantic point - a proper pure functional language will not have "side effects", it will have "effects" (either through algebraic effects or through monads or something) - nothing "side" about them. Side effects are effects that happen in addition to the main value of doing something (this medicine has side effects). Effects are just things that you want to happen in the world, and many functional languages reason about them as first class objects instead of implicit behaviors. That is, a function has an IO effect or returns a value in the IO monad instead of being a C function that can arbitrarily write to the file system.
Second, the main point of the post seems to be that functional programming will not make concurrency happening outside of the language (say, when talking to databases) safe, but that's a pretty simple point that's not stated as clearly as it could be.
Hopefully I'm not being too harsh - I might have misunderstood something, and the core point that functional programming doesn't magically fix everything is true - but it's that very confusion that I think makes this post unhelpful.
karmakaze|3 years ago
The only useful thing it almost says clearly is that FP doesn't have to be magic and can be used effectively by normal folks, but instead flips the title (for clicks) to imply it's not as good as they say.
chongli|3 years ago
raluk|3 years ago
Functional programming is not about "no side effects", but how to separate pure functions and side effects. Additionally FP is also about how to separate data and logic.
Veliladon|3 years ago
It's magic. Functional programmers are witches/warlocks. What else is the turbofish other than an arcane rune for magical purposes?
piaste|3 years ago
I'm reminded of the Codeless Code short story where the young acolyte visits a Haskell monastery, looks upon an engraving of the monad definition, and wonders "and this mystical inscription - this is code?"
abc_lisper|3 years ago
karmakaze|3 years ago
Having worked with Rails codebases I tend to avoid magic when not needed.
The best effect is using FP, then going back to what you used before and adopting more FP style: single assignment to local vars, immutable datastructures, less imperative control flow, etc.
hajile|3 years ago
On the whole, the type safety guarantees of something like StandardML over something like Golang are at least as valuable as many of the more traditional "functional" aspects.
nh23423fefe|3 years ago
No one says FP is panacea. Why are you refuting words you put into imaginary novices mouths. Engage with good ideas instead of shooting down bad ideas no one holds.
> what I call FPF ... emanates from people who’ve recently discovered FP ... and have yet to realize that — like all programming innovations since the 1940s — it doesn’t actually solve all the problems for us.
tabtab|3 years ago
anupamchugh|3 years ago
tabtab|3 years ago
https://www.reddit.com/r/DilbertProgramming/comments/qg99f0/...