2. “By evoking the need for deep conceptual
hierarchies, the automatic computer confronts us
with a radically new intellectual challenge that
has no precedent in our history.”
“ I don’t know of any other technology covering a
ratio of 10^10”
-Edsger Dijkstra
On the education of
Computer Science
3. We need to remove the barrier to entry for
aspiring programmers.
Portability.
Computer Science is an abstract science.
Its incredibly easy to lose motivation.
The instant gratification of seeing our programs
run is what keeps us going.
Make it easy to start
4. Instant feedback.
Highly valuable for interactive learning and
playing.
People are rediscovering their power.
Interactive environments
or REPLs
5. Dreamt of a portable browser based REPL that
is accessible from any device with a browser.
We spent a good chunk of last year working on
bringing a good number of programming
languages to the browser.
The result was http://repl.it/ about 17
programming languages in one page in the
browser.
Written entirely in JavaScript under a unified
API library called “jsrepl”.
Browser REPLs
7. Why not do it like everyone else on the server?
Fast, no round-trip to the server for eval.
Security, not worry about sandboxing
languages on the server.
Scalability and availability.
Can work offline.
Hack value.
Why bother?
8. Turns out it’s a very good compilation target.
“JS is the x86 of the Web”
Brendan Eich
“We had always thought that Java’s JVM would be the
VM of the web, but it turns out that it’s JavaScript.
JavaScript’s parser does a more efficient job of providing
code security than the JVM’s bytecode verifier. JavaScript
did a better job of keeping the write once, run everywhere
promise.”
Douglas Crockford
JavaScript the accidental webVM
10. Types
Typed Arrays (Already landed in webkit and
FF).
Binary Data.
Proper tail calls.
Synchronous wait.
Continuations?
Coroutines?
Generators?
Proper tail calls?
Could be even better!
11. Most programming languages expect stdin to
be blocking.
JavaScript has a blocking stdin:
window.prompt
It’s not available in Web Workers.
It’s ugly and not customizable.
So 90’s
Case study: stdin
12. Essentially means instead of returning results
from functions you just pass them to another
function.
Also means taking control of the call stack.
Free to stop any operation at any time and
continue at a later time.
Possible Solution: CPS
17. “Part of the beauty of JavaScript’s event loop is
that there’s a very clear synchronization point for
reaching a stable state in your programs.”
Dave Herman
WHY NO
COROUTINES!?
19. Better error messages
Static code analysis
Take control of the environment.
Demo of running and debugging JavaScript in
JavaScript
So what’s next for us?
Hi. I’m Amjad Masad. I work at Codecademy and we build our educational platform on top of the web platform. I’m going to start this talk by talking about why I think computer science education needs to be rethought.And then talk about our attempt at doing that and how we use JavaScript mainly to do that.
Dijkstra had some thoughts on teaching computer science. Even though he was completely pessimistic and I don’t agree with him on the solutions he offered. But I think he explained the problem really well. [SAY QUOTES]He wrote a paper which he called “On the cruelty of teaching computer science” which both these quotes come from.He talks about how we should approach computer science as a whole new different thing which he calls “Radical Novelty” and try to approach it with a blank mind and refuse to link it to what's familiar to us.I think we indeed have a problem and a huge one. Why else would we need a ridiculous programming task like fizzbuzz to weed out the non-programmers of the computer science graduates applying to jobs which happens to be 99%.Approaching computer science like any other discipline and use the text book approach is in my opinion completely wrong. We should try to come up and experiment with new ways of teaching programming that is both intuitive and not misleading to the student.And to do that I think we should look into ourselves. Because the answer is buried somewhere deep down in us programmers.
You know how when you’re learning a new technology, framework or library you just look for the getting started part. At least I do.When you’re writing documentation for your library or framework you also put in a getting started section.This is sort of like possession is nine-tenth of the law. I think it’s human nature. Getting started and seeing yourself actually dabbling in whatever your trying to learn gives the motivation to keep going and learning.So lets make it easy and frictionless to start.The initial hurdle of installing the environment is the barrier to entry for most aspiring programmers. We must jumpstart the learning process by presenting students with a portable and bootstrapped environment. They shouldn’t have to install anything. They shouldn’t have to be dulled by much reading and instructions.Computer science is a highly abstract science and programming is an intellectual act. Talking about programs without experiencing them first hand is like talking about magic without practicing it.I would be skeptical and I will lose interest and motivation really fast.It is very easy to loose motivation while working through a huge dull text book.Remember the first time you saw your program run. The thrill of seeing the computer obey your commands. Seeing your thought process manifest in the computer?This thrill is what we need to capitalize on. We need let the students experience and internalize this thrill to keep them going even at times when it feels too hard.
Which brings me to the concept of the REPL. And I mean it in both the traditional read-eval-print-loop and in the broader sense which Any environment that can present you with means to provide it input and for it in turn to provide you instant result for that input and then the ability to repeat the operation.REPLs in the broad sense are arguably the best tool for learning a new programming language or environment.My first interaction with a REPL was the LOGO programming language and it was great I played for days.The difference between REPLs over the traditional way of studying, thinking and then writing programs is playfulness.LOGO got it right and now I think Scratch is doing a great job.The programmer should be always be in a state of play. She should not be afraid of making errors or break it. In short Experimentation is king.Lately it seems that people are rediscovering that. It started with the Bret Vector’s inventing on principle talk which in essence is a glorified REPL. And it followed by Chris Granger’s LightTable.Which I’m a big fan of.However this isn’t a new thing. This is something the smalltalk and the lisp people have had for decades now.
2 years ago I started teaching myself different programming languages. I didn’t have a laptop and had experienced first hand the problem of installing and setting the development environment on different machines.So I started dreaming of a web-based browser REPL that is accessible from anywhere and has one simple goal. Being a highly accessible REPL.The project was in the intersection of my newly found love for JavaScript and programming languages. And its not like I was a compiler hacker. So I and my friend Max spent a substantial amount of time researching and playing around with interpreters.Finally we ended up writing interpreters for esoteric languages and reusing existing interpreters for other languages with some patching. However that wasn’t enough. We needed practical languages, languages people used on day to day basis. Namely Python, Ruby, Lua etc.At first we foolishly thought we could actually write and maintain these interpreters. Until one day I stumbled upon a very cool project called emscripten by AlonAzakai of Mozilla.Which we used to translate the native interpreters written in C / C++ to JavaScript.We did all that under a unified API open source library which we called jsrepl.
Pushing the boundaries of what browsers can do. We managed to open many issues and provide many test cases for V8 and SpiderMonkey developers.
CoffeeScript borrows some nice convenience features from python and ruby and provides beautiful syntax.Roy brings some features from static functional languages to javascriptClojureScriptClojure to JavaScriptSync to async compilers. I can’t keep track of these. Write sync looking async code in JS.LLVM to JavaScript compiler.JSIL Microsoft IL to JavaScript compiler.https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
Luckily the TC39 committee which is responsible for the standardization of JS has the VM aspect of the language in mind.Typed Arrays and binary data are both essential features in a VM. Actually emscripten and in turn repl.it uses Typed Arrays if the running browser has it to emulate the Heap. Which has huge performance gains.Proper tail calls could allow compilers to emulate GOTO by using functions instead of labels. Browsers are a non-blocking environment and there is no obvious way to wait synchronously for an asynchronous event. However many programming languages aren’t designed for this kind of environment.Continuations, corotine, even generators are obvious solutions to that problem.But also going back to the second point proper tail calls with some effort could sort of solve that problem.
Much smarter people have commented on this and said that crazy control flow features will never make it in JS because it would break the execution model. (RUN TO COMPLETION).
