use Perl

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