Month: May 2012

Writing software for someone else

Posted on by John

One of the differences between amateur and professional software development is whether you’re writing software for yourself or for someone else. It’s like the difference between keeping a journal and being a journalist.

People who have only written software for their own use have no idea how much work goes into writing software for others. You have to imagine a thousand things a user might do that you would never do. You have to decide which of these things you will accommodate, and which you will disallow. And when you decide to disallow an action, you have to decide how to do so while causing minimal irritation to the user.

GUI applications are particularly hard to write, not because it’s difficult to draw buttons and boxes on a screen, but because it’s difficult to think of all the ways a user could arrive at a particular state.

In between writing software for yourself and writing software for others is writing software for people very much like yourself. Open source software started out this way, alpha programmers writing software for alpha programmers. Since then the OSS community has gotten much better at writing software for general users, though it still has room to improve.

Related post: Software exoskeletons

Why read and write tech books?

Posted on by John

Now that we have Google, countless blogs, and Stack Overflow, why should anyone buy technical books? And why should anybody write them? Charles Petzold’s answer is that books provide a narrative in a way that the web cannot.

Books about programming have certainly become less essential over the past 15 years or so. …

The Web has demonstrated that its greatest strength is the accumulation of information from many sources, and providing links between related concepts. However, where the Web falls down is in presenting long narratives, and I think this is a problem. For thousands of years, human beings have learned not by accumulating facts, but by following a narrative — a story that forges a path through the forest of information rather than merely describing all the trees.

… Books — at least those that are written well — provide narratives that the Web does not. …

As I’m writing a book, my primary intent is not to regurgitate the documentation but to impose a narrative on the material. This narrative has to begin with the basics and gradually introduce more and more material with a pace that neither overwhelms nor bores the reader. A narrative is necessarily a single path, and I spend much time and effort coming up with a good one.

From An Experiment in Book Publishing.

I completely agree. I love the kind of books Petzold is talking about. And by the way, a book with a dozen authors isn’t a real book in my opinion. I’m disappointed whenever I’m browsing a library and think I’ve found a book on something, only to realize I’ve found a stack of articles bound together with no narrative.

Unix doesn’t follow the Unix philosophy

Posted on by John

The Unix philosophy is a noble idea, but even Unix doesn’t follow it too closely. The Unix philosophy, as summarized by Doug McIlroy, says

  1. Write programs that do one thing and do it well.
  2. Write programs to work together.
  3. Write programs to handle text streams, because that is a universal interface.

Here is an example from James Hague where the first point has been strained.

The UNIX ls utility seemed like a good idea at the time. It’s the poster child for the UNIX way: a small tool that does exactly one thing well. Here that thing is to display a list of filenames. But deciding exactly what filenames to display and in what format led to the addition of over 35 command-line switches. Now the man page for the BSD version of ls bears the shame of this footnote: “To maintain backward compatibility, the relationships between the many options are quite complex.”

James Hague gives this as only one small example of how programmers have allowed things to become unnecessarily complicated. He concludes

We did this. We who claim to value simplicity are the guilty party. See, all those little design decisions actually matter, and there were places where we could have stopped and said “no, don’t do this.” And even if we were lazy and didn’t do the right thing when changes were easy, before there were thousands of users, we still could have gone back and fixed things later. But we didn’t.

He’s right, to some extent. But as I argued in Where the Unix philosophy breaks down, some of the growth in complexity is understandable. It’s a lot easier to maintain an orthogonal design when your software isn’t being used. Software that gets used becomes less orthogonal and develops diagonal shortcuts.

Why does ls have dozens of tangled options? Because users, even Unix users, are not overly fond of the first two points of the Unix philosophy. They don’t want to chain little programs together. They’d rather do more with the tool at hand than put it down to pick up new tools. They do appreciate the ideal of single-purpose tools that work well together, but only in moderation.

I agree that “all those little design decisions actually matter, and there were places where we could have stopped and said ‘no, don’t do this.'” Some complexity has come from a lack of foresight or a lack of courage. But not all of it. Some of it has come from satisfying what complex humans want from their software.

Related post: 100x better approach to software?

The Book of Inkscape

Posted on by John

When I first started using Inkscape, I read Inkscape: Guide to a Vector Drawing Program by Tavmjong Bah, 3rd edition. It’s now in its 4th edition, which I have not seen.

