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

Sergiu Ivanov sivanov at colimite.fr
Thu Jul 12 21:25:10 UTC 2018


Hello Chris,

Thus quoth  Chris Smith  on Thu Jul 12 2018 at 22:48 (+0200):
> I've seen plenty of students as old as 12 to 13 who literally cannot
> see whether there's a comma in an expression, or whether a word is
> spelled "ie" or "ei", without extreme measures like covering the
> surrounding text.

This sounds a lot like symptoms of dyslexia.  Are you talking about
students _without_ such disorders?

-
Sergiu


Thus quoth  Chris Smith  on Thu Jul 12 2018 at 22:48 (+0200):
> This is a good question, and I think it depends on your goals.
>
> If your goal is to inspire interest and attract children to programming,
> then you are best served by making it obvious what can and can't be done,
> and making it very difficult to make a mistake.  Some visual languages are
> very good at this, and Scratch, for example, is a good example.  Going even
> further, Scratch and similar languages are often used in situations where
> the students can do literally anything, and *something* interesting
> happens, inspiring that spark of excitement and feeling of "I did that!"
> This is a magical moment, and it can change lives.
>
> On the other hand, building new skills is the point of educating.  Avoiding
> the need for new skills means avoiding the opportunity to learn.  Children
> often still struggle with precise perception.  I've seen plenty of students
> as old as 12 to 13 who literally cannot see whether there's a comma in an
> expression, or whether a word is spelled "ie" or "ei", without extreme
> measures like covering the surrounding text.  Their brain just skips over
> these concerns.  Of course, they struggle in mathematics, and also basic
> language and communication.  Once again, one can avoid the problem and try
> to help them to be successful without needing that skill, which a visual
> language is great at.  But of course, they ultimately do need the skill in
> order to communicate in the first place!  So there's also value in placing
> them in an environment where they need to learn it.  When making this
> decision, though, it's important to focus on skills that are truly
> necessary, and not (for example) remembering what order to write "public
> static void main" in their Java programs.
>
> On Thu, Jul 12, 2018 at 2:16 PM Paul <aquagnu at gmail.com> wrote:
>
>> Wooow! Yes!!
>>
>> But today there is serious competition (Smalltalk, Python; I planned
>> Scratch – but it’s for children of 7-9 years). I thing you are good teacher
>> 😊
>>
>> Btw, what do you think: what is better – textual programming or visual
>> programming for children? For me, Labview/G was insight in 90s 😊 Today
>> there is Luna language – it’s visual too. IMHO visual programming better
>> illustrates ideas/concepts, or?
>>
>>
>>
>> *From: *Chris Smith <cdsmith at gmail.com>
>> *Sent: *12 июля 2018 г. 21:00
>> *To: *aquagnu at gmail.com
>> *Subject: *Re: [Haskell-cafe] Investing in languages (Was: What is
>> yourfavouriteHaskell "aha" moment?)
>>
>>
>>
>> Perhaps you mean something fun and visual like this?
>> https://code.world/#PhFFj32Bx0FcpQvvoVJW0xw
>>
>> Or this? https://code.world/#PO1BKCj-kA9ztKKnE7rOueA
>>
>>
>>
>> These are written in the simplified variant of Haskell that I teach, which
>> uses a custom Prelude that skips type classes and other advanced features,
>> uses rebindable syntax to simplify types (for example, you'll see Number
>> instead of Int, Double, etc.), and automatically provides graphics
>> functions that work in the browser.
>>
>>
>>
>> On Thu, Jul 12, 2018 at 1:54 PM Paul <aquagnu at gmail.com> wrote:
>>
>> Hmm, Chris, thanks for answer. Interesting. I was surprised when I first
>> learned that someone somewhere is teaching the children to Haskell, but if
>> you say so – then it’s possible and may be it’s good! 😊
>>
>> Sometimes children don’t like right things, but like fun. So, I though
>> that more preferable to show them some bright demo: UI, graphics, some
>> simple games, databases, to rise the interest, you know – this feeling of
>> first code. First “wooow! It works!!!” 😊 Haskell, for me, looks
>> pedantic, not for fun. May be I’m not right, I have not such experience.
>>
>>
>>
>>
>>
>> *From: *Chris Smith <cdsmith at gmail.com>
>> *Sent: *12 июля 2018 г. 19:59
>> *To: *aquagnu at gmail.com
>> *Subject: *Re: [Haskell-cafe] Investing in languages (Was: What is
>> yourfavourite Haskell "aha" moment?)
>>
>>
>>
>> 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.
>>
>>
>>
>>
>>
> _______________________________________________
> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180712/2069461d/attachment.sig>


More information about the Haskell-Cafe mailing list