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# — I don’t care if it’s Rubenesque as long as it’s Rubyesque

A week or so back David Ing raised a concern that the new language features in C# 3.0 are bloating the language.  Jim Downing adds to the conversation by asking if C# if Fit or Fat.  I certainly understand their concerns, but for me, waiting for the new C# 3.0 features is like being a 5-year old on Christmas Eve knowing that the package in the corner is a Milleneum Falcon toy.  I think Linq is overhyped, but the stuff they supposedly did just to support Linq is going to rock.  The movement in regards to programming languages that I’m seeing is to pack more punch with less code weight, and I think the C# 3.0 stuff is going to help the mainstream move in that direction.

  1. Filter/Map/Reduce type functional programming constructs.  I’ve never even gotten to use a language in anger that has these features (except JavaScript with Prototype), but I find myself wishing for them quite frequently.

  2. Lambda expressions.  I’m using anonymous delegates quite frequently now, but the syntax is fugly.  I’ve spoken with developers who won’t use them because they feel, with some justification, that the resulting code is just too unreadable.  Lambda expressions are going to make the code noise go down.

  3. Type inference.  Again, this is going to reduce code noise – and without sacrificing static typed checks from the compiler.  I love what Generics do, but the resulting code is also fugly.  One of the advantages of a Ruby or Python over C# is the extra “noise” code in C# compared to duck typed languages.  Type inference helps alleviate that issue in C#, especially with Generic type declarations.

  4. Extension methods.  Bring it on!  I’ve been wanting them badly on my current project.  I think the Fluent Language stuff we’ve been talking about the last couple weeks will be much easier to extend with extension methods.  I thought of an extension method I want to add to RhinoMocks today for StructureMap integration in testing.

Yeah, it’s more things to know, and somebody is going to write truly atrocious code with the new features, but I’d rather have the sharpest tools possible and I’ll be responsible for not cutting my fingers off. 