I received a copy of The Book of Inkscape by Dmitry Kirsanov recently, and it looks like the book I would have preferred to start with. Both books are fine introductions, but Kirsanov’s book is more my style.

Bah’s book is more inductive. It teaches you the elements of Inkscape by first taking you through a series of projects. Kirsanov’s book is organized more like a textbook or a reference. Some people would prefer Bah’s book, especially if it were their intention to work through all the exercises. I prefer Kirsanov’s book, organized more by topic than by project. It’s easier to dip in and out of as needed.

I’d like to learn Inkscape well. I could imagine going through a book slowly, carefully working all the examples, exploring side roads, etc. But that’s not realistic for me any time soon. For now, I expect I’ll learn more about Inkscape just-in-time as I need to make illustrations. And Kirsanov’s book is better suited for that.

More Inkscape posts

Should you walk or run in the rain?

Posted on by John

One of the problems in X and the City, a book I mentioned the other day, is deciding whether you’ll get wetter by walking or running in the rain.

The author takes several factors into account and models the total amount of water a person absorbs as

T = \frac{Iwd}{v}\left(ct \cos\theta + l(c \sin\theta + v)\right).

This assumes a person is essentially a rectangular box of height l, width w, and thickness t. The rain is falling at an angle θ to the vertical (e.g. θ = 0 for rain coming straight down). The distance you need to walk or run is d and your speed is v. The rain is falling with speed c. The parameter I is the rain intensity, ranging from 0 for no rain to 1 for continuous flow. The book goes into greater detail, deriving the formula and estimating numerical values for the parameters.

Conclusion?

If the rain is driving into you from the front, run as fast as you safely can. On the other hand, if the rain is coming from behind you, and you can keep pace with its horizontal speed by waling, do so!

Using SciPy with IronPython

Posted on by John

Three years ago I wrote a post about my disappointment using SciPy with IronPython. A lot has changed since then, so I thought I’d write a short follow-up post.

To install NumPy and SciPy for use with IronPython, follow the instructions here. [Update: no longer available.] After installation, NumPy works as expected.

There is one small gotcha with SciPy. To use SciPy with IronPython, start ipy with the command line argument -X:Frames. Then you can use SciPy as you would from CPython. For example.

c:> ipy -X:Frames
>>> import scipy as sp
>>> sp.pi
3.141592653589793

Without the -X:Frames option you’ll get an error when you try to import scipy.

AttributeError: 'module' object has no attribute '_getframe'

According to this page [link rot],

The issue is that SciPy makes use of the CPython API for inspecting the current stack frame which IronPython doesn’t enable by default because of a small runtime performance hit. You can turn on this functionality by passing the command line argument “-X:Frames” to on the command line.

The 1970s

Posted on by John

Here’s a perspective on the 1970s I found interesting: The decade was so embarrassing that climbing out of the ’70s was a proud achievement.

The 1970s were America’s low tide. Not since the Depression had the country been so wracked with woe. Never — not even during the Depression — had American pride and self-confidence plunged deeper. But the decade was also, paradoxically, in some ways America’s finest hour. America was afflicted in the 1970s by a systemic crisis analogous to the one that struck Imperial Rome in the middle of the third century A.D. … But unlike the Romans, Americans staggered only briefly before the crisis. They took the blow. For a short time they behaved foolishly, and on one or two occasions, even disgracefully. Then they recouped. They rethought. They reinvented.

Source: How We Got Here: The 70’s: The Decade That Brought You Modern Life—For Better or Worse

Differential Equations and the City

Posted on by John

This afternoon I got a review copy of X and the City: Modeling Aspects of Urban Life (ISBN 0691154643) by John A. Adam. It’s a book about mathematical modeling, taking all its examples from urban life: public transportation, growth, pollution, etc. I’ve only skimmed through the book so far, but it looks like most of the applications involve differential equations. Some depend on algebra or probability.

The book looks interesting. I hope to say more about the book once I’ve had a chance to read it. The examples are all short, so it may be any easy book to read a little at a time.

I also got a review copy of The Book of Inkscape (ISBN 1593271816) today, and I’m expecting several other books soon. It may take a while to get through these since this is a busy time for me. When it rains, it pours.

If you’d like help applying differential equations, let’s talk.