At TechDays in Belgium Micrososft’s C# designer and Technical Fellow Anders Hejlsberg spoke on trends in programming languages; you can watch the video here.
I recommend it highly, not so much because of any new or surprising content, but because in his low-key way Hejlsberg is a great communicator. The talk is mostly not about the far future, and much of what he covers relates directly to C# 4.0 and F# as found in Visual Studio 2010. Despite his personal investment in C#, Hejlsberg talks cheerfully about the benefits of F# and gives perhaps the best overview of functional programming I have heard, explaining what it is and why it is well suited to concurrency.
I will not try and summarise the whole talk here; but will bring out its unifying thought, which is that programming is moving towards a style that emphasises the “what” rather than the “how” of the tasks it encodes. This fits with a number of other ideas: greater abstraction, more declarative, more use of DSLs (domain-specific languages).
The example he gives early on describes how to get a count of groups in a set of data. You can do this using a somewhat manual approach, iterating through the data, identifying the groups, storing them somewhere, and incrementing the count as items belonging to each group are discovered.
Alternatively you can code it in one shot using the count keyword in LINQ or SQL (though Hejlsberg talked about LINQ). This is an example of using a DSL (Domain Specific Language), and also demonstrates a “what” rather than “how” approach to code. It is easier for another programmer to see your intention, as there is no need to analyse a set of loops and variables to discover what they do.
There is another reason to prefer this approach. Since the implementation is not specified, the compiler can more easily optimise your code; you do not care provided the result is correct. This becomes hugely important when it comes to concurrency, where we want the compiler or runtime to utilise many CPU cores if they are available. He has a screenshot of Task Manager running on a 128-core machine which apparently exists in Redmond (I can’t quite read the figure for total RAM but think it may be 128GB):
Hejlsberg says there was a language doldrums between 1995 and 2005, when many assumed that Java was the be-all and end-all. I wonder if this is a tacit admission that C#, which he was working on during that period, is not that different in philosophy from Java? The doldrums are over and we now have an explosion of new and revived languages: Ruby, Groovy, Python, Clojure, Boo, Erlang, F#, PowerShell and more. However, Hejlsberg says it makes sense for these to run on an existing framework – in practice either the Java or .NET runtime – since the benefits are so great.
Hejsberg also predicts that distinctions such as dynamic versus static languages will disappear as each language absorbs the best features from other languages. “Traditional taxonomies of languages are breaking down as languages pick paradigms from each other,” he says. The new language paradigm is multi-paradigm.
Just as C# has now acquired dynamic features, we can expect it to get better support for immutability in future (borrowed from functional languages).
Hmmm… Python grew (and thrived) during 1995 and 2005. Ruby existed during that time, but didn’t take off until the Rails explosion. Erlang similarly, plus Clojure, Boo and F# are all based on existing languages (Lisp, Python and OCaml respectively). The “doldrums” of languages was only for those who had their eyes elsewhere. 🙂
Also, “it makes sense for these to run on an existing framework – in practice either the Java or .NET runtime – since the benefits are so great” needs qualifying; what are those benefits? In practise I see more benefit for the .NET runtime being able to Python than for Python being able to run on .NET… (In other words Hejlsberg sees the future in terms of the major runtimes, whilst languages like Python and Ruby would see the future very much in their own terms – with the major runtimes needing to support them in order to remain relevant.)
On the other hand this is very encouraging: “The new language paradigm is multi-paradigm”. Of course Python has *always* seen itself as a multi-paradigm language.
I think that may be this system. The 128 GB is an OS limit; the box has more.
@Michael All good points. Re. runtimes, one thing I recall Martin Fowler saying is that JRuby was easier to sell to corporates than native Ruby because they drew comfort from the fact that it ran on a tried and trusted runtime. Hejlsberg simply refers to the richness of the existing frameworks.
Tim
The advantage of the CLR and the JVM is that corporates don’t have to throw away their considerable investment in existing code.
At the bank I work in we have 10 yrs+ of working, debugged, tested, documented Java code. We’ve used both Jython and Groovy to leverage our framework in new ways.
I expect we will end up doing the same thing with Scala and Clojure at some point as well.
Its a similar story with our C# code, F# will help up leverage that code.
Craig, that is 64 core system. I believe Anders used this one (and he probably used native code to get 100% CPU usage, unlike my 50%):
http://www.danielmoth.com/Blog/windows-7-task-manager-screenshot.aspx
There’s a big difference between doldrums and focus. I’d say that in the period between 1995 and 2005, there was plenty of language development activity going on. But businesses were not paying attention. They were focused on getting business done so Anders’ other creations like Delphi were getting exercised thoroughly in IT shops all over the world. Two things are driving the renewed interest in languages, in my opinion: Multi-core CPUs and better language interop options. Getting 8 to 16 CPUs to hum using C# isn’t easy. But with PLINQ or F#, it’s quite possible to do so without a herculean effort. And using Python from my C# code has traditionally been too slow for me to consider using it for serious applications. But the Dynamic Language Runtime (DLR) integration into .NET 4.0 changes that with CallSite caching. The polymorphic cache that is in the box with .NET 4.0 has boosted my C# to Python code speed by a factor of 10,000. I’ve gone from hundreds of transactions per second across the C# to IronPython bridge before .NET 4.0 to millions of transactions per second. One million percent improvements in any field generally make businesses sit up and take notice. And when businesses take notice, activity in the field picks up in response. That’s the phenomenon that we are witnessing, in my opinion.
Kevin is right. It was in the early 2000s that F# began development. Many inside the movement knew of the great benefits but the industry pressure to stay the same was great. It wasn’t until the manycore crisis became truly manifest that the these types of languages were invited into the fold. Even then, the adoption has been a bit hesitant.
The truth of the matter is that adding dynamic features to existing languages isn’t enough. Without immutability, all of the other functional features combined won’t solve anything. The big problem here is that the entire existing .NET library was written for mutability. To have a truly safe environment for manycore programming, the entire framework needs to be rewritten.
C# looks at the world with Enterprise development shop glasses, and as such it adds up.
It is important to remember though that there are other uses of computers in the wild than Enterprise data centers.
Luckily, otherwise programming would suck badly.