Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

C# Futures, Diminishing Returns, and the Scala Parachute

 A while ago Jeremy Miller posted about C# futures. In response to his own thoughts on what might be required, including mixins for example, he suggested that c# may be approaching the same point, that further changes post C# 3.0 might push it over the point of diminishing returns.

There is an experience of diminishing returns on languages and frameworks. At a certain point adding new ideas to a language increases its complexity so much that the productivity benefits form the new features are outweighed for anyone coming in to the language by the cost of learning its idiosyncrasies. Part of the issue here is boiling frogs problem. Those of us using the language do not notice the complexity burden increasing, because we only have to cope with understanding the additions, but for someone arriving fresh at the language, it’s like jumping into boiling water. It’s much like a long-running TV show, where new audiences cannot grasp all the references to previous shows and so never start watching. In the end the networks cancel the show, because it cannot attract new viewers and the existing ones are not being replaced as they fade away. Our hit show plays out as re-runs. MFC became more and more complex with time, especially after it shifted to include support for OLE, to the point where it became too hard for many people to start developing with it, so now, for application developers at least, it tends to be legacy code.

It looks as though, for Bruce Eckel at least, Java has passed the point of diminishing returns.

What is interesting beyond the realization that the Rubicon may have been crossed is not some kind of CLR vs. JVM triumphalism but the assertion that new features belong in new languages, designed to be that way from the ground up. Bruce notes that for some developers the choice is to leave Java for a new language and interestingly its not Ruby, but Scala. Ignoring the, Ruby is no longer cool, Scala is, message that has somewhat clouded the debate, the interesting part of Scala (which has a .NET implementation) is that it may be an easier transition for Java developers than the switch to Ruby, especially those who may prefer a statically typed language over a dynamic one. Of course what is easy for Java developers is also easy for C# developers.

Maybe it is possible that rather than focusing on changes to C# the C# team should pick up on the goals of Scala, to incorporate functional language features into a new language that is more familiar to C# developers than Ruby, but at the same time is designed from the ground up to incorporate the functional programming features that otherwise might be shoehorned into C#.

About Ian Cooper

