On Fri, Aug 28, 2015 at 11:07 PM, Silvio Frischknecht <silvio.frischi@gmail.com> wrote:

> I kindly disagree.

This being a haskell mailing list, I expected that :)

> If the focus is to teach computer architecture, you are
> not teaching programming. If the focus is on programming, then it should
> focus on the conceptual aspects of programming, not on computers.
> A course at school should of course teach both, but in my opinion not
> concurrently. There’s no point in teaching something implicitly by using
> the teaching of something else.

It's more about algorithms than computer architecture. An imperative
program very clearly describes algorithms; Haskell does not. Unless you
have a very good understanding of things like lazyness, non-strictness
and tail recursion, you wont know what happens when and how.

«It is easier to optimize correct code than to correct optimized code.»
--Bill Harlan

More heretically I draw your attention to Bob Harper's SECP

«everyone knows that algorithms as welearned them at school are irrelevant to practice. »
http://www.cs.cmu.edu/~rwh/papers/secp/secp.pdf

In my view «CS is the science of algorithms» is one of those memes that has held back our field because it underplays data.

And traditional programming pedagogy (aka imperative programming) is wrong because it emphasizes code at the cost of data

> We are not talking about undergraduates here, but kids or teenagers.
> Think about which is the reason why you are teaching something to them.
> It is not to teach some specific skill or to make them be advantaged in
> future undergraduate courses. It is to teach them to reason.
> Functional programming is just more reasoning than technicalities.

All the more reason not to teach Haskell. To CS undergraduates you might
teach your favorite programming paradigm. They can take it, and they
will also learn others anyway. To teenagers who might never learn
another language, it is not a good idea.

>> There are also a lot of very basic data structures that can simply not
>> be used in purely functional code like hash tables, pipes or random
>> access arrays.
>
> Why do you think that manipulating arrays is a better skill to teach
> to kids than manipulating linked lists?

What about double linked lists then. Most updatable data structures are
just clumsy in Haskell.

I see a lot of naivete in this thread (not just your claims).

Every programming language will do some things niftily and (many) others clumsily.

And when as teachers we consider the importance of Law of Primacy we need to carefully consider the order in which we introduce material.

A case could be made [as Donn Cave does below] for assembly.
From my pov getting Hindley-Milner intuitions right should take primacy over updatable data structures.

Likewise the best language of your choice will be based on what you consider primary.

How do we come to an objective evaluation of that??? Dunno...

> There was a nice article on reddit of a parent that was in progress of teaching
> Haskell to his/her 10-years old, and it was a great experience. I cannot find it anymore.
> Remember, kids (motivated kids, at least) are way smarter than what school
> usually seems to think.

Some kids are smarter, some less so. In secondary school you should have
a curriculum that most students can follow.

Just to be clear I'd be pleasantly surprised if someone can show haskell is a good thing for school children.

I dont know what is... Depends on the school and the child I guess??

On FP finally (50 years after Lisp!) making it to the abc level of CS-curricula:   http://blog.languager.org/2015/06/functional-programming-moving-target.html

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe