Category: Programming

“If we spoke a different language, we would perceive a somewhat different world”. Quotations on Simplicity in Software Design.

“There is nothing permanent except change”.

Sigh.

A random “design pattern” which just popped into my head:

Imagine you have some large data structure which is expensive to update. Maybe it’s a list of integers and you want to clamp each element to be between 0 and 100. Normally, you’d go through each element, perform the check and update it if required.

Instead, I suggest keeping the original list and creating a seperate log of the ‘modifications’ which have been made to it. So now you have the original list and a note saying “by the way, when you read an element you also have to clamp it to the range 0-100”. Now you’ve made the update cheap, but accessing the data is more costly.

However, if your program is otherwise idle later on, it can come back and coalesce everything back down.

So you’re basically saving time in your “change it” code, paying it back a little at a time in the “access it” code, and you’ve got the option to pay off the debt entirely when you’ve got a bit of idle time spare.

Whether this is useful or not depends on the frequency and cost of updates and accesses. I’m noting it here as another potential “tool in the box” for algorithmic optimization. It probably lives next to memoization and similar such techniques.

I play in a rock band, and as a consequence I’ve been spending a lot of time trying out audio software under linux. Usually when I’m trying out programs I have quite a high tolerance for bugs, clunkiness and bad designs, but when I’m using computers to record music I want to get on with the music and forget about the computers.

Without being disrepectful to the efforts of the Linux Audio Developers, currently linux ain’t a great place to be for audio. It’s getting a lot better with ALSA and Jack. But there’s no way I would recommend linux audio to anyone other than a hardcore techy.

So, should I install Windows and do audio there? I’d rather not give Microsoft any money. Maybe I should buy a Mac? I’m sure the grass would be greener over there. Certainly, the idea of paying some relatively small amount of money to get some better quality software sounds attractive. Gosh, that’s me .. a devout linux user .. wishing for a bit of commercial software.

There’s nothing special about these other operating systems in terms of the technical features they offer. The difference is the presence of commercial software companies who produce decent quality applications. You don’t get much of that under linux. These companies spend a while checking out user requirements, writing the code (including all the boring bits) and only shipping when it’s good enough to capture a reasonable share of the market. The end result is never going to be perfect bug-free software, but it’s pretty good.

I’d love there to be a top-class open source audio package for linux. But I don’t see how one is going to appear. If I were to write such an open source package, I’d have to do it in the evening after I come home from work. After all, I need to work during the day in order to buy food, pay the bills and live within our current economic system.

So, there’s the rub. If you want to get a team of focused developers working on an application, you need to pay them so that the project can be their “day job” and they can pay the bills. The only way you can pay them is if you can make money by selling the results of their efforts. Commercial software makes sense.

There’s certainly lots of people out there who expend huge effort developing open source software for apparently very little reward (the guy writing Ardour comes to mind). I would like to be able to do this kind of stuff without burning the candle at both ends. I work enough (paid) hours programming for my employer, and that leaves me disinclined to spend the remaining waking hours coding.

Also, since the volunteer brigade consists almost entirely of geeks, they have great success at certain types of application, such as web servers and compilers. Geeks like playing with new technology. They like doing the cool stuff, and consequently they tend to leave the boring bits of applications incomplete. Witness the number of projects with some small bit of “cool technology” at the core, but with atrocious GUIs. Maybe audio software is more left-brain touchy-feely and doesn’t win so big with the volunteers.

Apart from volunteers, there are other ways in which open source software gets built. Some open source software comes out of academic research projects, funded by government or industry. Some software starts life as an internal company tool which gets jettisoned, such as the Objective C support in gcc. A small amount of software is specifically commisioned by someone who pays a programmer to fulfil their requirements. I’ve done this kind of work before, but there’s not very much call for it.

Economies of scale make “commisioning” unsuitable as a method of seeing that good linux audio software get written. When a commercial company wants to build a new application, it takes on a certain amount of risk (the cost of development) which it hopes to recover through many sales of the product. The cost of the product is ultimately shared across many people. If someone were to commision an open source audio project they would singly bear the cost of development, which makes it prohibitively expensive.

