SICP translated to JavaScript
comp.nus.edu.sg
Sections of Structure and Interpretation of Computer Programs translated to JavaScript by Professor Martin Henz with executable examples.
comp.nus.edu.sg
Side note: the navigation is really irritating. The back button only works sometimes, because it's replacing content without doing some kind of pushState. So you have to hunt for links.
Another side note: Sean Burke and Piers Cawley have ported some of mjd's excellent book Higher-Order Perl to JavaScript. This might be even better, because both Perl and JS have C-like syntax hiding some impressive functional capabilities. I wish someone would finish that, but I guess few people even know about HOP, these days.
"Sweet.js brings the hygienic macros of languages like Scheme and Rust to JavaScript. Macros allow you to sweeten the syntax of JavaScript and craft the language you’ve always wanted."
That isn't JavaScript.
It depresses me how much of HOP is irrelevant in Python because they have proper iterators. And how few Perl programmers realize that these days the lack is a major omission in the language.
Are there any particular resources you would recommend for someone like me to get going quickly with python? In particular ones that specifically address the type of blind spot you mention?
The iterator section is http://docs.python.org/2/tutorial/classes.html#iterators. Here it is quickly. Suppose that an object has a __iter__ method which will return something with a next method that will, when it has exhausted the iterator, call StopIteration. Then all native looping constructs can loop over that object and it will just work.
If you call a function that internally calls yield and nowhere calls return, then you get back a generator, which is an object with those methods.
There is also syntax to construct such generators inline without even an explicit function.
All of the closure based looping stuff in HOP which supports potentially infinite streams? It is all built in!
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...
sub new_iter {
my $i = 0;
return sub {$i++}
}
my $iter = new_iter();
while(my $number = $iter->()) {
say $number;
}
Re: Underscore... there is a Perl port - http://vti.github.io/underscore-perl/
Apparently this is changing with ES6.
Btw, I'm curious as to why the HOJ book didn't get taken down? I checked and the HOP book is not released under a license that allows for derivative works. I'm curious because I've made an interactive version of SICP (using scheme) and I can't find any other books to do this to because no one releases books under permissive enough licenses.
What syntax is there to teach?
Or "Linux Device Drivers: Javascript edition" ?
Can we just accept that JS is not for everything?
My software has a fairly large chunk of code which is a gardening expert system. I'm hesitant to call it AI because it's so dumb, but it's along those lines. It knows things like "If you live in Phoenix and it's April, you should wait to plant your lettuce until September".
It's useful to have it on the client, when you're in the garden and there's no connectivity, or when you tweak your settings and don't want to have to download a bunch of "conclusions" from the server. It's useful to have it on the server so that the server can send emails, pre-cache HTML for faster loading pages, etc.
If my server is written in Ruby (which is is right now) then I have to re-implement that entire system twice. That's double the code. It feels gross. And I can't help but feel like most web-apps have code like this that could be shared between the client and the server.
It's true that the ideas in the book transcend programming languages, and that the first 3 chapters could probably could be covered in JavaScript with little modification, if a little clumsily. But rewriting the 4th and 5th to include sections on parsing JavaScript would be quite challenging, and furthermore JavaScript does not have as simple semantics as Scheme, so there would be a loss of a great deal of elegance and beauty. The metacircular Scheme interpreter can run itself, which would be harder to do in JavaScript since its core is more rich and Scheme's core: objects, methods and so on complicate it quite a bit.
All that being said, I still think lots of great concepts behind SICP can be explained with JS as the main language instead of scheme. If it can help some people to feel at home and quick the book, that's just great. They'll most likely like it and then read the real SICP for the other parts.
Lastly, I must agree that when I read SICP the first time, it was also to learn scheme as a side-effect. But it's not necessarily everyone.
"It's as if -- as if the key to the treasure is the treasure!"
i think the (new) book is valuable in that it might reach some people who have some mental block about just wanting to know what they "need" to know and think that all they need to know is javascript, but for those who just like learning? start scheming. it's freakin' awesome.
I was careful in picking my words. I don't think Javascript is suited to express kernel level system control. There are many windows managers written in dynamic languages (lua, python, lisp). GDE = Desktop Environment ? I don't know if computing Package Manager dependency graphs be that slower if written in js, probably.
Beside the point was not about micro benchmark performance but about separation of concerns and reuse, more than a third of ls is output formatting.
http://www.codinghorror.com/blog/2007/07/the-principle-of-le...
(Note that the author intended this to be humourous/exaggerated - Some people took exception though.)
(please don't do the latter... or is it too late?)
Edit: I say this as a web developer. I feel like it's often forgotten that Ruby and Javascript aren't the only languages worth using.
For me the only place for JavaScript is on the browser.
For anything else, there are endless languages to choose from.
The Americans have taken over and the Americans have, based on their own linguistic experience, decided most people can only handle one spoken language and one programming language.
For some of us, we can handle six programming languages and be fine.
For "average" people, they're lucky to get one programming language, so it was decided to fad-hype-hipster promote One Language To Rule Them All for fronted, backend, sideend, middleware, topware, bottomware, programming your embedded system, programming your car, scripting your operating system, and programming your blender.
Look on github for how many people write shell scripts in ruby because they don't know how bash works. You can find the same over-syntax'd-programming-environment-as-shell-script with node too. We're the exceptions. They can't handle the truth.
to get? I'm not sure what that means.
"I don't get why people live on geologically mapped flood plains."
> Look on github for how many people write shell scripts in ruby because they don't know how bash works.
I have seen this happen in a company I used to work for, when new system engineers came on board, but in this case it was Groovy.
As someone who has done this (and who currently works in C), I will say only that shell scripts translated to Ruby can be a lot easier to read and maintain than those written in bash... if I get to the point where I'm having to pipe to more than two of awk/sed/grep I will generally just write it in Ruby, because then my mother could read it. YMMV though. In every other sense I agree with you entirely, and I think the proliferation of JS rewrites of things that work in actually-designed languages is appalling.
If you're just iterating over a directory and checking some files, that's great shell script territory. If you're making a launcher script for another program to set the environment, check directories, fix permissions, and run pre-flight checks, that's great for shell script.
But, sometimes we end up with feature creep. You start out with "Well, this shell script just has to parse some CSV and insert into sqlite" then before you know it, it also has to check another pre-existing DB for redundancy checks or constraints, then you're 100 pages into the Advanced Bash-Scripting Guide trying to make Bash do something that would be a six liner in Perl 4.
The benefits of over-programming bash scripts is extensive portability though (if you make sure you aren't using features only in very late version of the shell).
Unfortunately, I very frequently see this in shell scripts...
ls $SOME_PATH | awk...
Average programmers aren't working on shell scripts, client side code, and server side code at the same time.
Honestly, HN too has hordes of people who can't write FizzBuzz. No reason to feel elitist for anybody really.
I have been coding since 1986 and only learned about it via the usual HN hiring discussions.
A lot of so-called experts aren't capable of doing more than copy other people's solutions. Fizzbuzz offers a simple but new problem for candidates to solve.
I took the scheme version of the class and learned a ton. From what I've heard, the reasons for the switch included javascript being more practical and the previous professor deciding to take a break from teaching that class. Basically, many of the reasons overlap with that for Berkeley switching 61A from scheme to python [2].
I've also heard that the javascript version of the class is just as rigorous and challenging as the scheme version.
Shameless plug: if you want an interactive version of SICP in the original scheme, check out http://xuanji.appspot.com/isicp/1-1-elements.html
[1] Which might explain why the lack of macros in javascript wasn't a concern
Edit: Here's a list of available Scheme implementations. SICP uses MIT/GNU Scheme, which uses an Emacs-like editor.
Scheme is a deliberately minimalist language, which is fairly accessible and easy to write your own implementation of. In fact, in SICP, you do that, a couple of times, writing first a Scheme interpreter, then extending it in various ways like adding logic programming capabilities, then you write a virtual machine and a compiler that compiles down to that virtual machine.
JavaScript is, well, a weird and warty language. You wouldn't want to try implementing JavaScript in an introductory CS class, and it's much less amenable to language extension like the logic programming variant of Scheme you implement in SICP.
But I notice that this translation of SICP into JavaScript doesn't got that far; it only goes up through Chapter 2 of SICP.
Ever looked at R6RS?
The main issues I have with R6RS are the library system (which I think is too complex, and it frustratingly adds an extra level of indentation as you need to wrap everything in one big expression), and some of the libraries in the standard library, like the I/O library, the Unicode library (which standardizes on such things as char-upcase and char-downcase, which are fairly useless in a Unicode context, without adding much that's actually useful).
R6RS is this kind of weird, awkward beast that's not sure what it's doing. It neither strips the language down to a minimal core, nor does it build up a comprehensive set of libraries containing all of the basics that people expect from standard libraries in a language these days.
Is Scheme really decreasing in usage? Sure, in recent years there have been high-profile moves to Python at MIT and UCB, but I don't know of any hard stats on worldwide Scheme usage. Not that it matters.
The fifth act of SICP is meta-linguistic abstraction, and among Javascript's merits it is not. SICP is no more a book about Scheme than Moby Dick is a whale tale.
I admire the effort, and understand the sentiment behind the project. I just think the authors are missing the big picture of SICP. In fairness, few of us are Ablesons or Sussmans.
Replace "casual dining" with "megacorporations" and you get an actual movie made in 2000 [1]. And, of course, that example is not unique [2][3][4][5][6][7][8][9][10].
[1] http://www.imdb.com/title/tt0171359/
[2] http://www.imdb.com/title/tt0114279/
[3] http://www.imdb.com/title/tt0117509/
[4] http://www.imdb.com/title/tt0184791/
[5] http://www.imdb.com/title/tt0265713/
[6] et cetera
[7] et cetera
[8] et cetera
[9] ad nauseum
[10] ad infinitum
You can use a subset of Common Lisp and the programs in SICP would mostly look the same when written in that CL subset.
I have a surprise for you: Scheme has warts, too.
Scheme is super-easy to set up these days.
Step 1: Download http://racket-lang.org/
Step 2: Follow the quick start guide: http://docs.racket-lang.org/quick/
Step 3: Click "Run"
No "click through Visual Studio's project setup" phase, no "how do I open the text editor from IDLE" phase, no "open a command prompt" it's all right there.
This makes the environment and the language perfect for beginner students.
I really loved that response :)
It explains and implements a Forth environment from scratch, initially in literate assembler code (yes, that exists) and then, once that's bootstrapped enough, in literate Forth that it runs using itself.
http://sage.math.washington.edu/home/wstein/www/home/wbhart/...
This generation is going to be rewrite in Javascript/v8, everything that can be written in Javascript.