Slow languages battle across time
prog21.dadgum.com
prog21.dadgum.com
I'd be curious, also, to take an benchmark of a program written in C in 1980, and compare it to Python today. I wouldn't be surprised if the slow Python version ran faster, simply because of the faster CPU. This would completely contradict the author's point.
So stuff that we'd be waiting for for a couple of days in the 80's can be done in a few seconds now. Of course that also means that we're generally much less aware of where the inefficiencies are until something really grinds to a halt but still, it's absolutely amazing to me even today that digital circuits can run at the speeds they have and that we can afford to run pretty numerically intensive stuff in interpreted languages and not bat an eye when the answer pops up in under a second.
2 MHz looked pretty good back in the day.
The computer I worked with most as a kid (besides the TRS-80 and the 'Dragon') was a BBC micro, it had an expansion bus for - no kidding - a second 6502 so you could have true parallelism. That meant you only had to wait for a day instead of two if you were taxing the machine and had something that was compute bound.
In the first paragraph, the writer links to an earlier blog post[1] which brings up the point that, though there's a lot of debate about the merits of different programming languages, things are fast enough that you really don't have to worry about that. Even the slowest languages are more than fast enough for most purposes.
Ironically, The Fine Article from which the BASIC times are taken is one reviewing Action!, a compiler/IDE of sorts for a structured language for the Atari. It has an Action! version of the sieve, and cites a run time of 1.5 seconds, rather faster than 324 seconds the Atari BASIC version takes.
Yes, Moore's Law and all that... but there was more to computing in those days than gutter BASIC.