Despite lots of second-guessing, there is no consensus that the CLR is inherently unfriendly to dynamic languages. The JVM didn't bend over backwards for such languages either, and yet Jython is a great success thanks to the heroic efforts of its inventor, Jim Hugunin. Now Hugunin has turned his attention to .NET, and reports promising results with a prototype Python implementation for .NET called IronPython.The day this story posted, Larry O'Brien pointed me to Jim Waldo's essay, To type or not to type, which says in part:
Such projects always seem to spring from an inspired individual or small team. In fact, Microsoft has such a team. It created JScript.NET, the most dynamic of Microsoft's .NET languages. But JScript.NET is the unloved stepsister of C# and VB.NET.
Dynamic languages are rooted in a culture that is simply not indigenous to Redmond. That may change, but for the time being, the future of dynamic languages in .NET lies with non-Microsoft innovators. [Full story at InfoWorld.com]
When we argue over whether or not a programming language should have types, we are not discussing a matter of fact. Instead, we are participating in what [linguistic philosopher John L.] Austin would call confessional language; what we are really doing is saying something about ourselves.
In particular, I think that those who advocate typed languages are (generally) participating in different kinds of programming exercises then those who advocate untyped languages. In particular, people who argue for strongly typed languages tend to be involved in projects that are
- large, with lots of interacting components;
- require multiple people to work together;
- will take a long time to develop (weeks or months, not hours); and
- will live for a long time, changing over that time.
On the other hand, people who like untyped languages tend to be involved in projects that
- require lots of prototyping;
- are done by one person, or a small group of people;
- tend to be small or short term; and
- often are used for a short period of time, or are not altered through their lifetime.
I've been thinking about this for a couple of days, because it's true that my own programming work is better characterized by the second list of attributes than by the first. Does this mean my passion for dynamic languages merely reflects my own orientation?
This led to another question: what is a large system? I tend to regard any application -- even a dozens-of-modules, millions-of-lines-of-code application -- as a good-sized component that participates in the large system we call the Web.
It's no accident that Perl was the original language of choice for programming that large system. Perl's dynamic nature was just what we needed in an environment that was itself dynamic, producing new services that could interact in unpredictable ways to yield emergent outcomes.
Nowadays Python is my first choice. Its approach to typing -- strong and dynamic -- is part of the reason why. But for programming the Web, I'll reach first for any of the dynamic languages before I'll reach for C# or Java. I've only recently been able to explain why. It's about the data. No one programming language's (or VM's) type system can (or should) span the Web. That's why XML has become one of the primary ways we invent, absorb, and interconnect data models. Dynamic languages offer complementary affordances.
Ten years ago I wrote my most widely cited BYTE cover story, called Componentware. I said then that software development was becoming a two-tiered system. There would be a relatively small number of component builders, working in compiled (today: JITed) languages such as C and C++ (today: C#, Java) to produce reusable components (today: services). And there would be a relatively large number of solution builders, working in scripting (today: dynamic) languages such as Visual Basic (today: Perl, Python, Ruby) to produce applications.
That components-and-glue metaphor still describes the software world today -- if anything, much more powerfully. The object orientation and static typing features of the JVM and the CLR are tools of the component builder's trade. And the dynamic features of what we still often call scripting languages are tools of the solution builder's trade. This isn't an either/or situation, though. Software development works best when the membrane that divides the component builder from the solution builder is flexible and porous, because the two activities are not as distinct as we suppose. This, I think, is why Sean McGrath calls Jython "Java's strategic weapon for the 21st century." And it's why I continue to want first-class dynamic language implementations for the CLR. The two tribes that Jim Waldo identifies are, roughly, the component builders and the solution builders. Dynamic languages are not only the solution builders' best tool. They're also the best way for the two tribes to collaborate on programming the planetary web of data.
Former URL: http://weblog.infoworld.com/udell/2004/03/03.html#a932