Fair enough, I think your “concerns” about Haskell are totally valid and valuable feedbacks.
5 Likes
I’m familiar with the downsides of this approach too 
Still, trade-offs are everywhere, and in the end, I tend to follow my preference while being aware of all the pitfalls. I guess, I got bitten more by the lean standard libraries approach 
Regarding error messages, I take your point that “this is just one example (and most likely not the best one)” so here’s an attempt at an example that is fairer, because it doesn’t involve typeclasses or overloading of operators and numeric literals (that OCaml doesn’t support anyway). OCaml’s message is still better though.
True, I’m still a bit sour about this particularly confusing GHC behaviour
Actually, GHC error messages are even better now, as you get a stable unique error code which you can read more about online with examples and suggestions on how to fix them!
GHCi, version 9.8.1: https://www.haskell.org/ghc/ :? for help
ghci> True && [False, False, True]
<interactive>:1:9: error: [GHC-83865]
• Couldn't match expected type ‘Bool’ with actual type ‘[Bool]’
• In the second argument of ‘(&&)’, namely ‘[False, False, True]’
In the expression: True && [False, False, True]
In an equation for ‘it’: it = True && [False, False, True]
3 Likes
The ideal language for my would be a set of languages that are easily interoperable and where I can pick the complexity level I get exposed to based on the problem at hand.
C#, F# and F* somewhat go into that direction, but it’s still a long way.
Haskell seems to go the “let’s retrofit whatever we can” route. I’m not a fan of that approach.
3 Likes
Actually, in this case Haskell’s message is still better than OCaml’s:
# true && [false; false; true];;
Error: this variant expression is expected to have type bool
There is no constructor :: within type bool
We can thank OCaml’s ‘type-directed disambiguation’ of constructors for this ambiguous error.
9 Likes
In less nebulous terms? The first step to fixing problems is defining them clearly.
2 Likes
But this is how the feature shoot-out trade-off table should really end:
| lang | research potential | stability (∴ production use, comfort zone) |
|---|---|---|
| haskell | more | less |
| ocaml | less | more |
cobol (sorry couldn’t resist  ) |
none | infinite |
6 Likes
Lately I’ve been working a lot with Standard ML (so basically OCaml–) and one thing I absolutely miss is generic deriving. For the codebase I need to define basically a map function for every datatype, but without typeclasses and generic deriving I have to write all of this error prone boilerplate myself.
Related to this is newtypes, I miss them a lot. IMO deriving (via)/newtypes is by far the best haskell feature
What I like in Ocaml is that letrec is explicit, so i can easily shadow variables so the earlier assignment is out of scope in the rest of the function.
4 Likes
I’ve done so many times on various occasions. Yes, there’s progress on some fronts, but I believe that progress is often based on specific individuals (e.g. SPJ or Moritz pushing the stability efforts).
The problem is that it’s not primarily a technical issue, but one of aligning perception and defining priorities. So, software engineering approaches don’t work that well.
Some examples:
- Towards a better end-user experience in tooling · Issue #48 · haskellfoundation/tech-proposals · GitHub
- Add midstream bindist proposal by hasufell · Pull Request #61 · haskellfoundation/tech-proposals · GitHub
- https://github.com/ghc-proposals/ghc-proposals/pull/625
All these issues talk about perception, goals and priorities. These are in flux depending on the members of committes, maintainers of tools and libraries, as well as funding and clientele of some companies.
The end user experience is always an afterthought.
3 Likes
This is a great case in point of why I believe the situation is improving. I hope this doesn’t come across as impolite, because that is not my intention, but this is my perception: a couple of years ago stability was not on SPJ’s radar. He didn’t think about it and he didn’t deeply appreciate how important stability is to a language ecosystem. Now he does, moreover he is one of the biggest cheerleaders for stability! That is the outcome of a lot of challenging values-aligning work by several people (particularly the stability working group).
8 Likes
And I don’t want to sound like a groupie, but SPJ is special, not just because he’s the father of Haskell, but because he keeps surprising us with his way of reasoning, collaboration and listening to other peoples arguments.
But I’m not convinced that show’s a shift in community perception. I think some of the tension we experience is intrinsic due to the roots of Haskell and will never truly cease to exist. A language like “Go” does not have much of this tension, partly because the community perception is focused on “getting things done” almost uniformly and low appetite for experiments.
Haskell will always attract people with high appetite for experimentation and that will keep causing churn, tension and debate about stability, goals, complexity etc.
Yes, I believe the GHC SC stability document is a major step forward, which is why I’ve actively participated in those discussions.
And yet, my feeling is always that these things depend way too much on the support of individual people and the fact that we just got here after 33 years of Haskell tells a lot about (past) perception and priorities.
These things are nebulous and you really only experience them once you want to change something non-trivial. That is why I keep trying to push towards a “think about the end user first” approach. And I don’t think I’ve been particularly successful… it’s one thing to improve a library or tool yourself and a completely separate thing trying to change perception. You can’t work against the community perception for a long period of time.
So I guess my outlook is more pessimistic than yours.
8 Likes
In OCaml, there’s code generation enabled by preprocessor tools called PPX (one example is ppx_deriving). It’s not as powerful as TemplateHaskell (i.e. it doesn’t have access to types, only to syntax, so it’s more like Rust macros) but it works well in practice 
Instead of being type-directed, it relies more on naming conventions and incapsulation but I find this trade-off reasonable.
Related to this is newtypes, I miss them a lot. IMO deriving (via)/newtypes is by far the best haskell feature
OCaml actually has newtypes as well. You can define them like this:
type size = Size of int [@@unboxed]
I think that ppx deriving can leverage this to derive stuff differently. Not sure if it has been done already but I like that this can be handled on the library and the ecosystem level, removing the compiler from the pipeline bottleneck.
4 Likes
To summarize how things appear to me:
We both believe that “culture eats strategy for breakfast”. Substantial elements of Haskell’s culture make it difficult to implement sustainable improvements to user experience. That makes you pessimistic, because you know that culture is hard to change. On the other hand I’m optimistic because I believe the culture will change.
Does that sound like a fair summary?
3 Likes
What makes you think that?
Yeah.
How many years does haskell have left? This thread revived my worry of haskell becoming basically dead.
How many years does Haskell have left?
In the continuing absence of an all-new general-purpose non-strict programming language - many.
2 Likes
My concern is if that would be enough to tie enough people in haskell. What if non-strict evaluation comes to be considered ‘legacy’?
More points for lazy evaluation (2011) provides an informative example of what would be lost. But if that isn’t convincing enough, read section 1. Conventional Programming Languages: Fat and Flabby of Can Programming Be Liberated from the von Neumann Style? A Functional Style and Its Algebra of Programs (1978) by John Backus to better appreciate just how dystopian a programming future devoid of non-strict semantics would be…
3 Likes
Yea, I mean every other parts of the world is going straight into the dystopian world. What would prevent programming from following the trend?
1 Like
Welp, maybe it fizzles out, maybe it gets huge traction. It all depends on what people do, so there’s no predicting.
If it helps, I’ve been involved in a little game called Garry’s mod that exists since 2005, and was released for purchase in 2006. It was just 10$ at the time. We’re in 2024 now and that game still has a huge community. People are still making awesome things in the Lua it supports. It’s not as old as Haskell, but it defied all my expectations.
The world of politics may be bleak, but I am convinced that Haskell will live a long and happy life yet. Disagreements about direction aside, I think we have a beautiful community with wonderful people. Everyone Is brilliant in their own way. The Haskell foundation is also doing amazing work.
There’s no predicting the future, but right now I think Haskell, and its people, are doing quite alright.
19 Likes
I don’t mean to draw parallels… but if it helps, look at PHP ? 
Conspicuous failure to die, and actually some significant and sustained improvement of long-standing weaknesses. It’s possible if enough people want it.
2 Likes