I’ve always been aware that .NET supports multiple languages (obviously) and that Microsoft has been experimenting with this to some extent. It’s only recently struck me just to what extent this is the case though.
Here’s a list – almost certainly incomplete – of .NET languages from Microsoft alone.
- C#
- VB (or VB.NET if you wish)
- C++/CLI
- F#
- IronPython
- IronRuby
- Spec#
- M (with Oslo)
- Axum
- Managed JScript
- PowerShell
- Cω
- J# (not shipping any more, I believe)
Some of these are research languages which are more important for the ideas they’ve contributed to more mainstream ones at a later date than for anything else – but there’s still a lot of effort represented in the list.
In addition, there are third party languages targeting .NET, such as Boo, IronScheme and Scala. (Wikipedia lists loads of them.)
Now, think back to the time before .NET. Was Microsoft actively experimenting with languages back then? Plenty of people were trying things against the JVM, but Sun was pretty much absent from that party. .NET seems to be a "missing ingredient" that has allowed smart folk at Microsoft to let their imaginations loose in ways which they couldn’t previously. (Of course, not everyone in the language business at MS started there: Jim Hugunin was hired by Microsoft precisely because of his work on IronPython.)
I wonder how long this will continue.
Tower of Babel, or land of polyglots?
What does this mean for the average developer? Currently, if you’re writing a non-web application in .NET, you really only need to know a single language – and any of them will do. (Plus potentially SQL of course…) Compare this with web developers who have to be intimately familiar with HTML, CSS and JavaScript – and the differences between various implementations.
How long will it be before backend developers are expected to know a dynamic language, a static OO language and a functional language? Does the benefit of mixing several languages in a project worth the impedance mismatch and the increased skillset requirements? I’m not going to make any predictions on that front – I can certainly see the benefits of each of these approaches in certain situations. They’ve been designed to play well together, but there are bound to be limitations and oddities: times when you need to change how you write your F# so that it’s easily callable from C#, for example.
Whether or not you learn multiple languages to a professional level is one thing, but becoming familiar with them is a different matter. In the course of co-authoring Functional Programming for the Real World (where "co-author" is a bit of a stretch title – I’ve played more of an editorial role really, with the added bonus of picking on Tomas whenever I felt he was perhaps a little harsh towards C#) I’ve learned to appreciate many of F#’s qualities, but I don’t really know the language. If someone asked me to write a complete application in it (rather than just a toy experiment) I’d be reaching for books every other minute. I hope I’ll learn more over the course of time, but I doubt that I’ll ever be sufficiently experienced in it to put it on my CV. The same goes for IronPython, although I’m considerably more likely to need Python at work than I am F#. (Python is one of the three "approved" languages at Google, along with Java and C++.) None of this means that time spent in these languages is wasted: I’ll be able to apply a lot of what I’ve learned about F# to my C# coding, even if it will make me pine for things like pattern matching and asynchronous workflows periodically.
I think it’s pretty much a given that these days we all need to bring a wide range of technologies to bear in most jobs. While it used to be just about feasible in the .NET 1.1 days to have a pretty good grasp of all the major aspects (ASP.NET for sites and web services, ADO.NET, WinForms, Windows services, class libraries, interop) it’s just impossible these days. We learn something new when we need to – but usually against the background of a familiar language. How well would we cope if we had to learn whole new languages (to the level of being able to use them for production code) as often as we have to learn new libraries?
This worries me a little. I’m pleased to see that C# 4 is a much smaller change than the previous versions were. Admittedly I’d rather have had immutability support than dynamic, but that’s just me… and that’s the problem, too. While I worry about our ability to actually learn everything that’s becoming available, it’s all good stuff. Can there be "too much of a good thing"?
What I really don’t want to see is developers having to know multiple languages, and everyone knowing them poorly. I’m a big believer in having a thorough understanding of your language, so that even if everything else is new, you can rely on your understanding of that aspect of your code. It would be a shame if the pressure of knowing many languages turned many of us into cargo cult programmers. The utopia would be for us all to turn into language renaissance developers. I suspect the reality will be somewhere between the two.
Still, as long as I get to keep helping authors write about languages I know almost nothing about, I’m sure I’ll be happy…
Jon Skeet's coding blog 
Thank you for discussing this topic which Bothering me since a while, and lead me to the question that rise from this 1 mach speed of new technology.
If I focus on what I know now and expand my knowledge to get thorough understanding of it, will I wake up tomorrow and find myself had missed the train? On the other hand, if I follow the wave and try to keep up to date with all of these new languages and technologies, how could I find the time and effort to grasp all these in thorough understanding?
So, how could one balance between the two? Just a question…
LikeLike
“I’ll be able to apply a lot of what I’ve learned about F# to my C# coding”
I think that’s the key. We don’t necessarily need to learn many languages, a few will do provided they teach us different things. As I’ve moved from COBOL to C to VB to C# to Python to Ruby (with some digressions along the way) each has extended the set of conceptual tools I can bring to bear on a problem. Heck, if I went back to COBOL now (not something I’m exactly gagging for, mind you) I bet I’d do it heaps better than I did when I considered myself expert a couple of decades ago…
LikeLike
http://en.wikipedia.org/wiki/List_of_.NET_languages
Add C Omega to the list (an incubator project but a worthy one)
J#
PowerShell is worth a mention too
I love that they added f#, the impedance mismatch between FastFunc and Delegate is a pain but apart from that the flexibility is amazing. I want it given the same love in 2010 as VB.Net and c# :)
I do feel a pang at not being anywhere close to the same standard at f# as I am in c#. I really need to use f# more for that.
LikeLike
I fully expect the trend to move toward polyglot programmers and am much anticipating it. Heck, hopefully it serves as another inspiration for your average developer to “get off the couch” and start applying themselves, for the sake of their company and the world. The “developer” still needs to make great strides toward “professionalism” as it is.
Though languages exist (like C#) which have both dynamic and static aspects to it I think it’s unreasonable to expect such languages to be “good enough” to be used for everything. Some languages are going to have their niche, and with the continued penetration of DSL’s, the “Babel” factor is only going to increase.
I reckon that corporate policies that are anything different than “we will develop this component in the most suitable language available” will ultimately lead to the lowering of market value and relevance for that organisation.
LikeLike
You might be interested in my code generator which will convert your .net assembly written in c# to java, javascript, php or javascript.
See homepage at http://jsc.sourceforge.net
LikeLike
Skeet,
Nice post … I agree with almost all of your points except …
“If someone asked me to write a complete application in it (rather than just a toy experiment) I’d be reaching for books every other minute.” … Perhaps, but I have a feeling your level of comfort is based on being a ‘stone cold’ expert in the language as you are with Csharp and Java. IMHO. Most capable devs are not absolutely expert in a language … rather they seek to know a language well and have a strong understanding of areas related to their work. I think the number of libraries (third party and bundled) and the breadth of concepts (for example: J2ME, J2EE, Windows Mobile, embedded, the list is almost endless) on the major platforms make it extremely difficult to do otherwise. So, if somebody can take F# concepts and code and rewrite them in CSharp they’ve got the F# language nailed pretty well. IMHO.
“How long will it be before backend developers are expected to know a dynamic language, a static OO and a functional language?” … I don’t agree. Clearly, the changes and the rate of change in CSharp to a great extent make it possible to do ALL of those things (functional, dynamic and OO) without ever leaving C#. And I think that its an awesome thing to see the language grow in several new directions almost simultaneously!!
LikeLike
What about javascript?
LikeLike
@Shuggy: Darn, I meant to include PowerShell when I was originally composing the list. Will update it – and add links for IronScheme etc.
LikeLike
Anon: Yes, I’ll add managed JavaScript too…
LikeLike
IMHO libraries and frameworks will be the key to the future, as they have been in the past, and stable languages will be the winners.
If we discuss the benefits of C then surely one of its greatest strengths is that the core language had only 4 major changes since 1969. C became the “Language abstraction layer”, the one that you could count on for every machine instruction set since the PDP-7, and when you wanted something new you got a library not a new language.
http://en.wikipedia.org/wiki/C_(programming_language)#History
Now, I know the new rage is “application oriented languages” with internal and external DSLs and a sort of move away from a core language and libraries, but I think if we are not careful that we are going to see a sort of “DSL hell” on the horizon.
Don’t read this the wrong way. I am not saying that developers will not need multiple languages, they will, since languages provide different abstractions, styles, assumptions and perspectives on solving a problem, but I think that the list will be closer to 5 then 50..
BTW.. didn’t we just get “Link to X”, where x was a DSL in the set {SQL, XML, anything} to get rid of the DSLs for the average developer?
LikeLike
First of all, the research and unsupported really languages don’t count as virtually no one uses these languages in production. Is your gripe that they are made available on the internet?
Let’s take out the research/unsupported languages and focus in on what will be available in Visual Studio 2010:
VB.NET/C# – Really the same language as the grammar is just slightly different.
C++/CLI – For mixed mode projects. Every single release of .NET has had a form of C++.
F# – For researchers, algorithm experts and those working with a large degree of concurrency. The terse syntax allows for experimentation and fast implementation. Immutability provides a level of safety not available in other .NET languages.
IronPython/IronRuby – Microsoft’s plan with these languages is to lure away web folks currently writing on Linux.
M – If you can explain an elegant way to do the same thing in an existing language I would be on board. The benefit of being able to convert grammars on the fly is huge.
PowerShell – Microsoft has long needed a first-party scripting language for system administration. However, I do agree that most would be better off just using IronPython/IronRuby for the same tasks.
After some reflection, it seems to me that Microsoft could safely cut it down to five and maintain the same level of language domain coverage:
OO, FP, Mixed Mode, Dynamic, Data
C#, F#, C++/CLI, IronRuby, M
The others seem as though they exist mainly to keep old users users around (VB) or attract new users from other platforms (IronPython and PowerShell).
In any case, I don’t think you have much to worry about. Mainstream programmers will stick with what they already know (VB/C#). Interop programmers will continue to use C++/CLI. The other languages are simply opening up the .NET platform to a whole new range of domain experts. In the end we will all benefit greatly from it.
LikeLike
This isn’t really .Net specific, this is a trend elsewhere as well. How many languages compile down to Java byte-code and target the JVM (JRuby, Groovy, Scala, Clojure, Jython, Rhino, etc.)? The CLR and JVM are turning into platforms, on comparable footing to processor architectures. How many languages compile to x86, for example?
I don’t necessarily think this trend will force C# (or Java) programmers to learn all of these other languages any more than C++ programmers are forced to learn Lisp, Pascal, Erlang, Javascript, or assembly. On the whole I think this is actually a good trend. Because there are many advantages to byte code based platforms such as high-quality shared libraries/frameworks, better security models, virtualization options, greater platform independence, etc.
In 10 or 20 years we may look back and wonder how anyone could be crazy enough to write so much software that compiled down to bare-metal machine code. It may very well be the norm by then that the only things you ever explicitly compile to machine code is a managed runtime / byte code virtual machine.
LikeLike
@Richard: I don’t have a “gripe”. I’m ambivalent about it – I can see huge benefits to having so many options, but also potential drawbacks. We’ll see.
@Wedge: The difference between Java and .NET here is that Microsoft has done a lot more of this experimentation (and in a shorter space of time) than Sun did with the JVM.
LikeLike
Of course the last sentence of my previous post should have been “LINQ to X”…
LikeLike
Jon,
The vast majority of programmers are ALREADY cargo-cult programmers. We HAVE to be – the frameworks are too large, the platforms too extensive, and the choices too broad to be otherwise.
One-trick ponies are a dying breed, and with good reason – but I haven’t seen ANYTHING in the new glut of languages that makes me jump up and shout “I gotta get me some of that!”. Most of it merits a “meh” at best. It’s just not that exciting. We’ve got problems to solve. Real work to do. Learning the language-of-the-day is not a productive use of our time. In fact, learning anything other than the bare minimum required to complete the task in front of us is not a productive use of our time.
I humbly suggest that Microsoft FIX SOME F’ING BUGS instead of release yet-another-language. C# 4 included.
Note: this rant in no way reflects any disrespect to your own personal awesomeness. Please don’t delete my intrinsic field.
LikeLike
Too many tools, too lesser tool users.
I guess there is explosion of tools & it adds so much complexity. They said COM was a problem, so there is .NET.
Doesn’t .NET come with its own complexity baggage?
Also, there are 10 ways of doing data access. I guess, we would know which one is suited for a given scenario (when would I use hibernate vs data services vs plain old ado.net?)
I know, this is a profession which requires updating oneself. But how does the business get benefited by our use of ORM vs ado.net? We don’t seem to be worried about it.
The sad thing is technology drives the market than the other way round.
LikeLike