Haskell for a New Decade [pdf]

> "The barrier to entry for GHC development remains impossibly high"

Could not agree more. I've put in a couple merge requests to the ghc Haskell compiler, and it's very difficult to even figure out what's going on, nevermind make a meaningful contribution.

Functional programming. Meaning solving large swathes of a problem with (->) alone. Sadly a lack of GC does have downsides in this respect.

> Instead of Haskell we should be thinking of programming language research and how to get the best ideas into our mainstream languages.

I see a lot of this happening in Kotlin and Rust (not too mainstream, but clearly more mainstream than Haskell). Also FB putting it weight behind Reason/OCaml clearly shows the movement. To be fair: sdiehl did mention in the preso that copying these concept over to other languages takes 10-20 years.

> How do we make immutability easy and ergonomic and get rid of nulls in C#?

The problem here is: you dont. To some extend you have to get these things right from the start. The father of null, Tony Hoare, now considers it his $1B mistake. Why? Because this is hard to fix.

> Can we have guarantees in our program.

Sure you can. C# gives you some typing guarantees. Now pattern matching switch statements (with exhaustivity checking) combined with sum types are coming: this will help! But the guarantees that Haskell (and Idris/Elm/PureScript) bring are next level, and impossible to replicate in a language that does not encode purity in the type system nor has type classes.

When will Haskell get a different spokesperson? Stephen isn’t effective in this role. These posts have jumped the shark to the point when I see a big Haskell post on HN and see stephendiehl.com it’s just time to tune out.

For Haskell to succeed, it has to move away from rigid commitment to various pure functional paradigms and move to eager execution by default. But Stephen does not help this, just preferring to instead dig in more on expecting the reality of the rest of the world to change itself to accommodate the strictures under false pretense that the strictures are parochially better.

Haskell’s real failure to launch is not because of complex tooling issues between cabal & stack, not because of a big mess of compiler pragmas to get basic String functionality, not due to complexity of understanding monads or type classes.

The problem is that the stated benefits of pure functional programming are not actually benefits at least not when writing business software.

The slides (rather arrogantly) say we’re at the blood-letting and leeches stage of software. Well claiming Haskell is a solution is like inventing epicycles to explain orbits or elevate alchemy to a science. It wastes everyone’s time with artificial complexity substituted for advanced capability.

I can't speak for everyone but for me the type system is not what made Haskell difficult. I loved it. What made it difficult was laziness. I'd find myself always trying to reason about execution (even though most of the time you probably shouldn't). Laziness might even be fine in a world built around it, but for a language to be practical it has to interface with systems that are not designed that way (numerous external libraries developed in strict languages). This isn't to say laziness is bad, or even worse - just that for a typical engineer switching from strict languages it's a large mental tax.

The problem is while you can adapt and bolt on some functional programming techniques to existing languages like C# - to bring the power of the type system to an existing language is all but impossible. There are a few areas it has started to sneak in, like nullable types. But from my naive perspective you just can't bolt on an expessive type system like that, let alone a dependently typed one.