I will admit to being a huge (read, fawning) fan of Paul Graham. I've never met him, but I think his essays are terrific (especially the ones on Lisp). He clearly has a ninth-degree black belt in programming, and yet he's one of the most clear-headed prose writers I've read when it comes to dilating complicated technical subjects. I, personally, would have no idea how Lisp macros — the single most powerful and mind-bending concept I've encountered in programming — work without the benefit of his book On Lisp, which has been circulating freely as digital samizdat on the Web for many years. Since I aspire to be both a black belt programmer and a clear-headed writer, I tend to take what he says and does very seriously indeed.

I'm not alone, of course, and so when Graham announced that he was creating a new dialect of Lisp (called "Arc"), I and many others got very excited. We were all particularly intrigued by the statement of design philosophy that appeared on his home page a couple of years ago, and have been waiting with bated breath ever since.

Well, Arc is out. And with its release (more of a stable pre-release) came a torrent of criticism. In fact, the criticism began years ago (Arc is vaporware, etc.). I won't rehearse the criticism here; I'll just make the general point that people have a lot of damn gall.

As far as I can tell, Paul Graham's reasons for writing Arc are the same as for any voluntary development project. He'd like to give himself the tool he wishes he had, he'd like to amuse himself intellectually, he'd like to explore various aspects of design, he'd like to play around with some ideas he's had for years, and he'd also like to contribute something useful to the world. These seem to me excellent reasons for doing just about anything, and it's nice that he's chosen to throw in the last one.

There are several legitimate reasons to feel miffed about software. You might be frustrated with the release schedule or the number of bugs or the fact that such-and-such a feature isn't implemented yet. You might find the community that supports it unhelpful or the authors arrogant and imperious toward their users. You might think the whole thing is wrong from the start.

If it's a commercial piece of software for which you've paid money, I can understand angry charges and criticisms. But FREE (as in beer, as in freedom, as in range, whatever) software? What gives anyone the right to shoot their mouth of like this?

It's not that people can't have these opinions. It's that they air them so freely and with so little charity. Graham would be well within his rights to take his toys and go home, after all. He wouldn't be the first FOSS developer to do so. It seems like once a month some talented hacker writes a farewell letter in which he or she admits that the constant battering is starting to wear them down.

I'm not suggesting that people stop critiquing software and design philosophies. Nor am I suggesting that everyone suppress their natural frustrations. I'm merely suggesting that all such critiques and frustrations be firmly wound up in a gentle cloak of charity, good will, and constructiveness. It might be true that the developer can tell a jackass from a contributor, but he or she might not. And the consequences of beating up on people in this way is the suppression of the motives I outlined above. Do we really want a world in which people don't play for love of the game, but only because they're compelled to by some other force?

In that piece on design philosophy, Graham wrote, "The great languages have been the ones that good programmers designed for their own use– C, Smalltalk, Lisp." I think he's right about that, and I think we could probably generalize that sentiment to lots of areas of human endeavor. Fortunately for us, lots of people with that idea have drawn the perfectly humane conclusion that what's useful to them might be useful to others. If drawing that conclusion brings you nothing but grief, there's no loss in really making it something for your own use. After all, couldn't you just work on the project for love of the game and keep it to yourself?

If I were Graham, I might be asking myself why I'm even bothering. And that bothers me.

Stéfan Sinclair, one of DH's most talented hackers, responded to the last post with a question about the "dominant language" in DH. I suggested it was Java, but (as I noted in the comment thread), I really have no basis for saying that. Here's Stéfan:

I’d say (as unempirically) that there are more DH projects developing (not just using) code with scripting languages like PHP, than there are with Java, especially outside of the larger centres. But maybe this is just speculation based on what I see as the norm for project cycles: a researcher (or small team) gets some funding which includes money for hiring some research assistants – often graduate students – who are more likely competent in PHP (or Ruby or Perl) than in Java. Moreover, I think DH projects tend to favour getting something up fairly quickly over design and robustness; another reason why scripting languages would be more prominent. There are centres with dedicated staff willing and able to work in Java, but that seems to me a relatively rare luxury.

I didn’t mean to nitpick regarding a minor part of the post, I was just curious. I don’t think it’s crowning a champion programming language that matters, it’s more about how the reality of the DH research environment should be influencing the curriculum (or perhaps there are too few of us teaching programming for it to matter that much).

I think Stefan is probably right, but of course, both of us are relying on general impressions.

When you look at the development of computer science curricula over the last few decades, you can clearly see that discipline responding to industry pressures. Scheme might remain the language of Hal Abelson's venerable 6.001 course at MIT, but in general, we've watched CS go from Pascal, to C, to C++, to Java as the demand for engineers with particular "skills" has changed out in the real world. I don't know many CS professors who think C++ and Java are good teaching languages, though. Many of the professors I've talked to actually long for the days of Pascal, but they also know that students will object to learning a language that isn't in common use.

