Programmers Today Don't Know They're Born

So much has changed in the computing world since I first got my ZX81 at the age of what I think was 9. The power of PCs is just insane nowadays in comparison, in fact even some of the cheapest mobile phones make the glory days of home computing look like a relic from a bygone era.

We have graphical and CPU horsepower that can produce amazing images, and whilst not quite completely photo realistic, that step is only a matter of time. The Internet has brought specialist information into the home of anybody, created communities of like minded people that cross boundaries of nationality, race, sexuality and politics. We regularly talk to people who we might otherwise not even take a second glance at had we met them in a supermarket.

I hereby state that I love all these sides of progress, they are truly wonderful and I have no wish for us to go back. However, I feel something in this whole transformation process has been lost.

Machine Code Beckons

When you got a ZX Spectrum, a Commodore 64, Oric 1, BBC Micro, Amstrad CPC, Dragon 32, or whatever... they all did one thing that no computer does these days. They encouraged you to learn how to program it. Admittedly they did so with one of the world's most awful languages, BASIC, but they did so none the less. More than that, once they hooked you into coding on them, they encouraged a vital step further, they almost demanded you begin speaking their language.


Yes, anybody who spent a certain amount of time with their old computer would almost inevitably want to write code in machine language, the binary instructions that the CPU spoke at the heart of all systems. They encouraged this because the technical limitations meant that BASIC was just too slow for anything other than a Football Management game.

After some studying of machine code, you'd soon start to understand and appreciate many things about the system you were using, from how the chip itself actually worked, to how it spoke with other components. You understood how every programming task had to be broken down into ever simpler elements, because this was the only way to get things done. There was none of this grabbing a library here, or just downloading and altering something off the Internet there, you wrote it all yourself.

But Speed Was a Huge Problem

The limitations of CPU power made it all the harder, because these machines could only execute so many millions of cycles a second. Oh but millions is loads isn't it! No, actually it isn't. Take the ZX Spectrum for example, it had a CPU clocked at 3.5Mhz, which means the CPU ran at 3,500,000 cycles per second. But it takes between three and six of those cycles to execute a single machine cycle (the measurement used to define how long an instruction takes), and instructions themselves can take between 1 and 6 machine cycles.

Suddenly that big sounding number is reduced radically, and quite how to exactly calculate how many it can manage per second becomes a lot harder. But let's take a few best case scenarios and say on average an instruction takes 2 machine cycles, which uses a minimum of 3 clock cycles, that's 3.5 million divided by 2 divided by 3, which is roughly 583,333 instructions per second.

But even that number is misleading, because if you are coding a game, then frames per second comes into play. In olden days, before LCDs we all used CRTs for our televisions, you might even know somebody who still has one. PAL TV in the UK ran at 50Hz, which is fifty hertz, and hertz is times per second. Because of historical limitations that I won't go into here, but involved a lack of transmission bandwidth, each frame of video was divided up into two fields, sent as alternating lines. Therefore 50Hz was more like 25Hz if you de-interlaced the v... ok I'm getting off the point a bit here.

So where were we? Oh yes, if you are aiming for a 25Hz image, not a bad aim for fluid fast moving graphics, your earlier amount of instructions per second becomes 23,000 instructions per frame. That's pretty much all you get, if you take longer then you miss the next frame or even worse you start drawing over that frame whilst it's being sent to the TV set causing what is these days known as tearing. Part of your image is from the previous frame, other parts from the next one, a distracting mess.


I'm not even going to get into how much harder things were on the ZX81 or Atari 2600, both machines which lacked proper display hardware, and actually required the CPU to be doing specific things for anything to even display an image every update. When some of your instructions per frame are actually spent sending that frame to your telly, even less is there to play with.

The Thinking Lost to a Programming Generation

Yes, I'm approaching my point here, be still mon ami we are nearly there. Coding well for these old machines required a level of skill and ingenuity which seems missing from so many coders these days. So what if your program runs 20% slower than it could do if you knew enough about what you were doing to have written it more efficiently in the first place? Next year's line of CPUs will run it 30% faster.

Who cares if your stuff uses twice the RAM it needs to? In twelve months time it'll be cheaper and more abundant. These days it not only isn't worth the time to hand craft things in machine code for optimum performance, it isn't even worth writing your C code so it compiles into faster machine language.

I remember programming in the days of DOS and 16-bit Windows, with horrendous segment offset memory models that would drive you insane. Back then when you stepped through your code there was no right clicking in a window and inspecting variables, your view was a line of C code and then the assembly language it translated into. It made you see the direct result of how you wrote your code and what came out the other side.

And basic knowledge of what looked good and what looked bad in machine code told you how just doing simple things in C would make things run noticeably faster. That was a good skill to have, one which is somewhat redundant now. However I'm not sure it is, and the most noticeable area I see it in is ironically an interpreted language which is quite far removed from the days of the ZX Spectrum, yet writing it badly can cause huge performance issues.

Old Skills with New SQLs

Enter the modern relational database system, aka the RDBS, at the heart of almost every modern website and the biggest danger to it's performance. Anyone can download free software and design their own database system, pretty easily, however the pitfalls in making a bad one are far and wide. Do a poor job of it and you end up with a bad legacy that will bite you over and over again. You can even have the best designed database system in the world, and still bring it to its knees by coding awful queries.

Here I find that old classic computer knowledge, and the skills I developed all those years ago, applying themselves rather well. I know what sort of things a CPU can do fast, and what things it does slowly. I know what eats RAM and why, I know what things are quick to compare and why.


Now I'm not saying my first forays into SQL where glorious, in the beginning I was as blind as the next blind person, but as I grew to see how they worked I discovered the pitfalls and the peaks. Can you design a super fast DB without any of this knowledge? Sure you can, but knowing why it finds some things harder than others certainly increases your hit rate.

Coding these days seems far more about pulling off the shelf libraries, over complicated interfaces designed to make things easier, but ultimately all far too much of it does is hide you from complexity you really should know. Sure, some fancy interface might connect to a database on your behalf and write the SQL query for you, heck some of them will even create a whole database without you knowing much about SQL.

But they will almost always come across plenty of situations where complicated querys don't scale, and I guess for most companies that isn't an issue since if the size of the system becomes unwieldy they'll just upgrade the hardware. But so often I wonder how much CPU time and power the world could save, if we just wrote it all properly in the first place.

Why with all this modern day horse power does Microsoft Windows 7 still seem to hang around doing nothing just as often as Windows 95? Why does my Spectrum always seem more responsive than kit millions of times its power? How can Flash and a web browser eat so much of my CPU time and memory? Unless it's working out the cure for cancer in the background, I can only think it's nothing more than badly written.

Now if you'll excuse me, I'm off to play with 64-bit hand coded machine language Linux, it's only 16k. You can write a "Hello World" app in just 31 bytes, try doing that in Windows!