As operating systems consolidate around managed interfaces, they'll choose the Java and .Net VMs, not the Perl, Python, or PHP VMs. But the agility of the dynamic languages and the collaborative energy of their open source communities are two of the pistons that crank the engine of progress. These worlds need to converge -- and at the O'Reilly Open Source Conference there was new evidence that they will. Jim Hugunin, father of Jython (Python for JVM), made a pair of dramatic announcements. He has released the first version of IronPython (Python for CLR/Mono). And by the time you read this, he'll have started his new job at Microsoft. Good hire! [Full story at InfoWorld.com]In my keynote talk at the Vancouver Python Workshop, I stressed the strategic importance of integrating dynamic languages with the Java and .NET runtimes. I've written a lot about dynamic languages and yet, when asked to define what they are and why they matter, I struggle. So from now on, I'm going to point people to this whitepaper by David Ascher, who is the managing director of ActiveState and led the development of Komodo, a Mozilla-based IDE (integrated development environment) for dynamic languages.
Ascher's whitepaper lists a series of challenges for dynamic languages. Topping the list is Lack of strategic vision:
To date, dynamic languages have not been driven by strategic plans. In fact, most successful open source projects (Mono and Gnome being notable exceptions) have enjoyed success in spite of a lack of a long-term plan, let alone a clearly defined vision. The pragmatic, tactical approach to fix what's broken today as opposed to anticipate the problems of tomorrow, has, when combined with the selection processes inherent in the open source ecosystem, led to a survival of the fittest for today's problems, rather than rewarding those with the most compelling vision for future success. It's worth asking if the lack of a plan is guaranteed to be a winning approach in the long term. A good example to highlight here is the different approaches toward newer standards such as SOAP, evident in dynamic languages vs. Java and C#, for example. The dynamic language communities are generally content with letting "someone else" worry about the standards-definition process, and are confident that they'll be able to support them when they are defined and stable. In contrast, Microsoft and Sun have committed significant resources to defining the standard, for clearly competitive, non-altruistic reasons. It is reasonable to expect that the resulting standards have been more influenced by how well they fit with those languages than with languages that got involved late in the standard-definition process. In this case, the combination of strategic planning and the resources of large corporations clearly resulted in shifts in the standard toward more strongly-typed languages. An interesting counter-spin is that dynamic language enthusiasts tend to prefer a different approach to web services over SOAP (namely REpresentational State Transfer, known as REST), which (they claim) is simpler, more pragmatic, portable, robust, and less resource-intensive. [David Ascher]This statement resonates with a number of things I've read lately, including Sean McGrath's remark that "anyone coding middleware in a statically compiled language, working in a commercial environment where time is money, has rocks in their head," and Adam Bosworth's comments about the relevance of REST and lightweight XML-over-HTTP to a services organization such as Google.
Shortly before Bosworth left BEA for Google, we met to discuss the Alchemy project. He remarked, in passing, that he thinks there's a 40% chance that SOAP may still fail. I hope he's wrong. We're going to need a fabric of pervasive intermediation, and the TCP/IP of Web services -- that is, SOAP -- will enable that. But we're also going to need a whole lot of agility woven into that fabric. I want middleware that works like Indigo, but I want to program it in a language that works like Python.
Former URL: http://weblog.infoworld.com/udell/2004/08/09.html#a1055