On your second point, while it seems nice to have Haskell features slowly percolate into other languages, I urge caution in thinking that's a panacea for not learning more complex languages. Haskell is greater than the sum of all it's features. It's power comes from the combination of everything working together in a very well thought-out way.

So I don't necessarily disagree with your tone, just some additional commentary from someone who knows C++, Python, Java, and Haskell equally well (and perhaps equally bad ;) ).

I doubt that seriously. Could you write a complete Mars landing project in Haskell for instance? That would impress me. That's the area where Ada excels, or (less impressive) C and FramaC. But Haskell? No way.

AFAIK there is not one serious large project written in Haskell There is not even one sophisticated Haskell IDE for daily use written in Haskell (excuse me Leksah). Tell me if I am wrong, and if there actually are really big Haskell projects. Please don't listen compilers, they are not really complex.

The only advantage which Haskell actually has in comparison to other modern languages is its greatest disadvantage. The overall rock solid type safety of the whole application makes it very difficult to add additional unpredicted functionality which requires a significant change in many modules (where on the other hand the type system helps a lot). I am very impressed by the efforts and the implementations of Haskell but the simple fact that the Cabal hell -- for the simple job of a basic package manager -- lasted for years reveals that Haskell is not that practical after all.

I invested a lot of time to learn Haskell to use it seriously but after I switched to Nim (nim-lang.org) I realized how easy I can get real productivity.

Depending on what you mean by "in Haskell", probably. You can write hard-realtime software in an embedded DSL in Haskell that gives you explicit control over timings, scheduling, etc, while still giving you Haskell's higher order features for composing your programs.

https://hackage.haskell.org/package/atom

As I understand, the company that wrote it uses it in production in automotive systems.

What is an example of an extremely complex problem that you have solved that would be vastly more harder to implement in another language.

The most powerful thing that I have noticed is the type system. When you have a complex problem, you end up breaking it up by writing a lot of functions. In case of a language with a less powerful type system, it is hard for you to string them all together to build the complete program.

But with Haskell, if you have cared to actually annotate the types, this becomes a really trivial task. It also detects flaws in your reasoning (because the result of the previous step is incompatible with the input of the current step).

So, doing this would be vastly more difficult in a language like Python or even a language with less powerful type system like C.

As is the JVM (and most languages running on it). Not only that, but the JVM has actually a proven track record of being good and performant at it. And you can solve these problems with pretty much the language of your choice.

What makes you think Haskell is well suited for it? Immutability? This is available in a lot of languages (and for languages where it's not enforced, simple programmer discipline and code reviews address it).

In my university, Programming 101 (mandatory) was (and is) Haskell. For context, there is typically a mix of experience among the class - some will have programmed seriously before, but others will have only studied math.

I had already studied Java, but I found Haskell a delightful re-introduction (it was my first exposure to functional programming) and I see its value as an educational tool.

My own first language was QBasic and I'm very happy about it. If I'd been made to suffer through parsers instead of putting colorful circles on the screen, I would think of programming as hard work, and that probably wouldn't lead to a very good career.

Computers are to computing science what telescopes are to astronomy, or something. Haskell is a great language for expressing computations, the thing CS is about. It's not meant to flip bits and observe processor states and page faults, if that is your idea of fun. That's more computer engineering stuff.

But Haskell is absolutely capable of drawing pretty circles on the screen in just a couple of lines of code![1]

[1]: https://hackage.haskell.org/package/gloss-1.9.4.1/docs/Graph...

I think Haskell is good at expressing a narrow range of ideas that, honestly, aren't all that fruitful outside the FP field. There are three main reasons why it's not a great language for expressing arbitrary algorithms:

1) It uses the pointer model instead of the integer RAM model. That leads to extra logarithmic factors.

2) Immutability. That's hypothesized to also cause extra logarithmic factors, but AFAIK that's still an open problem.

3) Non-strict evaluation. That wreaks havoc with space complexity, and compositional analysis of performance in general.

Yes, you can add epicycles to remedy these drawbacks (arrays, ST, strictness annotations). But I'd rather use a C-like language in the first place. That's closer to the "core" of CS as I understand it, and that's how most algorithm research is done.

Speaking more pragmatically, outside of CS study, most of the programs I write do not require me to write high-performance algorithms – they tend to be very I/O bound, and call out to external libraries/services for the data crunching. When I need performance (because of course I do at times), there is an amazing library that lets me write C code in Haskell[1]. The fact that some sections of my program is performance critical doesn't mean I have to write the entire program in C. I can write just the performance critical parts in C.

[1]: https://github.com/fpco/inline-c/blob/master/README.md

