[Haskell-cafe] Investing in languages (Was: What is your favourite Haskell "aha" moment?)

Thu Jul 12 17:00:09 UTC 2018

Oops, readding the mailing list.

On Thu, Jul 12, 2018 at 12:59 PM Chris Smith <cdsmith at gmail.com> wrote:

> I'll answer this, since I have been teaching Haskell to children for six
> years or so. :)
>
> I think it's important to distinguish between Haskell AS USED in most of
> the community, and Haskell as it COULD be used.  I agree that you don't
> want to teach the first of those to children.  But Haskell is still a great
> teaching choice, mainly because GHC is so configurable that you can create
> the environment you want, and just build it with a Haskell compiler.  With
> GHC plugins, this is becoming even more true, but it already arises from a
> combination of (a) very lightweight and intuitive core syntax in the first
> place, (b) great support for custom preludes, and (c) the RebindableSyntax
> extension, and the fact that so much syntax is defined in terms of
> desugaring.
>
> If you're seriously talking about teaching children, then your concerns
> about web frameworks and such are a bit silly.  (Unless by "children" you
> meant mid to late teens and after, in which case this becomes relevant.)
> "Advanced" type features are also not particularly relevant (though there's
> some fuzziness about what counts as "advanced"; for instance, I've recently
> decided it's better to teach GADT syntax as the only option for defining
> algebraic data types, even though I never expect most students to take
> advantage of the extra power of GADTs.)
>
> The main concern I have with F#, though, is that the semantics are far too
> complex.  It has all the power of a functional language, but none of the
> semantic simplicity. If students already struggle with compositional
> programming (and they do), they struggle even more when the simplest way to
> understand what's going on -- namely, substitution -- is taken away from
> them.  If you're going to teach a computational model based on sequencing
> actions on a global state (the state being the screen, network, etc.), then
> you might as well include mutable variables in that global state, and you
> might as well teach Python, which will at least be more intuitive, if not
> simpler.
>
> On Thu, Jul 12, 2018 at 7:46 AM PY <aquagnu at gmail.com> wrote:
>
>> I am afraid that it can lead to flame again, but F# has super-capacity:
>> you can check measuring units, type providers, computation expressions,
>> active patterns, static/dynamic types constraints, constraints on existing
>> method, etc... It's clean, borrows some ideas from Haskell, some are
>> original and Haskell borrows them (but with worse implementation). IMHO for
>> children teaching to FP F# is the best. Even more, currently C# also has a
>> lot of FP features (
>> https://github.com/dotnet/csharplang/blob/master/proposals/patterns.md#arithmetic-simplification
>> -- is not it super easy and beauty?). Rust is more low level: you should
>> think about memory "management", OOP has some problems... And serious
>> argument for children teaching: salary trends (joke sure) :-) But you can
>> compare salary in F# and Haskell, for example - people often choice
>> language after check current salaries in the market. Also F# is more
>> focused on realistic tasks and business value. It lacks performance, UWP
>> yet (but in progress)... To feel how F# is sexy compare Web application
>> written in Websharper and in any Haskell framework. Haskell is beauty but
>> I'm afraid its fate unfortunately will be the same as one of Common Lisp,
>> NetBSD, etc - it's ground for ideas and experiments and has disputable
>> design. Also it's more-more difficult to teach children to Haskell than to
>> F#...
>> IMHO is general to teach FP is more easy than to teach OOP if FP is not
>> Haskell (some language which targets more eager/efficient/dynamic/real
>> goals instead of abstract types playing).
>>
>> 12.07.2018 13:28, Vanessa McHale wrote:
>>
>> I wouldn't say Rust has a large capacity for FP. I am not familiar with
>> F#. The thing that makes FP infeasible in Rust is not the lack of purity
>> but rather the fact that affine types make it difficult to treat
>> functions as first-class values.
>>
>>
>> On 07/12/2018 01:40 AM, Brett Gilio wrote:
>>
>> Tony,
>>
>> I am curious on your attitude towards multi-paradigm and ML-like
>> languages. I agree that functional programming is easily the better of
>> the bundle in many forms of application logic and elegance (which is
>> why I have come to love Scheme and Haskell), but do you see any room
>> for those languages like F# or Rust which have large capacities for FP
>> but are either functional-first (but not pure) or a hybrid?
>>
>> Brett Gilio
>>
>> On 07/12/2018 01:35 AM, Tony Morris wrote:
>>
>>   I used to teach undergrad OOP nonsense. I have been teaching FP for 15
>> years. [^1]
>>
>> The latter is *way* easier. Existing programmers are more difficult than
>> children, but still way easier to teach FP than all the other stuff.
>>
>> [^1]: Canberra anyone? https://qfpl.io/posts/2018-canberra-intro-to-fp/
>>
>>
>> On 07/12/2018 04:23 PM, Joachim Durchholz wrote:
>>
>> Am 11.07.2018 um 16:36 schrieb Damian Nadales:
>>
>>
>> I speak only from my own narrow perspective. I'd say programming is
>> hard, but functional programming is harder.
>>
>>
>> Actually it's pretty much the opposite, I hear from teachers.
>>
>>
>> Maybe that's why Java replaced Haskell in some universities
>> curricula
>>
>> The considerations are marketable skills.
>> A considerable fraction of students is looking at the curriculum and
>> at job offers, and if they find that the lists don't match, they will
>> go to another university.
>> Also, industry keeps lobbying for teaching skills that they can use.
>> Industry can give money to universities so this gives them influence
>> on the curriculum (and only if they get time to talk the topic over
>> with the dean). This aspect can vary considerably between countries,
>> depending on how much money the universities tend to acquire from
>> industry.
>>
>>
>> https://chrisdone.com/posts/dijkstra-haskell-java. For some reason
>> most programmers I know are not scared of learning OO, but they fear
>> functional programming.
>>
>>
>> Programmers were *very* scared of OO in the nineties. It took roughly
>> a decade or two (depending on where you put the starting point) to get
>> comfortable with OO.
>>
>>
>>     I think the reason might be that OO concepts
>>
>> like inheritance and passing messages between objects are a bit more
>> concrete and easier to grasp (when you present toy examples at least).
>>
>>
>> OO is about how to deal with having to pack everything into its own
>> class (and how to arrange stuff into classes).
>> Functional is about how to deal with the inability to update. Here,
>> the functional camp actually has the easier job, because you can just
>> tell people to just write code that creates new data objects and get
>> over with it. Performance concerns can be handwaved away by saying
>> that the compiler is hyper-aggressive, and "you can look at the
>> intermediate code if you suspect the compiler is the issue".
>> (Functional is a bit similar to SQL here, but the SQL optimizers are
>> much less competent than GHC at detecting optimization opportunities.)
>>
>>
>> Then you have design patterns, which have intuitive names and give
>> some very general guidelines that one can try after reading them (and
>> add his/her own personal twist). I doubt people can read the Monad
>> laws and make any sense out of them at the first try.
>>
>>
>> That's true, but much of the misconceptions around monads from the
>> first days have been cleared up.
>> But yes the monad laws are too hard to read. OTOH you won't be able to
>> read the Tree code in the JDK without the explanations either.
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>>
>>
>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180712/274a3d1b/attachment-0001.html>