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 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 *Sent: *12 июля 2018 г. 21:00 *To: *aquagnu@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 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 *Sent: *12 июля 2018 г. 19:59 *To: *aquagnu@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 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#arith... -- 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.

12.07.2018 23:48, Chris Smith wrote:

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

Yes! Even more, mature brain has such selectivity too :) We can miss something totally, because most people are thinking in traditional, standard ways (something like good known roads) and will not take new knowledge but will dispute with new knowledge and to try to ignore it or "destroy it mentally", but this is a slightly different disease ;)

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 mailto:aquagnu@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 mailto:cdsmith@gmail.com *Sent: *12 июля 2018 г. 21:00 *To: *aquagnu@gmail.com mailto:aquagnu@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 mailto:aquagnu@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 mailto:cdsmith@gmail.com *Sent: *12 июля 2018 г. 19:59 *To: *aquagnu@gmail.com mailto:aquagnu@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 mailto:aquagnu@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#arith... -- 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.