programming anyone ?

You know what's funny about Beryl/Vista ? They're doing the same stuff the Mac was doing years ago on puny hardware. I mean really, how frickin' hard is it to draw a window as a texture on a pair of triangles ? Seriously!

Programmers are sloppy, because sloppy is all the industry wants to pay for. Way back in the day when CPU cycles were super expensive, programmers were paid better money and given the time to tweak the crap out of everything, because if they didn't, the app would run dog slow and people wouldn't buy it. The problem is that somehow, people now tolerate underperforming software. They see it as a reason to upgrade... good god, they actually fall for it! Gee I certainly remember surfing the web on a 486 with 8mb of Ram back in the day. Now my OS needs a good 50-60mb to itself, and that's after I ripped out all the cruft. Normally it would be 100mb just for sitting idle with a background image and a neon-colored task bar. Gee uh, where'd all my system resources go ? Does it really require 7.3 million bytes to house a TCP/IP stack when some embedded devices pull it off with oh, 6kb or so ?

The truth however, is that if we were to write code as tightly and meticulously as we did in the 80's and 90's, software would perform, on average, at least 5 to 10 times faster than today, excluding hard bottlenecks like disk access and network bandwidth. It would also take 50 times longer to write the software, and I'd say less than 1% of people who call themselves "programmers" are even able to write such finely tuned code. Everyone doing VB ? Out. Everyone doing RAD ? Out. All you Ruby on Rails weenies ? follow me to this dark alley *BLAM*

I remember spending hours on little loops, with a CPU reference manual and a calculator. Sometimes I did little time sketches to figure out the best way to stagger memory accesses so as to not starve the execution pipes. Often times that meant weaving two disparate functions together, one being memory-hungry, the other CPU hungry. Together they filled each other's latency pockets, and my routine ran nearly thrice faster as a result. No C compiler I've ever seen could do such kinky things. Heck one time I even wrote a little assembler demo whose code executed twice: forward, then backward. The opcodes and data were carefully selected to represent valid instructions when reversed. It was more than a nerdy trick, it allowed my routine to fit entirely in the CPU's on-die cache, which gave it a huge speed boost but more importantly, it enabled a lowly 486 to mix 48 sound channels in real-time. Today's Cubase can't even handle a couple dozen channels without stuttering and/or crashing, on computers over 100 times faster than a 486.