Saturday, October 16, 2004

There’s something that bothered me about the Squeak environment, and it’s the same thing that bothered me about LambdaMOO and OS/2’s Workplace Shell, and to some extent, about objects in general: the objects you create make sense in that environment but it is hard to remove them from that environment. There is an entire “world” there with objects depending on code in classes, which depends on code in other classes and so on. It’s all very nice while you are in that world. There are incredibly cool things that can be done. But it’s hard to interact with other worlds, especially when they have been customized (different versions, patches, optional packages, etc.).

The Mac community had this problem too. Resource forks are all very nice, but they only work while you live inside the Mac community. Once you step out, they are a mess. The resource forks didn’t work with ftp or http or gopher or other file systems. The Mac folk just blamed everyone else for being so primitive. But being primitive is good. I’m probably the only one in the world who thinks file extensions are good. Other sorts of metadata—unix file permissions, Windows file attributes, etc.—have the same problem. They live outside the simplest system (files have a name + data), so they get lost.

WinFS sounds like it will be very cool ... as long as I live within the Longhorn world. As soon as I step out, it’s all lost. These days I keep much more on the network than I did just a few years ago—blogger, web, gmail, network file server, multiple computers, cell phone, PDA, TiVo. Any solution that only works when I’m in a little part of that world is not very interesting except as a toy.

Any centralized storage of data/objects is just not going to work in my life. The more I think about it, the less I think object-oriented programming is as useful these days. Objects are about tying data to behavior. Behavior is code. Code is highly unlikely to work on all the different systems I work on. The most useful thing for me is to have data and code separated. And as I mentioned above, metadata is too messy. So I need to have data with no metadata and no code. It would be fine if the metadata lived in the same file as the data. This fits in with the Unix model: data and programs are separate, data can work with many different programs, and programs can work with many different types of data. It doesn’t fit well with the Windows and Mac application models: a file (data) has a certain type, which is associated with a particular application (code). Instead of a Word document, an Excel spreadsheet, a Photoshop file, I need file types that have data alone and work with many different applications: HTML, JPEG, PNG, Text, CSV.

For a while now I’ve been happy separating data and programs at the OS level. It buys me a lot of flexibility and power. I’ve been thinking about whether it makes sense to do the same inside a program. If encapsulation at the file system level (e.g. my inability to decipher a Word document without running Microsoft Word) is bad, is encapsulation also bad at the object level? Maybe it’s time to give up on object-oriented programming.

0 comments: