Wednesday, July 30


And Your Litle Dog Too!

I'm a programmer. I program computers. It's what I get paid to do, and then when I'm done, I go home and do some more for free.

I've been programming since I was fourteen, back when a sixteen-bit computer (which today would probably be considered inadequate to control a sewing machine) was considered Wow, sixteen bits! You've got a sixteen-bit computer? Wow! My first computer was a Tandy CoCo - the Colour (or Color) Computer, cheaper and less expandable than an Apple II but with a better CPU (those 6502 owners only dreamed of having a a 6809! The 6809 had a multiply instruction! Take that, 6502 suckers!) and a better Basic - one of the last good programs Microsoft wrote. By the time Microsoft wrote AmigaBasic, they were well on their way to suckitude.

But that's beside the point. Well, no, in fact it is the point. AmigaBasic sucked. It worked, mostly; it got the job done. It didn't support about 90% of the features of the system (unless you jumped through flaming hoops). It broke the Amiga programming guidelines in major ways, so that when later machines came out it didn't work at all. Its suckiness was highlighted by later Basics like GFA and Amos, which were five to ten times faster and actually let you use some of the power of the Amiga. But it got the job done.

My second paying job introduced me to a new programming language: Progress. Progress is a fourth-generation langugage, a 4GL, designed for writing database applications. (Basic is a third-generation language, Assembly language is second-generation. First generation languages are written with numbers rather than letters.)

In my first two weeks working with Progress I learned more about databases than six months of lectures at University could impart. In Progress, the database has a wonderful immediacy. In other languages, you connect to a database, send queries to it, receive results back. In Progress, the database is just there. Searching and sorting isn't something you have to write programs for, it just happens. Want to find all the customers in New York state and sort them in alphabetical order?

for each customer
where state = "NY"
by name:
And off you go.

I started with Progress when it was at version 3. By version 6, they'd fixed every problem but one: You couldn't write programs larger than 64k. Sixty-four kilobytes. This was a holdover from the original sixteen-bit implementations of Progress; even though you were running it on a 32-bit computer, a Honeywell Superteam, say, or an IBM RS/6000 (they still make those, by the way, though the name has changed), even though you now had 32 bits at your command, Progress was still stuck in 16-bit land.

Guess what?

It still is.

Servers these days run at 2GHz rather than 20MHz, 64 bits are yours for the asking from any number of vendors, and Progress is still stuck in 16 bit land. These days you can break your program up into functions and procedures, each of which can be as large as 60k themselves, so the overall program can be larger. But you still have to watch your action segment and your expression segment and your text segment and your debug segment and the sizes of all of your procedures and functions, or Splatooie! You added one too many lines of code, now your program won't run any more.

And in the latest, greatest version of Progress, 9.1D, you still only get 32k of local variables, too. Including strings.

Absurd, right?

No. Well, yes. But what really ticks me off is that Progress is still the best language there is for what I do. There are no languages that even come close. Progress is the second slowest programing language I've ever seen; I downloaded and compiled dozens of interpreters before I finally found anything slower. It's slower than the Unix shell at arithmetic, and the Unix shell doesn't even know what a number is. That's how slow Progress is.

And it's still the best language for what I do.

It's like... Say you have a big family - six or seven kids. Or brothers and sisters, if you like. You need a big car. The only one on the market that seats nine people has a two-stroke, three cylinder engine and comes in a choice of lime green or fuchsia. Seven years later, when you go to buy a new car, it's still the only car that seats nine. It still has that noisy, smoke-spewing engine. Now it comes in twelve different colours. But the price has tripled.

You'd feel a little frustrated, right? You idiots, you might think. Why can't you put a decent engine in this bloody thing? Or you might get upset with the other car companies: Why the heck don't you make a car that can take more than two adults and a hamster?, you might ask.

You get fed up enough that you decide to make your own car.

Which is where I am today. Well, I got there last year, but I'm lazy.

