In my opinion, the first CS course in school (and to some extent
the math and physics courses as well) should aim, more than teaching specific
skills or knowledge, to transmit to student the beauty of programming _itself_
(respectively math and physics).
The student should be able to perceive the feelings of wonder and enlightenment
that rise from solving a challenging problem, or to understand some
previously obscure phenomenon, by applying math and reasoning.
This objective is well suited for a CS course because students can also
be initially motivated by the promise of learning something really useful.
Haskell is particularly well suited for this task, not because the student would
necessarily be able to perceive the beauty of Haskell itself, but because
Haskell does not obscure, and in some ways enhance, the beauty of
programming as a whole. In contrast, when first CS courses start with
convoluted or low level languages such as C or Java, students loose
the point of everything, overwhelmed by pointers, useless OOP,
obscure syntax, low-level technical details. Wonder and enlightenment
become pain and frustration.
Btw, if you want to _also_ teach computer architecture in addition to
programming, I think that is best suited to a different part of the course
and does not need to be interleaved with learning programming, so
I wouldn’t bother with C and the like. Or better, you can explain C
as a tool to better understand computers and operating systems, but
after they’ve learnt how to program, not as a tool to learn programming.
Using Haskell (specifically some kind of concepts, e.g. equational reasoning)
will also make easier for students to see the connection between math
and programming, making them more motivated to learn math as well.
To me, your choice to start the CS course by teaching Haskell is
a wonderful choice and your students will thank you in a few years.
Go ahead!
> — Olaf
Greetings,
Nicola
It depends on the age of the students and the math they already know.
I don’t have specific examples of in-class exercises or things like that.
However, the point is that writing Haskell code you can
often come up with shorter or more elegant solutions by
manipulating terms exactly as done in elementary algebra.
Starting from a 10lines function and coming up with
a simple and readable oneliner is fun and rewarding,
and shows one of the possible connections to math,
especially if you can make them reason about types,
in which case the task becomes very similar to theorem
proving than to algebraic manipulations alone.
Another possible connection arise when you teach things
such as the Monoid typeclass.
Even if students have not been exposed to abstract
mathematics, they can still appreciate the usefulness of
abstracting similar operations (addition in this case) to
being able to uniformly reason about apparently different
concepts. Abstraction is the core of mathematics, but is
also a fundamental concept in programming, of course,
so you’re implicitly teaching two things at once.
> Regards,
> Torsten
I kindly disagree. 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.
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.
That’s also why I don’t agree with the math curriculum in high-school
(only elementary algebra, trigonometry and basic calculus, at least here in Italy).
If a student doesn’t go to college or studies something non-scientific
(or even some low-math science), he’ll never see an abstract
mathematical concept (see e.g. groups) in all his lives, thus living
forever by completely ignoring what math is all about.
(and this is really connected with the record-low public trust in science
that we are suffering).
My reasoning applies to any functional language, not just Haskell.
If you don’t want to worry with the type system, you can turn to
Common Lisp or Racket. I started with scheme and it was indeed pretty
amazing.
> 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?
>
> Haskell also requires quite a bit of intelligence and perseverance to
> master. So unless your kids are all geniuses I would not recommend it.
>
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.
> Python would by my language of choice. You won't have to worry about low
> level stuff or typing, but can still write those step by step programs.
>
Python would be also my first choice if I had to choose an imperative language,
that’s granted.
> Cheers
>
> Silvio
Cheers,
Nicola
Hi,
In my opinion, Haskell is a terrible first language to learn.
It has a very complicated type-system, and it's restriction to purely
functional programming does not convey very well how (current) computers
work. Current computers work by you giving them an step by step guide
what to do. This I think is what should be at the base of any
beginners-programming course.
Python would by my language of choice. You won't have to worry about low
level stuff or typing, but can still write those step by step programs.
That’s also why I don’t agree with the math curriculum in high-school
(only elementary algebra, trigonometry and basic calculus, at least here in Italy).
If a student doesn’t go to college or studies something non-scientific
(or even some low-math science), he’ll never see an abstract
mathematical concept (see e.g. groups) in all his lives, thus living
forever by completely ignoring what math is all about.
(and this is really connected with the record-low public trust in science
that we are suffering).
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.
> 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.
> 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.
Cheers
Silvio
> 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.
> 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.
> 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.
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Personally, I would try to start with something with immediate feedback. Introduce functions on numbers with the REPL, something they are presumably familiar with. Then go on to show how we can use and manipulate things other than numbers in exactly the same way.
A fun place to go quickly is the diagrams package. Just like we can have functions and operations with numbers, we can have them with shapes. Hook it up to something like IHaskell so that students can render shapes in the REPL just like they did with numbers. It'll take some setup: IHaskell is a pain to install and you might want to create your own wrapper around diagrams to have simpler types.
But I think it would be worth it: you'll get an intuitive example of functions producing more complex outputs with immediate feedback in the form of pictures, made up by putting shapes together. The students will be able to produce designs that look cool by experimenting with the library while getting the hang of Haskell.
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Now, how is this different from a comparison of the amount of effort
spent on the relevant libraries?
..where the difference is still enormous, like multiple orders of magnitude.
--
с уважениeм / respectfully,
Косырев Серёга
--
“And those who were seen dancing were thought to be insane
by those who could not hear the music.”
– Friedrich Wilhelm Nietzsche
On Sat, Aug 29, 2015 at 12:26:04AM +0300, Kosyrev Serge wrote:
> Now, how is this different from a comparison of the amount of effort
> spent on the relevant libraries?
>
> ..where the difference is still enormous, like multiple orders of magnitude.
That's exactly the point (amusingly illustrated in this comic [1]).
I must say the suggestion to use `diagrams` (made by Tikhon Jelvis)
makes really sense: it's fun, it's easy/quick to set up, it's powerful.
https://www.cs.utexas.edu/users/EWD/OtherDocs/To%20the%20Budget%20Council%20concerning%20Haskell.pdf
On Fri, Aug 28, 2015, 23:17 M Farkas-Dyck <stra...@gmail.com> wrote:
> Python is a good language if you want an imperative language
Python is a good language if you want pain.
Probably better to use the more exact language in the original.
On Sat, Aug 29, 2015, 00:57 M Farkas-Dyck <stra...@gmail.com> wrote:
On 28/08/2015, Mike Meyer <m...@mired.org> wrote:
> Probably better to use the more exact language in the original.What more exact language?
"Imperative language" instead of "pain".
It's no more exact. I'm not disputing whether Python is an imperative
language; I'm rather disputing whether it's good ☺
On 28/08/2015, Mike Meyer <m...@mired.org> wrote:
> I have to disagree, and for much the same reason that Nicola does: these
> details matter if you're teaching computer architecture, but not if you are
> teaching programming. At least, not in an introductory course.
Here I fully agree.
If one is teaching computer architecture, assembly is uniquely appropriate.
If one is teaching programming, Haskell is non-uniquely appropriate,
but I would not consider Python appropiate.
Haskell is a better imperative programming language than Python. It
has mutable state where needed, in the ST monad.
Beautiful is better than ugly.
Explicit is better than implicit.
Haskell is better than Python.
On Sat, Aug 29, 2015, 01:50 M Farkas-Dyck <stra...@gmail.com> wrote:
Haskell is a better imperative programming language than Python.
Except that teaching beginners to write imperative code in Haskell is doing both them and Haskell a grave disservice. If you're going to do that, you ought to pick a language that was designed for it.
Il giorno 28/ago/2015, alle ore 22:17, Alberto G. Corona <agoc...@gmail.com> ha scritto:Exactly Mike,
The destruction of pedagogy and innovation by Rationalism:
http://nocorrecto.blogspot.com.es/2014/05/the-destruction-of-pedagogy-and.html
In my opinion, the focus on beauty of the language is simply inappropriate for a teaching language. An experienced programmer or mathematician might enjoy transforming a ten line function into a simple one with only one line, but I think for many students, it won't be so interesting to transform one working program into a nicer one. Not all people see simplicity of math as a beautiful thing, for them a simpler formula is not much more interesting than an equal more complicated one. I believe that you need some experience to appreciate simplicity and elegance.
Just my two cents,
Benno
How very nicely put! Alexey's statement had bugged me quite the same,
and your formulation is just about exactly what I would have said.
--
с уважениeм / respectfully,
Косырев Серёга
I understand what you’re trying to get at, and why this simplified
example is supposed to stand in for a more general, complex, elaborate
situation. However, I believe a more thorough, explicit description
of this sort of situation may reveal such a simplified example is not
adequately representative of the general problem.
The function to sum up all the naturals up to N is most commonly
written thus, in Haskell and Python:
sumToN n = n * (n + 1) `div` 2
def sum_to_n(n): return n * (n + 1) / 2
No loops, no worries about stacks, no recursion or induction or
intuition about computational processes supporting complexity.
Depending on the student’s background, this may be the first solution
that is attempted for the given problem. The general point of this
observation is that it often happens in computer programming that a
programming-oriented solution is accidentally complex because it goes
for a brute-force approach that ignores important qualities of the
underlying problem space that enable solutions that avoid complexity.
Granted, alternate strategies with lower complexity are not always
available, and sometimes you do need some kind of aggregation. These
are likewise easy in Haskell and Python:
sumToN n = sum [1..n]
def sum_to_n(n): return reduce(add, range(n + 1))
It’s noteworthy that both of these solutions have terrible performance
for somewhat similar reasons unless you specifically go out of your
way to avoid the issue. In GHCi, asking for the value of this sum at
one billion seems to produce a very large list, and it depletes my
machine’s RAM quite quickly. Doing the same in Python also creates a
very large list and likewise starves my machine for memory.
These issues can be solved by both programming environments.
If you test the Haskell bit in a simple complete program compiled with
`-O2`, it takes a while to run with a billion as `n`, but it does
finish in a few seconds without consuming memory in proportion to `n`.
GHC can optimize that list away, but you need to be aware of the issue
to understand how to solve it: some things fuse away in compilation
and stay around in interpreted code.
The Python bit isn’t magically optimized by CPython 2.7. However, the
recommended approach to these issues is to use `xrange` instead, which
returns a generator object that produces results lazily, one by one,
much like the list in Haskell, and `reduce` doesn’t need to hold onto
the whole list of results since it’s actually working like a strict
left fold. In fact, new versions of Python altogether skip the old
list-building `range` function, and their `range` is Python 2.7’s
`xrange`, so this issue goes away if you can use a new version of the
language. Perhaps a future version of GHC may fuse lists away in
GHCi.
You may now argue that summing is only meant to stand in for some more
elaborate computation, so this whole deal misses the point. I agree.
In fact, this is a much more fair comparison:
sumToN n = foldl1 (+) [1..n]
def sum_to_n(n): return reduce(add, xrange(n + 1))
Indeed, both of these fail on empty ranges, and they have similar
performance if the Haskell version is compiled with optimisation.
There are many variations of these solutions, such as enabling them to
use 0 as the result for empty summations or expressing them in terms
of different primitives. But indeed these are two somewhat
representative ways of expressing processes that need to perform
aggregation of results over a range, both expressed in ways that are a
natural fix **for the problem** as specified, ignoring issues related
to language communities, preferences and idioms.
You may now argue that the point of your original statements is
precisely about idioms. I don’t know what the recommended, dominant
idiom may be for any given portion of the Python community. I suppose
it largely depends on the background of the sample you take from the
Python community. This StackOverflow answer seems to suggest some
people recommend `reduce` with lambdas for this sort of construct, yet
others recommend `for` loops:
http://stackoverflow.com/questions/13840379/python-multiply-all-items-in-a-list-together
Perhaps this solution is even more representative of common idioms in
a way that is somewhat less specific to the toy problem of performing
simple summations:
sumToN n = foldl1 (\ x y → x + y) [1..n]
def sum_to_n(n): return reduce(lambda x, y: x + y, xrange(n + 1))
Do these perform the same as before? I don’t know about the one in
Haskell; I didn’t check. I suppose it may possibly depend on whether
tests are performed in GHCi or compiled code with various optimization
options. It should be absolutely trivial for the GHC simplifier to
reduce both into the same code, but does it work quite the same in
GHCi? I don’t know. The Python versions do appear to differ a bit in
performance according to comments in that StackOverflow post.
In any case, loops are also a common, recommended idiom in Python:
sumToN n = runST $ do
s <- newSTRef 0
for_ [1..n] $ \ i -> do
modifySTRef' s (+ i)
readSTRef s
def sum_to_n(n):
s = 0
for i in xrange(n + 1):
s += i
return s
I’m pretty sure most Haskell novices wouldn’t write this one, just as
I’m pretty sure most Python novices wouldn’t use `reduce`. These two
behave more or less the same: they don’t leak space. They would leak
space if you didn’t know you had to use `xrange` instead of `range`,
or if you didn’t know you had to use `modifySTRef'` instead of
`modifySTRef` (although the specific mechamism for the space leak is
not precisely the same, but the causes are quite similar). Python
solved this issue in recent versions by getting rid of the one that’s
arguably less useful; in Haskell, there are warnings in the
documentation: https://hackage.haskell.org/package/base-4.8.1.0/docs/Data-STRef.html#v:modifySTRef
I must confess I fell into the trap when I wrote the Haskell version:
I forgot to use `modifySTRef'`. I also fell into the `range` trap a
few days ago writing Python 2.7 at work; the only reason I avoided it
today is that it bit me very recently. I’ve been programming for 16
years and writing Haskell and Python for work and leisure for about 6
years.
My point is that understanding these subtleties is important and you
cannot be an effective software engineer if you don’t know how to
avoid these sorts of pitfalls in whatever technology and style of
expression you pick. Moreover, a modern, “multi-paradigm” language
will support and provide incentives for various styles of expression
to varying degrees, and they come with code quality and performance
tradeoffs that are not necessarily clear-cut.
Programming is tricky and abstractions leak. Python uses fewer
abstractions than Haskell, and Haskell’s abstractions (of comparable
abstractness) leak less, and that’s how they both manage to be used
successfully by practitioners. I prefer Haskell, because in the long
run, having abstractions leak less allows me to compose taller towers
of abstraction, which gives me more power as a software engineer.
Whether this is relevant for a novice depends, I suppose, on where the
novice wishes to go.
Note: Some imports and pragmas may be necessary to make these examples
work in their respective languages. I believe it’s fair to leave them
out in all cases; providing a batteries-included default namespace is
a significant issue, but it’s somewhat independent of these musings.
Going through your email I was wondering which one is "more beautiful" for each case and it's clear that Haskell is optimized for functional style and Python for imperative style, and things in their respective opposite styles look clumsy. That's it, end of story.
Michał
Original Message
From: Manuel Gómez
Sent: Saturday, August 29, 2015 2:30 PM
To: Silvio Frischknecht
Cc: Haskell Cafe
Subject: Re: [Haskell-cafe] Why Haskell is beautiful to the novice
> They would leak space if you didn’t know you had to use `xrange`
> instead of `range`.
I might have run into that as well. I don't really know Python that
well. It is a problem I never came across in any imperative languages,
so I foolishly assumed it wouldn't happen in Python either. But as you
said they seem to have fixed it. Still, I would think the python space
leak is relatively easy to spot and explain. Esp. when compared to
tail-recursion modulo Constructors.
Silvio
I am not entirely sure what is the real meaning of "optimized for" in
your phrasing, but what is clear is that Python 'optimizes' without
being asked for, e.g. when you use generators in order to cascade some
sequence processing, as in the "sum" example, nothing wrong happens,
while lazy lists reserve several nasty surprises. -O2 optimization, or
explicit strictness annotations (and BangPatterns) are there, and may
save our lives, but "what is clear" is that teaching Haskell as a
practical language usable for large data, is quite non-trivial, and its
beauty for novices evaporates quite fast.
[This 'sum' example under GHCi will be problematic anyway].
I taught Haskell so long, that I became reckless, and my students got a
rather tiresome project based on Haskell OpenGL. It was a massacre, a
general unhappiness... Two years later my dept. decided to abandon
advanced Haskell (with monads of all sorts), and left only the 2nd year
introduction to functional programming, its style and algorithmics. I
couldn't defend the "professional Haskell" too hard, the gap between the
elementary FP, and the "true stuff" became too big in the context of our
curriculum.
Just my three cents...
Anyway this threads degenerates a bit, and begins to contain statements
I find dubious, or too restricted, e.g.,
> A beginning student doesn't need to learn OOP in
> any kind of depth.
etc.
I suspect that the author of this phrase was not yet born when I began
to teach programming... Now, I would never dare to declare what a
beginning student *really needs*. Programming is a kind of art, a
fragment of culture, a vision of the world, and the Pursuit of Happiness
is different for different people. Linguists (or historians, etc.) may
*begin* with logic/relational programming, biologists with objects, and
mathematically-oriented yougsters, with FP.
Or not.
Jerzy Karczmarczuk
/Caen, France/
The print statement has an EFFECT. That effect is not a
*SIDE* effect. Here's the definition of "side effect":
1. A subsidiary consequence of an action, occurrence,
or state of affairs; an unintended secondary result.
2. An effect (usually for the worse) of a drug or other
chemical other than that for which it is administered
In the case of the little program above, the fact that
output is sent to a destination is neither subsidiary,
nor unintended, nor secondary, nor other than that for
which the program was constructed.
I flatly deny that "UNINTENDED ... results" are what
attracts ANYONE to programming. Effects, *YES*;
*side* effects, NO.
I could compare Java and COBOL; it wouldn't make Java worthy.
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
On 31/08/2015, Mike Meyer <m...@mired.org> wrote:
> Of course not. There are application areas for which COBOL is clearly
> superior to - and hence more worthy than - Java. Or Haskell.
Name one.
Dear cafe,
please correct me if questions like this should not go via this mailing list.
Presumably everyone on this list agrees that Haskell stands out as a beautiful and pleasant language to have. The recent nitpicking and real-world problems like cabal hell don't change that. However, statements supporting Haskell's beauty usually involve: "In Haskell it is so much clearer/easier/faster to ... than in another language." That is, the beauty of Haskell presents itself to those who can compare it to other imperative or not strongly typed languages that one learned before Haskell.
My question is, for what reason should anyone not acquainted with any programming language find Haskell beautiful? Maybe it does not look beautiful at all to the novice. The novice can not draw on the comparison, unless he takes the effort to learn more than one language in parallel. The novice likely also does not have the mathematical background to see the beautiful correspondence between the language and its semantics. (My reason to love FP is because it is executable domain theory.) One might argue that it is not the language itself that is beautiful, but rather the concepts (data structures, algorithms, recursion) and Haskell does a great job to preserve their beauty into the implementation. Do you agree?
Disclaimer: I am about to start teaching a first course in computer science in secondary school. I can teach whatever I want, since this is the first CS course the school ever had. I want to teach beautiful things. I love functional programming. I need not start teaching programming right away. But I am reluctant to expose the pupils to something whose beauty escapes them completely.
-- Olaf
Le 01/09/2015 08:59, Mike Meyer a écrit :
> There are application areas for which COBOL is clearly superior to -
> and hence more worthy than - Java. Or Haskell.
Perhaps.
But could you
1. Tell us which application areas? Concretely.
2. Explain what does it mean "superior"?
3. Explain WHY Java is inferior?
On 31/08/2015, Mike Meyer <m...@mired.org> wrote:
> Of course not. There are application areas for which COBOL is clearly
> superior to - and hence more worthy than - Java. Or Haskell.
Name one.
Current computers work by you giving them an step by step guide
what to do. This I think is what should be at the base of any
beginners-programming course.
I could go on. It's a long and depressing list.
It's a very common habit for people not only to learn to live with the artificial constraints of a system but to accept and respect them. It's a form of Stockholm Syndrome. I can remember, in 2001, a Visual Basic programmer colleague dismissing the concept of the UNIX virtual filesystem as an abstract, fragile and unnecessary conceit. As if his drive letters were not themselves virtual, but somehow more real. As if they were still necessary, despite the fact that his PC would not let him remove a floppy disk that was in use. Stockholm syndrome persisting long after the kidnappers had departed.
(I don't mean to be rude, but your belief that imperative programming is more obvious and natural seems like much the same syndrome.)
Worse, remembering the details of these obstacles is seen as expertise, not an encumbrance. Such people are resistant to change not only from habit but because removing the constraints makes their "expertise" obsolete, which is a threat. If they had ever learned an appreciation of the bigger picture, the removal of the old system would simply give them the opportunity to learn how those grander concepts are expressed in the new one.
Start teaching the bigger concepts. They are actually less complicated than the trivial and transitory implementation details. The brighter students will learn the system details for themselves, anyway (often better than the teacher). The less bright will not truly understand the complexities of the system if they have to learn their details before they learn the concepts and will be severely hampered when they are confronted with those concepts later on.
Would anybody ever suggest that physics students should be required to be taught the workings of the internal combustion engine before they can learn that speed = distance / time? I don't think so. And yet the equivalent is regularly insisted upon with regard to computer science.
The minds of teenagers are, in many cases, more flexible, imaginative and receptive than they will ever be again. Teaching them not to think is a terrible waste.
Now, I want to go back to one thing you said:
"Current computers work by you giving them an step by step guide
what to do."
Current computers require you to request memory before you create a data structure and release it when you are done. When is the last time that you, as a Python coder, had to call malloc or free? How often have you had to take care to safely dereference a pointer? If you think Python is a step-by-step guide to a computer, there's an army of C-coders over there who would like to have a word.
I see no logic to saying that Python's set of constraints and freedoms represents "real computing" while Haskell's do not. The only thing of which Python can be said to be definitively representative is GvR's personal preferences and eccentricities.
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.
Haskell also requires quite a bit of intelligence and perseverance to
master. So unless your kids are all geniuses I would not recommend it.
Python would by my language of choice. You won't have to worry about low
level stuff or typing, but can still write those step by step programs.
And again, nothing stops someone making a nice structured language whose compiler targets COBOL.