Will C# 3.0 become an uglier version of Python ?

It is now about 1 year since official release of C# 2.0 and .NET framework 2.0. The next version of C# language – the C# 3.0 seems to get more and more attention – in blogs, official channels and MSDN. There is lot of excitement and big expectations – but I have nagging feeling that the general direction of the C# development is not necessary an improvement.

The main new features of the C# 3.0 language are implicitly typed variables and anonymous types, extension methods, lambda expressions, and LINQ – possibility of using SQL-ish dialect inside the C#. With exception of the last, all of them must sound very familiar to every Python programmer. All variables in Python are implicitly typed, we can extend classes to much larger degree than extension methods and lambda expressions were always integral part of Python (inherited from Lisp and Scheme).

For several reasons, I believe that this is wrong. Strong typing and type safety is very important for every programming language that is suitable for building large and complicated systems – enterprise level applications. Allowing dynamic typing may be tempting, but what it does is moving discovery of errors from compilation time to runtime. There is nothing wrong with dynamic typing – Python, Perl and few others are great languages. Albeit there are large and complex systems written in Python (e.g. Zope), I think that “classical” strongly typed languages (Java, C#) still does result in more robust systems.

Adding functional constructs such as lambda expressions and extension methods basically creates a hybrid functional-OO language, sort of a cat-dog. For seasoned Lisp programmer, even Python’s support for functional programming is not good enough – and Python is internally much more dynamic language than C#: functions, classes and modules are first class objects (just compare the simplicity of event handling in Python with events and delegates). What value will it add to embedd some limited functional constructs to fairly traditional OO language as C# is ?

The project LINQ and mixing up SQL with C# in same source file is from my point of view worst idea of all C# 3.0 new features. It may sound great and be very helpful for small projects, but for enterprise size applications it makes so much easier to create complete mess in application architecture… Same thing happened few years ago with visual GUI building tools – people started to place lots of business logic into form event handlers – this is no problem for 3-4 screen mini app, but disaster for large and complex system, where you do want to have proper layers, roles and responsibilities and at minimum some form of MVC pattern. Again, there was nothing wrong with UI designers, it is just that they made doing incorrect thing so much easier …

The problem of “impedance mismatch” between world of objects and world or relational tables is real and none of the solutions we have today is perfect and applicable everywhere: code generators (of either database or object layer), “active” datasets, business object frameworks, mappers and ORM layers. What they do give us, though, is modularization and separation of concerns which is very important for code maintainability and readability. Mixing everything together inside same class just does not sound right.

Very important for success of programming language is simplicity and support for writing understandable and maintainable code. Somehow, both Java and C# seem to loose the original simple elegance of their origin. Adding generics in C# 2.0 and Java 5 was for me strange mixture of blessing and curse – yes, generics do help solve some type of problems in a very elegant way, but quite often lead to unexpected issues and complications elsewhere. Our recent adventures with CSLA framework are a very good illustration of this – but that’s topic for another entry.

No programming language is perfect for every purpose. This is why we have so many of them. So if you want to have very dynamic language with functional programming support in .NET environment why not to use Python directly ? The .NET implementation IronPython is amazingly fast, compiles to CLR and works just fine. If you want very solid language for enterprise development on Microsoft operating system, there is absolutely nothing wrong with C# 2.0. There is no need to mix them together …

Why do I suggest that C# would become uglier version of Python ? Because I believe it will look uglier to almost everybody. For somebody with strong traditional OO background and lots of strongly-typed languages history (some ex-Java, ex-ex-C++ programmer like myself), “var i” sounds too much like Visual Basic and extending class by method injection and not by inheritance is close to blasphemy. And for Python enthusiast, who enjoys dynamic features and scripting power of Python (like myself ;-)) all that stuff with data types and private/protected hide-and-seek games is just unnecessary ballast – not speaking about those terrible curly brackets, ouch …

Besides, if you *really* must do all the things above, how about using “Object i” instead “var i”, injecting methods to classes by using Spring.NET (which can, btw do much cooler things thanks to AOP and dynamic proxies) and trying out something like iBatis.NET for making sure that your C# code and SQL code coexist peacefully ?

6 Responses to Will C# 3.0 become an uglier version of Python ?

  1. Thomas Krause says:

    Implicitly typed does not mean dynamically typed. C# 3.0 is still strongly typed and type checking happens at compile time.

    The compiler just “looks” at the right expression of the “var”-statement and infers the type from this expression. Example:

    var a = 3;


    int a = 3;

    compiles to the same IL code. There is absolutely no difference between these two after compilation.

    Also LINQ is not SQL specific. SQL is just one of several possible usage scenarios of LINQ. In fact the C# compiler does not have any knowledge of SQL. Even in big business applications LINQ is still useful for quering collections, like:

    string[] names = from c in Customers select c.Name; //not tested

    instead of something like:

    string[] names = new string[Customers.Length];
    for(int i=0; i

  2. Miro says:

    Thanks for comment and clarification, Thomas.

    If variable is actually strongly typed after compilation, the more I’d like to let programmer decide (and have to think about) the actual data type, rather than letting compiler guess what programmer may have meant by analyzing the expression. This IMHO does not help, it makes it more obscure.

    Consider this:
    float a = 3;
    var a = 3; // a will be int. Or should it be byte ? Or short ? Or Uint16 ? Or uint 32 ?

  3. Thomas Krause says:

    Actually the reason why they introduced var was anonymous types. If you consider the following linq query:

    from c in Customers select c.Name, c.Forename;

    You would need a type that can store both the Name and the Forename, which would make the querying of multiple values at the same time very complex. For example:

    class NameAndForename
    string Name;
    string Forename;

    NameAndForename[] names = from c in Customers select c.Name, c.Forename;

    To solve this the compiler automatically creates an “anonymous type” that looks like the type above but is not directly visible to the user. The problem is of course that this auto generated type does not have a name that you can use to declare your variable. This is the reason why they introduced the var keyword:

    var names = from c in Customers select c.Name, c.Forename;

    This line automatically creates a type with the properties Name and Forename and uses this type in the var-declaration. You can access the properties just like the properties of a user defined type:


    all with Intellisense, since it is still strongly typed at compile time.

    For normal code the programmer can (and should in most cases) still use direct typing.

    As for your example:
    I think it will use an int, but I’m not sure. For primitive types it is propably best if you avoid the var keyword. In all other cases I don’t think that there is much guessing involved (for either the compiler or the user):

    var a = new List();
    var b = “bla”;
    var c = new Object();

    Thomas Krause

  4. Alexey Lavnikov says:

    What does look better?

    Dictionary<string, List<Dictionary>> myMegaDict = new Dictionary<string, List<Dictionary>>();

    or this:

    var myMegaDict = new Dictionary<string, List<Dictionary>>();

  5. Evan says:

    When you type in var, the query statement is actually generating an iqueryable object that holds the sql that is generated. Why they decided to represent this in C# is beyond me, but your interpretation of how it works is wayyy off.

    Just because C# includes anonymous type doesn’t mean they are handled the same way loosely typed languages are.

    Before you criticize a technology you might want to try actually using it. Linq is great for what it does, it’s not the most performant application of sql queries but it works great for small scale applications (like small business websites) or other uses where the managers can’t just throw more DBA’s at a specific problem.

    If you don’t like abstraction of var and deferred execution just force it to return a list of results directly.

    List results = new List

  6. Miro says:

    Thanks for your comment, Evan.

    As you may have noticed, the post is from 2006. Many things changed since including LINQ. Certainly today we have advantage of 2+ years of real life experience with its applications.

    I have used LINQ and I have seen many bad ways how it was used and abused. Although today I can perhaps better appreciate LINQ’s pragmatic value, I still prefer clean separation between such different languages as C# and SQL.

    And because since 2006 I have discovered and learned to enjoy Ruby, today I would certainly pick different language than Python for comparing the elegance :-).

    Enjoy your LINQs …

%d bloggers like this: