[Haskell-cafe] New type of ($) operator in GHC 8.0 is problematic

[Joachim Durchholz]

Am 09.02.2016 um 14:20 schrieb Rustom Mody:
> And one of the big
> regresses is the illusion that a *single *language that spans the spectrum
> from beginner learning to serious software engineering is a neat idea: a
> grand unified/universal language.

It is still an ideal.
Not because it is such a good idea. I'm pretty much unconvinced whether 
that is the case or not.
It is an ideal to approximatet because learning a new language, and 
learning it well enough to use it in anger, is such a huge investment in 
time and effort, and we simply cannot afford to build a language for 
each domain. Also, we cannot do so because there isn't even a consensus 
what the domains should be, and I'd expect such a list to be a moving 
target anyway.

 > Such a language already exists -- C++.
> An earlier generation called it PL-1.

No no no.
C++ was never meant to be easy to learn. It was intended to be easy to 
learn for C programmers, but C wasn't intended to be easy to learn, it 
was intended to be efficient on PDP-series computers with a 
non-optimizing compiler.
PL-1 wasn't intended to be easy to learn either - it was hoped it would 
be, but the primary goal was to include as many language features as 
humanly possible, in the hopes of creating something powerful.
So the two languages and the universal-easy-to-learn camp do not share 
any design goals.

> FP in ACM Curriculum 2013
> <http://blog.languager.org/2015/06/functional-programming-moving-target.html>
> spells out this – omnibus language – and such fallacies in more detail.

He claims this, but he does not back that up with any arguments.
There's only reference to authority (Peter Naur).

> And as regards prior art regarding the benefits for multiple close but
> different languages for teaching, one could see the multiple teachpacks
> <http://docs.racket-lang.org/teachpack/index.html?q=> of Scheme/Racket
> And even closer to home, helium
> <http://www.open.ou.nl/bhr/heeren-helium.pdf> is a haskell expressly
> designed to make teaching easier by not over-generalizing types

I think the link you gave is making a subtly but fundamentally different 
point: That to teach programming, you need a different and simplified 
language to get the core points across. There are actually good points 
to be made in favor of that approach.

However, this is about making Haskell the working language easy to 
learn. The demography includes people who know what a type system is, 
what a function is, and they will usually even know what a side effect 
is and already avoid that if they can.
Tell them that they see a simplified prelude and they will want to see 
the real one. Show them the real one and they will run away, flailing 
and scream, just as ten years ago, you could achieve the same effect by 
mentioning monads.

If the type system is starting to make it hard to learn the language 
well enough to use it professionally, or to even understand what the 
professional library writers did and why, then the type system has 
become too difficult.