On Programming Language Futures

One of the things that I think is so cool about the CLR is the fact that it is multi-language… The first commercially successful multi-language runtime environment.  One of the things that I think is neat about that is we have to potential to survive the next paradigm shift in software development…  That is when the next “big language” comes out from someone’s nights and weekend coding or a side project at some large company it could run on the CLR... giving it immediate access to a huge framework of functionality. 

I want to do everything we can to make sure the runtime is ready for that language and the many other “small languages” that will come about.  That is why we invested in Reflection Emit, ILDASM, CodeDom, and other compiler support features (there are even books on the subject)


JasonZ (the head-cheese on the CLR team) recently posted a little about what we did in Whidbey and asks about dynamic languages.  I think there is a very good chance that dynamic languages could be the next big change in the computing world.  Xml and web services are making applications much more about arrogating and sorting through data and that is one thing these languages rock at… And certainly we are seeing results perf as the recent info on IronPyton suggest. 


What do you think?  What is your favorite language?  If you had to bet, would language would you say is going to “as popular as C++” in 5 years?  10 years?  Do you think the CLR will be in a position to support that language?

Comments (24)

  1. Sean Malloy says:

    +1 for Smalltalk as a favourite language.

    Most popular language in 10 years? Perhaps Ruby.

  2. Matt Swift says:

    I just hope we still get to actually USE languages in 10 years! 😉

  3. as populer as c++ in 5 years? hm. c++, most probably. 🙂


    -thomas woelfer

  4. Stephane Rodriguez says:

    – I am not sure there is always a clear distinction between the features of a language and the accompanying base class library. What would C# be without the BCL? Try writing a C# app without the BCL. Try writing a really useful C# app with a minimal use of the BCL. Clearly it’s mixed together.

    – What about expressiveness in the metrics? When I see code like this (http://weblogs.asp.net/Feroze_Daud/archive/2004/03/30/104440.aspx), written with C#, I tend to think it’s low-level C++-like code, yet what it’s doing is nothing really of value, nothing that couldn’t be handled natively by the BCL, especially when it comes to managing encodings.

    – Dynamic languages? I am not sure if I understand the benefits of this. If this means less debuggable, then it’s certainly not for me.

    – Modern languages? Probably in the top 3 I would target the ability for that language to be expressive enough to cope with quick and sharp requirement changes over time. Yes, it means both the BCL and the IDE is involved, but each have their own things to provide to the table.

  5. Grant Boyle says:

    > What is your favorite language?

    C++: templates, STL, MI, RAII, pointers, enough rope to hang myself

    > If you had to bet, would language would you say is going to “as popular as C++” in 5 years? 10 years?

    The most popular language in 5-10 years is likely to be a descendent of today’s Java.

    > Do you think the CLR will be in a position to support that language?

    Not realistically for two reasons: (1) There is no firm comittment to cross platform support which will be non-optional in 5-10 years if not sooner and (2) The language is only half the story, the libraries associated with a language make up the other half. Supporting only the syntax will be ineffective whether you’re talking Java or Python or whatever.

  6. John Lewicki says:

    Its not really a language, but I wonder if MS has anything up its sleeve with respect to aspect oriented programming? Theres an awful lot of momentum behind this in the Java community right now. I recall promises of a new framework to replace ContextBoundObject, IContextProperty, etc. when those classes were ‘undocumented’ right before V1. I havent yet seen anything in Whidbey that could serve as a replacement. Am I missing it? Has the idea of transparent interception fallen out of vogue at MS?

  7. Rick Byers <rick@kinitos.com> says:

    I agree the multi-language nature of the CLR is very cool. However, I think the language-neutrality is sometimes over-estimated. The CLR (and the BCL) is primarily designed for a specific class of statically-typed object-oriented languages, and support for languages with different models has not been without its problems. Reading the reports from language implementers, it’s apparent that the CLR is far from a silver bullet for universal runtime environments (I doubt such a thing is even possible). Your book ("Programming in the .NET Environment") has an excellent set of Appendices describing the efforts of porting various languages to .NET, but I was a little disappointed to see that many of them (like similar papers elsewhere) end with serious caveats such as the inability to interoperate with other implementations of the language, required syntax modifications that break backwards compatibility with the language, or performance being too low to be practically useful.

    I am very impressed to hear of Jim Hugunin’s success with IronPython, and I’m excited to find out if it resolves the limitations previous implementations (eg. Mark Hammond’s Python for .NET) have struggled with. For example, Python supports multiple inheritence, so what limitations will the lack of this support in the CLR place on users of IronPython?

    In my opinion, it’s far from certain that the "next big language" could (practically) run on today’s CLR.

    I believe the important question is whether the CLR will evolve quickly to accommodate alternate programming paradigms as they become popular. I think the lightweight-code-generation support in Whidbey is a great first step. Also, the work being done by Don Syme at MSR on functional languages in .NET and ILX (http://research.microsoft.com/projects/ilx/ilx.aspx) is very exciting. It’ll be interesting to see if some of his extensions are applied in the commercial CLR.

    Personally, my favourite language is probably ML or Haskell, although I must admit I use only mainstream languages (C#, C++, etc) in my work for practical reasons (understandability by other developers, complexity of build/test/deployment, etc). I’m impressed by the work on ML-like languages for .NET (F# and Mondrian), but I’m not yet convinced that using them is necessarily better than sticking with the traditional environments (SMLnj, GHC). I’m also very excited about Xen (X Omega), and can’t wait to start experimenting with it.

    Anyway, I can’t wait to see how .NET language support will evolve. Keep up the awesome work Brad!

  8. Reza A says:

    I am agree with John, I believe, the aspect-oriented programming would be the next big thing in software development, and I don’t see any movement toward it in MS products.

  9. Keith Patrick says:

    My favorite language is still unmanaged C++ (Managed C++ has so many macros in it that it can be nearly unreadable). There are really 3 things about it that made it my favorite: 1) Templates, but managed languages are getting it soon or now. Why? I rarely ever did run-time type-checking. I worked on a project for over a year before I had to hunt down RTTI documentation to learn how to do it (I had done Java prior, but in C++, it was just something I never needed to do), 2) non-null parameter references (& as opposed to * in the decl). I don’t know how this would be done in a reference-based language, as the non-nullable was a) not guaranteed and b) somewhat implicit due to being able to treat objects as stack objects or as pointers, and 3) const modifiers on methods and parameters (want to know how to implement read-only collections without having twice the collections? I had them all over the place in my C++ code. In fact, it was a coding requirement that got enforced in every review.)

  10. Brian says:

    I was surprised by John’s and Reza’s comments that Microsoft is missing the boat on Aspect Oriented Programming. It has always seemed to me that attributes are a big step in that direction.

  11. Jason Zander says:

    Check out the notes from the PDC CLR panel (http://weblogs.asp.net/jasonz/archive/2003/10/30/53588.aspx) on aspect oriented programming.

    AOP seems fine for things like logging function calls, where there are no side effects. but I question its usefulness for everything that it has been applied for. Take locking. You could write a collection class that added an aspect around making every method mutli-thread safe. It would be easy to do using the technique, since you could get a lock enter/leave automatically injected. But the performance would suck as you call many methods in the same class re-entering the lock. Here you should really be thinking about the right locking boundaries and explicitly coding them.

  12. Judah H. says:

    I know this might sound cheesy to say it on a C#-related blog, but I believe C# could be as popular as or more so than C++ in 5 to 10 years. Consider it for a moment – certainly MS shops will be writing C# code and lots of it, especially when Longhorn rolls around. And should Linux ever gain foothold in the desktop market, projects like Mono will be there, picking up steam and will very likely have a loyal following of Linux developers.

    As far as Mono goes, there’s already been a lot of speculation that it could be a major development tool on Linux, and given Novell’s commitment to the project, plus the respect Miguel commands within the Linux community, I think Mono and C# could make it big in the Linux community. If virtually all the Microsoft camps are writing C# code (very probable) and at least some in the Linux camps are writing C# code (also probable), C# could become the language of choice in the future for writing high level code. Of course, C and C++ will always have a place in the low-level applications development and the systems development worlds, but I think there’s a real possibility that C# will be a widely used, if not the most popular, high level language in the coming years.

  13. The next step IMHO is for the IDEs themselves to play nicely with multiple languages. Partial classes help, but I’d really like to see a single code canvas where I could switch between C#, VB, and other .NET languages at will within the same file, and also be able to edit "non-compiled" embedded language elements (such as embedded SQL, CSS, XML, and regular expresssions) with native IDE features rather than having to embed them in strings.

    On-the-fly Babblefish-like translation would be a great addition to this. Sure, .NET languages vary in capabilities (e.g., C#’s "use" vs. VB’s "with"), but if a source code file could be translated *as much as possible*, it would go a long way toward enabling heterogenous teams to work together in their preferred language.

    The number of languages we deal with will naturally increase, but the IDE and compilers must work together to allow seamless integration and editing.



  14. John Lewicki says:


    Thanks for the link; I hadnt read that before. Its good to see that some smart folks at MS have AOP on the radar.

    I not necessarily looking for full a AOP language, I would be happy with something functionally equivalent to the context infrastructure. Ive used that infrastructure quite successfully in some tightly-scoped scenarios (method-level authentication, reconnecting automatically after a connection times out, centralized exception handing). I agree that it requires some care, but it does work nicely in certain situations.

  15. RJ says:

    I would say SVG!!!

  16. Shital Shah says:

    Which language would rule after next 10 years? It would be much like Natural Language where a "compiler" can analyse what you intend to do and generate highly dynamic, evolving and adopting processor instructions. I would imagine it can analyse words and phrases in context much like we human do when explaining the algorithm to each other on whiteboard. It might even have graphical input torepresent your intentions rather then just plain text editor. It might have it’s own historican learning database which could be developed by seperate companies that efficiently can recognise popular constructs and way of doing things (like creating internal appropriate data structures, classes, schemas and choosing Quicksort when you just mention sorting big contact list by name) and heavy use of AI. All of this would make my program actually look like psedo code written in natural language with some graphics. Debugging sessions would be actually making compiler learn about your intentions over the passes (much like explaining algorithm to other person who couldn’t understand right away). Pure English is not consise neither efficient at programming so I would guess it would be a variant or mix of English but much like English. You would be able to write 5 sentenses in this language which otherwise might cause you to create several classes and write lot of plumbing code, lot of other stuff like sort/data update code etc (much like how you explain consisely program outline to another person and expect that other guy will generate code to accomplish what you want).

    Can CLR handle it? Clearly not because this is completely different paradigams not a strict deterministic language. But the C#/BCL/CLR infrastructure will definitely be used to create "compilers" for this "natural language processor" (the same way "old C++" was used to create new language compilers and .Net CLR itself).

  17. &lt;a href=&quot;http://blogs.msdn.com/brada/archive/2004/03/30/104454.aspx&quot; target=&quot;_blank&quot;&gt;Some MSDN blog&lt;/a&gt;
    &lt;a href=&quot;http://java.sys-con.com/read/175807.htm&quot; target=&quot;_blank&quot;&gt;Some other Java blog I’ve

Skip to main content