3 ms·

This isn’t really worth reading for most I think. It may be actively misleading to newcomers to FP (I would count myself as one). It might be useful for people

This isn’t really worth reading for most I think. It may be actively misleading to newcomers to FP (I would count myself as one). It might be useful for people who want to promote FP to see the kind of issues people new to FP face, but not really, because they’ve already seen this a bunch of times. I think the author inadvertently reveals the source of their problems with the following comment: > I also do not believe that functional programming is "a completely different paradigm". I view it more as a bunch of programming patterns that are lumped together under the functional programming umbrella because they work well together. FP only started to make sense to me once I discarded all my OOP/Imperative ideas. I can see why refusing to do so would lead to thinking a lot of it doesn’t make sense (having been through that myself).

dcsommer 9y ago
On the other hand, programming is programming. I work in many languages, both functional and imperative. Often I'll use functional paradigms in imperative languages, and sometimes I have to use imperative escape hatches in functional languages. I have no issues flipping from one mode of thinking to the other. Use the best tool for the problem and all that. It is absolutely possible to look simultaneously at both functional and imperative langauges and compare them with respect to readability, debuggability, etc. I think criticism of the OP should be focused on comparing along these axes, not vague "think functionally" truisms. Also, I will say that some of his complaints apply more to OCaml specifically than functional languages in general. My own 2 cents is that the universe of functional languages could take a lesson or two from how much simplicity boosted Go's success, even though I think Go took it a bit too far.
- brabel 9y ago
  I've been playing with more complex languages like Rust and Pony (neither really functional, but with advanced type systems) and have to say writing some Go more recently has been a pleasure :D But it really is a trade off between whether you need to prioritize correctness or development speed. Regarding your comment that Go maybe took it a bit too far: I agree... in the functional world, I found a language that I really enjoyed and that maybe fixes more FP problems: Elm! Quite easy to read and write Elm code, it's a shame that it only exists on the front-end (it compiles to browser JS), would be really cool if someone ported it to the backend as well.
- marcosdumay 9y ago
  What you are saying is not what the GP is talking about, and not what is displayed at the article either. If you think primarily in imperative algorithms while programming in a FP language, or primary in functional algorithms while programming in an imperative language you will make nothing but assure everything will be wrong and work badly. Modern languages do make it possible to mix some bit from other paradigms, but they do certainly not all accept the same code. About the article, the problem seems to be even more superficial. The OP seems to have internalized the series of rules necessary to program in Javascript, and is understandably afraid of breaking them on his OCalm code. That is a natural problem to have when learning a second language, and can only increase when both languages are that different.
Zak 9y ago
I think the article might be worth reading from a how-not-to perspective. It seems very much like the author is applying paradigms from object-imperative languages to a functional language and meeting resistance. It's perfectly fine to not know how to express things idiomatically when learning a new language that uses an unfamiliar paradigm, but a critique written from that perspective is only useful in that it's a list of indicators that you're not using the language effectively.

dcsommer 9y ago

On the other hand, programming is programming. I work in many languages, both functional and imperative. Often I'll use functional paradigms in imperative languages, and sometimes I have to use imperative escape hatches in functional languages. I have no issues flipping from one mode of thinking to the other. Use the best tool for the problem and all that. It is absolutely possible to look simultaneously at both functional and imperative langauges and compare them with respect to readability, debuggability, etc. I think criticism of the OP should be focused on comparing along these axes, not vague "think functionally" truisms. Also, I will say that some of his complaints apply more to OCaml specifically than functional languages in general. My own 2 cents is that the universe of functional languages could take a lesson or two from how much simplicity boosted Go's success, even though I think Go took it a bit too far.

brabel 9y ago
I've been playing with more complex languages like Rust and Pony (neither really functional, but with advanced type systems) and have to say writing some Go more recently has been a pleasure :D But it really is a trade off between whether you need to prioritize correctness or development speed. Regarding your comment that Go maybe took it a bit too far: I agree... in the functional world, I found a language that I really enjoyed and that maybe fixes more FP problems: Elm! Quite easy to read and write Elm code, it's a shame that it only exists on the front-end (it compiles to browser JS), would be really cool if someone ported it to the backend as well.
marcosdumay 9y ago
What you are saying is not what the GP is talking about, and not what is displayed at the article either. If you think primarily in imperative algorithms while programming in a FP language, or primary in functional algorithms while programming in an imperative language you will make nothing but assure everything will be wrong and work badly. Modern languages do make it possible to mix some bit from other paradigms, but they do certainly not all accept the same code. About the article, the problem seems to be even more superficial. The OP seems to have internalized the series of rules necessary to program in Javascript, and is understandably afraid of breaking them on his OCalm code. That is a natural problem to have when learning a second language, and can only increase when both languages are that different.

Zak 9y ago

I think the article might be worth reading from a how-not-to perspective. It seems very much like the author is applying paradigms from object-imperative languages to a functional language and meeting resistance. It's perfectly fine to not know how to express things idiomatically when learning a new language that uses an unfamiliar paradigm, but a critique written from that perspective is only useful in that it's a list of indicators that you're not using the language effectively.