When I started out in programming, I asked a friend (a very skilled hacker who was pursuing a Ph.D in CS at the time) what language I should learn first. I remember very clearly his answer, which was something like, "Oh, I don't know. Just pick one. It doesn't matter. How about a fake one? There are lots of cool pseudo-languages out there that will teach you what you need to know . . ." I thought he was 100% insane, and I was astonished that this guy — who was and is a master programmer, in addition to being a highly skilled theorist — would suggest something so obviously out of touch with reality. A few years later, I realized that he was 100% right. What's important in programming is the concepts. If the goal is to learn programming and software engineering, the language literally doesn't matter. Abelson's Structure and Interpretation of Computer Programs (the textbook for 6.001), not only uses Scheme, but avoids explicitly teaching the language, per se. It's perhaps the best book I've ever read on programming.

DH, thankfully, is not burdened with "industry pressures" in the way CS is. When I tell my students that it's the concepts that are important, they believe me. They believed me even when none of their programming friends knew what Ruby was. I think they'd still believe me if I suggested that we all learn Haskell or Miranda. And that's a good thing.

Still, it would be very useful to know what languages people regularly work with in DH. If we knew the answer to that question, those of us who teach programming for the Humanities (and I know there are only a few of us out there) could perhaps structure the teaching of the concepts in such a way as to make it easy to transfer that knowledge into other kinds of languages. I do this a little bit already, by occasionally pointing out the ways in which different languages — like C or Javascript — approach some concept that we're studying in Ruby. I do that in part to emphasize that the fundamental concepts of programming don't change drastically from language to language.

It would also be good to know what languages people use in DH, because it might help us to focus development where it's most needed. We've been talking quite intensively about "tools" over the last few years in the DH community, but I've always felt that "tools" might best be thought of as an alias for libraries and APIs.

It's not possible to do a scientific poll on a blog like this, but I suspect my readership has enough hackers in the ranks to get some good anecdotal information.

So how about it? What languages do you use? What languages do the people around you use? What languages are people telling you you should know? I'd love to hear about it!

Well, it's time to pick up another programming language.

I've been doing this about once a year since the late nineties, and in that time, my motivations for programming glossolalia have changed a few times. At first, I think I mostly wanted to jump on the latest bandwagon. I was also highly susceptible to arguments from more experienced hackers about how such-and-such a language was the Greatest Thing Ever. But after awhile, I found myself wanting to study languages because I find them completely fascinating. Nowadays, I think it's just a way to expand my thinking about what languages are and what they can do.

But honestly, after doing this ten or twelve times, I find that I'm beginning to stray into the outer rim. What's next? Haskell? Erlang? I had more or less decided that I'd do one of those over the summer, but a couple of days ago I stumbled on Groovy.

What's Groovy? A language with an absurd name, for one. But beyond that, Groovy (according to the home page):

• is an agile and dynamic language for the Java Virtual Machine
• builds upon the strengths of Java but has additional power features inspired by languages like Python, Ruby and Smalltalk
• makes modern programming features available to Java developers with almost-zero learning curve
• supports Domain-Specific Languages and other compact syntax so your code becomes easy to read and maintain
• makes writing shell and build scripts easy with its powerful processing primitives, OO abilities and an Ant DSL
• increases developer productivity by reducing scaffolding code when developing web, GUI, database or console applications
• simplifies testing by supporting unit testing and mocking out-of-the-box
• seamlessly integrates with all existing Java objects and libraries
• compiles straight to Java bytecode so you can use it anywhere you can use Java

I've used a few alternative languages for the JVM, including JRuby, Jython, and Kawa. I mean, what's not to like? The syntax of Ruby, Python, or (be still my beating heart) Scheme with all the might and magic of the Java class library? What could be better?

In my experience, the original languages and runtime environments are better. I don't know what it is. I always feel like the Javish stuff just don't belong there somehow — like it's some kind of crude hack. And before I get hate mail, let me say that these implementations are not crude hacks. They're very skillfully done. There's just something about the mixture that doesn't sit well with me.

I haven't started looking closely at Groovy yet, but I can see the general plan. They've taken some of the best ideas from languages like Ruby, Perl, Python, and Smalltalk, kept the general contours of Java's C-ish syntax, and built a scripting language that has all the soul-stirring power and ubiquity of the Java class library in a nice little package. And, of course, it's trivially easy to embed Groovy in Java or to integrate them in some other way.

Now, I might find it annoying (that is: slow, or poorly documented, or whatever). But if it really does have the ease of use and expressive power of a good scripting language, I may start teaching it in my Digital Humanities courses. I've been teaching Ruby to English majors for a number of years now, and I still think it's a magnificent teaching language. But if Groovy was similarly good for teaching and allowed an easy migration path for students interested in Java, I just might be sold. Java is the dominant language in DH, and while a few of my students have been able to pick up Java after learning Ruby, it would be nice to have a language that was semantically closer to Java. I could imagine a class that goes through Groovy, and then ends by starting off with Java. But then, Groovy really would have to be groovy.

They will have to change the name, though. Can I really have a course description that says we'll be learning Groovy?

I'll report back when I've played with it some more.