Why F# rather than IronPython in Visual Studio 2010?

Dynamic languages are all the rage; and after JavaScript, Python is perhaps the dynamic language of the day, loved by Google and gaining increasing attention. IronPython, built on .NET, is stable and at version 2.6. Now Visual Studio 2010 turns up with an additional language in the box, but it is not IronPython; rather it is a little-known language out of Microsoft Research called F#.

Now, F# is very interesting and brings real diversity to Visual Studio; it is great for mathematics and for parallel programming. But wouldn’t IronPython have sparked more immediate interest from the .NET community? Judging by this feature request, with 500 votes, it would. It’s is a little embarrassing for Microsoft that the favoured IDE for IronPython work is SharpDevelop. Plenty of IronPython enthusiasts are pressing for Visual Studio support.

Here’s what IronPython MVP Jeff Hardy says:

I think I can safely say that adding full, high-quality support for IronPython to Visual Studio would require at least a couple of man-years of work. The rabbit hole goes pretty deep when you consider all of the functionality that VS offers, not to mention the difficulty of doing IntelliSense well. I estimate they’d have to at least double the IronPython team to get full support into VS11. IronRuby would require the same commitment.

Hardy is hopeful for VS 2012.

I still find it odd. Official Visual Studio integration would do a lot to raise awareness and usage of IronPython; and make Microsoft’s commitment to dynamic languages more visible – though I guess F# supporters will be happy with Microsoft’s priorities here.

15 thoughts on “Why F# rather than IronPython in Visual Studio 2010?”

  1. > language of the day, loved by Google
    I’d say it’s disputable and heard that they don’t use Python in new projects.

    Being ‘dynamic’ is not enough. Python’s threading sucks, it’s version compability is unstable. Python GIVES NOTHING behind just another language support.

    And do not forget the integration with the .NET object model. OCaml (F#) is a step to being functional keeping OO support, it’s ideal for such a tasks. And Microsoft participates to it’s researches, so it’s perspectives much more clear to them.

    I think MS stakes on concurrency, and Axum (Erlang) + F# (OCaml) are only the first steps on that way.

  2. “I’d say it’s disputable and heard that they don’t use Python in new projects.”
    So why are they funding unladen-swallow? Python has historically been google’s *preferred* language, and I haven’t heard anything about that changing – least of all from all the Python core-developers who work for google (Guido van Rossum, Alex Martelli, Collin Winter, Jeffery Yasskin, Thomas Wouters to name just a few.) I call bullsh*t on that claim – at least without evidence.

    “Being ‘dynamic’ is not enough.”
    It’s a damn good start for concise and expressive languages without the architectural restrictions that static typing brings. This is why dynamic languages in general, and Python in particular, have been growing in popularity in recent years.

    “Python’s threading sucks,”
    Have you tried it? Do you know that it sucks or are you just repeating rumours? I hear a lot of talk about threading problems in Python but very few people who have directly experienced them. For compute intensive or multi-cpu work the standard library multiprocessing module is the recommended route in Python. GIL contention in Python 2 is an issue that came to light very recently and is already fixed in Python 3 and also been backported to Python 2. You seem to be throwing FUD around at a merry old pace. As an added bonus, threading in IronPython uses .NET threading semantics – so threading in IronPython only sucks as much as threading in C#…

    “it’s version compability is unstable.”
    Not true. Python places a very high value on backwards compatibility – which is why Python 3 has been such a major break.

    “Python GIVES NOTHING behind just another language support.”
    But a language that is very different from the traditional languages used on .NET (including F#), and one that is popular and growing in popularity.

  3. The difference between F# and IronPython/Ruby is that F# was basically ready when VS2010 was being planned (late 2007), and already had some VS integration they could build off of. IronPython 2.0 (the first DLR-based release) was still in Alpha at that time, with no VS integration.

    My other theory is that functional languages are popular in the financial/HPFC arena, and that sector has (had?) lots of money – and at the end of the day, that’s what Microsoft wants.

  4. I find it truly refreshing that a major player like MS is seriously backing and betting on a language which enables the brevity of dynamic languages like Python and Ruby, but with the benefits that static typing brings to the table in addition to great support for both OO and functional programming.
    (A practical answer to why MS prefers to support F# instead of IronPython in VS is that F# is controlled by MS, while Python is controlled by an employee of Google.)

    Tim, it’s not obvious that F# will become a success (to quote Leon Starr: “As is so often the case in the software field, ‘popular’ and ‘stupid’ go hand in hand.”), but I have a feeling you seriously underestimate F#.

  5. Tim, it’s not obvious that F# will become a success (to quote Leon Starr: “As is so often the case in the software field, ‘popular’ and ’stupid’ go hand in hand.”), but I have a feeling you seriously underestimate F#.

    I haven’t formed a judgment yet, which I suppose means you are right, but that could change 🙂

    I’m really grateful for the comments here and keen to pick up feedback on both languages.

    Tim

  6. There are some great F# presentations out there, including some by Don Syme and Luca Bolognese, and here’s a great one by Luke Hoban on “F# for Parallel and Asynchronous Programming”, highly recommended:
    http://ecn.channel9.msdn.com/o9/pdc09/wmvhigh/FT20.wmv

    Support for “easy” parallell programming is important, but perhaps even more relevant for most developers is support for easy asynchronous programming. F# and Silverlight may turn out to be a killer combination.

  7. Jeff Hardy got it in 1: F# was ready sooner.

    The tooling is no minor thing, either. Good tooling for dynamic languages is no walk in the park. Witness VS’s JavaScript support.

  8. There are some great F# presentations out there, including some by Don Syme and Luca Bolognese, and here’s a great one by Luke Hoban on “F# for Parallel and Asynchronous fashion Programming”, highly recommended:

  9. F# is not a “little-known” language… F# is a .NET port of the well-known ML language. When Java came out it was the same… What would have been the chances for IronPython to beat the standard implementation?

    F# is a great implementation and to me is the biggest thing in PL community since Java. F# interactive and type inference give to the language a DL flavour but the performance of a compiled one.

    Here is perf measurement on linux:

    http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php

    IronPython is great I think, but to be a VS language is not simply to be popular.

  10. Just to be more precise: it was a port of ML though now it has a syntax and many things on its own. I was suggesting that the language that inspired it has been studied for decades, and taught to many people.

  11. intellij idea has a good ide for ruby..rubymine..the autocomplete isn’t perfect but it’s really really good…

  12. 1. Ironpython runs on Visual Studio just fine.

    2. Ironpython was written on C#.

    3. Ironpython is superior to both C and Cpython because it supports multi-threaded programming.

    4. Inronpython lacks Classes and thus requires C# for that.

Comments are closed.