Whenever I've got trouble understanding what the decisions were that brought a person to a given conclusion, what their premises are and how those premises lead to a result, I'm bothered.
But I'm especially bothered when I see that behavior, and recognize it as a large scale decision, think that I've already embraced those ideas and then abandoned them for something better, and see that that view of the universe that I've already moved past is one that I will at some point soon be laboring under.
This is the case with my exchange with Dave Winer about XML-RPC .
In a piece titled The Crazy Bar Scene in Star Wars he asks "where is the Unix equivalent of COM and Apple Events?"
I wish someone would give me a reason to want COM under Windows. Until that happens I won't be looking for a Un*x equivalent.
In my kitchen there's a food processor, and a chef's knife and a sharpening stone.
Together, the chef's knife and stone cost a bit more than the food processor, but we're not going to make this comparison based on capital costs.
The food processor takes no skill. Anyone can take the food processor home, remove it from the box, and in seconds have cucumber slices with a consistent thickness. They can cut french fries, or shave slivers of carrots for a salad.
Most people start off with a knife with a blade cut from a sheet of metal, not from a forged blade. But even if the same person who had so much luck with the food processor ended up with a good forged blade and a sharpening system, when they brought this home and opened it up they'd end up with uneven sized pieces, and probably a few unintentional bits of finger in their salad.
Immediate user experience: Food processor, good; knife, frustrating and painful.
When I first read Kernighan and Plauger's Software Tools I didn't get it. This was back in the days of the Apple ][, and I hadn't been exposed to the concept of multiple programs running at the same time. And of course this didn't change through my experiences with MS-DOS, where piping was occasionally useful, but it was implemented via temp files.
I discovered objects, and C++ (version 1! with single inheritance!), and thought they were the coolest thing. I built a little graphical event system and wrote modules for it. I revamped a large portion of a commercial C app to be more "object oriented".
At some point Windows became viable, and I discovered that someone had done what I'd been doing on an application wide scale on a processor wide scale, and it didn't have many of the issues that had driven me away from the Macintosh.
We could send messages to other processes, other processes we didn't even control! And we could subclass and superclass controls that other people had written, even insert our own controls into other people's applications.
I was psyched.
When the Internet started to explode, I (and a bunch of friends) who were part of the local FidoNet community wanted to branch out and build a real-time network. The result of that was Chattanooga On-line , and as we looked around at how to build Chattanooga On-line , the Linux kernel and the FSF/GNU software base was the only way we could see to afford to do it.
So I discovered the Un*x philosophy. All of a sudden I understood what interoperability between applications meant. Kernighan & Plauger made sense.
If I want to dice an onion, I can plug in the food processor, find an appropriate blade, find the right thickness setting, put the blade in the holder in the hopper, put the cover on, turn on the food processor, open everything back up, with another utensil scrape the diced onion into the frying pan, then disassemble the whole thing and take it over to the sink and wash it.
This takes quite some time. So when I found myself with a simple task I'd grab a cutting board, whip my knife out of the drawer, do the chopping, scrape the onion into the pan with the knife blade, and slide the knife blade along the edge of the board to get the remaining onion bits off of it, and I'm ready for the next vegetable.
The results weren't nearly as consistent as the food processor, but it took so much less time that the food processor was sitting unused more and more.
And then something very interesting happened. I noticed that I was getting more consistent with the knife, and faster. While the food processor would smush some of the food along the edges of the moving bits, the knife cut cleanly.
I noticed that the food processor left a lot of bits to wash up, and sometimes it'd break and I'd have to order a specialized part to fix it.
But funny, that forged carbon steel blade just keeps working. If it starts to get a little slow I sprinkle a little water on it and take a few passes over the stone, and I'm back chopping.
Sure, if I were cooking for 50 I'd break out the food processor; if I were trying to train someone who wasn't interested in long-term ramifications I'd hand them the food processor.
In 1995 I got an opportunity to return to my roots, to sling assembly language and write games, so I left Chattanooga and went to the left coast to do Windows programming. But the Windows programming was in a company with a lot of crusty old Un*x programmers, some of whom had their fingers in the original OS code, or only one separated from the original authors.
But I was still a Windows coder, and I thought they were crusty old codgers who couldn't see the future. So I've watched COM grow up. I've watched OLE come to power. I've watched Windows applications become more clickable, presumably more interoperable (although I've seen precious little evidence of that), more flashy.
But while Windows becomes more clickable and prettier, I've struggled through operations that my Un*x using colleagues slapped together trivially.
While I spent hours clicking and building project files for a bunch of file format drivers with an identical build process, they typed "ls *.c >> Makefile" and did a little editing.
While I spent hours digging through obscure documentation and web pages on making the Direct3d interface of the moment work, they slapped together some OpenGL code and played with the visualizations.
While I tried to make programs communicate with each other they piped a couple of command lines together.
While I struggled with subtle keystroke variations and behaviors in various different editors inherent in various different applications, they worked in an environment where they could customize the hell out of their favorite editor, and integrate it seemlessly into their development environment.
And oddly, it didn't matter if their editor, or any other tool, for that matter, was built to run in a terminal window or as a fully graphical application. Even more bizarrely, if they found an application that took a lot of system configuration to run well, they'd just run it on the machine on which it worked and piped the interface bits over to the machine they were running on.
And they could customize their working environment far more than me. Want a click to bring a window to the foreground? Sure. Or not. How about tell which window keystroke input should go to? Yep. Even independent of what's the front window, something theoretically possible in Windows, but in practice it tends to choke on certain applications.
And their applications did fantastic things. Not only did they have all the pull-down menus and easy to use stuff, but they had command line versions for when they wanted to do the same things to lots of images.
They could even customize their colors! And developers abided by the color rules, unlike, say, the Visual C++ help system which followed the Windows custom color selections sometimes.
Eventually I downloaded the Cygnus tools. Yeah, NT doesn't like pipes much, and I cut myself the first few times, but...
Ya ever have a friend who bought all the latest gadgets from Ronco . You ask them to chop a potato and they ask "peeled, spiral sliced, fry cut, or what size dice?" and then spend the next 45 minutes rooting through drawers and cupboards to find the appropriate tools?
Objects have a wonderful cleanness about them. When you get the object religion they feel "right". The whole idea of abstracting down the actions of your application to some base data structures, and then defining those data structures as how the operations on them differ is conceptually very attractive.
But in the end those operations are defined by the underlying architecture which operates on them. The objects are often easier to think about, an easier way to conceptualize an operation, but in the end they're all executing machine code.
Somewhere, there's steel breaking apart cells.
Somewhere, there's packets flowing over a wire.
Sometimes, if you want to output a string it's a lot quicker to use printf("Hello, World!\n"); than to instantiate an output device, get a handle to the output device graphics context, instantiate a font, associate the font with the graphics context, find the rectangle that's the size of the graphics context, and call dc->DrawText("Hello, World", 12, &rect, DT_CENTER);.
Sometimes it's not even obvious that there's objects happening, but if one system has a set of calls, say "read" and "write" that work across a bunch of different types of things, like, say, files, and pipes, and sockets, and the other system implements a different type of object with different calls for each of those, which is the object oriented system?
Sometimes, as a matter of fact, the object oriented abstraction is more complex than the underlying operation. Often it's very difficult to tell people who've bought into the object religion that this is the case.
I know. I was once a true believer.
As we fragment the web like toilers building the tower of Babel, each of us using our own new words to describe some subtleties of the operations that are all the same underneath, we should be careful about which of those new languages we embrace, which ones really give us more power to work on the underlying structure, and which ones just serve to divide us.
While y'all embrace your complexity for its own sake, I'll be sitting here playing with better tools in a futile attempt to build that tower to the heavens while the rest of y'all are experimenting with whatever new dialect is "in" today.
And I'll be happily querying databases and searching existing content and such while the rest of y'all are wondering why the only way to communicate with the other aliens seems to be waving either money or a blaster around.
To bring us full circle to the Mos Eisley Cantina metaphor.
Friday, October 29th, 1999 danlyke@flutterby.com