Followup to Databases are Dumb: No one got it. Yet. I'm confident my understanding of the subject is not the issue.
Databases are Dumb
Lately I've started to be really bugged by how dumb database constructs are. Let's take the table as and example. I sometimes would like a table to tell me how many rows it contains. Alas, the table doesn't know, it rudely ignores me. Long ago I discovered that tables will only talk if SQL asks the question. So I learned to formulate a query to SQL that it passes on to table, and gives me back my answer. I don't like the middleman so much. I can't ask, "table, how many rows?". I have to tell SQL to ask table to count something. I don't know why, but I can't tell SQL to count the rows, I have to ask it to count either a column, or all columns. That's really dumb to me because, don't all rows in a table have the same columns? Why do I have to specify one column, or all columns (*), when I just want a count of rows?
Maybe I'm being too demanding, insisting that a table know about its contents. Tables are made up of columns. "Table, how many columns do you have?", I ask. Then I find out that table won't even tell me that. I have to ask this other table to tell me what's in the first table, and I still have to tell SQL how to ask the question for me.
Well, after a while I get tired of trying to get tables to talk to me. I try to get columns to talk to me, but they're even ruder than tables.
Then I have a little light bulb go on. Maybe instead of asking the tables, I can ask the content of the tables. After all, that's really what I'm usually interested in. I know there are fifty states in the United States, but I forget what the capitals are. So I try that. I decide I'd like to ask, "States, what are you capitols?". We'll there's a table in my database that I'm told has all the states, but it turns out there's no way to ask the states anything. I can ask the table to tell me what's in it, but only by telling SQL to ask for something. I'm getting really frustrated about now. My SQL guide tries to be helpful by telling me it can find out for me how many states have capitols that start with the letter 'A', but I'm not interested in that kind of aggregation. Sometimes my geography is bad, so I can't even point to the state that I want. I always get New Hampshire and Vermont mixed up (sorry about that). So I'd like to say "States, whichever one of you is Vermont, speak up and tell me your capitol". But again, I am back to asking SQL to ask the states table something about Vermont and it's capitol. SQL is really very picky about how I ask, too. Anyway, it turns out that the States table doesn't actually know anyway, all it knows is that there's another table that knows the names of all the cities, and can tell me if a city is the capitol. Talk about pointing fingers! After all that, I finally figure out that I can tell SQL to ask the States table if any of its states are named "Vermont" and if there is one (which I already know exists) to ask the cities table for all the cities in Vermont which are its capitol -- even though I know a state can only have one capitol. What a struggle. All I really wanted to ask was "What's the capitol of Vermont?", and after several false starts I discover I have to ask a whole bunch of different people about all kinds of things I don't care about and narrow down the results to the one thing I do care about. What a waste!
This essay argues that business accounting "has no model appropriate for software or programming."
"The intangible but extremely complicated patterns of thought are that software has value only when it's accompanied by the programmers who write it. No company can treat programmers the same as a factory because programmers demand continuous attention and support well beyond any factory."
It almost makes Alan Cooper sound like an advocate for agile methods.
My employer let me go this week. Not as part of a general layouff, but more over a difference of style. The good news is, I have a lot of (now former) co-workers that I enjoyed good working relationships with. Aside: managers are not highly represented in the group I got along with well.
I got a good severance package, so I'm going to take the rest of August off. I'll work a bit on some of the projects I've too stressed to focus on. I'm especially interested in FIT FrameworkForIntegratedTest and Fitster, as well as my own AntFit.
All the papers and transactions are done and I'm officially registered for the O'Reilly OSCON 2003 in Portland, OR. I signed up for a Perl tutorial with chromatic. I look forward to meeting fellow Advogatons.
It's starting to look more and more like my employer will pay my way to O'Reilly Open Source Convention 2003. The convention is slated for the Marriot just down the street from my office in Portland, OR. It would be great to have an Advogato BOF, at least informally. Do I hear interest?
sarum asks about the crappy TCP/IP stack in Windows. Years ago, a company named FTP Software had a nifty TCP/IP stack for DOS. They were the lucky owners of the ftp.com domain, now bought by NetManage (along with the rest of the company). FTP Software's stack worked with Crynwr packet drivers, NDIS and ODI drivers. It was an old-school TSR and when HiMEM/EMM and all that fun stuff was around it knew all about tricks to play to reduce its memory footprint. Then Windows 3.0 came out, and they supported that, with VxDs and other painful stuff, and the WinSock API was borne, in part through contributions from engineers at FTP Software. Yes, it was a commercial product, but it was damn good, and the programmers hung out on UseNet if you needed help. They had things like ICMP router discovery, TCP/IP Slow Start, Van Jacobson compression and a slew of other advanced TCP/IP RFCs before MSFT even know how to spell IP. Did I mention one of the founders of the company wrote the SLIP RFC? If you bought the dev kit, you pretty much got full source, assuming you could fathom the hairy C, x86 assembly, and interrupt mess that was the legacy of being DOS-based.
Some time after, Microsoft started shipping Windows 3.1 with a built-in TCP/IP stack. People started asking why they should pay for a stack when Windows shipped with on "for free". Well MSFT's stack was based on the BSD code, and it was a crappy port. With the release of Win95, third-party tcp/ip support was all but dead. The WinDOS implementation is still a crappy port, with bad default settings for MTU, RTT, TCP window size and so on.
In short, MSFT Borgified FTP Software and TCP/IP.
So now, you can't get a decent TCP/IP implementation for Windows. The WinNT/2000/XP isn't much better, but hey, MSFT and their partners get to charge consulting fees to help people configure their stacks to have half-decent performance.
How do I know all this? Do a search on the web for ugopher.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!