I think that Haskell2010 could be the last Haskell standard. Modern Haskell has diverged to such a degree that it seems to be (almost) impossible to define a common standard. Even if they would, as long as there a over 100 language extension (increasing over time) there will be developers using them. Take a look at C++20, I think it's obvious that C++ is beyond repair at this point in time, even if you wouldn't add any more language features.
Sure, a new Haskell standard would allow for more compiler competition and that's a good thing, but it cannot fix the language. I think what we really need is a new language that picks all the good parts from Haskell, but has a very small syntactical core. Something like Go, but purely functional. You might say Rust or Elm. But Rust is too performance oriented and already quite big, hence more like a C++ replacement. And Elm is too domain specific and maybe a bit too simple (lacks ad-hoc polymorphism).
So maybe a general purpose Elm like language with ad-hoc polymorphism, but not as complex as Purescript, with a GC that compiles to binaries and WASM with a standard code formatter and very conservative regarding new language features, just like Golang.
> Modern Haskell has diverged to such a degree that it seems to be (almost) impossible to define a common standard. Even if they would, as long as there a over 100 language extension (increasing over time) there will be developers using them. Take a look at C++20, I think it's obvious that C++ is beyond repair at this point in time, even if you wouldn't add any more language features.
I disagree. C++20 is a standard, even if it is ugly and terribly complex it is being implemented by three separate compilers. And look at Javascript. The attention given to it is starting to show, making the language neater than in the past. The task is not straightforward but the point of the article is that there is absolutely no manpower ready to do it. I think that a few dedicated people could do the work well.
I sometimes think that not enough people appreciate the tough spot that C++ was in around 2008 and just how far it has come since then. The additions via evolution to C++ have been far beyond what I would have thought possible. IMO, the 3 year release cycle is just the right pace.
Yes, I know the language has become complicated and there are still a lot of rough edges. But it's a model of change that's worth emulating.
The C++ additions surrounding move constructors, rvalue references increased my practical complexity understanding the language (although mostly grokked now). Everything else seemed the good kinds of additions; just having a new, more palatable way to express things. If you go deep in templates, some stuff might add complexity, but overall a lot of new stuff just vastly shortcuts the crazy turing complete stuff people were doing anyway
> I think what we really need is a new language that picks all the good parts from Haskell, but has a very small syntactical core. Something like Go, but purely functional.
I'll wait patiently until people start asking for more language features, like the ten thousand last times... every widely used language ends up converging towards at least C++-levels of expressiveness (Java, TypeScript, Go, Python with static types, Caml, etc... you name it) because it turns out that those features are actually needed.
I agree that they all converge on a standard set of features, but I disagree that the features are needed.
You could get everything done with Javascript's prototype system that you wanted done with classes.
You can get everything done with Go's interfaces (and a bit of boilerplate for the edge cases) that you can do with generics.
The problem is that people come to this language from other languages, and have expectations that this language is basically the same as the other language they already know (and if not, why not?). There's a constant pressure on languages to conform to a single set of "known good" conventions [0]
The unusual languages are needed because we need that diversity, but they are never going to be "mainstream" until/unless a Java dev can learn them inside 3 months without challenging any of their assumptions about programming.
[0] the classic is Erlang vs Elixir - Erlang is "weird", Elixir is "awesome"
> You could get everything done with Javascript's prototype system that you wanted done with classes.
> You can get everything done with Go's interfaces (and a bit of boilerplate for the edge cases) that you can do with generics.
by that logic why don't you just use lisp for everything ? it's been there since 1958 and you can also get everything done with it, including reimplementing yourself a Go- or Js-like DSL if you allow yourself a Racket.
The truth is, your "get everything done" actually does not include everything, because "writing less boilerplate" is not only a feature, but one of the most important ones. Boilerplate is unambiguously bad and a place where terrible bugs hide - any time you can replace it by something with much less chances of bugs, such as a language feature, you should (and I'd argue it's professional malpractice to chose not to when you have the option).
Boilerplate isn't necessarily evil. Imo, repetitive boilerplate is where the problem comes in. I.e. it's not a bad thing that every HTTP app has an almost-the-same way to start the HTTP server. It is a bad thing when you're writing almost the same code but with different types 37 times.
There's a seemingly inevitable tradeoff between complexity and bugs. Low complexity tends to lead to repetitive, simple, avoidable bugs. High complexity leads to unique, hard to reason about bugs.
I find the preference for simple vs complex code has to do with what kind of bugs programmers want to troubleshoot. Some prefer simple and repetitive bugs, others prefer fewer, more difficult bugs.
On that note, I remember when Borland released BIDS 1.0 and was doing with the preprocessor what Go, reinvented almost 20 years later.
Or using Eclipse EMF to read UML interchange files generated from Rational Rose and generate the boilerplate for Java applications, before generics and compiler plugins were a standard Java feature.
When languages aren't feature rich, someone will eventually start writing that boilerplate, hence why //go:generate exists, despite the fact that Go people telling writing boilerplate is not a problem.
disclaimer: I'm a haskell user who has worked professionally with F# for 3 years
I don't think something like native F# would fit Haskell's niche: Haskell's type system is a lot more complete (and complex, by virtue of cruft and necessity) than F#'s. F# also has a lot of object oriented stuff which Haskell doesn't have (by design, i'd say). Maybe purescript or idris if they had more mature native compilation targets would come closer, but even those are strict (while Haskell is lazy) and laziness by default is a big thing that sets Haskell apart from virtually any other language in use.
F# is too restrictive and poor in terms of types and syntax. OCaml would make a better option as the Haskell "successor". Though, personally I don't think it will ever happen.
Maybe what the standardization committee should do, make some of these extensions (the often used and less controversial ones) into the language standard?
Sure, a new Haskell standard would allow for more compiler competition and that's a good thing, but it cannot fix the language. I think what we really need is a new language that picks all the good parts from Haskell, but has a very small syntactical core. Something like Go, but purely functional. You might say Rust or Elm. But Rust is too performance oriented and already quite big, hence more like a C++ replacement. And Elm is too domain specific and maybe a bit too simple (lacks ad-hoc polymorphism).
So maybe a general purpose Elm like language with ad-hoc polymorphism, but not as complex as Purescript, with a GC that compiles to binaries and WASM with a standard code formatter and very conservative regarding new language features, just like Golang.