Wednesday, July 30
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?
And off you go.
for each customer
where state = "NY"
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.
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.
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.
Tuesday, July 22
I don't know how many of my readers have been following the recent kerfuffle over SCO (The Santa Cruz Organisation) suing IBM for more than $1 billion. SCO alleges that IBM took code that SCO owned and put it into Linux.
Yesterday SCO's share price rose on news that they had registered copyright on the Unix source - a completely meaningless step. Copyright registration merely says they you filed a copy of the work with the copyright office on a particular date. Unlike patent or trademark registration, it says nothing at all about whether you actually have any legal right to the work.
SCO's claim against IBM is nebulous - perhaps deliberately so. It is partly based on copyright, partly based on patents, partly based on trade secrets. So far SCO has not publically produced any evidence to support any part of their claim. Instead, they have moved directly to making not-at-all veiled threats towards Linux users: Pay us or we'll sue you too.
It's pretty clear why SCO has taken this route: The company is doomed. Back in the day, SCO had a good and competitive product. Take a high-end PC - say, a 386/33, or later a 486/50, add a Stallion board (a popular multi-port serial card) and a bunch of Wyse 60 terminals, install SCO, and you had a capable multi-user system for a lot less money than the proprietary Unix boxes of the day, and much less money than a traditional mini-computer.
A lot of small-to-medium businesses ran the company on SCO.
In recent years, though, SCO has been caught between Windows NT - a cow of an operating system, but reasonably stable and backed by Microsoft's marketing department - and Linux, which is not only a substantially better system than SCO, but is free.
There's no way out for SCO. There are no opportunities left. The only people still on SCO are legacy users - those who have always run on SCO, who have SCO-trained technical staff, and those who need an application that hasn't yet been ported to Linux.
So SCO went where the money is, and sued IBM. It's quite possible that they don't expect to win the lawsuit, but are looking instead to get bought out as part of a settlement. IBM don't appear to by playing according to SCO's script, however, and have told them to get knotted.
So now SCO have turned on Linux users, suggesting that they may be legally vulnerable if they continue to use Linux without paying SCO. This, without any case going to court, much less being proven. SCO have also issued warnings aimed at Linus Torvalds, the creator of Linux, saying that he too may be liable.
So in a short period of time, SCO have managed to make deadly enemies of every geek on the planet and IBM, which is not a good combination. On their side, they have Microsoft, who have listed Linux as their number two threat (after the sagging world economy). Microsoft recently - as in, after the lawsuit - paid SCO an undisclosed amount for a Unix license. Note that Microsoft do not sell Unix.
The remaining factor to this mess is that SCO is not a large company. Their market capitalisation is less than the likely tax they aim to extract from Linux users all over the world. In other words, to Linux users, it would be cheaper - and better in the long term - to buy SCO and close it down than to pay the tax.
It's just a pity that no-one thought to do this six months ago when their stock was in the toilet.
51 queries taking 2.8013 seconds, 187 records returned.
Powered by Minx 1.1.6c-pink.