SD Times' "Does .NET With LINQ Beat Java?" Article Raises More Questions Than It Answers
David Worthington's Does .NET With LINQ Beat Java? Software Development Times article of January 30, 2008 has a snappy head but the article's deck, "Framework's data query capabilities give it an edge, experts claim," appears to be disputed by at least one "expert," namely Jonathan Bruce of DataDirect Technologies (see below.)
Worthington quotes Jonathan as saying:
DataDirect’s Bruce acknowledged that from a productivity point of view, LINQ combined with its tooling gives .NET shops a productivity advantage that the Java community cannot match. He credits Microsoft’s ability to “package [productivity patterns and tooling] all up into something useful."
That said, he noted that LINQ is an unproven technology that is new to the market and said that he could not imagine anyone making corporate bets on LINQ just yet. “On the Java side, data access is rounded and stable. As a technology officer, it is an easier bet to make [on] what will reduce risks from a data perspective,” he explained. [Emphasis added.]
If Bruce "could not imagine anyone making corporate bets on LINQ just yet," why has DataDirect announced their intention to provide EntityClient-enabled ADO.NET data providers for the Entity Framework? Java's "rounded and stable" data access sounds to me like an apologia for the status quo (a.k.a. JDBC).
Apparently, Bruce isn't aware of LINQ to Objects, LINQ to XML, and the widening variety of current third-party LINQ implemetations and upcoming Microsoft versions:
Another example is XQuery, a language designed to query XML data. XQuery, he said, does a better job with data from many venues because of XML’s flexibility. By contrast, he claimed, the current implementation of LINQ is very targeted to what the developer is querying and the ability to “mash up data sources” has not been delivered yet, Bruce explained.
One of LINQ's strong points is it's "ability to 'mash up data sources'." Jon Udell's LINQ 101 post of September 28, 2005 demonstrated a three-way join between an XML data source and two CLR objects with the PDC 2005's LINQ preview. You can now join generic sequences from sets of in-memory objects (LINQ to Objects), XML documents, relational databases (LINQ to SQL and LINQ to Databases), and other domains with LINQ to SharePoint, LINQ to ActiveDirectory, LINQ to Amazon, and LINQ to Streams. If this capability for joining IEnumerable<T> sequences doesn't enable mashups, I don't know what does.
I find LINQ to XML to be a much more approachable and practical method for querying and composing XML Infosets than XQuery and/or XSLT. It's interesting that Microsoft is working on LINQ to Stored XML to supplement or replace its pre-XQuery 1.0 implementation for the SQL Server 2005+ xml data type.
Note: I have some questions about Bruce's prognostications in the "Jonathan Bruce's Data Services and LINQ Crystal Ball Appears a Bit Cloudy" topic of LINQ and Entity Framework Posts for 1/28/2008+.
Atom 1.0 site feed
3 comments:
All those .NET beat Java posts in various magazines are really just Bullshit to get attention, pageviews and ad-sales. Linq brings nothing to the data-access front what wasn't there already. Sure, you can define some things a bit nicer in some ways, but other things get complicated rather quickly. Is Java now suddenly crap? Hardly. Their eco system provides very mature, solid tools, libraries, appservers and IDEs.
Claiming that .NET has no beat Java is IMHO simply false. Let's first catch up, and that will be a HARD struggle. Things like AspectJ, SQL/J, JRuby, Hibernate 3, IntelliJ, Spring... all major databases support java from start to finish without compromises... let's first try to match those features before the '.NET world' starts claiming they've 'won'...
The .NET / Microsoft world is surrounded with walls made of mirroring steel: people who are inside can't look to the outside, they only see themselves.
Frans,
If LINQ "brings nothing to the data-access front [t]hat wasn't there already," why are you expending all that energy on LINQ to LLBLGen?
--rj
Marketing and keeping market share. The thing is: even if it's already available, it doesn't mean users are using it. Now with Linq, people will want to use it, so if it's not linq that's what they find in your API, they'll likely pass and move on to an API which does support linq. :)
Technically, there's nothing really new under the hood with linq. It's in some occasions easier to write the query (and in other situations it's not), but it's not that it gives NEW things to the toolbox which weren't there before.
I.o.w.: someone with an o/r mapper without linq support can still do what s/he wants: linq isn't needed to do o/r mapping or querying in a compiler checked way.
As we're one of the very few who implements/implemented a FULL linq provider (I don't cound XPO's linq support, as that fails in many ways due to its very small scope), it's a good selling point. However from a technical point of view, it's not really necessary, as the features used by the linq provider are already there (except perhaps derived table support, but that wasn't hard to add) which was my point ;).
Post a Comment