We’ve been wondering what people who are focused on Java think about LINQ, so it’s good to see some Roger Voss and Jonathan Bruce start the discussion. A few very good points have come out that deserve some emphasis. For example, Voss notes:
There has arisen a mode of thinking in Java land that by embracing dynamic scripting languages we can essentially address shortcomings in Java or bolster Java with exciting new capabilities. The scripting language Groovy is perhaps the ultimate expression to date of this line of thinking. It is an appealing notion – why add new features to Java, such as an intrinsic XML type, when Groovy already has a great markup language feature that makes working in XML very groovy indeed?
LINQ/XLinq/VB9 take the opposite approach – why ask people to learn a different programming syntax and query model for different data types? The LINQ technologies focus on what is similar across most types of data (the IEnumerable<T> abstraction, for example).
Voss also notes:
[LINQ] will be a language intrinsic capability for universal query. A day will come where it will even be used in every day programming situations – say, query all the fields of a visual form beginning with some name prefix string, and then perform a common operation on all those widgets that the query selected. One of Anders Hejlsberg’s favorite demos is illustrating how LINQ can be used to query (and filter with clauses) out of type system reflection information.
This is a very critical point: LINQ encourages developers to think about data in a more declarative way — by defining the characteristics of data that will match a query, and the shape of transformed data — rather than as an imperative sequence of navigation and data manipulation operations. This has great potential for making code easier to write, understand, and maintain while allowing a relatively painless transition from the current generation of programming languages and the style that they encourage.
Voss makes another point far better than I can:
The common wisdom preached by the Ruby advocates and exemplified by its neatest accomplishments, such as ActiveRecord, is that such can only be accomplished by the dynamic, loosely typed scripting languages. However, the LINQ feature in C# 3.0 will turn this thinking completely on its head. It will bring in to question whether we really have to throw strong typing away in order to do these neat new things. LINQ creates tuples or anonymous types but it is able to retain type checking. The new feature of implicitly typed local variable declarations make it possible to hold a reference to these tuples in order to access and manipulate them. Unlike EJB3 query language, a LINQ query expression is type checked by the compiler. The end result is the simplicity style of the dynamic scripting languages but with the full rigor of a traditional strongly typed language.
Or as Erik Meijer likes to say “static typing when possible, dynamic typing when necessary.” It’s not conflict between two rival programming styles any more than there is a conflict between the screwdrivers and hammers in your toolbox — use the best fastener (and the appropriate tool) for the job at hand; when either will work, fall back to the easiest / cheapest / most familiar / whatever, don’t agonize or preach about it.
Jonathan Bruce generally agrees with Voss, but makes an important clarification and recommendation:
I do disagree with his assertion that “There will still just be XPath for XML, and nothing at all for in-memory object graphs. Tuples?”. He should consider XQuery and what this means as signicifant bridge to providing the mechanics of LINQ for the Java platform.
Feature for feature, XQuery (seen as a programming language rather than an XML query language) and LINQ/XLinq are probably more similar than they are different. Both have learned from traditional programming languages, functional programming, and XML technologies such as DOM and XSLT. They do take a rather different approach to the question of data integration, however: XQuery provides an uber-data model to which XML, relations, and object graphs can be converted, and LINQ provides a minimalist abstraction that underlies each of them natively. We will just have to see which approach resonates best with the .NET and Java users.