I have been lately busy studying LINQ. One area of concern I found is the differences C# and VB.NET have choosen to tackle the syntaxes of LINQ:

• LINQ's query operator syntax that relays on extension methods and Lambda expressions. Both languages support all the LINQ query operators but VB.NET does NOT support Lambda statements (only support Lambda expressions)

• LINQ's query expression syntax (the SQL like syntax). Here C# supports a subset of the query operators in this syntax while VB.NET supports all of them!!

• LINQ's expression tree syntax (the most complicated of the bunch). This one is early similar to LLBL's RelationPredicate bucket approach (though surly feels less mature). This syntax is usually usefull to build dynamic queries and is supported by both languages

My question is how will LINQToLLBL address the language differences between the two languages. Will we see full support of all the provider's query operates in the "query syntax" in both languages?

omar wrote:

I have been lately busy studying LINQ. One area of concern I found is the differences C# and VB.NET have choosen to tackle the syntaxes of LINQ:

• LINQ's query operator syntax that relays on extension methods and Lambda expressions. Both languages support all the LINQ query operators but VB.NET does NOT support Lambda statements (only support Lambda expressions)

Lambda statements are used for anonymous methods (their name in C# 2.0), and as those elements can only run in-memory, they're either compiled by the linq provider into code running in-memory during the projection or ignored/resulting in an exception: they can't be converted to SQL anyway, so you won't miss anything in this case when using VB.NET.

• LINQ's query expression syntax (the SQL like syntax). Here C# supports a subset of the query operators in this syntax while VB.NET supports all of them!!

VB.NET has 'skip' and 'aggregate' as keywords if I'm not mistaken. We don't support Skip, as it is pretty awkward to use: in many occasions it results in an error as skip isn't supported in those cases, so we added an extension method: 'TakePage()'. Skip is therefore not supported (also because the llblgen pro api doesn't support skipping rows).

Before anyone thinks this should be added to the Linq support: var q = from c in metaData.Customer.Skip(10) join o in metaData.Order on c.CustomerID equals o.CustomerID into co where co.EmployeeID==3 select c;

(I'm on another machine right now, it might be that this query isn't correct, though the point is the 'Skip' call inside the join)

What to do here? It is legit Linq, however it's a silly query. Paging is done on the last projection anyway, so TakePage will cover that. It also will avoid crap like:

var q = (from c in metaData.Customer orderby c.Country ascending, c.City descending select c).Skip(3).Take(5);

vs. var q = (from c in metaData.Customer orderby c.Country ascending, c.City descending select c).Take(5).Skip(3);

Yes these are different. . The main culprit is the difference between sequence and set. SQL uses sets, Linq uses sequences. Sequences are sets, but also have an order, sets don't. This means that an operation defined in linq which requires an order, can be defined in a linq query which DOESN'T define an order (as the sequence provdes one!) however to be able to convert it to sql it HAS TO have an order, as with the above query with Skip() called on metaData.Customer: that table has by definition no order. The sequence 'Customer' however, according to linq, does have an order.

'Aggregate' has no meaning in a database, as the Linq method 'Aggregate' isn't usable to write aggregates on a database.

• LINQ's expression tree syntax (the most complicated of the bunch). This one is early similar to LLBL's RelationPredicate bucket approach (though surly feels less mature). This syntax is usually usefull to build dynamic queries and is supported by both languages

As long as your code produces a Lambda expression or other expression object, you're fine.

My question is how will LINQToLLBL address the language differences between the two languages. Will we see full support of all the provider's query operates in the "query syntax" in both languages?

VB.NET generates different code than C# for what looks like the same query. This is often due to nullable types: VB.NET generates coalesce expressions where C# doesn't. C#'s '+' operator for strings produces Add expressions (With a method call to String.Concat()) while VB.NET generates from '&' operator calls between strings directly String.Concat method call expressions.

Though, in the end it doesn't matter: both generate code which produces at runtime an expression tree which is handleable and convertable to LLBLGen pro query elements and thus to SQL. I first was worried as well that VB.NET and C# would generate very different expression trees and that it wasn't possible to produce proper query elements because the original language was unknown. However this isn't the case (to my knowledge). As you might have read in my latest blogpost, method/property mappings are definable pretty easily and it might be that VB.NET users require additional mappings for VB.NET specific method calls. Though these are easy to add either yourself or by us if we find out what they are. At the moment I don't recall a VB.NET construct which would cause problems.

There are many ways to break a linq provider at runtime, as Linq's syntax isn't that solid. though these problems are for the developer: s/he should write the query which produces the results s/he wants, not the query which looks clever but is overkill in many ways.

