Wandering Thoughts archives

Two sorts of languages

Here is a thesis:

There are two sorts of languages: languages where writing your own code is (usually) almost as fast as using the builtin features, and languages where the builtins are an order of magnitude faster than doing the same work in your own code.

C is an example of the first sort of language; it is merely silly, not laughably absurd, to reimplement your own version of strchr(). Python is an example of the second sort of language; it's utterly stupid to write your own version of the builtin string .find() method.

(There are degrees of this, depending on how much slower attempts to reimplement the builtins wind up.)

This difference matters a lot for how you write programs. In the second sort of language, the way to make things fast is to use the builtins as much as possible by finding some way to express your problem in their terms; programs often spend a lot of time and effort connecting builtins together and mapping back and forth between them. Programs in the first sort of language are usually written in a much more direct way; people use the builtins, but mostly when they're convenient.

(For example, if you want to find the first occurrence in a memory block of a byte with values between (varying) A and B, a C programmer will probably write a memchr-alike but a Python programmer will probably build and match a regular expression on the fly.)

The difference also places the implementors and the users of the first sort of languages on a much more level playing field. In the second sort of language, there are strong limits on what you can do as a mere user; you can never create your own extension that runs as fast as the builtins, which means that user-level extensions are always to some degree second class citizens.

The irritation of single-instance applications

There is a certain habit in applications these days of only allowing you to run one copy of themselves; for example, Firefox. I find myself more and more irritated by this, because it is usually implemented sloppily.

A good implementation must hide the fact that it is not actually running a second copy of the application. Sloppy implementations fail to completely hide this fact, generally by missing various differences between the environment that the original version of the application is running in and the environment that the second copy is running in.

Firefox on Unix provides a particularly blatant example of this, but it's a hard problem in general; there are a lot of different bits of the environment and it is in practice very challenging to make sure that you have covered everything. It may even be impossible; what if you're using a library that changes its behavior in response to environment variables? If this seems far-fetched, consider $PRINTER and $EDITOR.

Given the difficulties, you should really not do this unless you have to, for example because running two copies of the application at once corrupts data somewhere. If you want to offer this as a convenience feature, please make sure that it can be turned off, ideally with both a global configuration option and a command line switch.

Sidebar: how to do this really badly

Even worse than sloppy single-instance applications are programs that do not even bother pretending, where running a second copy of the program does bad things to whatever you were doing in the first copy. For example, Adobe Acrobat Reader, where you can only ever be reading one PDF at once; if you try to start a second copy of acroread, the second PDF replaces what you were reading in the first one.

(Back in the days when Acroread was my only real choice for PDFs, this was infuriating. Now that I have evince it is merely extremely irritating.)

A note to would-be photo editing applications

Dear F-Spot and similar applications: please understand that I already have a digital photo 'workflow'. However peculiar it is, it works fine for me and I have no interest in having you replace it; all I want to do is edit a photo every now and then. Can't you just let me do that, without making me import all of my photos into your world or otherwise going through all sorts of contortions?

Or in short: if you make me choose all or nothing, I am going to choose nothing. It's a pity, because I'm sure that there's a nice simple photo editing application somewhere underneath all of the things that I don't want and don't have the time or energy to fight with.

(The Gimp may be complete overkill for simple photo editing, but at least it doesn't insist on taking over my life.)

There is a general idea here: the more your program insists on doing, the more someone has to like about it in order to use it. Conversely, the less it insists on doing, the more it can be used in modular ways, the more chance there is that people going to like some bit of it and keep using that bit, giving you a chance to lure them in to the rest of the program over time.

(Sure, by all means make it capable of running their whole life. Just don't have it insist on doing so, no matter how good it is at it.)