Dear cafe inhabitants, first of all thanks for all the elaborate answers. I did not imagine to trigger such an avalanche of opinions. Let me try to steer away from the Python/Haskell comparison (as comparison is what I wanted to avoid) and collect some points I found important in the past discussion. 1. There is a difference between teaching how the machines we call computers work and how computers are used to solve problems. What is computer science? The science about computers or science that can be executed on a computer? Both subjects are beautiful, in different ways. Haskell, I used to think, was designed explicitly to abstract away from how its programs are actually run on the hardware, to the point where one can not even tell (and care) what order certain computations are executed in, or whether they are executed at all. Therefore Haskell is certainly not the best language to teach about the mechanics of computing. Similarly, there are practical problems that may be more difficult to express in a functional language, because the problem may be already of a sequential, mutable, effect-full nature (e.g. writing an adventure game). 2. For teaching purposes, the remark that kids want something they can show off to others should not not be under-estimated. In order to quickly obtain showable results, one might choose a toy language (DSL?) or program robots. For this reason I considered HTML as a first introduction to syntax, even if it is not a programming language as such. But there exist syntax checkers and one can create and view HTML on every modern device. By the way, is there a live CD (not DVD) image that contains the Haskell platform and some other languages? 3. One skill/revelation that I want to install in the students of both math and CS, and which I believe Haskell is more suitable for than imperative languages, is the fact that in mathematics and computer science there are no hidden layers/aspects, no mysteries. Everything is composed of smaller, simpler parts. And if one wishes, one can unwrap one layer and look inside. How deeply one wishes to look inside is a question of audience, then. The layering might consist of recursion, classes, objects. It does not matter. The important point is that the path to a solution must descend the layers to the simple parts. This is in contrast with arts and humanities, where one can study the same piece of art, the same novel, several times in a lifetime and each time discover new things, and probably still miss others which require expert education. Mergesort, once grasped, is there in all its completeness, simplicity and beauty, there is no further interpretation. As others have remarked in this discussion, the `no mysteries' only applies to the denotational semantics, but not the operational semantics in case of Haskell. For assembler it might very well be the other way around. Thanks, Olaf