Hacker News Reader

Comment by magicalist | Hacker News Reader

This is a nonsensical comparison. Considering that the language chosen requires fairly verbose code (everything from a minimum 14 bytes for a function declaration to longwinded API names, eg "fillStyle" that takes a string with another 7 bytes of decoration[1]), this is exactly what you'd expect. The challenges presented by the particular language and execution environment are a large part of the entire point of these exercises, they aren't a failing.

So, good work, you've declared all such competitions with languages less terse than assembly "scary" and no doubt a harbinger of some slippery slope. I hope there aren't any competitions with ISAs smaller than x86, or your world really might fall apart.

[1] 'rgb(,,)'. converting to hex might be a good size optimization there, actually, but it would still need a '#' and be a formatted string.

View on HN

I don't find the comparison nonsensical (and I do ruby/coffeescript all day :-) - we have at least to take into consideration that the abstraction here came with an amazing cost nonetheless.

There is always meat in looking at the tradeoffs necessary for language/platform design, but the problem is that this particular argument is completely specious.

For instance, 256b.net demos aren't 256 bytes of assembly, they're 256 byte executables. If you download a demo, you can see that the ASM files, even with comments removed, are typically 1 or 2 kilobytes.

So now we have less functionality and worse performance in the same or half as much space, and that's still ignoring the fact that the mapping of source code bytes to actual instructions don't in any way resemble each other. If you included some measure of information density, you should probably be allowed at least another kilobyte of Javascript.

Then we get to functionality and performance. We all (hopefully) know the tradeoffs inherent in dynamic and JIT-compiled languages running in a browser that's trying its best to be an entire OS with all the intervening cruft between code and hardware that that implies. On the other hand, the 256b demos require DOSBox because they use extremely specific hacks, so should js1k demos be allowed to use one specific version of a browser, with (for instance) a known math and canvas object key order so it never has to refer to anything by name? Should it be allowed to use WebGL? The actual competition requires them to work in all "current browsers", including IE, but if you could get the WebGL syntax overhead to work in 1k, you could kick the crap out of the 256 byte demos...but what would that even mean?

In other words, it's an important consideration but this is a terrible comparison :)

I'm not sure to understand your point (maybe I understood you in reverse, not sure!):

- "dosbox" 256b demos don't use extremely specific hacks: they use what was 10 to 15 years ago the standard platform (ie: DOS, Bios, VGA...); that will be the fate of today's javascript cool WebGL/Canvas stuff, including my own (see [1])

- the question about weither to use extensions or not (ie: WebGL, OpenGL, soundcards hardware...) is there for both assembly and javascript demos (see [2])

- basically IMO, unless you use WebGL, the performance of what you'll get is an order of magnitude or two slower than the equivalent in ASM so far on my tests at least

- please note that I'm not an ASM "freak": I tend to use ASM only for the small loops that require it (for instance, I released [3] which 95% Pascal and 5% asm roughly)

So I stand on my point: unless we rely on hardware and WebGL, we have lost several orders of magnitude of performance, by replacing a standard by another.

But please note I still enjoy these things coming out and I seriously hope WebGL et al. will get widespread usage!

[1] http://thbar.github.com/playground/

[2] http://www.geeks3d.com/20101126/demoscene-38644-mandelbulb-i... 1k intro of an OpenGL Mandelbrot set in 3D coded in assembly

[3] http://www.pouet.net/prod.php?which=17268 1995 demo

I don't know where you get "less functionality and worse performance in the same or half as much space"- the point of the link was to show that 256 byte demos actually demonstrate more functionality. What makes you think you have more functionality in 1k of JS?

As you said, "if you could get the WebGL syntax overhead to work in 1k, you could kick the crap out of the 256 byte demos." I believe that's exactly the point. Even if there is all this theoretical power in our JS environments, we aren't using our environment nearly as efficiently as the 256 byte demos used theirs.

It's also worth noting that those 256b demos ran on the standard platforms of their day, which yes, required MS-DOS, but then could run on any intel compatible processor, with any standard motherboard, with any standard bios, with any standard video card. And I would be surprised if they actually called into MS-DOS at all, and didn't just talk to the hardware directly.

Reply on news.ycombinator.com