2 ms·
The biggest problem I see with it is the author's allergy of functional programming. He even attempted to remove some of the existing ad hoc FP features in the
by hga 11y ago
The biggest problem I see with it is the author's allergy of functional programming. He even attempted to remove some of the existing ad hoc FP features in the move to Python 3 or the like. Hence my comment about wasting time fighting the language.
It plus Java, as MIT and I'm sure many other schools do (those that aren't just pure "JavaSchools") are going to leave students who don't make extra effort ... deficient when it comes to FP, the virtues of which I don't need to extol to you, although I'll add that it seems to be one of the good answers to making the most of our current "Moore's Law maybe", "Dennard scaling no" multi-core situation.
- nickpsecurity 11y agoI came from an imperative background so it didn't bother me so much. I agree it makes people suck at FP. Least there's good free work like "How to Design Programs" with the Racket tools. Should give them a nice boost. However, there's lots of ways to scale. FP is better at it but not necessary. It's easier for a decent imperative programmer to learn to scalable concurrency than to learn FP. So, path of least resistance & backward compatible means that non-FP approaches should get most traction. That's what we see in practice. Good news is that your point got many interested in making an attempt and led to more FP developers + languages. I even saw a case study of a company in finance using Haskell for production due to concise, correct, and concurrent properties. Plenty potential here.