I appreciate the technical advantages of open source software. I have often took advantage of the opportunities for learning, extending and fixing open source program which I couldn’t have done if I were using closed commercial software. And, I’ve volunteered lots of time to work on such projects. But I don’t see how it’s possible to truely walk the free-software walk when we live in a capitalist economy. RMS can believe that “reward is often not a motivator” if he wants, but peer recognition isn’t going to pay the bills.

Actually, I’ll postulate a thought experiment in which we already live in the RMS world, where all software was free. One day, someone comes up with this radical new notion of “proprietry software”. The promise of these crazy guys is that, if you’re prepared to loose some of your software freedoms and pay them a reasonable amount of money for results, they’ll be able to get some programmers together to concentrate full-time on the software, rather than working in a call-center or whatever they’re currently doing. What’s more, they’ll be able to get HCI experts to help design the GUI, and good authors to write the documentation.

So, my original question was “how do you write better applications?”. Open source may have many eyes making bugs shallow, but commercial software has fulltime eyes working on the program every day.

James Gosling is talking about his latest language project, Jackpot. It appears to be a combination of two things – “let’s edit AST’s instead of ASCII source code” and a mini theorem-prover which understands dataflow.

A few years ago, Microsoft were onto a similar thing with their Intentional Programming research project, which has since been wiped off the face of the net (except for this spinoff company and a chapter in the “Generative Programming” book).

When you run a traditional compiler, it reads in your ascii source code and analyses it to form an information-rich representation. It knows all the types, where each variable is declared and used, whether a line of code is reachable or not. It needs to know all this information before it can generate the assembly version of your program. But that same information would be very useful to developers too.

In a system like DevStudio, there’s a big wall between your text editor and the compiler. You throw your source code over the wall to the compiler, and some time later it throws you back a .obj file. It can also throw you back a dump of some of the information it figured out (“browse information”). That doesn’t work so well, because whenever you start editing code, the information gets out of date.

What systems like IP and Jackpot do is move the wall. Now, on one side you have your editor and the “information gathering” engine. On the other side you have a code generator which uses the gathered information. This means that your editor can use knowledge of the semantics of the language to enhance it’s editing factilities and presentation of your code. You can do neat editing things like having each appearance of a particular variable name be linked together, so that if you select one and edit it, they all change together. You can redefine the input mechanisms to use customized notations. You can neat visualization thing such as converting sqrt(x) into the mathematical symbol for square root, or converting a complication boolean expression into a circuit diagram with AND, NOT, OR gates. In IP, you can also define reduction methods which transform your code – the idea being that you can define a high-level notation (which you’ll then use day-to-day) and a set of reduction methods which map those high-level constructs onto something more efficient.

The “big idea” is that code should express the intention of the programmer rather than being an abstraction of machine code. This is also a goal of declarative languages and domain-specific languages.

I’ve got to the start where I’ve abandoned too many personal programming projects. Now I’m loathed to start any new ones unless it’s going to be really signficant.

I can think of three reasons for doing a project – to create something, to learn something, or because you’ve got nothing better to do.

Creating something is the raison d’etre of programming. Creating something new is great. Pushing the envelope, exploring new ground. Finding a more efficient, elegant or more general solution to an already solved problem is great. In contrast, reinventing the wheel is loathsome. Writing Yet Another Window Manager or Yet Another Text Editor should a hangable offence.

Having said that, writing programs for your own education is part of the ongoing process of improvement which any programmer should pursue. Writing a garbage collector yourself is probably the best way to learn about them. But I try hard to limit the scope of “learning programs” because otherwise you can spend weeks on irrelevant details.

The last reason – “because you’ve nothing else to do” – is the worst reason for sitting programming a computer. Directionless wandering will suck hours from your life, and at the end you’re only tired rather than wise.

So, I’ve written substantial, yet incomplete, portions of DTP programs, compiler backends. I’ve written too many raytracers, mostly as a way of learning a new language. They’re complex enough to explore the language and tools adequately, but I know how to write one from memory.