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.]

In my Jan/Feb Internet Computing column, Serendipitous Reuse (PDF), I talked about interface coupling and the benefits of REST’s uniform interface constraint. I find that whenever you discuss that topic, though, REST detractors tend to say, “Well, you’re just pushing the coupling problems to the data.”

The problem with that assertion is that it assumes coupling is a fixed constant — if you eliminate it from one point, whatever you’ve gotten rid of just has to pop up somewhere elsewhere, like some sort of strange “Conservation of Coupling” law. Of course, that’s not true. In my latest column, Demystifying RESTful Data Coupling (PDF), I turn my attention to this claim and explain how RESTful data works, and why it too, like RESTful interfaces, reduces coupling when compared to WS-* and other similar approaches.

Constructive feedback welcomed, as always.

As you may know, I’m a columnist for IEEE Internet Computing (IC), and I’m also on their editorial board. Our annual board meeting is coming up, so to help with planning, we’ve issued a call for special issue proposals.

The topics that typically come up in this blog and others it connects to are pretty much all fair game as special issue topics: REST and the programmatic web, service definition languages, scalability issues, intermediation, tools, reuse, development languages, back-end integration, etc. Putting together a special issue doesn’t take a lot of work, either. It requires you to find 3-4 authors each willing to contribute an article, reviewers to review those articles (and IC can help with that), and a couple others to work with you as editors. As editors you also have to write a brief introduction for the special issue. I’ve done a few special issues over the years and if you enlist the right authors, it’s a lot less work than you might think.

As far as technical magazines go, IC is typically one of the most cited, usually second only to IEEE Software, as measured by independent firms. I think one reason for this is that it has a nice balance of industry and academic articles, so its pages provide information relevant to both the practitioner and the researcher.

A little over a week ago, Ron Schmelzer of ZapThink, who’s pretty well known as an expert SOA analyst, quietly snuck an interesting comment into the ESB brouhaha that developed here recently. The ESB proponents who expressed displeasure at my view of ESBs, especially those who quoted ZapThink in their defense, will want to read what Ron had to say. If you don’t feel like chasing that link, here’s what he said:

The poster (Curt) who says that ZapThink says that ESBs are an enabling technology on the road to SOA has mischaracterized our position. Speaking from ZapThink’s perspective, we don’t believe that ESBs are neither necessary nor sufficient to enable SOA. In fact, we’ve seen plenty of SOA solutions that leverage a wide variety of non-ESB infrastructure. To be as unambiguous as possible: ESB is vendor marketing spin. True, there is certainly capabilities within an ESB that *might* enable companies to produce truly loosely coupled, composite, and heterogeneous Services in an environment of continuous change, but you can just as easily build tightly-coupled, proprietary, point-to-point Service integration with ESBs. There’s nothing about an ESB that substitutes for the need to do architecture. And there’s nothing about architecture that requires the adherence to a particular technological infrastructure.

If you want to make SOA work in a heterogeneous environment, why would you want to limit yourself to one technology, one approach? You’re buying right into their strategy of locking you into a platform. That’s only good if you sell platforms. Wake up folks - architecture is YOUR responsibility, not that of some vendors hawking middleware!

So, don’t put ZapThink in the camp of the ESB bigots. We certainly are not. Implement SOA with intermediaries and REST. Why not?

In a comment to the many comments on my post entitled “The ESB Question,” Bill de hÓra gets it right:

I’m disappointed with the responses here. Steve’s an expert technologist in this domain. There’s a real opportunity for learning when the ESB approach is *appropriate* - instead we see the same old reactionary web v enterprise positioning and the usual suspect arguments being rolled out against REST style integration.

Bill’s right; the discussion has unfortunately mostly degenerated into the usual no-light-all-heat “us vs. them” argument. I especially object to the folks who twist what I say and accuse me of saying things that I never even remotely hinted at, but I guess that’s the price of blogging publicly.

I’m not going to try to address the comments individually, especially the ones from the guys who, amusingly, wrote lengthy diatribes explaining to me just what ESBs are, what they’re supposed to do, and why they’re beneficial. Yes, guys, I get all that. Perhaps you should go back and read some of my publications from 3, or 4, or 5 years ago? Funny how I don’t recall any of you being around back then, when I felt more positive about ESBs (hint, it was before that term was coined) and I was blogging and writing to that effect.

Arguing this issue on technical merits is rather pointless. One of the best comments in this thread was from Dan Hatfield:

Honestly, I see the ESB as primarily a political thing. It allows for a greater degree of control on delivered solutions. In large companies, we don’t often do architecture - we do politecture…The politics drive the architecture. Not the way it should be…but that’s the way it is.

So true, so true. Another non-technical way to look at it is from the viewpoint of Clayton Christensen’s classic book, The Innovator’s Dilemma. For quite a few years now, we’ve seen a series of sustaining innovations in the “object/service RPC” line of descent originally popularized by CORBA and COM, both of which built on earlier RPC, distributed object, and TP monitor technologies. RMI, EJB, SOAP, WS-*, and ESB are all offspring in that line, and there are surely more to come. I feel that REST, on the other hand, fits the definition of a disruptive innovation perfectly (and if you’re too lazy to read the book, then please at least follow the link, otherwise you won’t understand this at all). The proponents of the sustaining technologies look at REST and say, “well it can’t solve this and it can’t solve that” and voice numerous other complaints about it, precisely as Christensen predicts they would. But Chistensen also explains why, at the end of the day, any real or perceived technical shortcomings simply don’t matter (and in this case, they’re mostly perceived, not real). HTTP-based REST approaches have a lower barrier to entry and are less complex than anything the sustaining technologies have to offer, and REST is disrupting them, whether all the smart folks pushing ESBs like it or not. It’s not a technical issue, and there’s no amount of technology the non-REST tribe can throw at it to stop it because it’s based on how markets work, not on the technical specifics.

At the end of the day, if you don’t think REST is viable or you don’t like dynamic languages, then don’t use them. It just means that you’re at a different point than I am on the Technology Adoption Lifecycle curve. Like I already said in my first follow-up, I’m not in that business anymore, so it doesn’t matter to me at all. I’ll just keep using what I know to be generally superior to all the other approaches I’ve worked on over the years.