In a change from things beautiful, here’s a post about something not-beautiful. A recent message on the Haskell web-devel list asking about the meaning of the word “gateway” triggered this rant.
CGI stands for “common gateway interface,” and is basically:
a web server invoking another program,
with a specifically defined set of environment variables set to various values related to the request and the program’s location in the filesystem,
communicating further information via sending it to the program’s stdin, and
receiving a header and body response on the other end of the program’s stdout, which it then may process before returning it to the HTTP client.
I don’t know how old it really is, but certainly for the last decade at least, since the rise of perl and Java, there’s been a constant debate about “static” versus “dynamic” typing systems.
I’ve seemingly flipped back and forth myself. I spent the ’90s doing things like tcl and perl hacking, started full-time in Java in ‘99, and even switched an entire company off Python and on to Java1. After that, Ruby snuck in to solve some of the frustrations of Java, and before I knew it I was doing all of my work in it. Then came Haskell. From the “usefulness of the type system” point of view, Haskell is really on the opposite end of the spectrum from Java, with Ruby in the middle, but you have to be somewhat less naïve than average to see this.
A couple of friends and I recently decided to write a mailing list server in Haskell. We’ve taken some derision for this1, with people telling us that there are plenty of them out there already, but we also have a couple of fairly powerful forces motivating us to do this. One is, of course, to learn Haskell better, and nobody can really argue with that. But another is that there are certain features missing from other mailing list managers that I feel are important.
久しぶり (“hisashiburi”) in Japanese means, more or less, “Long time no see.” And it’s been more than eight months since my last post; so much for the promised next one on DSLs!
As it turns out, the pressures of programming full time, running a business on top of that, and making a little non-computer time for myself leave little time for my “mostly for fun” computer-related activities, such as mailing lists, TSAC, and of course this blog. I will admit I’ve been spending a noticable amount of perhaps less-productive time posting to the TLUG mailing list; I’m thinking I should try to redirect a bit of that here.
As we improve our programming skills, we learn in different ways, and from different sources. Drawing my my experience and current state, my theory de jour is that your level of learning and the technologies and methods you use fall into four different stages.
The article certainly gives good advice: make your software maintainable, generalize when necessary, have a change-friendly environment. But it doesn’t give much help when it comes to the specifics how one might implement these rather general concepts.
Here’s my hint on the matter: I suggest, when you’re sitting down to develop a feature, you design and write the code and the system around it with not only the intent of making it perform the function you need now, but also with the intent of being rewritten later.
Despite the amount of time we here at Starling seem to spend on sales, business administration, accounting, systems administration, and all of the myriad other things that go along with running a small business, we still find a reasonable amount of time to spend on actual development. Development, besides being our most enjoyable activity, is after all the whole point of the company.
We sit between a couple of computers and a whiteboard, and though we’re often writing code, we’re constantly switching back and forth between typing, talking, and drawing. Much of the work we do during this would be considered “design” or “architecture” work in many shops, and would be done in meetings separate from the time you spend in front of your computer coding. That’s why we prefer to call what we do during these times, “development” rather than “programming.”