Ricardo: So, you are as daft on technical discussions as you are on philosophical ones...why am I surprised? ;)
> > So this LINQ is just another way to be circumscribed to M$ products? > What if I want to run it against a non M$ engine? LINQ is just a generalized way to query objects (regardless of their source, SQL is just one among many possible back ends). The special syntax is supported by each language individually, with common semantics supported by the run-time and supporting libraries. It works just as well on Mono. And any runtime can do something similar, using similar strategies. > > And, why do we presume that pre-compiling on the client is better than > pre-compiling on the server? You're the only one presuming anything in this discussion. I am just as familiar with SQL as you and I do see LINQ as an interesting twist on the concept of language-supported query syntax, because of the semantics in this case is widened beyond merely relational data. LINQ is relevant not just to relational database, but also RESTful services, document-centric databases (like CouchDB and MangoDB), and just about any conceivable source of "objects" at all. > >> This isn't to suggest there was a problem with parsing SQL on the >> server side, though precompiled queries defined on the server side are >> known to execute better than their text-based equivalents coming >> dynamically from the client side. > > This is because the server is somehow unable to do *exactly* the same > pre-compilation the client does? Why? Are servers a bit dumb? No but being able to decouple the compilation from the execution engine is an interesting architectural achievement. (Though, with respect to SQL, Stephen's point about LINQ queries not being fully compiled and still needing to go through a planning phase is valid). > Pre-compiled queries defined on the server side are faster because the > server does not have to do the pre-compilation step on the run. That's all. Right, and if the server gets code in nearly executable form, that is also faster than receiving it as text and having to go through parsing/AST generation phase before any planning or execution. > >> The idea of passing code around as data is the main innovation, and it >> is already proving important for multicore and distributed computing >> in practice. >> >> > You mean passing code around as data (as in sending an sql sentence to a > remote server) is nowadays considered an innovation? No, you're not grasping the concept. It's passing around essentially an AST (abstract symbol tree) in a format that requires little to no translation to be "executable" that is innovative. Nor -- I went to great pains to explain -- did MS invent the concept. > Is then linq addressed to very specific multicore and distributed > computing needs, and the rest of us mortals may just dismiss it and save > the time of learning yet another complicated way of doing the same thing > we've been doing for years? Grrr. You can fossilize if you like, I prefer to learn the latest technologies and keep up with the advanced concepts behind them. :) - Publius > > [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[email protected] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
