> So it reduces to, "For any given language some things are simple and others complex. For other languages what is simple and complex differ".
Though that might be the case, what doesn't change with languages is what users typically consider as simple problems. So "simple problems" are specific to user expectations, not language features. So I think the parent's point still stands.
"what doesn't change with languages is what users typically consider as simple problems.".
If you meant users of the language (vs users of an app built with the langauge) you are wrong.
Consider Text Processing (awk vs Java , even though Java has Text processing libraries), Distributed Computation (Erlang vs C - though you can do DC with C ) , "close to the metal" coding (C vs Scheme), Continuation Passing Style (again C vs Scheme, with a different "winner"), Array processing (J vs Java), statistical code (R vs C++).
What users consider "simple problems" does change with the language used, contra what you said above.
And just like if you start with "Continuation Passing Style is easy" as a criterion , Scheme beats C, or "customized memory management" makes C win over Scheme, if you use "ease of memoizing a function" as a selection criterion you'll end up with a Lisp (over Haskell or C or Java).
Change the criterion and a different language rises to the top. As I said earlier this isn't saying much.
The point was, to make any language "win", just choose one of its strengths as a deciding criterion and take another language without that feature as a punching bag. So to make Haskell "win", All I have to do is state "monadic programming should be easy" or "effectful programming should be clearly distinguished from the pure functional core by the type system." or "Using typeclasses to structure my code should be trivial"
And Haskell "wins" by default over other languages.
That said, fwiw, in my experience the "sweet spot" of Haskell is in large + heavily algorithmic + complex code bases, where its powerful type system shines. It is very fast without sacrificing abstraction. I've built some large machine learning systems with it and I couldn't be happier.
I know other people who are building trading systems in it and they seem delighted too.
As I said, just my experience and I making no claim about how other languages are losers somehow because they have different goals.
This is what I use it for. My program ends up being as long as Perl, but as fast as C. For me, that's the best of both worlds.
For gluing libraries together, it's not the best, but in the last few months it's gotten quite good. There is hardly anything I want to do that would involve reinventing any wheels that I already have in $other_language.
"I've built some large machine learning systems with it and I couldn't be happier."
Does Haskell have good matrix libraries? That seems to be at the core of a lot of machine learning tasks, and when I briefly checked a few years back, I didn't see any Haskell native matrix libraries. I think there were LAPACK bindings, maybe.
Though that might be the case, what doesn't change with languages is what users typically consider as simple problems. So "simple problems" are specific to user expectations, not language features. So I think the parent's point still stands.