Sunday, March 25, 2007

Is LINQ the writing on the wall for C#?

C++ was the writing on the wall for C. C is a phenomenally successful low level systems programming language. If you want to write an operating system you use C. I remember first becoming aware of C as a teenage BASIC freak when it was discussed in the computing magazines I used to read. In those days the choice for budding programmers like me was between the ROM based BASIC interpreter, or writing in Assembly language. C was described as a way of getting the speed and power of assembler with the ease of BASIC and it pretty much took over the PC programming world. A lot of business applications were written in C because there was no higher level abstraction that could do the job. Visual Basic took years to get the necessary performance and functionality to write decent enterprise level applications. A lot of people would argue that it never got there. But now, no one would dream of writing a business application with C, we all use modern OO languages like Java or .NET. C++ is an OO language right? So why don’t we build modern business applications with C++? The reason is that C++ is a low level systems programming language with some OO stuff grafted on. You still have to do all your own memory management and worst of all you have to get your head around all that mind boggling pointer stuff that’s frankly beyond the average Mort. For a long time, though, a lot of business applications were built with C++. People were right to believe that OO programming gave them a fantastic tool to get on top of the complexity of large programs, but what they needed was the OO stuff without the C stuff and that’s where, first Java and then C# came into the picture. So why is LINQ the writing on the wall for C#? Well I’m being slightly provocative here, it’s just a thought experiment, but doesn’t this look like a repeat of the whole C + OO = C++ thing. LINQ is giving us functional programming in C#, which isn’t a functional programming language, it’s an imperative language. There’s no doubt that the current trend in programming is away from imperative and towards a more declarative style. SQL’s been doing this it for decades in it’s own tightly bounded domain and now we’re beginning to see general purpose declarative languages becoming more widely known. The problem with grafting some functional stuff on top of an imperative language is that the imperative stuff stops you from getting all the benefits of the functional stuff in the same way that the C in C++ stopped C++ from giving the programmer all the benefits if a language with first class types. Is C#+LINQ another intermediate Frankenstein's monster like C++? When we've all had plenty of practice with LINQ are we going to start thinking that we don't need all that imperative syntax? In ten years time will I be writing, “nobody would dream of writing a business application with an imperative language!”?


Anonymous said...

boy, this is the most insightful post on LINQ vs C# 2.0

Mike Hadlow said...

Thanks bill!