Journal severoon's Journal: A New Kind of Program 1
Recently I've noticed a new trend in programs. It seems that, when I wasn't looking, programmers stopped writing applications that do anything useful for end users. Even more surprising, these useless programs have become very, very popular.
Does this sound crazy? Well, let me ask you this, then: have you heard of a web browser called Firefox? Have you heard of an Integrated Development Environment (IDE) called Eclipse? Both of these programs, by themselves, are utterly useless...the core of each of these applications is nothing more than a platform for plug-ins, and it is the plug-ins (also called "extensions") that do all of the heavy lifting.
If you are unfamiliar with the philosophy driving these two applications, and what I can only assume is an avalanche of applications that will soon follow this same technique, allow me to explain. A few years ago, an application was simply a collection of code that was assembled into a cohesive unit and deployed (or "installed") that way on a computer. Each part of that application was typically dependent on a large number of other parts of the same application, creating an intricate and tangled web of interdependencies between them. In essence, these "parts" were so interdependent that they really did not exist separately from each other, and even labelling them "parts" in the first place requires a suspension of disbelief. Truthfully, it was more appropriate to call the entire application as a whole a "part".
Because of this web of interdependency in the architecture of an application, all of the customizability of such apps had to be pre-planned from the very beginning. This is typically done in software at the beginning of the development cycle, and it's called "collecting requirements". Software development teams literally sit down and draft a list of requirements the end product must meet in terms of its functionality. In a word processing application, for example, if the user is to be given a choice of whether a ruler is to appear in the main content pane of the editing window, the software that makes that ruler possible must be designed and developed right into the code. In a later version, if other code in the app depends upon that ruler and the ruler must be changed to exhibit new functionality, it's quite possible (and probable) that all of the dependant bits of code will have to be updated as well to leverage this new functionality.
I'm sure the first glimmers of change came with applications like Photoshop. For several years and several versions now, one of the main features well-known to all Photoshop users is its array of filters that can be used to do various things to an image. For instance, there's a filter to sharpen a blurry image. There's a filter to blur a sharp image. There are filters that add dust and speckles to images, filters that add noise, and even filters that make a photo look like a watercolor painting or a stained glass window. At some point, someone on the Photoshop development team realized that the potential for so many different filters existed that there's no way one company could ever implement them all. So, to make their product even more capable, they set about developing a feature in Photoshop not intended for use by end users editing images, but rather for other companies. This feature was fairly simple--it was a small bit of software that makes it possible for a bit of code to request the data making up whatever image is currently active in the application. This bit of code is then free to modify the data (the image) in any way it wants and then hand back the new image to Photoshop. (Of course, it's actually much more complicated than this, as these bits of code--third-party filters--can interact with Photoshop features such as selections, the color chooser, etc.)
Now other companies could write filters for Photoshop that could be purchased by users and installed, and they'd pop up in the menu with all the rest of the default filters that come with Photoshop. The nice thing about this, for these companies, is that whenever they want to release a new version of thier filter, they don't need to worry about updating any dependent code in Photoshop; there's a well-defined separation between the main application and the work the filter does, so they're free to simply release the new version of the filter and the user installs it, replacing the older version and getting access to the new functionality.
I'm sure it didn't even take a full version cycle for the Photoshop development team to realize this as an important benefit they could leverage for their default filters as well. So even though these default filters are a standard part of Photoshop, they exist as plug-ins just as if a third-party company had developed them.
(I feel I must insert a quick aside here to die-hard emacs users. Yes, I know emacs came before Photoshop. Yes, I know emacs is a far better example than Photoshop. I'm trying to make this accessible to Windows users. Besides, I use vi.
Fast forward to Firefox. This browser takes this idea to a whole new level--this app is essentially this concept on steroids. Upon installation of the browser, there is virtually no user-available part of the application that is hard-wired into the application itself...it's all extensions. The "application," to use the term as we would have a few years ago, is simply a framework for browser-type extensions...a framework that allows extensions to be installed, uninstalled, and swap information with each other. Remove all of the standard plug-ins that come as a default part of the application, and that's all you're left with--the application would probably not even be able to display a window on the screen because that functionality is the job of one of its standard extensions. I do not think the old definition of the term application will weather this change in philosophy--I think it's probably going to evolve to mean something like: "a framework for plug-ins related to a common theme and a standard set of those plug-ins that implement a set of basic requirements." In other words, in Firefox's case, the term application must include the standard set of default plug-ins that are supplied with the default application.
The benefit of this approach is apparent from a comparison with Photoshop filters. Virtually any part of Firefox can be replaced by removing an existing extension and supplying a new extension in its place that does everything the old one did and more. For instance, when I installed Firefox it sported a set of context-sensitive flyout menus that pop up when I clicked the right mouse button. I installed an extension that added small icons to these context-sensitive menus. I added another extension that monitors if I request a context-sensitive menu on a highlighted word--if I do, it provides an option for me to look up that sequence of letters in an on-line dictionary. (Which one? I can configure this extension with up to 4 on-line dictionaries of my choosing.) The other day I was a little frustrated with the way Firefox handled downloading files. Within 5 minutes, I found a list of extensions available for it that completely alter the way downloading files is handled, each replete with its own bevy of configuration options.
The great thing about this new approach is that it recognizes the unique needs of end users. It doesn't expect all users to agree on the way a particular thing should be handled. It doesn't even require users to share the same set of expectations of what the application *should* do. Think about the dictionary extension I added to my browser--some developer out there could just as easily write a thesaurus extension, an encyclopedia extension, a rhyming dictionary extension, even extensions specific to disciplines such as astronomy (look up this constellation) or organic chemistry (do a search for scientific papers on the highlighted compound). The possibilities are endless.
Of course, no great idea goes completely unpunished. One of the greatest drawbacks of this philosophy is: the possibilities are endless. Often referred to as "the tyranny of choice," it's very easy for users to quickly become buried beneath an avalanche of extensions that do everything from enabling your browser's status bar to display the surf conditions of your area's nearest beach to a sidebar that constantly probes the port space of a subnet of your choosing. You see, the temptation is great for developers to implement extensions that are only tenuously connected to the basic purpose of the application. Ask yourself: is displaying the current surf conditions functionality that should be present in a web browser? The problem is, some developer out there thinks so...and that extension need not be installed in your particular browser to make it vexing to you. Such an extension need only be available to start causing you problems; when you go to search through the list of available extensions "just to see what's out there," you are immediately faced with the daunting task of reading a listing of extensions longer than the US tax code. In fact, Firefox, a web browser that has not yet reached a stable 1.0 version release, already has quite a formidable list of available extensions that requires the better part of an afternoon to parse. I shudder to think how I'll know which extensions exist that are useful to me by version 5.0.
This approach to programming isn't actually a totally new idea--it's been around for a long time in the computer world, and it's actually quite familiar to users of UNIX-based platforms (such as Linux). It is often said that the UNIX philosophy is to write a tool focused on "doing one thing well." Programmers that grew up on UNIX-based platforms tend to write lots and lots of small tools that do very small jobs, but allow the user to do that job in every conceivable way. Then, to carry out tasks, these small tools are chained together in creative ways (called "pipelines") to get the desired effect. This idea of extensible applications such as Firefox is the same pretty girl, she's just wearing a different dress.
So, this means we can learn a lot about the direction this new approach to designing applications will take by looking at Linux, the UNIX-based operating system for PCs. There are options for pretty much anything a user wants on the Linux platform. Let's say, for instance, that I want a program that allows me to read email in a text-only environment. I can choose from mail, elm, pine, zmail, joe, emacs configured with e-mail client extensions...and the list goes on. How can I, as a user with a finite lifetime and limited patience, even begin to understand the possibilities of each and every kind of application if text-based email clients alone can consume several days' research? The best solution that the Linux community has come up with is: distributions. That is, a bunch of people get together and spend a whole lot of time figuring out what particular mix of tools and applications they prefer, and once they all agree they assemble a Linux installation complete with that set of applications. And this might solve our little problem--except, there's lots of these people, and they can't all agree on just a couple of different distributions. You saw this one coming, I'll bet; now I'm faced with choosing a distro from the pool of available distros: Gentoo, FreeBSD, Linspire, Mandrake, Fedora, SuSe, Debian, Slackware, Knoppix...and this is only a sampling of the most popular of them.
With this level of customizability comes other problems as well. For example, if you go to a friend's house and he also has Firefox installed and customized to his liking, would you recognize it as the same browser you use at home? It depends on the degrees of customization you both use. At what point are you actually using a completely different application? There is definitely something to be said for consistency...you may both be calling your preferred web browser Firefox, but if you share no common ground, are you both using the same web browser? Then there's the issue of security. Who's to say that in all of the thousands and thousands of extensions available for a particular application, there isn't some cracker out there who's generously contributed an extension that provides useful functionality to both you (your default page is automatically set to the cookie recipe of the day) and him (he gets back-door access to your machine, a log of the sites you visit and any usernames/passwords entered at those sites, etc)? How do you know a particular extension you might find useful can be trusted?
It's clear to me that the immediate advantages of this new approach outweigh my fears about future consequences. I do think these potential problems become somewhat less menacing if we make every attempt up front to anticipate them. As long as we do that, creativity and time is on our side.
In the meantime, I have to get cracking on finding a Firefox extension that will allow me to compare the specific gravities of known water table toxins.
Borg need plugins (Score:2)
I think about this once in a while...you see, my computer(s) are so horribly customized that the casual person who sits down at them can't figure out