<div dir="ltr">I'd like to opine that I personally like that our types are getting more honest in reflecting how things work, and that even the impredicativety hack might be on track to being a userland expressible construct in a later ghc release (if my fuzzy understanding of the impredicative subsumption work thats in progress is correct and that it actually pans out )<div><br></div><div>i like the bike shed, i dont care how we mix the paint colors, as long as it doesn't create more confusion</div><div><br></div><div>cheers </div><div>_Carter</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 9, 2016 at 9:43 AM, Joachim Durchholz <span dir="ltr"><<a href="mailto:jo@durchholz.org" target="_blank">jo@durchholz.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Am 09.02.2016 um 14:20 schrieb Rustom Mody:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
And one of the big<br></span>
regresses is the illusion that a *single *language that spans the spectrum<span class=""><br>
from beginner learning to serious software engineering is a neat idea: a<br>
grand unified/universal language.<br>
</span></blockquote>
<br>
It is still an ideal.<br>
Not because it is such a good idea. I'm pretty much unconvinced whether that is the case or not.<br>
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.<span class=""><br>
<br>
> Such a language already exists -- C++.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
An earlier generation called it PL-1.<br>
</blockquote>
<br></span>
No no no.<br>
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.<br>
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.<br>
So the two languages and the universal-easy-to-learn camp do not share any design goals.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
FP in ACM Curriculum 2013<br></span>
<<a href="http://blog.languager.org/2015/06/functional-programming-moving-target.html" rel="noreferrer" target="_blank">http://blog.languager.org/2015/06/functional-programming-moving-target.html</a>><span class=""><br>
spells out this – omnibus language – and such fallacies in more detail.<br>
</span></blockquote>
<br>
He claims this, but he does not back that up with any arguments.<br>
There's only reference to authority (Peter Naur).<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
And as regards prior art regarding the benefits for multiple close but<br>
different languages for teaching, one could see the multiple teachpacks<br></span>
<<a href="http://docs.racket-lang.org/teachpack/index.html?q=" rel="noreferrer" target="_blank">http://docs.racket-lang.org/teachpack/index.html?q=</a>> of Scheme/Racket<span class=""><br>
And even closer to home, helium<br></span>
<<a href="http://www.open.ou.nl/bhr/heeren-helium.pdf" rel="noreferrer" target="_blank">http://www.open.ou.nl/bhr/heeren-helium.pdf</a>> is a haskell expressly<span class=""><br>
designed to make teaching easier by not over-generalizing types<br>
</span></blockquote>
<br>
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.<br>
<br>
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.<br>
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.<br>
<br>
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.<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br></div>