[joeroot]

The first language decision is always a tough one. Having spent the past few months teaching programming to school children part time, I found that you're often weighing up a number of considerations.

1) You want a language/environment which encourages creativity and offers visual feedback as a reward. This is where Brett Victor's demonstration becomes remarkably powerful. Instant feedback is important not only for the creative process, but for maintaining interest. Some children will never enjoy programming, but for those who will, how can you excite them? Languages such as JavaScript can be a good tool for this. Children spend most of their time in an IT lesson playing web games when your back is turned. Teaching them how to make those games helps foster an interest, and JS is a good language for doing this.

2) Do you want a language which teaches the basic building blocks of CS, or do you want a language which is of practical engineering benefit? You could argue that functional languages such as Haskell encourage children to really think about what computation is, or conversely you could propose that teaching JAVA prepares them better for the real world. Both have benefits, striking a balance is difficult. Deciding what's important can often be subjective: functional or OO, strongly or weakly typed, concurrent or not? There are so many factors at play that no-one will ever agree on a perfect learning language.

3) Simplicity of syntax and semantics. Wrapping your head around abstract concepts can be a challenge when young. Maybe Haskell's functions are too unimaginable to grasp, or Smalltalk's object model too mired in strange syntax. Is a type system containing Integers and Floats meaningless to a child who still finds fractions puzzling?

4) Finally, compiling and debugging are pains which few children are going to endure without losing interest. The requirement for code to run within the browser, I believe, is paramount: no installation, no mangled libraries and dependencies. Instead it can be run on a school computer just as easily as it can at home. Codecademy has done this really nicely, and it looks like John and his team at Khan Academy have done the same.

JavaScript ticks a number of boxes in my opinion. The number of tools and libraries available means children can build interesting, visual programs. Functions as first-class citizens helps introduce students to concepts within CS, and execution within the browser is a huge benefit.

Nonetheless, I don't believe it has it all. Its object model makes the teaching of basic OO concepts a nightmare. Its untyped and furthermore its type coercion can cause strange behaviour (this IMO can be extremely damaging; things work then all of a sudden they don't). Operator overloading is odd. Its just too quirky! Personally I don't believe it is an appropriate first language. It does some things nicely, but I believe it leaves itself open to a lot of bad habits if left unchecked. Ultimately I believe a first language should enable the student to pick up any language they want thereafter, and feel comfortable within it. Primarily it should teach pure concepts, not syntax and style.

Shameless plug, but having reached my own personal conclusion I decided to write my own language for the browser as an MSc thesis (http://joeroot.com/wardrobe/try/ | https://github.com/joeroot/wardrobe). Its still far from complete, but I think it serves as a demonstration of what I feel is important in a language. I like many was inspired by Brett Victor's talk, and thats the eventual, unmet goal for the environment. But for now my focus is on the language and implementing it within the browser. It is strongly typed (but fewer types), has first-class functions alongside a pure OO model, and less syntactic pluralism to name a few of its traits.

As I said before however, programming languages are a hugely subjective topic, and I think John's project is a big step forward. Personal experience of teaching children would suggest that this looks like a far more involved experience than what is currently available.

[bryanlarsen]

You're right about some of the warts of javascript. John specifically discusses these in a different blog post. http://ejohn.org/blog/javascript-as-a-first-language/

Some of these warts are surprisingly easy to work around: for instance, they always use "===" and don't even tell the student about "==" until much later.

In other cases I just think you're wrong. For instance, I think that the prototype system is simpler and easier to understand than classical objects, while at the same time being more powerful.

[joeroot]

Thanks for the blog post, I hadn't seen that before. As I said before, these things are subjective. In my opinion, the prototype model is too far removed from the classical object model to ever teach effectively with it. Primarily, my dislike of it within a classroom comes from the fact that it demolishes any chance of real typing. I think this is a serious issue when teaching children, both from a pure CS stand point and from an engineering principles stand point. It may make life easier for some programmers, its quick and light, but for teaching I think its inappropriate. I don't believe that in using it, the student gains no real insight into either CS or engineering. That being said, I'm no prototyping expert, so any counter argument would be informative!

[ehsanu1]

A prototypal language can easily simulate classical OOP. The converse is not true. Take a look at how CoffeeScript implements classes. There are also a plethora of libraries that provide various class/inheritance models, with whatever taste of complexity you'd like.

You also want "real typing". Do you mean strong typing or static typing? In either case, the language will fight you all the way, being intrinsically weekly/dynamically typed, and so it is somewhat orthogonal to prototypes vs classical OOP.

IMO, if you want to teach type theory, you ought to be doing it in a language like Haskell anyways. Which might not the best thing to expose an absolute beginner to. ;)