Getting to grips with LINQ 2.0

Microsoft’s Eric Meijer spoke at QCon about “LINQ 2.0” in his keynote. So what on earth is LINQ 2.0? The name is probably inappropriate; he explained to me later that it is just a convenient tag for “what comes after LINQ 1.0”. Meijer started by talking about integrating relational concepts into languages; he didn’t say exactly what this would look like, but the idea is that you could specify relationships between objects, independent of the objects themselves. This is not LINQ 2.0 though; perhaps it is LINQ 1.1. LINQ 2.0 is about simplifying multi-tier, cross-platform web applications- hence the title of the talk, “Democratizing the cloud.”

So how do we do that? The starting point is that users want the same experience everywhere, irrespective of computer platform or device. Meijer’s idea is programmers should be able to code for the easiest case, which is an application running directly on the client, and be able to transmute it into a cross-platform, multi-tier application with very little change to the code.

That means a cross-platform runtime, right? Sort-of, but Meijer doesn’t envisage having to distribute a runtime engine such as .NET, the JVM (Java Virtual Machine) or Flash. Rather, he wants to use what is already available. Therefore he envisages .NET IL (intermediate language) binaries becoming a universally executable format. The runtime could be the CLR (Common Language Runtime), or the JVM, or the Flash player, or the browser. This would be transparent to the developer, because some intermediate piece would translate the .NET IL to JavaScript, or Java, or a Flash SWF. or somehing else.

This is a little similar to the concept behind the Google Web Toolkit, which lets you code in Java but translates your code to JavaScript. The idea is that you code in whatever language you like, provided that it compiles to IL. For deployment, some sort of cross-compiler does whatever is needed to run it. Maybe it gets converted to JavaScript, or a SWF, or WPF, or WPF/E; you are not meant to care. He calls this late-binding against the client runtime. Note that this is different from implementing the CLR on multiple platforms, though Microsoft is beginning to do this as well (WPF/E).

So that’s the cross-platform runtime sorted. What about the programming side? How do we make our single-tier VB.NET application into a multi-tier web application?

Meijer talks about growing the application organically using refactoring. His use of the term “refactoring” is wrong I think; refactoring is meant to leave functionality unchanged. He means something more like re-purposing. You would take a method and add an attribute to convert it to a web service. Of course ASP.NET already has this (WebMethod attribute), but Meijer’s idea seems to include greater intelligence about the plumbing behind the exposed method. He believes programmers should only need to think sequentially, even though in reality web applications may have multiple entry-points and users may do things like clicking the Back button.

Meijer applies the same thinking to concurrent programming; developers should be able to do this with simple attributes, rather than struggling with synchronization statements and the like. Similar logic applies to state handling: Meijer reckons programmers should be able to program statefully, and have the infrastructure deal with the problems.

We should give programmers the illusion that their servers are stateful, while we can implement that in some scaleable way. That should be done once instead of all programmers trying to solve that problem.

No roadmap

I chatted to Meijer after his session. He emphasised that there is no roadmap for implementing “LINQ 2.0”; he is merely sharing some research thinking. What I’ve described above may never be implemented, or may evolve into something very different. Some parts sound fanciful to me. Will the idea of compiling IL for different runtimes really fly? Is it feasible to reduce multi-tier programming to a few attributes? Will this be any better than DCOM, which was meant to make distributed objects easy, but proved more complex and less robust than had been hoped?

That said, there’s little doubt that advances in programming will be about introducing new levels of abstraction, which may well provoke scepticism among old-school developers. This has happened before. I respect Meijer for what strikes me as good work in LINQ 1.0, so I’m paying attention.

8 comments to Getting to grips with LINQ 2.0

I have my severe doubts about some aspects of this LINQ approach. After having attended the MSDN Roadshow it struck me that LINQ might, in some cases, be encouraging bad practice. The kind of bad practice I have in mind is where somebody puts all the data access and business logic code in the client simply because the development environment allows it.

Where I work, if we are developing a large database application we put as much business logic and data access code as close to the data storage as possible, in stored procedures. It’s easier to maintain, much better performing (as optimisations can be done with reference to the underlying data) and generally more robust.

Well, I’m open-minded about it. One thing that’s very good about LINQ is that it brings relational concepts to client-side programming.

Another database-originated feature I’d like to see on the client is proper support for transactions. Imagine how much easier it would be to write, say, an installer script for a package if you knew you were going to be targeting a transaction file system. 🙂

I’m not entirely sure the world needs a lot more AJAX though. Usability, accessibility and performance are usually afterthoughts. I think these have traditionally been a problem for the ASP.NET community anyway.

Regards LINQ and doing things the right way, I’d tend to agree with the sentiment but not with use of stored procs. Performance with a good OR/M tool like LLBLGen is as good or a little less than use of stored procs with much better productivity. In my experience it also reduces the pain for people upgrading your application.

I guess best practice would say you should use Linq where you currently have your data access layer. Most of my app UIs only ever see custom objects, not datasets or the like.

Some “very large scale applications” (eg. web 2.0 sites) have found a lot of drawbacks in relational databases – this is where LINQ V.Next may be looking. Google released an extension of the Hibernate framework that allows you to query shards of data that are spread across many servers (or [web]services). I could see Linq following along the same lines.

I have no idea if this type of stuff is really going to be that useful for the majority of developers out there. esp. if your application data cannot traverse the company firewall, or you have limited support infrastructure/people to handle network outages.