5 ms·

The comparisons the article makes are not apples-to-apples. The authors start with a binary file, and compare it to uncompressed text files. For example, zlib.h

The comparisons the article makes are not apples-to-apples. The authors start with a binary file, and compare it to uncompressed text files. For example, zlib.h on Mountain Lion is 80511 bytes, but only 22031 bytes when gzip compressed (around half the size of Turbo Pascal). The article's tone implies that these were the 'good old days' when compilers were small and fast. However, priorities have rightly changed. We now have computers that can execute billions of operations per second without breaking a sweat, I/O devices which can perform tens of thousands of IOPS, and laptop GPUs that can push 3D content to a 5.1 million pixel display. It's likely that Turbo Pascal was highly optimized to deal with the constraint's of that day's computers. A lot of developer man hours were almost certainly allocated to shaving off extra bytes from the executable. It's usually not worth devoting such man hours to tiny performance improvements, considering the beefy hardware most people have.

klodolph 14y ago
> The article's tone implies that these were the 'good old days' when compilers were small and fast. That's reading a lot into two short paragraphs. Tone doesn't come across well in text, and the shorter the text is, the harder it is to figure out tone. I don't hear nostalgia for the 'good old days' in the article, what I hear is, "Wow! What a feat of engineering to fit an IDE and compiler into 40k!" We get the same kick out of watching demo competitions. Have you seen the "Elevated" demo? Including the music, sound effects, textures, everything, it's only 4k... http://www.youtube.com/watch?v=_YWMGuh15nE http://www.youtube.com/watch?v=_YWMGuh15nE
AurSaraf 14y ago
Knowing the author's other writing (which is, by the way, very recommended), I would think he isn't trying to say "look how wrong we went, lets make things smaller again" but instead "look how fun that was, but come on, those days are over. Now that we have comparably infinite resources, lets focus on what can be made with them." tl;dr The Author would probably agree with you more than you think
MarkSweep 14y ago
The one apple-to-apple comparision is the touch command. You would think that touch would not be that big: http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/touch.c http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/touch.c

klodolph 14y ago

> The article's tone implies that these were the 'good old days' when compilers were small and fast. That's reading a lot into two short paragraphs. Tone doesn't come across well in text, and the shorter the text is, the harder it is to figure out tone. I don't hear nostalgia for the 'good old days' in the article, what I hear is, "Wow! What a feat of engineering to fit an IDE and compiler into 40k!" We get the same kick out of watching demo competitions. Have you seen the "Elevated" demo? Including the music, sound effects, textures, everything, it's only 4k... http://www.youtube.com/watch?v=_YWMGuh15nE http://www.youtube.com/watch?v=_YWMGuh15nE

AurSaraf 14y ago

Knowing the author's other writing (which is, by the way, very recommended), I would think he isn't trying to say "look how wrong we went, lets make things smaller again" but instead "look how fun that was, but come on, those days are over. Now that we have comparably infinite resources, lets focus on what can be made with them." tl;dr The Author would probably agree with you more than you think

MarkSweep 14y ago

The one apple-to-apple comparision is the touch command. You would think that touch would not be that big: http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/touch.c http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/touch.c