God what's the compilation time of millions of line of Haskell?

> In 30 years time, I'm sure the industry will be extolling the virtues of algebraic data types, purity, immutability and referential transparency.

There are plenty of industrial languages with algebraic data types and immutability. Not as many as I would like with purity but I doubt it will take 30 years.

> God what's the compilation time of millions of line of Haskell?

It wasn't compiled with GHC, but a proprietary compiler. It could typecheck the entire lot in a few minutes (in parallel) which was usually enough to detect breaking changes.

> There are plenty of industrial languages with algebraic data types and immutability.

A few do, yes, certainly not plenty. But defaults matter and immutability means more than just "const", e.g. persistent collections.

> Not as many as I would like with purity but I doubt it will take 30 years.

Given that big tech is delivering languages that are basically the same as Algol 60, I honestly think it will take at least 30 years.

http://cowlark.com/2009-11-15-go/

Purity is nice and clear to reason about. But when you want the last drop of performance, having a place to overwrite memory as you invoke a SIMD algorithm or cast and do bitwise stuff is invaluable from a performance point of view, whether we like it or not.

Such a function can still be pure on the outside. This is real (state) encapsulation, not the encapsulation sold to you by OOP vendors.

Ok but there was discussion about Haskell so I was sticking to that... of course if you can have functional as an extra without preventing imperative in the low level then you can apply the best of both worlds.

Haskell let's one write fast imperative code when needed or call C functions.