This was initially inspired by Matt's entry about Joel Spolsky's observations about the .NET CLR.
The .NET CLR isn't very exciting, at least now. Perhaps if Microsoft delivered on the promise of getting Eiffel, Haskel, Oberon, Smalltalk, Perl, Python, APL and JavaScript all working in .NET as first-class languages, then there might be something to examine. As it stands, Langauge Independance today on .NET means exchanging {, } and ; for begin, end and end-of-line. I agree with Joel here; the promise isn't very compelling.
But Microsoft did identify something important: multi-language development. The main issue they are trying to resolve are C++ component producers and VB component consumers, dealing in a world where documentation and interfaces are a little too opaque for everyone to be happy. Java has solved this problem, and Perl doesn't seem to have an issue with open/opaque interfaces (modulo the odd, poorly documented and buggy XSub). That's all well and good, but the issues that need resolving are integrating Java/Perl/C/C*, SQL, JavaScript, HTML, a templating language and perhaps some XSLT into a single project.
Those languages won't be integrated into a single runtime, or unified into a single language, because they each focus on solving a different problem in a different domain. Maybe if the entire world were recast as a big LISP machine, multi-language development would go away, but there's an equally strong argument that you'd instead need to invent 4 and 5 different sets of LISP macros or LISP dialects to do what Java/SQL/XSLT do already.
Add it all up, and it looks like multi-language development is a fundementally good idea (or at least the best idea we came up with over 60 years of trying). Distilling that down to a single Ur-syntax won't fly (unless you constrain yourself to solving the problem of the C++ producer and VB consumer).
Everything old is new again. Who'dve thunk it?
Re:The past revisited. Again.
ziggy on 2002-05-06T20:52:09
That's a really astute observation. With all of the hoo-hah about cross-language compatibility within a single VM, I never saw it as a rehashing of calling conventions.Surely there is more to CLR and
.NET than just that. Or has the idea of a "compatible calling convention" simply been upgraded to include method calls, object definition, versioning, cryptographic signatures and reflection? And do you really need to have a VM for all of that? Re:The past revisited. Again.
Elian on 2002-05-06T21:10:05
It's a little more than calling conventions--there are exceptions as well. But that's about it, and getting cross-language exceptions isn't that big a deal either.
All the other stuff is either upgraded calling conventions (method calls, reflection) or fancy dynamic loader stuff (versioning, crypto signatures). And no, you don't need a VM for it at all. You can do it entirely as normal, compiled code.
The single biggest hurdle is the initial definition of the conventions, and that's as much engineering tradeoffs with the political ramifications that go with them as anything else. It's definitely much easier to put them in place from the start than it is to add them in after. (Which is why the new 'systems' have a more coherent base for this than older systems. Witness what the JVM gets you as opposed to what you get on a Unix box, for example)
