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 ?