The fastest computing experience I had was somewhere around 2001-02 or so, I had PIII 1Gz with 256MB of RAM and 3MBit DSL connection.

Everything was screaming: every piece of software I ran, every site I visited. I forgot how "Please wait..." popups looked like.

After that, it's been declining ever since: my software has gotten slower and slower, and web sites started to bring back dial-up memories from mid-90s.

After switching to Linux I got back most of what I lost, but the web still feels much slower, even Gmail is giving me "Still working..." strip at the top on a daily basis and randomly 1-2 squares on google maps remain gray after initial page load: hard to bitch about free stuff though.

I personally have found a lot of software to be I/O bound instead of CPU bound. Specifically hard drives. Try loading up something. Does it wait forever because the CPU is at 100%? Or is the hard drive light blinking like nuts?

Our quest for never-ending data seems to slow things down. In the age of terrabyte hard drives, the only real limitation on program size is the average broadband connection on most freely downloadable apps. (And it's even worse for programs that come on a disc!)

There recently was an article about how spellcheck worked with limited resources. Word might be loading a smallish, compressed English dictionary back then, but loading uncompressed, unabridged English dictionary today since there's no real hard drive space constraint.

Never blame a poor, bloated algorithm when the problem is just as likely our unfettered need for more data.

I personally have found that most software is idiocy-bound, like creating a search thread for every key typed in "Quicksearch" box (Vista, with indexing disabled). Or loading an entire page via 12 AJAX-requests, instead of serving it all at once, circa 1998. (and THEN doing a round-trip to the server only to report back that I shouldn't be putting dashes in my phone number)

As for I/O... it's is nothing, I've got plenty of it.

I think some of the meta-point might be a bit strained here. It's true that there's a lot of bloated software out there. And the example at the top, Acobat Reader, is one of the worst. It's a dog, and really easy to improve on. I've never heard of the "Foxit" product, but the poppler-based Evince reader on my Ubuntu box is similarly "snappy", even on huge documents (scanned-in D&D sourcebooks, for example -- yes, I'm a geek) where Adobe really crawls.

That said, there's a ton of common GUI software out there that really does deliver a pretty quick UI experience. Firefox 3 comes to mind as a good example here (especially given how hard it is to make some web content "snappy"). Likewise many of the smaller utilities on a modern Linux desktop are nice and quick.

Basically, the problem is real, but not as widespread as the article posits. A quick and clean desktop experience on modern hardware is both possible and available if you're willing to look for it.

But yeah, Acrobat is awful.

BeOS felt really fast, on a 200 mhz computer, several years ago. While the article's example is of Assembly optimized for performance over readability/maintainability (and I know people have written entire GUI OSs in Assembly, e.g. http://www.menuetos.net/), I know a clean, maintainable, responsive OS in a higher-level language is also possible. While I don't really know the details, I think BeOS had an asynchronous scheduling / interprocess communication model that was ahead of its time. (I'm not sure if parallels to Erlang apply.)

And, I second that Acrobat is an unusually bad case, though a pretty commonly known example. (Few of you probably use the same HR software we do, for example... Not naming names.)

From what I remember it was very async in its GUI programming model. You wrote little event handlers and it took care of the rest.

linux+fluxbox and you are ok. I recommend Fluxbuntu as a good example it beats xubuntu and its really beautiful(xubuntu is ugly in comparison). Its a very slim OS i really like it, but i use Kubuntu on my machine, its powerful enough to handle KDE and i love KDE, but on my other pc i have a fluxbuntu installation.

"The more memory something hogs, the slower it’ll run."

Well it used to be a compromise. You could blow your memory budget to get a bit of a speedup. But now memory bloat seems to be a cause of sluggishness.

Well, my "specialty" if you could call it that, is QA automation, writing automated test scripts for the system under test. So I would not consider myself a "super hacker" by any extent. My current job is writing in 4-Test, the language of Borland Silk. Before that, I did mainly unit testing development, some JUnit and XMLUnit, but primarily CPPUnit, the c++ port of JUnit. In unit testing especially one is cogniscent of what objects are in play at any given point, since one is writing a class or a method to test a certain set of objects in the system under test. So I think one becomes very aware of memory-related issues. I found the hard way writing in CPPUnit that it is easy to "trash memory" if one isn't careful. That said, I think I prefer CPPUnit, and C++ generally, for the very reason of the "tough love" it has by not having an in-built garbage collector like java has. It requires a bit more of one's attention, but frankly at the end of the day it executed swimmingly. So, with admittedly my limited perspective from the test automation world, I would personally have to vote for programming languages and approaches that force memory, and thereby performance, attention and efficiency. It is something like linux. Before I learned linux commands by playing around with cygwin, I much prefered DOS since it was more familiar. But once I learned to love talking to my computer via the cygwin shell, I never went back! Thus with writing de-constructors, once you get into the habit of it, you can't ever go back to not doing it! :-)