14 Aug 2000 raph   » (Master)

I've been listening to music using XMMS recently, and also playing with the waterfall plugin. Very pretty stuff, but the fact that the spectrum display is linear, rather than logarithmic, really bothers me. 90% of the screen area is given over to the high frequencies in the track. So when there's interesting things going on with flanged hi-hats, etc., you see nice patterns, but for the actual voice and melody, it's all munged together. I think I'd ditch xmms and go back to mpg123, but I find that the latter dies on a number of malformed mp3's, while xmms plays gamely through.

Code reuse

Dijkstra has long been a skeptic of code reuse. He has a quote that reads something like "the only reason to reuse a piece of code is if it's exceptionally high quality." I tend to agree with him. Take a skim through sourceforge or freshmeat one day and ask yourself how much of that code really deserves to be reused.

On the flip side, there is code out there that has been lovingly crafted and refined over a period of years (libjpeg and zlib immediately come to mind, but there are others). For some reason, these bits of code find themselves reused without inheritance, frameworks, contract programming, factoring, xp, or any of these other purported silver bullets.

So, I know am I crotchety old man, but I file code reuse and the many supporting technologies intended to foster it into the "only vaguely interesting" category. Concentrate on getting really high quality code out there, and the rest will take care of itself. Of course, that's really, really hard, probably beyond the reach of most free software hackers. Feel free to prove me wrong, though :)


While we're on the subject, I find that a lot of the really low quality code out there is infected by what I call the "scripting mentality." Three facets particularly bother me:

1. Not checking error codes. Virtually all invocations of functions or commands should be of the form of: status = invocation(...); if (status) { cleanup() }. Having cleanup do the right thing (error logging, reporting to the user interface, making sure the system doesn't go into an inconsistent state) is often much more difficult than the task at hand. Yet it is absolutely necessary if the goal is a program that doesn't just break randomly. Commands do fail. Most script writers just ignore that.

Here, I think, is the perfect illustration of the syndrome: as of perl 5.005_03, the print function does not return a false value when it fails (for example, when writing into a full disk), even though that's promised by the manual. I find the fact that this bug is not even noticed enough to get it fixed is revealing.

2. Sloppy config information. Most scripts require some kind of config information just to function, and more to do useful things. Yet, getting the config information into the script is often compeletely ad-hoc, often involving both environment variables and hand-editing files.

3. Quoting. Since scripting languages and the interfaces to scriptable components tend to be string-based, there are usually string quoting and escaping rules that have to be followed. Yet, it's so easy to ignore these issues. The Web, with it's wonky URL and query escaping rules, is particularly vulnerable. Unix sh quoting problems are a rich source of material for the Unix Hater's Handbook as well.

Thus, I consider the scripting approach to be quite valid for one-off jobs when programmer time is critical, and the person using the script can understand and deal with the consequences of errors without too much pain. It doesn't tend to scale very well to the case when lots of people other than the author will be using the code.


This morning's slowness at Advogato was caused by a DDoS against the Berkeley computer science subnets, facilitated by people breaking into RedHat boxes on campus.

Our computing infrastructure is so fragile and untrustworthy that it really should only be considered a toy. Yet, somehow, we manage to get our work done!

Latest blog entries     Older blog entries

New Advogato Features

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!