Steve Vinoski’s Blog

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?

I just returned home from QCon London, and its excellence exceeded my expectations. As usual, the quality of speakers QCon attracts (just like JAOO) is outstanding, and they cover a very wide variety of topics.

Kent Beck’s keynote was excellent. It was about developer responsibility, developer integrity, and the relationships developers have with those around them (here’s a good summary). Extremely insightful, not unexpectedly of course, and covering important topics that are unfortunately often taboo among technical folk.

It’s been awhile since I spent any quality time with Kent, but we did manage to sneak off to a back room at the speaker party on Thursday evening and get 20 minutes or so of conversation in, which is better than nothing. Given that the first two to drop in were Jim Webber and Joe Armstrong, though, neither of us minded the extra company. Generally, though, I think I could easily spend a couple solid days talking to Kent about development issues.

I spoke in Stefan Tilkov’s track on Thursday, and I thought it went OK. Stefan has already provided detailed notes on each talk (except his own, which was really good) on his blog, so I won’t bother with repeating any of that. I got to meet Paul Fremantle in person for the first time, which was nice, though I have to say I remain puzzled by his “REST is too hard for the average developer” claim he made in his talk, since it definitely doesn’t match my recent experiences with watching others learn it and apply it. I’ve heard Sanjiva say the same thing before as well, so I wonder if it’s just something they keep telling themselves, hoping it will come true if they repeat it enough. ;-)

On Friday I thoroughly enjoyed Simon Peyton-Jones’s Haskell talk and Joe Armstrong’s Erlang talk. Both were excellent speakers, and both talks ventured into areas that I’m sure many of the attendees were not familiar with, so I’m sure most everyone who listened learned a lot. Thankfully there were no “Haskell vs. Erlang” wars, but that’s not surprising given that Simon and Joe are friends, plus they know that that argument serves neither language.

The best part of the week, though, was getting to meet and hang out with Joe and other Erlang folk. Joe’s really an excellent guy. He’s quite energetic, and his brain just doesn’t stop. He’s curious about a lot of technical things beyond Erlang, and I found discussions with him to be full of interesting questions and insights. Given the fact that I work with Erlang quite a lot these days, my hope going in was simply that I’d get a chance to just say hi to him, but I turned out to be lucky enough to spend many hours with him over the course of the conference. I also met Francesco Cesarini, a well-known and long-time Erlang consultant, whom I’m sure has probably forgotten more Erlang than I’ve learned so far. I also met Alexis Richardson, who works on RabbitMQ, the right way to implement AMQP. Francesco graciously invited me to speak at the Erlang Exchange this summer, so I’ll be seeing them all again before too long to talk even more about what’s quickly become one of my favorite programming languages.

Congrats to Floyd, Kresten, and the whole QCon team for putting on yet another excellent conference. I’m looking forward to JAOO Australia (in both Brisbane and Sydney) next!

When I spoke at QCon San Francisco last November, Stefan Tilkov interviewed me, and the video is now available on InfoQ.com.

We covered a range of topics: CORBA, dynamic languages, REST, distribution, concurrency, Erlang. Stefan asked some great questions, and I hope I gave some worthwhile answers. Thanks again, Stefan.

Mark Baker:

I’ve had enough. I’m not participating in any more “REST vs. SOAP” discussions. When I started on this mission to educate those who didn’t understand how the Web could help them, I figured it would be pretty straightforward; I’d explain it, they’d understand, and then we’d all skip away hand-in-hand whistling show tunes. Of course, it didn’t quite work out that way. Instead, I ended up spending on the order of $100K of my own money on travel, as well as the opportunity cost of many hundreds of otherwise billable hours, for what is working out to be essentially nothing in return. If that weren’t enough, my health has suffered the past year or so, in ways I won’t get into here, but that I’m confident are in part attributable to the despair I’ve felt over this extended period of frustration.

Mark, I’m sorry to hear about your situation, and I certainly can’t blame you for your decision. As you say, the war really has been won, and you’ve more than earned a break. I saw you take many arrows — and I mean many arrows — over the years as you patiently explained REST to the world and worked hard to keep the wrong technical things from happening in the standards committees. For whatever it’s worth, I greatly admire and applaud your strength and your perseverance, and congratulate you on your achievements.

I also want to sincerely thank you for personally bringing REST to my attention in an email exchange way back around 2000-2001. Over the years REST has helped transform and improve the way I view and develop distributed systems, so much so that it played a big part in my decision to leave a long and well-established career in middleware development about a year ago and switch to developing software for an entirely different industry. In my current position, I’m thankfully free to use REST when and where it makes sense without having to fight all the stupid battles that you’ve understandably grown weary of.

An aside: the personal toll that Mark is suffering is most unfortunate. There’s simply no room in technical discussions for the negativity and hate that causes situations like that. Yet, despite the fact that the war is indeed over, and even though most of us now try to boringly proceed with useful logical discussions, there are still a few hostile jerks out there who didn’t get the memo. For example, I recently had to completely ban one such jackass from commenting here due to his continued personal attacks and insults, not only against me but against Mark, Tim Bray, and anyone else who supports REST. (Thankfully he adds no technical insight or knowledge whatsoever to either side of the discussion, so it’s no loss.) It saddens me that the destructive voices of hate like his can sometimes drive the bright, insightful and truly useful voices like Mark’s out of a technical conversation. It’s up to all of us to continuously try to prevent such situations, whether we’re discussing REST or some other topic.

Mark, thanks again for all your efforts. If there’s any way you think I can help, don’t hesitate to let me know.

Via Tim Bray, a commencement address by Bruce Eckel. It’s worth reading the whole thing, but I found this part especially interesting:

An even more fascinating metric is this: 5% of programmers are 20x more productive than the other 95%. If this were a science, like it claims, we could figure out how to get everyone to the same level.

Let’s say that this follows the 80-20 rule. Roughly 80% of programmers don’t read books, don’t go to conferences, don’t continue learning, don’t do anything but what they covered in college. Maybe they’ve gotten a job in a big company where they can do the same thing over and over. The other 20% struggle with their profession: they read, try to learn things, listen to podcasts, go to user group meetings and sometimes a conference. 80% of this 20% are not very successful yet; they’re still beginning, still trying. The other 20% of this 20% — that’s about 5% of the whole who are 20x more productive.

The lesson here is that if you want to be a great developer, you’ve gotta put in the extra effort that Bruce talks about. There are no shortcuts. In my experience, I’ve seen that there are quite a few developers who rarely read things that pertain to their profession, never attend conferences or talks, and certainly never look into trying new approaches that are even the slightest bit different from what they already know. Well, unless they’re forced to, of course, via organizational changes or layoffs. I don’t understand why anyone would willingly choose a profession for which they’re unwilling to invest in continuous career-long learning.

I also like what he says here:

You need to pay attention to economics and business, both of which are far-from-exact sciences. Listen to books and lectures on tape while you commute. Understanding the underlying business issues may allow you to detect the fortunes of the company you’re working for and take action early. When I first started working I looked askance at people who paid attention to business issues — that was suit stuff, not real technology. But those people were the smart ones.

Another reason to pay attention to the business side is that it’s actually rare that the best technology wins. I used to struggle greatly with this, and over the years I’ve seen many developers do the same. Understanding how markets work and how technologies advance in the marketplace is important for every developer, so they can put their work in perspective and perhaps be a little less religious about it.

So, from these ideas, my two recommendations for 2008 are:

1. Learn a new programming language or new approach that takes you out of your comfort zone.
2. Study one or more technology-focused business books.

In both cases, you’ll be very glad you did.