Steve Vinoski's Blog

Multilingual programming is one of my all-time favorite topics, and I feel very strongly that software developers should be adept at multiple programming languages. Developers need to be able to apply whatever language in their arsenal best suits the problem at hand, and perhaps even quickly learn a new language if what they already know doesn’t fit.

Too many developers seem to think that familiarity with one general-purpose language is good enough, but it isn’t. Knowing one language forces you to try to bend or change problems to fit whatever that language happens to be. That’s like trying to solve a problem by choosing a data structure or algorithm to use without ever considering the nature or details of the problem.

One of my favorite quotes on this topic is from Steve Yegge:

…an “X programmer”, for any value of X, is a weak player. You have to cross-train to be a decent athlete these days. Programmers need to be fluent in multiple languages with fundamentally different “character” before they can make truly informed design decisions.

Yes indeed.

Too many developers also come up with weak excuses for not learning new programming languages, most of them being just different ways of saying, “But it’s different from the language I already know!” Don’t whine about the differences — instead, learn to appreciate them and take advantage of them.

I’ve hinted at the fact that I like this topic in previous issues of my Internet Computing column when I covered the usefulness and applicability of languages such as JavaScript and E4X, Ruby (twice), and Erlang (also twice) for middleware and integration projects. My latest column, entitled “Multilingual Programming” (PDF), attempts to provide a few reasons why knowing and being able to apply multiple languages can be highly beneficial. As always, I welcome comments and feedback.

[Update: if you prefer not to read PDF, this column is now also available online in HTML.]

Shell scripts as web services? Perhaps an obvious question, but hasn’t this capability already been around for about 15 years?

I see that at least one person on the planet believes I’m the “Father of CORBA.” I can certainly understand why people would think that, but I can definitely say that it’s inaccurate.

In 1989 Hewlett-Packard bought Apollo Computer, where I worked as a diagnostics engineer. Five years prior to that I started my career at Texas Instruments as an electrical engineer working on integrated circuits, and ended up having to write a lot of testing software despite having no software training whatsoever, except for a freshman class in BASIC required for all engineering majors. I found I really liked software, though, so I joined Apollo because the job there was half hardware and half software. By late 1990, though, Hewlett-Packard politics had just about killed the group I worked in, and my manager told me I’d be smart to find myself something else to work on before I was forced to do so. I had been developing a hardware debugger in C++ that involved distributed computing, so I looked around the former Apollo site for any groups using C++ in distributed systems. Turned out Jim Waldo was leading such a group — they were building the first Object Request Broker (ORB). I joined them in January 1991, which was 6 months before the first version of the CORBA spec was published. Ken Arnold was also part of that group. I joined just as they wrapped up the first ORB prototype.

One could argue, therefore, that Jim Waldo is the Father of CORBA, since he led the development of the first ORB. Alternatively, one could argue that Joe Sventek is the Father of CORBA, since he was the editor of the first CORBA specification (Joe was also at HP, though he worked in a different group located in California). However, while they both played important roles in initially defining CORBA, there is to the best of my knowledge no single person who can be called the Father of CORBA. Rather, it was definitely a “design by committee” effort, and I certainly don’t count as one of the fathers since at that time I wasn’t even part of the committee.

BTW, here’s a bit of trivia: for those of you who remember Cliff Stoll‘s “Stalking the Wily Hacker” and “Cuckoo’s Egg” publications, documenting his successful effort to identify who was hacking into computer systems at Lawrence Berkeley Laboratory, Joe Sventek’s account was one that the hacker used to gain access. Joe explained to me that he had been away from the laboratory for quite awhile, residing in the U.K. I believe, so red flags went up when there was activity in his account.

I finally got around to watching and listening to Bob Ippolito‘s “Exploring Erlang” video, and I don’t know of any more thorough hour-long introduction to the language than this one. If you’re interested in Erlang but are too busy or too lazy to read Joe Armstrong’s great book or any of the many papers and articles that describe Erlang, then Bob’s talk is for you.

A few interesting points for me:

• In a few places Bob mentions that while he finds Erlang syntax unusual it’s really no big deal, and you quickly get used to it. I can verify that he’s absolutely right. A lot of people seem to get really hung up on this issue; if you’re one of them, all I can say is that your concerns are very greatly exaggerated.
• Along the lines of the previous point, one of the questions Bob takes after his presentation is from a gentleman who says that his technical lead refuses to use Erlang — in a telephony application, no less — and that his tech lead rolled his own stuff for concurrency and interprocess communication. Hmm, I wonder if that technical leader’s initials are “N.I.H.” It would be interesting to see how well his solution could hold up in the environments in which Erlang has already well proven itself. Given all the attempts I’ve seen over my career at solving such things, many of them made by people who mistakenly think it’s not that difficult to get right, my guess is “not that well.”
• Bob mentioned that he finds Erlang to be a very small and thus easily learnable language. He’s absolutely right about that, too; I wish I could count the number of times I’ve said the exact same thing in conversation, in presentations, and in writing. Many people who come from Java or C++ or other general-purpose languages assume that languages need to be huge to be useful, so they assume that small languages must be toys, and they also assume any “real” language requires years to learn. How incredibly wrong they are.
• Bob keeps the whole discussion grounded by explaining how Erlang saves him and his team time and money. In case it’s not clear, he’s talking about actual time and actual money. He explains that he can serve millions of web requests per day from just a single machine (though he naturally uses more than one for redundancy and reliability), for example, and by mentioning the small size of his team — I think he said 8? — he hints at the productivity that Erlang affords. My experiences are, again, quite similar.

Coincidentally I also watched Jim Weirich‘s “Shaving with Occam” presentation from the MountainWest RubyConf 2008 held at the end of March, and was pleasantly surprised to find that he devoted a good portion of his talk to Erlang. He mentioned how it was like Lisp in the sense that it has a small core, simple rules for manipulating that core, and powerful abstractions for building new things from the simple rules and small core. Yet, I shouldn’t be surprised. I don’t know Jim at all, but judging from the dates he mentions in his talk I think his career spans around 30 years. It’s also pretty clear that he’s had broad and deep experience with many technologies during that time. From what I’ve seen, people like Jim who have an incredibly deep first-hand understanding of the utility and importance of simplicity, brevity, and powerful abstractions in software development seem to have no problem whatsoever quickly seeing and comprehending the immense value of Erlang.

You’re still not exploring Erlang? What are you waiting for?

Nick Gerakines has posted a detailed example of a RESTful web service implemented using Erlang and Yaws. It provides a lot of implementation information that I didn’t have room for in my InfoQ article on this topic.

Sam’s issue isn’t addressed here either, but no matter, the details of Nick’s example are worth examining nonetheless.