Now, it's a truism in computing (and a true truism at that) that all computers suck. All hardware sucks, all software sucks; the difference being that at least you can kick the hardware - you can only swear at the software. Computer languages - or to be pedantic, the compilers and interpreters that implement them - are software, and they suck too.

Which is why I'm writing my own car. Uh, language. You got that bit, right?

Except that if you're going to write your own language, you have to do it in another language. And all the other languages suck. If they didn't suck, you wouldn't be writing your own language in the first place, since it's hard; you'd be relaxing watching DNA Squared or writing music or solving partial differential equations or whatever it is you do to relax. But they do suck, so you are writing your own your own language, and you're writing it in a language that sucks.

Aargh! You'd write it in your own language, which wouldn't suck so much (for the same reason that your pet or your children are generally less disagreeable than those belonging to other people), only you don't have your language because that's what you're trying to write.

So any attempt to produce a language that at least sucks somewhat less condemns you to writing large amounts of code in someone else's sucky language. It's like having to drive your two-stroke three-cylinder pile of rust ninety miles to the workshop every day so that you can work on your new car. Everything would be so easy if only you already had what you are trying to build in the first place.

It's driving me nuts.

Posted by: Pixy Misa at 09:28 AM | Comments (5) | Add Comment | Trackbacks (Suck)
Post contains 1143 words, total size 7 kb.

1 Hi Pixy! Gus said that Progress 10 will have speed improvements to the interpreter. So at least they have got the message (5 years too late maybe...) Mep!

Posted by: Keanie at Wednesday, July 30 2003 07:08 PM (6Yo0u)

2 I saw that. Nice to see that they are actually awake, but we'll see what we see... It's been getting slower every year since version 4, so they have a lot of catching up to do.

Posted by: PixyMisa at Thursday, July 31 2003 03:23 AM (LBXBY)

3 Just visiting, thanks to the referral by Steve DB... after reading your "all programming languages suck" diatribe, I begin to understand how appropriate this blog title is! *chuckle* Personally, I think that the idea is not to find a language that doesn't suck (which is, as you point out, a lost cause)... but rather, to find one that sucks in a manner compatible to the way you work. Or, at any rate, one for which the suckiness doesn't get in your way. (After all, every language started out as SOMEBODY'S dream language.) Put it this way -- I work at a company, a rather successful software startup, where the primary working languages are C++ and Lisp. (I have become firmly convinced that C++ was invented to raise suckiness to an art form.) On the other hand, I may be biased; for years assembly language was my language of choice. (Power. Infinite power over the machine, and it's mine. MINE!! All mine!!!) Sorry. I'll crawl back into my hole now. best wishes, Daniel in Medford

Posted by: Daniel in Medford at Thursday, July 31 2003 04:59 PM (bqP7j)

4 From a purely mercurial viewpoint the best way to raise your employability is to learn SQL and become a database expert. For every hardcore programming job there are 5-10 database jobs. A programmer will often get fired as soon as the job is done. The database expert is the last to get canned because every organization needs someone to keep the databases running. Read E.F. Codd's book and learn relational DB theory (normalization especially) and SQL, and your career is set.

Posted by: Gideon at Thursday, July 31 2003 05:40 PM (aQiN5)

5 Well, I'm a database administrator and a system administrator and a programmer and a web designer and a network engineer (as long as the network doesn't get too hairy). So I'm at a point where I don't have to worry too much about looking for work (also, Australia's economy has been relatively robust of late, which helps). I've been using PostgreSQL for another project, and while it works well, it's just not as, hmm, as maneuvrable as Progress. I have two copies of Codd already, thanks :) But I'd rather my career were uncertain than to have it set in concrete if that meant working with SQL all day :(

Posted by: PixyMisa at Friday, August 01 2003 12:36 AM (LBXBY)

Hide Comments | Add Comment

Comments are disabled. Post is locked.
51kb generated in CPU 0.08, elapsed 0.4232 seconds.
56 queries taking 0.3668 seconds, 298 records returned.
Powered by Minx 1.1.6c-pink.