“Speed matters”, a few thoughts

Estimated reading time: 6 minutes

I just read the blog post Speed matters: Why working quickly is more important than it seems and have been pretty convinced by its argument.

This idea was already in my mind for quite some time but this post clarified it. According to the author, The general rule seems to be: systems which eat items quickly are fed more items. Slow systems starve.

I found myself, while reading this post, searching for other situations where speed is the key, and here is a few that I find interesting:

Art

The first domain that striked me is art.

Music is a good example. Instrument practice requires to be able to quickly change notes, sound and rhythm. That’s, by the way, the goal of music training.

It’s also the case with music theory, and even reading training in general, where quickly reading the notes and other indications on the music sheet enables the learning of the piece to flow better.

An other artistic domain where speed gain is the goal of the training is drawing, graphical art. I’m not an artist, but from what I could understand, a good drawing study session is a session where the artist improved his execution speed on a precise point.

For example, a beginner would have a hard time tracing their strokes as they desire. But by dint of hard work, will be able to trace quickly and precisely, and then concentrate on more specific or more difficult points of the technique.

It appears to me now that speed gaining is the main goal of any learning whatsoever. Mastering an element would then mean being able to execute it quickly, and in doing so, opens the doors to more complex elements, composed of the simpler ones.

Programming

An other domain that I instantly thought about while reading this article is computer programming.

The author suggests that all fast systems will tend to attract and be reused a lot. I think that’s one of the main reasons that explain today’s enthusiasm for dynamic programming languages like Python or Javascript.

The speed offered by these languages are on the development cycle side. Here, no more never-ending compilation times. We can start up the program right after changing its source code. The feeling of loss of inertia is highly reduced, which encourages the developer to experiment more things in their project, since they don’t need to stop and wait the end of an often long compilation.

Nevertheless, I think that trendy dynamic languages are not on their maximum potential in terms of speed. And that these, and even all the languages in general, would gain from having a development environment similar to that of the Lisp languages.

Indeed, the Lisp languages have a long legacy of interactive development environments that have taken the form of systems like SLIME for Common Lisp or Geiser for Scheme.

These systems offer an instantaneous feedback. Here, more than a development cycle without compilation times, restarting the program is out of the question. Changes on the code are performed in real time in the running program. Moreover, these environments offer an instantaneous access to the documentation.

The predisposition of Lisp for these kind of environments is one of the main reason I use these languages today. Being able to modify every bit of code in an instant and experimenting new things in split seconds is a real pleasure. When I have to use less evolved languages, it feels like middle ages, and my motivation takes a blow…

A few more leads

In my opinion, more things would gain from becoming faster.

Being a pretty shy individual, open-source project communities that are responsive feel more friendly and encouraging to me.

If a community is responsive, I will be encouraged to try more things in it, even if my contributions are refused. Because here, the problem isn’t the negative response, it’s the lack of feedback, that gives an impression of awkwardness and disdain from the entire community.

By the way, if you never contributed to an open-source project, I highly recommend that you take a look at the CHICKEN project. Its community is actually very responsive and will not hesitate to guide you! It’s very stimulating!

One last point before I let you go: I think that operating systems would benefit from fast development cycles like those of Lisp. The current state of these systems is pretty alarming. I often wonder how the developers of these systems cope without having a nervous breakdown. These systems are very often written in languages like C, where the main compilers are pretty slow. And as well as these long compilation times, the time needed to restart the program is awfully long, you have to restart the machine!

I always wanted to contribute to operating system projects, but I’ll wait with hope that interactive systems will get there. A few projects are on the right track like micro-kernel systems like Minix or the RUMP subproject of NetBSD.