What do you think?  Exciting new stuff or unnecessary cruft.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://www.vikramlakhotia.com/ Vikram

    I am eagerly waiting for the C# 3.0 release. I think it will make my code a lot more cleaner and the features like linq will change the way we work with database and XML………..

  • http://gutzofter@blogspot.com Joseph D Gutierrez

    Did you know you can write an application in C without using pointers? I guess my point would be that as long as these ‘new’ features to the C# language are transparent, I’m cool with that. I had been out of software for about 10 years and came back bypassing the Java ‘phenom’. Started back in software with C# and ran into delegates. Hmmm… who needs that. Oh I do when I want to use an event driven architecture, but I could have kept my ignorance and still have written apps. I think for any new features that this is MUST!

  • http://blogs.conchango.com/howardvanrooijen Howard van Rooijen

    I really don’t like the use of the keyword “var” for type inference – I’m not sure what it is, but having “var” in C# makes me feel dirty!

    I really wish they’d use another keyword (such as “infer”) which is less ambiguous – var has too many historical links to variant types…

  • http://community.hdri.net/blogs/chads_blog cmyers

    @Jeremy: I bet Smalltalk had ’em! 😉

    @Steve: What is bloated? C++. Somewhere between where C# is now and where C++ is now is a shark waiting to be jumped.

  • Steve

    Why would anyone not want language enhancements to make C# more powerful, flexible, etc… ?

    Hmm, what is ‘bloated’ ?

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


    Keep in mind that none of these features are brand new inventions. Every single thing I mentioned is available today in other programming languages. In some cases these features are 10-15 years old. There’s plenty of material on best practices for this stuff, but we’re gonna have to reach outside of the normal .Net sources.

  • http://community.hdri.net/blogs/chads_blog cmyers

    @ Z-Bo – “That sounds like a bad sign”

    Blowing the breeze of current fads and trends is bad if you’re a religion. I’m starting to think that languages are the same way.

    If your language has to keep changing to keep up with things than either a.) it wasn’t designed for longevity in the first place or b.) it’s time to start over.

    Maybe it’s time we broke C# up instead of cramming more crap (albeit good crap) into it.

  • http://community.hdri.net/blogs/chads_blog cmyers

    You know, language feature creep is a design smell, imho (see: C++).

    With everyone talking about how great Ruby is or Boo is or this that or the other thing, and given that we have this wonderful CLR, are language arguments even relevant?

    Rather than stroking Anders’ pride and making C# the One Language To Rule Them All (and in the darkness bind them), why not make a bunch of smaller languages that are SIMILAR in syntax (thus eliminating a lot of learning curve), but have specific things they do VERY well and mixing and matching where you need it.

    Need a DSL? Use SuperFancyDSLLanguage. Need to do some AOP? Use blah blah you get the picture.

    We’re kinda already there with Boo, Spec#, etc. Why not make that the preferred way?

  • John "Z-Bo" Zabroski

    @Sergio Pereira
    @”It’s a good sign that the language is being kept fresh and alert to current trends.”

    That sounds like a bad sign, though, doesn’t it? A language should not be based on current trends, because they are by definition trendy. A language should be built on concepts that you think will last. However, the notion of being “alert to current trends” is pervasive in language design. As the joke goes, a language designer will finish designing the language when it meets their needs.

    Come to that, its clear the most important evolutions in language design come from innovations that remove accidental complexity from the task of writing software.

  • http://www.evanhoff.com/ Evan

    Exciting new stuff waiting to be abused to write even worse software..lol

    The language isn’t the problem in the c# community.

    I’m looking forward to the new language extensions. I still need to read up on how to properly use them in my designs.

  • http://grabbagoft.blogspot.com/ Jimmy Bogard

    I was really excited until I heard the news of DLR and IronRuby, etc. Internal DSLs, Fluent Interfaces, etc. look cleaner and are easier to write in Ruby anyway.

    With the DLR, there’s no need to settle for Rubyesque any more, just use Ruby. And with IronRuby running on top of DLR, why should I invest time in something like NBehave or Scott’s NUnit.Spec, when RBehave and RSpec will be so easy to integrate in the future with the DLR?

    In any case, these features absolutely make C# a sharper tool. People that disagree are probably those wanting dull tools for all of those Morts out there.

  • http://www.developernotes.com Nick Parker

    I think people are slowly looking for a happy medium between the syntactic elegance that they can get with Ruby and also the ability to lean on the compiler with statically typed languages. I think we will see tooling evolve for dynamic languages to provide the later of some sort.

  • http://www.albertrosa.com Albert Rosa

    Change is always good, yea sometimes its unneccessary but if it can be done better then do it better. I am always looking for something new especially if it will make my coding life much easier!

  • http://youredoingitwrong.mee.nu mcgurk

    I’m afraid that the C#/.NET team at MS is going to continue on this path of packing more shit into the language. Yeah, it may cause more ‘noise’ if there’s only one way to do something, but its easier to support code that does X the same way everywhere than it is to spport code that does X five different ways in five different places. I can hardly wait until the day when I sit down and see that someone has implemented a whole class’ worth of functionality as extension methods to the String class.

    What I hope is that, instead of adding new features into the language, they concentrate on the libraries next. Faster, stronger, better. More shit like System.AddIn, less shit like lambda expressions. Or maybe spend some time making it easier to construct testing frameworks… hell, I don’t know. But what I don’t ever want to see is them getting too feature-happy.

  • http://substantiality.net Sam Smoot

    Since extension-methods compile down to c#2 I couldn’t think of a good reason not to use them once a supporting CTP came out 6-ish months ago. Any opinions on that?

  • sergiopereira

    How can someone not like features that make the language more concise? It’s a good sign that the language is being kept fresh and alert to current trends.
    Imagine if this was the other way around, if they decided to cut these same features from the next release? No way. Bring them on.