Out of curiosity, what kind of CS do you mostly work with? If it falls under the umbrella of Curry-Howard, then sure, I agree with you. But CS has tons of other areas like graphics, crypto, AI... The impact of Curry-Howard related ideas on these areas has been disappointingly small, IMO.

I don't think it's a good idea because it might discourage a lot of students from the get go and they might simply drop out.

It's well established today that the language you start with has little impact on your mastery of the field years later (most of us started with BASIC I bet), so you might as well start with an easy language that will get people hooked.

If the students are curious and talented, they will move on to more complex things with time.

I think this is true at a lot of universities. I would have thought if you get a random CS grad they're much more likely to have Haskell experience than Go, Ruby, Clojure, etc.

That said, scheme never managed to feel like anything other than a toy language to me, and that we were being fed problems that happened to map neatly into the structure of the language. Write a RPN calculator! Write a Tree Parser! Stuff that really isn't that much harder (but admittedly more verbose) in imperative languages.

I couldn't help but to think "Sure, these problems are easy enough, but how would I blit pixels with this language? How would I process TCP/IP packets? What would a database interface look like? How am I supposed to do error handling?"

In the end I had no desire to integrate Scheme into my day to day programming.

I think its more too alien for your typical mid- to late-career developer that hasn't seen a CS classroom for a decade or more, or your typical successful non-CS-degree-holding autodidact developer that's done well with a narrow range of industrially-popular languages, than it is too alien for your typical CS grad.

Haskell will probably not take over the world of web programming. It currently is gaining widespread adoption in a variety of interesting places, however.

If you want to write a new libssl or libjpeg, you need to use c, c++, or rust (or a few others, of course).

https://code.facebook.com/posts/745068642270222/fighting-spa...

A common "best practice" with cryptographic material is to hold it as short a time as possible (um, but garbage collection makes that hard), and zero it before releasing it (but immutability gets in the way). That means that, in a language like Haskell, you're going to leak crypto material into the free memory pool unless you break the language paradigm to prevent it. Worse, you have to remember to break the language paradigm everywhere you need to.

In C++, you'd just wipe it with zeroes in the destructor, and use RAII to make sure it's freed when you don't need it any more. In Java, you have to explicitly overwrite it on your way out of the block (maybe with a "finally" clause). But in Haskell, you can't overwrite it (yeah, you actually can, but still...)

That's just a question of teaching it to more CS students then. I don't think it's outside of the reach of the average programmer.

And yes you probably wouldn't use it to build real-time applications. But you probably wouldn't use Python to write an operating system. No language fits all use-cases.

The aim isn't necessarily widespread adoption, so much as the ability for people who know it to use professionally. It's way past merely "production ready", but reputation is a lagging indicator and so most programmers are stuck doing Java...

Since the goal is to avoid {success at all costs}, getting 25% market share is probably not possible. 1 percent would be a start.

The problem, economically speaking, is that Haskell and Clojure engineers are massively underpaid, when you consider that an average Haskeller would be Principal+ at any Java shop. That's because the Java and C++ people can create bidding wars every year and spike their salaries, whereas using a better but more niche language makes that career strategy untenable.

Haskell's laziness isn't as much of an issue as people make it out to be. You can have strictness any time you need it, so it's more akin to an opt-out model than laziness being forced upon the programmer. It is correct to observe that high-performance applications frequently have a lot of strictness annotations, and the argument can be made that high-performance Haskell (while it can be close to C in performance) isn't "idiomatic"... although that claim is true of all high-level languages (even Java). High-performance Clojure ends up being full of '^' characters for type annotations, and high-performance Haskell ends up being full of '!' characters for strictness.

I haven't found the same to be true for other languages, but in my experience the Average Haskeller is so caught up in academic exercises, technical one-upmanship, and code golf shenanigans that I'm surprised they find any time to contribute any business value at all. Having a discussion about acceptable levels of technical debt with a Haskeller is like having a discussion about acceptable levels of meat products in your diet with a vegan in a world where there are no plant foods..."everything is technical debt, and none of it is acceptable, and we absolutely can't move on until we change all relevant functors to applicatives and all nested record accesses to lenses!"

And it is squarely a cultural issue, not a technical one...it is quite obvious that Haskell is a fantastically powerful language and capable of mowing over most enterprise-y languages with ease for a very wide variety of domains. Its just that Haskellers are so nitpicky about elegance and style that they don't know how to let shit be shit and get something done when it is needed.

This obviously isn't the only case for Haskellers. Looking at JGM's github feels like looking at Dumbledore's magic through the eyes of a Muggle. It just feels that way with the average Haskeller that I work with.

The upcoming GHC 8 provides the Strict extensions which makes everything strict by default on a per-module level. That should greatly reduce the number of »!« characters.