Scheme has set-car!, vector-set!, hash-set! etc to modify its standard containers. In clojure those containers are immutable. However, you could create equivalent immutable containers in Scheme, perhaps that's why he said "by default".

Why would anyone do that? We use immutable collections, immutable value objects, unmodifiable views and deep/shallow copies, but never serializing data to a string just for passing it around. I think most experienced Java developers would go for the type-safe alternatives.

Not a good idea. Browsers that do not support imgset would show all three images using that syntax. A new element name like "<set>" would be ignored by them.

CSS to the rescue

    imgset img{display:none;}
    imgset img:first-child{display:block;}

Same with modern HTML5 tags, modernizer or any other tool would handle that for you.

Not really, what about browsers that don't support first-child? Backwards compatibility is important.

With a couple of simple macros, the code could be fraction of its size and much more readable. Code with that property is atrocious in my mind. For example these "argument reading" bits are repeated over and over again:

ram[PC++0xfff]&0xff

((ram[PC++0xfff]&0xff)|((ram[PC++0xfff]&0xff)<<8))

Of course Notch said it has been generated, so he probably had a neat definition that barfed this garbage out. But it's strange that so many commentators here are defending the output as a reasonable coding style for a VM!

I think in a couple of months there will be a "+1" button at the top bar of Chrome so you can click it to "like" any page.. And having a "+" button next to it would've been confusing.

Mind blown. Also, I hate that you might be right.

Not since the end of The Usual Suspects...

gzipped base64-encoded data is about the same size as the original data, though. It only requires more processing to be done.