I like Haskell, perhaps because of my strong mathematics background. My dilemma is should I spend more time developing my Haskell skills or should I spend some time with the new C++ features, or learning Rust, or just programming in the languages that I am already productive in?
When I assess a programming language, one of the questions I ask myself is "How will this programming language help me write correct programs?" In more detail I want a language that helps with four goals related to the ability to produce programs that achieve their specifications:
(1) Partial correctness: the program doesn't give wrong answers
(2) Total correctness: the program does (1) and doesn't deadlock or get stuck in an infinite loop. It eventually produces a correct answer.
(3) The program does (2) within the desired performance bounds specified.
(4) The program does (3) while making efficient use of hardware.
Haskell definitely helps with (1). Reasoning about the partial correctness of Haskell programs is easier than it is with imperative programming languages. Total correctness is very hard, especially with multi-thread, multi-process, or multi processor programs, but I think that Haskell is helpful here as well.
The real problem is that Haskell makes (3) and (4) very difficult to understand. Some of this is that compilers for functional programming languages are magic, making it hard to reason about what they are doing. This is further aggravated by Haskell's non-strictness.
A discouraging look at Haskell: "Why Is Haskell Used So Little In The Industry"[1] and
"Disadvantages of Purely Functional Programming"[2]
Citing Credit Suisse and Standard Chartered is just
name-dropping big banks in the hope that it will deceive
people into thinking that these institutes are seriously
invested in Haskell. They are not.
Lol, Standard Chartered is hiring like 30 haskellers _this year_, and I'm pretty sure they were heavily invested in Haskell in 2010. That writer of that article has an axe to grind, and is twisting facts to suit it.
Update: sorry you're getting downvoted, that's not me. I think worrying about the predictability of performance is perfectly reasonable, especially in the presence of lazy evaluation.
Jon is a professional troll. He's done the same nonsense with lisp, ocaml, F# and haskell. And just as with all his other trolling, very little in those posts is accurate.
When I assess a programming language, one of the questions I ask myself is "How will this programming language help me write correct programs?" In more detail I want a language that helps with four goals related to the ability to produce programs that achieve their specifications:
(1) Partial correctness: the program doesn't give wrong answers
(2) Total correctness: the program does (1) and doesn't deadlock or get stuck in an infinite loop. It eventually produces a correct answer.
(3) The program does (2) within the desired performance bounds specified.
(4) The program does (3) while making efficient use of hardware.
Haskell definitely helps with (1). Reasoning about the partial correctness of Haskell programs is easier than it is with imperative programming languages. Total correctness is very hard, especially with multi-thread, multi-process, or multi processor programs, but I think that Haskell is helpful here as well.
The real problem is that Haskell makes (3) and (4) very difficult to understand. Some of this is that compilers for functional programming languages are magic, making it hard to reason about what they are doing. This is further aggravated by Haskell's non-strictness.
A discouraging look at Haskell: "Why Is Haskell Used So Little In The Industry"[1] and "Disadvantages of Purely Functional Programming"[2]
[1] http://flyingfrogblog.blogspot.co.uk/2010/05/why-is-haskell-...
[2] http://flyingfrogblog.blogspot.co.uk/2016/05/disadvantages-o...