A 5 year old can do bit of Python programming :). Start terminal, type Python and then type 2 + 3. Watch them getting kick out of typing huge numbers and Python spitting out the answers.
Rather, I'd reword it. Just getting faster feedback from coding to some response is not enough. It has to be to the desired responses. (So, for example, it doesn't help to get faster feedback to syntax highlighting.)
But more seriously, I strongly disagree about Haskell being anything like Python is for kids.
The level of abstract reasoning that Haskell requires for more than just adding two numbers is not easy or intuitive for kids. Following step-by-step instructions is intuitive. Writing Python line-by-line is easy to understand by analogy to a list of instructions. Eventually they can start using functions when they're comfortable, but you're very unlikely to succeed in teaching a five year old about typeclasses, monads, functional purity, effect systems, or anything like that. The thing with Haskell is that you have have to know almost all of that to do anything useful from day one. Even something as simple as drawing lines on the screen.[1]
Don't be ridiculous by suggesting Haskell is just the same to five year olds as Python.
[0]: https://wiki.haskell.org/Zygohistomorphic_prepromorphisms
> The thing with Haskell is that you have have to know almost all of that to do anything useful from day one.
Okay, then how is adding two numbers together useful? If that's Python programming then the equivalent counts as Haskell programming. You are setting a double standard for what you expect a 5 year old to be doing.
Even then, tell me which of these is simpler and more clear:
def double(x): return x + x
double x = x + x
let f x = x + x
That "actual code" I mentioned can involve drawing on the screen, which as I pointed out in painstaking detail, is not going to be explainable to a five year old with Haskell code. That kind of visual feedback is incredibly important to concrete learners, which everyone is at that age.
Haskell and Python are not similar with regards to "conceptual/semantic complexity." At all.
I have used Haskell in the past. I understand it. Someone who hasn't reached Piaget's "formal operational" stage is not going to understand it. Piaget's theory isn't perfect, but it is normally true that people start out at a very concrete level.
As I said, don't be ridiculous.
Here is some super complicated Python code that kids can learn a lot from:
from turtle import *
color('blue')
forward(200)
left(90)
forward(200)
left(90)
forward(200)
left(90)
forward(200)
left(90)
done()
Please, show me what my above code looks like in Haskell, since it's so comparable in complexity.
I don't think you have an appreciation for what goes into learning programming. You've probably been doing it for far too long at this point, without thinking back to the early days.
Why are you so defensive about Haskell in the first place?
Books like The Haskell School of Expression have been teaching functional programming using simple graphics in Haskell for a long time. Need I remind you that the entire concept of a Turtle comes from Logo, which is Lisp minus parentheses?
For the record, those kids do not look like 5 year olds. Once someone is old enough to do abstract reasoning, I think Haskell might be a workable choice, if carefully taught. More often than not, it's more likely to drive them away than something simpler. That article appears to be using some web interface which was designed to hide all of the monads... I think that's a splendid way to get started. The students aren't writing their "main" function. Unfortunately, the website linked from that website is down, so it's hard for me to verify.
You haven't been listening to anything I have said, so I'm going to stop. I wish you would reflect on software education, because however well-intentioned, starting with Haskell is likely to drive many more people away than it would help to show what they can accomplish and inspire them.
In fact, as far as teaching 5 year olds is concerned, I'd go with Lisp rather than Python.
λ length [1,2]
2
λ length [1,2,3]
3
No problems here. Now tuples:
λ length (1,2)
1
λ length (1,2,3)
No instance for (Foldable ((,,) t0 t1)) arising from a use of ‘length’ In the expression: length (1, 2, 3) No instance for (Num t0) arising from the literal ‘1’ The type variable ‘t0’ is ambiguous Note: there are several potential instances: instance RealFloat a => Num (Complex a) -- Defined in ‘Data.Complex’ instance HasResolution a => Num (Data.Fixed.Fixed a) -- Defined in ‘Data.Fixed’ instance forall (k :: BOX) (f :: k -> *) (a :: k). Num (f a) => Num (Alt f a) -- Defined in ‘Data.Monoid’ ...plus 7 others In the expression: 1 In the first argument of ‘length’, namely ‘(1, 2, 3)’ In the expression: length (1, 2, 3) No instance for (Num t1) arising from the literal ‘2’ The type variable ‘t1’ is ambiguous Note: there are several potential instances: instance RealFloat a => Num (Complex a) -- Defined in ‘Data.Complex’ instance HasResolution a => Num (Data.Fixed.Fixed
A quick googling does not tell me how to find the length of a tuple. The closest thing to an answer is, 'you probably don't actually want to do that'.
1. If you gave this response to the hypothetical five year old, you will simply make them cry, and then they will quit programming.
2. If you give this response to the hypothetical fifty year old, they will feel you're hemming and hawing to cover a weakness in the language rather than giving a more direct and honest answer.
In regards to (2), I'm not literally a 50 year old learning Haskell, but I am an adult teaching himself how to program for the first time, starting with Standard ML. Perhaps if you have a few minutes you'd be willing to let me elaborate on my complaint and check my understanding?
The main issue i'm imagining is modeling homogeneous data vs heterogeneous data. With tuples, the types of data are encoded in the tuple type, and are known at compile time. In SML its a product, so a tuple of length 2 is a different type then one of length 3. Presumably this is what you meant by 'not really collection types'?
Tuples of different lengths having different types is, if i'm understanding things correctly, the key point for this discussion. If i want to write a mythic 'tuple length' function in SML, it has to be generic enough to work on something of type a->int, and a* b->int, and a* b* c->int, etc... And so it has to make sense for any 'a->int (where 'a is a variable), which is to say it can't know anything about the structure of tuples! Is this reasoning correct?
Assuming it is, you can see why I called those answers 'hemming and hawing'. This is clearly not something put in the language based on some prior logic about indices or collections or fixed sizes...nobody wants to not be able to write functions from arbitrary tuples; it appeared as a design trade off in order to access type information at compile time. It also is not specific to the length function.
A second strategy to model heterogeneous data is to use a homogeneous collection like a list but then use a sum type to introduce heterogenity. This makes a different trade off: the types are the same for different sizes so we can write functions easily (including length!) but the types are the same so we've lost access to compile time information, and the class checks from the sum are done at run time.
Thanks for taking the time to read this far and correct my misconceptions!