Scala and Haskell are both "astronaut" languages. They really encourage highly complex abstractions. They're potentially very powerful, but it's easy to get lost in the clouds.
Some people love it, because it potentially gives you an enormous amount of leverage to solve difficult problems with careful but short solutions. I forget where I heard this joke, but you give a Java programmer some specs and he'll spend 4 hours writing code, whereas the Haskell programmer will spend 3 hours and 55 minutes meditating, then write a 10 line solution.
The counterpoint is all that abstraction is often just needless busy work, that more often serves to feed the programmer's ego rather than accomplish real work. It's also not pleasant trying to figure out compiler errors that you need a PhD in abstract algebraic topology to understand.
> Some people love it, because it potentially gives you an enormous amount of leverage to solve difficult problems with careful but short solutions. I forget where I heard this joke, but you give a Java programmer some specs and he'll spend 4 hours writing code, whereas the Haskell programmer will spend 3 hours and 55 minutes meditating, then write a 10 line solution.
I prefer the "meditative" approach, because it will more often produce something readable. It looks unproductive, because there is a small number of lines produced in a given amount of time, but that's actually good. With the approach where the programmer just sits down and bangs away at the keyboard straight away, producing lines of code at uniform velocity, you end up with loads of code doing nothing, "dowork", calling "doworkimpl", stack traces 50 stack frames long where no stack frame seems to be doing any useful work. The "meditative" approach in extreme cases can produce indecipherable code with y combinators and whatnot, if your coworker is a real monk, but generally brevity seems to be a nice benchmark. All those great Haskell abstractions don't actually produce short code, it's the basic Haskell that does it. It just takes a while to arrive at such a solution, be it C or Haskell. And it's a win long-term, when you need to get back to this code to debug it. And you are going to need to get back to debug it.
See e.g. The Evolution of a Haskell Programmer[1]. It's not the great abstractions that produce the shortest code. But it is the shortest code that is the clearest.
> Scala and Haskell are both "astronaut" languages. They really encourage highly complex abstractions.
Haskell encourages very simple but highly abstract abstractions. Scala, I would agree, tends high complexity as well high abstraction level.
Both can be barriers to understanding if one is not familiar with the particular abstraction, but they are different issues (high abstraction level tends to be something you go from not getting intuitively to getting intuitively in a phase transition, while high conplexity tends to be more gradual and has a greater irreducible cognitive load.)
> Scala and Haskell are both "astronaut" languages. They really encourage highly complex abstractions
They encourage highly simple abstractions. You can put functions like `fromString` and `map` onto interfaces. No need to go via builders/generators/collections.
Dijkstra said it best: "The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise."
> It's also not pleasant trying to figure out compiler errors that you need a PhD in abstract algebraic topology to understand.
I'd much rather deal with that and become better in my profession than being woken up at night because something is on fire at runtime and I have to jump in and understand it, fix it and clean up after it.
> I forget where I heard this joke, but you give a Java programmer some specs and he'll spend 4 hours writing code, whereas the Haskell programmer will spend 3 hours and 55 minutes meditating, then write a 10 line solution.
Given the choice of reviewing and maintaining one versus the other, I’ll take unwashed Java code any day. I’m not a fan of enlightened, esoteric solutions.
Reviewing 10 lines is likely easier than reviewing 500 lines that do the same thing.
Also something that is beautiful is not necessarily esoteric (though esoteric isn't really meaningful anyways. Chinese sounds esoteric to me just like English sounds esoteric to others).
But it really comes down to experience, not the qualities of the language. A professional in both Java and Haskell would most definitely prefer a few line Haskell solution vs a massive Java solution. Just like they would prefer a few line Java solution over a massive Java solution.
Some people love it, because it potentially gives you an enormous amount of leverage to solve difficult problems with careful but short solutions. I forget where I heard this joke, but you give a Java programmer some specs and he'll spend 4 hours writing code, whereas the Haskell programmer will spend 3 hours and 55 minutes meditating, then write a 10 line solution.
The counterpoint is all that abstraction is often just needless busy work, that more often serves to feed the programmer's ego rather than accomplish real work. It's also not pleasant trying to figure out compiler errors that you need a PhD in abstract algebraic topology to understand.