5 ms·

This is cool and I think Javascript is a perfectly suitable first time language, but I don't think it's ideal. Too many ways of doing things, too many code orga

This is cool and I think Javascript is a perfectly suitable first time language, but I don't think it's ideal. Too many ways of doing things, too many code organization and programming styles... it's going to be confusing for people moving beyond the courses. Still it's better than c++ or java.

dpritchett 14y ago
This could easily leverage CoffeeScript or even an education-oriented language that compiles to JS, but then the students wouldn't be able to immediately turn around and build real-world apps without additional cognitive overhead.
phleet 14y ago
Hey - I'm one of the interns that worked on this. I have my own reservations about JavaScript the language, but after seeing what John had built when I started, I believe that this is undoubtedly the right way to go. If we wanted to use another language to accomplish similar goals, the options would be: 1. Run the code on the server. This dramatically increases latency, introduces more security concerns and would dramatically increase our costs as this would inflate our server load dramatically. Really, its the latency here that makes this a no-go. As you use the number scrubber, it's re-executing several times a second, and that's just not going to work out with client-server communication (even with websockets). 2. Run a different language that compiles to JS and runs in the browser. As it stands, the overhead of doing this is also too much. It would be shipping a compiler or parser down to every client. CoffeeScript may be the most reasonable option there, but it has many of the same warts as JavaScript anyway. Any parser/compiler needed introduces an extra step in the pipeline and would inevitably reduce responsiveness. While JavaScript the language certainly has its problems, it's what it lets you do that counts here.
- chromatic 14y ago
  Run a different language that compiles to JS and runs in the browser. As it stands, the overhead of doing this is also too much. Not at all--it takes some work, but especially if most programs are less than a few hundred lines long, the overhead is far less than you think!
joeroot 14y ago
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/ http://joeroot.com/wardrobe/try/ | https://github.com/joeroot/wardrobe 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.
mechanical_fish 14y ago
Nothing matters more than ubiquity. Let me channel the old Steve Ballmer for a moment: Ubiquity! Ubiquity! Ubiquity! I learned to program with BASIC in the 80s. Somehow I survived, though old-school BASIC was like a clay tablet compared to JS. (Get this: No functions, all global scope. It was like assembly language but with less power.) But BASIC was awesome because every microcomputer had it built in. Walk up to a machine and start typing BASIC. I must have typed in the same program 20 times. I remember spending 45 minutes with this random Wang terminal thing at the local library, trying to find BASIC. I never did, of course, so I remember concluding that it was probably broken. I'm still not sure I was wrong, exactly. ;)

dpritchett 14y ago

This could easily leverage CoffeeScript or even an education-oriented language that compiles to JS, but then the students wouldn't be able to immediately turn around and build real-world apps without additional cognitive overhead.

phleet 14y ago

Hey - I'm one of the interns that worked on this. I have my own reservations about JavaScript the language, but after seeing what John had built when I started, I believe that this is undoubtedly the right way to go. If we wanted to use another language to accomplish similar goals, the options would be: 1. Run the code on the server. This dramatically increases latency, introduces more security concerns and would dramatically increase our costs as this would inflate our server load dramatically. Really, its the latency here that makes this a no-go. As you use the number scrubber, it's re-executing several times a second, and that's just not going to work out with client-server communication (even with websockets). 2. Run a different language that compiles to JS and runs in the browser. As it stands, the overhead of doing this is also too much. It would be shipping a compiler or parser down to every client. CoffeeScript may be the most reasonable option there, but it has many of the same warts as JavaScript anyway. Any parser/compiler needed introduces an extra step in the pipeline and would inevitably reduce responsiveness. While JavaScript the language certainly has its problems, it's what it lets you do that counts here.

chromatic 14y ago
Run a different language that compiles to JS and runs in the browser. As it stands, the overhead of doing this is also too much. Not at all--it takes some work, but especially if most programs are less than a few hundred lines long, the overhead is far less than you think!

joeroot 14y ago

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/ http://joeroot.com/wardrobe/try/ | https://github.com/joeroot/wardrobe 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.

mechanical_fish 14y ago

Nothing matters more than ubiquity. Let me channel the old Steve Ballmer for a moment: Ubiquity! Ubiquity! Ubiquity! I learned to program with BASIC in the 80s. Somehow I survived, though old-school BASIC was like a clay tablet compared to JS. (Get this: No functions, all global scope. It was like assembly language but with less power.) But BASIC was awesome because every microcomputer had it built in. Walk up to a machine and start typing BASIC. I must have typed in the same program 20 times. I remember spending 45 minutes with this random Wang terminal thing at the local library, trying to find BASIC. I never did, of course, so I remember concluding that it was probably broken. I'm still not sure I was wrong, exactly. ;)