The release plan is that once the Linq code is done (I hope to finish it at the end of the coming week, or if there's some delay the week after that), a CTP is released for customers. This means a pack of files (templates, tasks, runtime lib, doc, all our linq unittests) which can be used in the v2.5 designer (make a copy of the designer, place the v2.6 files in there), so you all can start testing the code. After that we'll make the breaking changes to v2.6's runtime lib. This means that the linq ctp is not final code, but it will mean that you all can test it out and can try to break it to see if we dropped the ball in some cases so we can fix that earlier on.

We'll add the unittests we used to test linq feature implementations with the ctp so you have a set of queries to work with (we're now at 200 different queries, and that's only adapter, non-prefetchpath code).

Thank you Frans for addressing my concerns. Though I still feel that you are not very enthusiastic about LINQ, I have to admit that the technology has its merits in giving our query code a declarative nature than the imperative nature of writing OOP code against an API.

One area I wish to see LLBL going for is the LinqToSQL designer adopted in VS2008. The dotNet community in Kuwait had an open day event lately and this feature proved very attractive to a lot of developers specially the "not so experienced" type. The idea of drag-and-drop then code is really appealing.

Are we going to see something like that for LLBL?

omar wrote:

Thank you Frans for addressing my concerns. Though I still feel that you are not very enthusiastic about LINQ, I have to admit that the technology has its merits in giving our query code a declarative nature than the imperative nature of writing OOP code against an API.

It has its place. Things I like is that you can write very compact queries in Linq and that people can get common training in linq and get started with llblgen pro right away.

One thing where people will be very dissapointed in is the learning curve with linq in general: it's not easier to use than llblgen pro query elements are. This isn't our fault (we implemented linq as-is ) but the way linq works, so the question 'how to write this sql in linq' will still be asked a lot.

One area I wish to see LLBL going for is the LinqToSQL designer adopted in VS2008. The dotNet community in Kuwait had an open day event lately and this feature proved very attractive to a lot of developers specially the "not so experienced" type. The idea of drag-and-drop then code is really appealing. Are we going to see something like that for LLBL?

The linq to sql designer is a bit of a gimmick: it doesn't have model refreshing when databases change, so it will be quickly abandoned by many users. It also isn't that productive, the llblgen pro designer is more productive: you can map entities very fast and that's not said about the linq to sql designer.

It does look OK though, the linq to sql designer. Though at the end of the day, a person who has no clue what an entity is will create a crappy system using any tool. So it might seem appealing at first to give an inexperienced developer a tool which allows him/her to drag/drop a model together (or point-click-generate a dataaccess layer), but to use that whole package effectively, one has to know what all the elements mean. So an inexperienced developer has to learn before using it effectively. That's no different with linq to sql, even though it might seem that way.

In v3, we'll add a DSL based mapping system. The DSL will be text based, with a powerfull editor. You'll quickly find out that it will work very very fast. But, as the DSL works on an object model (the project files will be text though), we'll also add different editors, working on the same model, e.g. a form which looks like the current one, and viewers for visualizing the model in a graphical form. Changing the model in one will be reflected in the others.

I don't think it's wise to fall for pretty pictures which turn out to have a low productivity rate (in linq to sql designer, you have to click a lot, fiddle a lot in a small area (property grid), the designer doesn't have power options like name formatting etc. I always want to achieve the maximum productivity value for a user, not a designer which looks the best, but sucks when it's used. Of course, a combination of both is the best, and we'll strive to make the thing look as appealing as possible, though productivity comes first.

When I was testing some DSL syntaxis it was striking how I could define entities, mappings etc. very very fast and had more freedom than the current entity editor could ever give me. It's essential that the editor is very helpful, so powerful intellisense for the DSL is a must, as well as refactoring support for the model.

I am with you that its sucks that the Linq2SQL designer does not have a mechanism in place to reflect database changes (although they are promising that in a coming release), but the thing is that this is definitely a reference design (a measuring stick if you want to) that independent vendors like yourself can reference to. This would greatly help in adopting LLBL as it lowers both the learning curve and the acceptance of developers since they are dealing with a technology similar (in surface) to something they have seen in dozens of presentations and have read tons of articles and books about.

This is similar to what Rocky mentions in his blog about why we are not seeing any grid controls for WPF (simply because MS did not release one and now every vendor has to come up with his own design instead of relating it to one from MS)

omar wrote:

I am with you that its sucks that the Linq2SQL designer does not have a mechanism in place to reflect database changes (although they are promising that in a coming release), but the thing is that this is definitely a reference design (a measuring stick if you want to) that independent vendors like yourself can reference to.

An upcoming release would be the next vs.net. That's not out for the next 2 years.

I fail to see why the linq to sql designer is a reference design. It's 'a' design, and if I may say so, seriously flawed in many ways.

Try to add a new field to a db table. Then try to add a new field to the entity mapped onto that table in the linq to sql designer. This will take alot of clicks and fiddling in small areas like the property grid.

In llblgen pro it takes 1 checkbox and a button click, if it's not already automated due to a refresh. That's why following MS' designs isn't worth the time: it's often very unproductive.

Take for example their class designer. Do you use the code editor to add a property to a class or the class designer? I bet the code editor because the class designer is unproductive. It looks great though.

This would greatly help in adopting LLBL as it lowers both the learning curve and the acceptance of developers since they are dealing with a technology similar (in surface) to something they have seen in dozens of presentations and have read tons of articles and books about.

I think I understand what you want to say, which I'll address after these remarks: What exactly do people gain when that editor is copied? Just because they've seen screencasts of how to work with an inferior editor approach, does that mean they know what they're doing? If a person understands what entities are etc., they can operate any editor within minutes. If not, they have a hard time. But consider this: the person who doesn't understand what an entity is, has a hard time regardless: saving and loading entities, using the classes in the program efficiently etc. .. it will be a nightmare.

I.o.w.: will a person be helped when an editor is present which is much less productive to complete a given task than another editor? I don't think so. This is very important: if the developer doesn't understand what an entity is, WHY entities are used etc., using an o/r mapper has no value whatsoever. It will be a pain to use, as it doesn't match what the developer DOES know: tables, SQL, etc. Linq doesn't match that either, and there's the reason why so many people ask 'how do I write this in linq' questions on ms' forums.

I find it particularly bad to follow MS' designs, as in general they suck when it comes to productivity. Sure, dragging a table onto a canvas is easy. But so is selecting a menu option and clicking some checkboxes. Saves me the trouble of: - browsing to the table in the service explorer (which requires me to connect to the DB!) - selecting the table and drag it - alter the name in the property grid (as that's the MS' approach: do something and further modify it in the property grid... )

Also, if I have 200 entities in my system, you definitely don't want to have them all on 1 canvas. But that's what the MS' designer forces you to do. We have customers with 1500 entities in their project. The LLBLGen Pro designer can handle that, but Linq to Sql's designer definitely can't and if I'm not mistaken, the entity framework designer has the same design flaw: everything has to be present on the same editor canvas.

What's more: to change things, you can't do that in-place. You've to shift your attention from the central canvas you're working on to a small portion of the IDE: the property grid. there you'll make most of the changes. In fact, there you'll do most of the work. I've always found that a stupid thing.

Pretty pictures What people like is the nice graphics. The LLBLGen Pro's inheritance viewer is similar to that: it shows in a fancy way how things relate.

The Linq to Sql designer offers little information in the picture. You see relations between entities, but not over which fields these relations are defined, onto which tables the entities are mapped etc. So in short: the picture looks nice, but shouldn't be the main editor of choice. It can help viewing how the entity relates to other entities in a visual manner, but that's it. I do agree with the sentiment that visualizing entities in the way linq to sql's designer does can help better understanding what's going on.

So, I'm not against that, not at all, however I find the designer of linq to sql lacking in many ways so mimicing that one in our designer is not what I think will be a good editor of choice.

As v3 will use MVC, adding such a viewer isn't going to take years of development and it is planned, though how much things are editable in that viewer is to be seen. The main target of the designer is to define entities, mappings and meta-data as easy and productive as possible. If that requires the developer to read a 2-page document, so be it. If the developer can define entities much faster with that editor after taking that time, why bother with a flawed editor?

As for getting a higher adoption rate... I'm not sure. People have a free o/r mapper, linq to sql, in their vs.net. If we provide the same experience in our designer, I think it won't be an attractive alternative, precisely because people don't see an advantage there: the 'other' editor is the same as what they have in vs.net. If we offer a different approach, it is a different ballgame.

Adoption of an o/r mapper designer typically starts by adopting o/r mapping for a project. As that takes knowledge of what o/r mapping is, do you think it will have a relevance if the novice developers on the team can drag/n/drop their time away? I don't see that. If I was a teamleader of these developers, I'd want them to be as productive as possible, i.e. be able to define a lot of entities in a short time, as that makes the project go forward.

This is similar to what Rocky mentions in his blog about why we are not seeing any grid controls for WPF (simply because MS did not release one and now every vendor has to come up with his own design instead of relating it to one from MS)

Heh, do you really believe that? Come on, Omar . Take a random 3rd party grid: it looks very very different from what MS offers. it operates different, has a different designer etc. i.o.w.: it's a completely different grid. And now these developers aren't able to make a WPF one because MS didn't provide a reference design? I don't think that's the reason. I think the reason is that it's a lot of work: every tiny detail has to be WPF-enabled. Though I don't see how a reference design should have helped them: they have a reference design to look at: their OWN grid for winforms.

Thank you for the elaboration and your opinion is duly noted. Its truly refreshing to hear opinions from both sides of the camp to really get things into perspective.

On a different note, as I find discussions with you so educational I would like it very much if you can find the time to blog or write an article about DSL and its place in the development toolbox

omar wrote:

Thank you for the elaboration and your opinion is duly noted. Its truly refreshing to hear opinions from both sides of the camp to really get things into perspective.

No problem And if you see holes in my reasoning, please step forward and correct me.

On a different note, as I find discussions with you so educational I would like it very much if you can find the time to blog or write an article about DSL and its place in the development toolbox

Definitely. DSL's will be a big leap forward in the toolbox of a developer in the coming years. When we've the DSL defined, I'll write more about it and how to create one .