What about robustness? In a world where computation lived within a single VM, strong type-checking and bytecode verification may have been reasons to prefer languages such as C# and Java. But we don't live in that world any more. Computation is distributed; interfaces are language neutral and document oriented; cross-domain trust is a work in progress. In these circumstances, dynamic languages -- which neither the Java nor .Net VMs yet fully embrace -- may be the best way to tame the services network we are now constructing. [Full story at InfoWorld.com]
In a comment on this article, Ted Leung asks: "Web services networks are networks of loosely coupled services. Part of the flexiblity of dynamic languages results in looser coupling in programs. Is this what Jon was after?"
Yes, in part. There are so many facets to this issue, though. One that I didn't allude to in the column, but think about a lot, is the role that I have long believed dynamic languages should play in the rapid development of what we are now calling "rich Internet clients," or what Adam Bosworth has recently been calling the Web services browser. It's always been interesting to me that in the early years of the Web, the terms "Perl script" and "cgi-bin" were often synonymous. The server-side Web was programmable, and a dynamic language was the way you did that programming. Those of us who saw application lifecycles shrink from years to days, or from months to hours, got a thrilling taste of what it could be like to evolve software in near-realtime, in response to immediate feedback from users.
The client-side Web was programmable too, but in ways that have only recently begun to live up to the original promise. Meanwhile, our communication clients -- email (and for some of us, nowadays, RSS) -- remain fixed-function monoliths that are, to this day, extended mainly by C, C++, or maybe nowadays Java or C# programmers.
I do think that dynamic languages can help us tame the complexity of server-to-server communication on Web services networks. The reason: we simply don't know which arrangements will prove workable and which won't, and we'll need highly productive RAD tools to plow through lots of experiments. By the same token, we know very little about how to best enable people to interact with Web services. Here too, we'll need all the productivity and flexibility we can get.
Former URL: http://weblog.infoworld.com/udell/2003/08/25.html#a780