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

[Carter Schonwald]

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 )

i like the bike shed, i dont care how we mix the paint colors, as long as
it doesn't create more confusion

cheers
_Carter

On Tue, Feb 9, 2016 at 9:43 AM, Joachim Durchholz <jo at durchholz.org> wrote:

> 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.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160209/c44a0456/attachment.html>