Banner Logo
Home
The Real Kato
About Me
Twitter
Facebook
Frozen Lunches
Links
Kottke
Daring Fireball
Amalah
Secret Agent Josephine
Dooce
Contact



Archives
Most Recent

2024 March
2006 May
2006 April
2006 March
2006 February
2006 January
2005 December
2005 November
2005 October
2005 September
2005 August
2005 July
2005 June


Categories
All Categories 

bloggers 
books 
commentary 
dating 
food 
funnyhaha 
interesting 
life 
movies 
music 
politics 
reviews 
science 
site-business 
sports 
style 
techwatch 
television 
theater 
travel 


Recent Comments
On College Football 2022: Week 6 Recap and Week 7 Pre...
Ken said:
Yeah, we've both had our share of hope and disappointment in this game. Let's just hope for a good b...
On College Football 2022: Week 6 Recap and Week 7 Pre...
Dan* said:
I'm not sure how I feel about this game. On one hand, I feel pretty optimistic that we have the tale...
On College Football 2022: Week 1 Preview
Dan* said:
Glad to see you'll be back writing football again, Ken! Congrats on the easy win today. You didn't ...
On College Football 2021: Week 10 Recap and Week 11 P...
Ken said:
Yeah, sorry one of our teams had to lose. I've come to appreciate Penn State as a classy and sympath...
On College Football 2021: Week 10 Recap and Week 11 P...
Dan* said:
Hey Ken, congratulations on the win yesterday! Some really odd choices by our coaching staff in that...


<< Previous: Hey There | Next: Bush Approval Rating... >>

Coding in the 21st Century
Monday, 2006 May 15 - 8:07 am
Here we are in 2006, and we still work with the software equivalent of stone hammers and knives.

In case I haven't mentioned it before, I work as a software engineer.

One thing I've long said to friends and co-workers is that we are in the stone age of software engineering. (Note that this is not a particular statement about my co-workers or my company, but rather about the industry in general.) What I mean by "stone age" is that we are still using very primitive tools and concepts, stuff that has been around since the 1960s.

Here's an example of a code snippet that software engineers write all the time:

myListOfThings = new int[MAX_ITEMS];
for (int i = 0; i < MAX_ITEMS; i++) {
   myListOfThings[i] = 0;
}

This creates an array of integers and initializes them all to zero. Note that in C++, this particular code fragment requires four lines of code, three variable declarations, and 18 punctuation marks and symbols. And every software engineer will have to type this several thousand times through the course of their career.

The fact that we are able to create software with several millions of lines of code is almost miraculous. It's as if we built the Sears Tower out of Lego building blocks. If you ever wonder why software has so many bugs, why the programs on your PC crash all the time, why code is so vulnerable to viruses: just think about typing that code fragment above a million times. In a program with four million lines of code, you'd have somewhere around fifteen million punctuation marks and symbols that would have to be typed correctly. You'd have maybe 500,000 different variables to keep straight. The code would be contained in ten thousand different files on your hard drive. How many errors do you think you'd make?

You'd be lucky to finish with less than twenty thousand errors. And then even if you fixed all the basic coding mistakes, you'd probably still have thousands of errors in the software logic.

Stone. Age.

Why isn't there something simpler? When looking at that code fragment above, C++ programmers might think, "Well, I could create an array of objects with well-defined constructors instead of using 'int', and then I wouldn't have to initialize the elements." But that solution could end up requiring even more code. And that's a problem with engineers: whenever we think about some solution to a problem, we often end up making things more complicated instead of making them simpler.

It's not that we haven't tried lots of different ways of solving this particular issue. Languages like Perl make it unnecessary to declare the size of an array. Many languages have constructs to initialize array elements in one statement. But even so, you'll still see "for-loops" all over the place. See, here's the thing: the problem isn't that the for-loop needs to be simpler, the problem is that we still have to deal with things like arrays and for-loops at all.

Right now, if you're a software engineer, you're probably trying to figure out how you'd write code without creating for-loops and if-then statements. You may be thinking, "well, if the language supported such-and-such operation and such-and-such syntax"... but that's not thinking boldly enough. The main problem, you see, is that we have to program in machine languages at all. Why wouldn't I click a button on a GUI if I wanted to create a "myListOfThings"? I'd only ever have to type the name of it once, and thereafter I could just click on it again. And there'd be no cryptic syntax, punctuation marks, or indentation style to worry about.

For 90% of the code that software engineers create, we could have pre-canned constructs that we make with the click of a button: finite state machines, AVL trees, publish-and-subscribe mechanisms, inter-process messaging, graphical user interfaces... we simply shouldn't have to write this stuff over and over again.

Some very smart people and some very ambitious companies have tried to take us down this path. We've got a wide variety of software development tools that let us create software graphically; the computer generates all the code for us. But the problem with all the tools I've seen is that either they're not powerful enough or they're not flexible enough. They solve a particular problem, but they don't solve every problem. There are tools to generate state machines, tools to generate graphical interfaces (you can write your own text editor using Apple's XCode Tools without typing a single line of code), tools to create databases, and so on; but the tools don't work well together, because there's no standard on how they should do so.

And that's the next problem... software engineers are big on inventing proprietary solutions to their specific problems, instead of working towards larger end goals like interoperability, compatibility, and standards.

I think it will be at least thirty years before we all start creating software a different way. It's not that we don't already know how to create a better solution: right now, we just don't have the incentive to do so. Somehow we manage to keep building our Lego skyscrapers and they manage not to fall apart, and so we keep on writing those for-loops. Microsoft right now is in the midst of building the equivalent of a two-hundred story skyscraper called Windows Vista, and it'll only be the miracle of a billion dollars and a thousand miles of duct tape that will prevent that building from crashing to the ground.

For now, all we can do is to try to make our Lego-building more solid. We can make coding standards and style guidelines to help reduce errors. We can try to make reusable components and things that fit together. We can buy more duct tape.

I just hope I'm still around when the renaissance arrives... when we finally start seeing software that just works.
Permalink  1 Comment   Bookmark and Share
Posted by Ken in: techwatch

Comments

Comment #1 from Steve (Guest)
2006 May 15 - 11:13 am : #
I have 3 words for you:
"F**ckin' A Bubba!"

Now I will alt-tab back to Visual Studio so I can finish that for loop.

Comments are closed for this post.
Login


Search This Site
Powered by FreeFind