Comings and Goings in Programming Languages

Last week I wrote my first GOTO statement in around fifteen years. Strictly speaking it was a JavaScript 'continue' statement, but I specified a label after it to let me jump out of a nested loop, so in my mind it's a GOTO.

At University I was taught that GOTOs and labels were a bad thing because they encouraged spaghetti code. That was ironic, as they also taught me BASIC and Fortran IV, which completely depend on those very same bad things. However, looking at some of the code I used to write back then, I saw their point. Later, when I was writing assembly code for a living, and half your program seemed to be jump statements of one form or another, I really had my nose rubbed in how difficult this style of programming could be.

So for many years now I've tried to steer clear of anything that looked like a GOTO or a label. The nearest I got was in a C program when I mistyped 'default' as 'defualt' and the stupid compiler thought I was creating a label in the middle of a switch statement. (Boy, was that bug hard to spot.)

Going back to my 'continue', I have enough years behind me now to appreciate that jumping out of two loops is no worse than jumping out of one via a 'break', especially as the target label was just a few lines above. But in trying to remember all the arguments against jumps and labels, I suddenly remembered a former colleague saying about a computer language that it was the only one he'd ever met that had the equivalent of a COMEFROM statement.

Sadly, I cannot remember what that language was. A search on the web though found a language that actually does have a COMEFROM statement, namely Intercal. There was also a page explaining how one would work in Fortran. This is all quite amusing, but it's odd how much more difficult the idea of coming from is then going to, even though they're logically equivalent.

For another humorous but fairly unusable computer language, I would recommend Shakespeare, the language that lets your program read like a Tudor play. With true style, that implements a GOTO like this:

Hamlet:
   Let us proceed to scene III.

Thirty Years of Experience - A Perspective, part 1

Having recently felt the need to update my CV, which now lists nearly thirty years of computing experience, I couldn't help noticing that quite a few of the skills I list are somewhat out of date. Fortran IV, Algol68, DEC VMS--who uses these any more? (More to the point, would I want a job using them anyway?) In fact, for most of my first decade in employment I was working on computers, operating systems, and languages that have all but vanished. Much of my second decade has already gone the same way. (Now that I think about it, most of the companies I've worked for no longer exist either. I'm pretty sure that's not my fault, though there does seems to be a pattern there.) So what use then, is thirty years of experience?

Does our field change so fast that there's a maximum amount of useful experience that you can acquire? After which, your total experience is being rendered redundant at one end as fast as you can add to it at the other?

Not liking the way this argument was going, I came up with two counter-arguments that show why it is still useful to have a many years of experience in computing.

Firstly, even if the languages I wrote in are dead, the knowledge of how to write good software is timeless. I've spent thirty years learning how to program.

Secondly, I have acquired a sense of perspective, useful in a field like software engineering where the landscape changes at exponential rates.

It's been three days since I started writing this entry (work, chores and childcare not being conducive to creativity), so I'll get back to these points in my next blog.