As for my book: When I started writing it, there were already a bunch of great English books on the subject but only very few if none at all in German. I sometimes wish I had written it in English though…

Very well done, and I’m sad that your book is in german :)

Are you by any chance using Ad-Block software or anything similar that might interfere with how the JavaScript is loaded?

If it continues to not work for you, you might want to go to http://www.codeplex.com/jsinq and download it from there. (The playground is not currently included in the source or binary distribution, but other examples are).

Please let me know if you continue to have problems with JSINQ and I’ll upload the playground so you can run it from your local machine.

I only get “An id, string or number was expected” JS error (translated from Danish).

people.where(function(p) { return p.lastname == ‘blah’ && p.firstname == ‘blah’; }).orderBy(function(p) { return p.lastname; })

You could do without the anonymous functions (see your example), but then you’d have to sacrifice a good amount of expressivenes (you can put anything in an anonymous function, but there’s only so much “logic” you can express with object literals, unless you want to write ASTs by hand).

With the LINQ query syntax, you can write

from p in people where p.lastname == ‘blah’ && p.firstname == ‘blah’ select p

which is not only shorter but also more readable (even than your already short and readable example).

I think the reason why LINQ (and XQuery for that matter) picked a SQL-like syntax is because that’s something people already know. It’s incredbly difficult to get developers to learn new things (you’d think otherwise, but unfortunately that’s not how it is) and so building on something people are already familiar with tends to be a good idea.

or something more well thought out.

I think the boundaries between syntactic sugar and DSLs are extremely blurry with the only real distinction being that one is built into the language and the other is bolted on-top of it. But if you take LINQ for example or generics in Java or lambda expressions in C#, you’ll realize that even that distinction doesn’t work too well (LINQ, Java generics and C# lambdas are dealt with by a preprocessor and not by the language compiler itself).

With LINQ in C# or VB.NET, the benefit of it not being a DSL in the traditional sense is that you get the compile-time type checking. But with JavaScript, that argument becomes almost negligible, because there typically isn’t a “compile-time” with JavaScript.

I’m not saying that JSINQ wouldn’t be more useful if it was built into the language itself, I’m just saying that I don’t see any severe disadvantages with it being a library.

JSINQ is an abstraction (I’ll give you that) and it is very leaky, but it’s not trying to be anything else. It’s not trying to create its own “SQL world”, instead it takes what JavaScript already knows how to do well (Lambdas, function composition, etc.) and exposes it through a slightly more convenient syntax. If you don’t see the need for a specialized DSL, you can get most of the benefits of JSINQ through its library part alone (jsinq-enumerable.js).

If you’re doing a lot of this stuff, code can be smaller and easier to read or debug.

It is not a clone of jLINQ for several reasons:
for one, it is API compatible with System.Linq.Enumerable which jLINQ is not (jLINQ for example lacks the selectMany, join and groupJoin operators which are really useful when writing more complex queries) and it has a query compiler that allows you to write queries using LINQ-style query expressions rather than by chaining together method calls (although that is what the queries are compiled into).

I’m not trying to belittle jLINQ (which I think is great), it’s just that JSINQ is catering to a different audience (those who already know LINQ).

Rusco.