When it comes to learning something like Haskell you are caught in dilemma between two ideas - Should you learn a functional programming language for fun and because it will make you a better thinker? or should you use your existing tools / stack to build something better than you have done before. What will be the better utilization of time?
While I was more oriented to former in the past, I have been inclining to latter, lately, for the reason, that what you have built remains more obvious to show and be proud of rather than knowledge of a programming language which might not be practical to build something good for variety of reasons (not soon to say the least).
I have been learning a bit of Haskell on the side recently just for the thrill of learning something completely different to the way I'm used to writing code.
My two cents so far is that using Haskell for "Real World" applications is not practical (at least in my experience), but by writing small applications in Haskell you learn a lot, it changes how you think. In my opinion, learning Haskell makes you a better programmer.
"here is a lightsaber, an elegant and powerful weapon. After you practice with this, you will be much better at stick-poking." is absurd.
More powerful abstractions tend to invalidate more and more combinations of terms. This means the space in which your program will be correct gets narrower and narrower.
The good news is, it means your abstractions will more precisely represent the correct program you want.
The bad news is, you'll want help from the computer and a well-designed language.
> No, it makes you a more dissatisfied programmer.
Maybe it makes you a more dissatistfied programmer.
> You can't take Haskell with you. Erik Meijer is wrong about this. You can't use monads productively in Python. You can try, but it doesn't work well.
Can you explain why? Because its my experience that monads, once you understand them even a little bit, open up a way of thinking about and addressing problems that can be productively used in most programming languages (Python certainly included).
> You need Haskell. Laziness, FP, immutability, types, the whole shebang. It all hangs together in a well designed way.
Certainly Haskell's very nice and hangs together fairly well (though its also got some warts.) And certainly, some people will be much more productive with Haskell than with other languages. But that doesn't mean that learning Haskell won't improve your productivity with other languages, and that the combination of available existing libraries, etc., might still make some other language a net win for a particular real-world project.
> Not even Scala can do FP well.
Scala is certainly less good at some things than Haskell is -- and its especially unsurprising that its not as great at FP since it deliberately compromises Haskell-style FP to support extended Java-style OO (and thereby also to interop well with Java.)
> "here is a lightsaber, an elegant and powerful weapon. After you practice with this, you will be much better at stick-poking." is absurd.
Except its not, either in the literal sense (lightsaber fighting, after all, is stick poking with SFX) or the figurative sense.
> Can you explain why? Because its my experience that monads, once you understand them even a little bit, open up a way of thinking about and addressing problems that can be productively used in most programming languages (Python certainly included).
I talked about part of the answer to this question at the New York Haskell Meetup awhile back.
The criticism there doesn't seem to be about why static typing is particularly a bar to productive use of monads, just the general criticism that dynamic languages lack type safety, and so limit you to monadic operations without the safety of static languages. It also makes the mistake of asserting that, because dynamic languages lack enforced types, the definition of a monad is different in those languages is different. But the definition of a monad is the same -- and includes the Monad Laws as well as the signatures of the bind and return (or fmap and join) functions -- independent of language. And the monad laws -- which even Haskell can't enforce for user-defined monads -- are just as important to correct monad use as the type signatures of the bind/return functions. Enforcement of essential properties is useful, but its not essential to productive use as the use of Monads in Haskell itself demonstrates.
Its manifestly clear that productive programming without type safety is possible, and I don't see anything there that distinguishes why that would be less true with monads.
> Dissatisfied with how poor the tools in other ecosystems are.
Don't pretend that the Haskell tool ecosystem is better than the others.
Does Haskell have a debugger which is as good and easy to use as the Chrome Developer Tools (JavaScript) or Visual Studio (C/C++/C#)? Is there a good editor (comparable to VS for C# or Eclipse/NetBeans for Java) with type-aware code completion? And don't tell me about cabal, that tool is much worse than package managers in other languages, the amount of time people waste with cabal is unbelievable.
(I'm also starting to believe that these "Haskell is the best thing ever"-kids will become a bigger issue than all those "Haskell is not practical"-naysayers for the growth and success of Haskell.
The latter is annoying, but can cause people to sit down and think how working with Haskell can be made more straight-forward, while the former is blinded by his ideology and is hostile against improvements which could be seen as acknowledgements of existing flaws in the language/ecosystem.)
While I was more oriented to former in the past, I have been inclining to latter, lately, for the reason, that what you have built remains more obvious to show and be proud of rather than knowledge of a programming language which might not be practical to build something good for variety of reasons (not soon to say the least).