Ian Cooper has over 18 years of experience delivering Microsoft platform solutions in government, healthcare, and finance. During that time he has worked for the DTi, Reuters, Sungard, Misys and Beazley delivering everything from bespoke enterpise solutions to 'shrink-wrapped' products to thousands of customers. Ian is a passionate exponent of the benefits of OO and Agile. He is test-infected and contagious. When he is not writing C# code he is also the and founder of the London .NET user group. http://www.dnug.org.uk
This entry was posted in Featured. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://pro-thoughts.blogspot.com/2008/11/best-of-f-and-c-nemerle-scala-various.html Vladimir Kelman

    @Ian, I think there is an attempt to introduce on .NET platform a language similar to Scala in its way of combining OOP and functional features using a familiar syntax, it’s Nemerle: http://nemerle.org/Main_Page
    I don’t know how good/successful it is. I, personally, learn Scala. As far as I know, Martin Odersky still wants to produce both JVM and CLR flavors of Scala in parallel, despite many voices asking him to drop .NET support. Scala is fantastic, and it’s a pity there is currently not enough resources to keep up in Scala .NET development.

    @Jeremy, by the way – Scala is a statically typed language, not a dynamic language like Ruby or Groovy, but it does not prevent it from having all the cool features similar to Ruby – thanks to advanced type system of Scala and well developed type inference.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller


    It’s not just wanting a dynamic language with all the goodness that metaprogramming can bring. I’d also want to tap into all the cool tools and libraries that the Ruby and Python communities have already done and continue to do. For that reason, IronRuby and IronPython easily trump any kind of Dynamic C# or the newer VB.Net. Yeah, I guess we could write our own RSpec equivalent, but I’d rather just use RSpec.

  • Pranks


    Just curious to know, whether its possible or not for C# team.

    If Microsoft can come out with Dynamic VB ( VBx ) to compete with dynamic languages that Run on DLR, Is it possible to introduce ” Dynamic C# ” and offer best of the things Ruby + Python + Etc has to offer.

    I think with Dynamic C#, developers willing to adopt Dynamic language will be thrilled.

    Since IronRuby, IronPython, Dynamic VB, PHP for DLR can come, why cannot Dynamic C# knock the door.

    Just a futuristic vision,—– thats all.

  • Ian Cooper


    I love LINQ and the language enhancements in C# 3.0.

    I would really like to see the next version of .NET pick up on some of the framework shortcomings. For example it would be great to see support for M:M mappings, table per concrete class or class when mapping inheritance, mapping Value types as opposed to Entity types (i.e. where the type has no identity in the Db, and is composed of 2-3 columns in another entities row; useful for concepts like Money which can have value and denomination), support for RDBMS other than SQL Server etc.

    But these are additions to the framework not changes to the language.


  • Casper

    You are probably right Ian, C# could’ve reached feature saturation at this point. Having said that though, I am quite impressed with the readability of most of the stuff. For instance, within prior exposure to LINQ, even an empirical Java zealot starting each morning cursing at .NET, would still be able to read what’s going on here without too much trouble:

    var query = from file in Directory.GetFiles(@”c:\logs”, “*.log”)
    from line in new LineReader(file)
    let entry = new LogEntry(line)
    where entry.Severity = Severity.Critical
    select entry;

    I find this to be quite a nice marriage, unlike some of the advanced stuff (the fold operator or custom operator associativity for instance) that we see in Scala which I really don’t see making it as a general purpose language. No doubt Scala is “the Ruby of 2008″ and it shall be interesting to watch what IDE and debugger support will do and whether non-CS people can follow along.

  • Ian Cooper

    @Stephan and Casper

    I think Bruce’s point is less, the future is Scala, and more don’t try to push functional language idioms into an existing imperative language, because you will hit diminishing returns due to backward compatibility. Instead, if you think that combining the OO and functional paradigms in one model, in a form accessible to your existing language users, is a goal: build a new language to do it.

    So, I am in one sense agreeing with Jeremy, that the best next step for C# may not be to incorporate more functional features because you will hit diminishing returns.

    Instead if you want to transition your user base to a functional paradigm, consider the approach of something like Scala which sets out with the goal of bringing functional programming to Java developers in a familiar yet clean fashion.

    In a sense it is an alternative to adopting F# to go functional.

  • Casper

    Stephan: As far as I read, Bruce is not recommending Scala as much as pointing out it is the only savior for the JVM. Clearly people can not agree on what belongs in Java, purists state “you can do it all with interfaces” while pragmatists really just want some language abstractions to help getting their job done. Personally I am not entirely convinced of Scala, it feels very research’ish and before to be crowned “next Java” it needs to prove itself useful to corporate developers as well. Flex on the other hand, already has proven itself, whether you like it or not.

  • http://stephan.reposita.org Stephan Schmidt

    I wrote about Scala and Bruce today :-)


    Someone wants to bet how long Bruce will recommend Scala? After Flex?

  • Ian Cooper


    F# is a functional language on the CLR, but I don’t believe it has the familiarity that Scala has for Java (or even C# programmers). I suspect Boo may have the same issues. The design goals for Scala seem to be about exploiting a familiar’ish syntax.

    It could be suggested that a lot of the reasons for Java’s widespread success was the familiarity to generations of C-language family programmers, who found the idioms recognizable.

    Scala may be taking a similar approach. It is in essence, what Java would look like if you were able to switch to use declarative over imperative approaches, without worrying about backward compatibility. The point about Bruce Eckel’s article, which I pick up on here, is that it is trying to be backwards compatible that kills. So rather than create a C# that is backward compatible and supports cool new features like mixins, just create a new language that is like C# but has those features without the need for compatibility.

  • Mike Breen

    I guess Scala isn’t even that cool anymore. To be really hip you need to be using Io, http://iolanguage.com/scm/git/checkout/Io/docs/guide.html#TOC681

  • Joann

    I believe that is why F# is getting so much attention in .NET world.