QCon London 2007: Erik Meijer on LINQ

Some notes from Erik Meijer’s talk here at QCon, probably in desperate need of some cleanup later (the notes, not the talk).

A nice example of a Haskell list comprehension and its connection to SQL’s select … from … where … form. Also interesting was his claim that once generics are introduced into a programming language, you start to really feel the need for type inference. Everything old, nothing new, all invented ages ago. Haskell has generics parametrized over type constructors, not only types — i.e. I can instantiate a “container” of “T” with “List” and “int”. One can do list comprehensions over monads (WTF does that mean?)

He went to MSFT to explore his ideas helped- Streams, tuples, unions, content classes, XML object literals, generalized member access + SQL comprehensions, going from X# tp Xen to C(omega). Only a few of C(omega)’s types survive in VB9 and C# 3.0. The idea of non-null types (preventing NPEs) is not yet in there, seems useful. Compiler plugins did not survive, either. Incoherence introduced when the programming language’s type system is not supported by the underlying runtime (example: nullable types and boxing/unboxing). LINQ is Monad comprehensions from Haskell, implemented in C# and VB. Any programming language could use LINQ (as VB and C# do). Programming language designer in him is appalled by SQL’s confusion of iterator variable with a table name. Both SQL and XQuery are data model + query syntax, tightly woven together. The same can be done for OO. LINQ = Queries over arbitrary collections of arbitrary data. There is no universal data model — none of them is good enough for all circumstances. But there are operations that make sense in all of these environments — sorting, grouping, filtering, mapping … independent of collection type, element type, function (to some degree).

LINQ programming language support is only syntactic sugar for LINQ’s standard operators. C# 3.0 supports type inference and lambda-expressions. In contrast to C(omega)’s earlier plugin model, LINQ is extensible for custom filters and selectors. Extension methods are used e.g. to add a “where” method to IEnumerable; remind me of Ruby’s open classes. Data and code can be passed as parameters, but in contrast to Lisp or Scheme doesn’t need to be quoted. The callee, not the caller decides whether they want to be passed an expression (the method gets passed an expression tree). (Christian Weyer, sitting next to me confirms one can programmatically add new code, even extension functions, to an existing app — this essentially gives us metaprogramming in C#). new { c.Name, c.Phone } as an example of an anonymous type, field name types inferred. Support for object initializers, looking similar to JSON (syntactic sugar, as Paul Fremantle points out, over something you could do with a lambda expression.)

A look at VB’s syntax, which actually looks nicer. Type inference again, the IDE pops up a tooltip with the full name even though it’s not been declared, code completion works (obviously), even in initializers. Strange syntax in VB (a dot in initializers, e.g. New With { .x=47 } only to trigger Intellisense (!). Erik shows extension methods, and how one could be added to any type — reminds me of opening Object in Ruby and adding some methods to it, with the difference that in Ruby you can also add attributes. On the other hand, in VB you get code completion …

VB support for creating XML trees, intuitive axes; but VB also supports XML literals (like E4X). <%= ... => syntax to escape back to VB within your literals. Also fascinating syntax: BillTo.<street> or PO...<item>. (Quote: “Who needs XQuery anymore?”).

Some words about LINQ for SQL. Typical features of an O/R mapper included (?), support for eager and lazy loading and filtering (via a Datashape).

Overall: great talk, great guy, way too little time. Final quote:

Programming Language Theory is relevant. But it requires at least 20 years of patience and ripening.

Question from Ted Neward: How do extensions functions (and other stuff he talked about) relate to metaprogramming and AOP? Erik is no fan of AOP, doesn’t believe in the usefulness of adding something afterwards which might violate invariants of existing codes. Points to partial methods as an alternative. So in contrast to AOP, the writer of the original code says where someone else can “weave” his own stuff into.

Question regarding expression trees: The compiler will create code that at runtime creates an expression tree, which is then compiled to e.g. SQL. lambda expression only as syntactic sugar over constructing an expression tree.

Question regarding JSON — Erik explains what it is; earlier he mentioned that he hopes and believes JSON will make XML disappear :-)