locked
LINQ syntax in VB.NET

    Question

  • I've been looking into this LINQ thing, and it's looking good. Thumbs up! I watched the videos on Channel9 with the Great Dane Anders Hejlsberg (ok he lives in the US but I like to think of him as Danish) - godt gået Anders og co!

    I really like the syntax in C# where you turn the query around when compared to SQL, so it is like FROM {x} WHERE {y == 1} SELECT {z}. This I understand was done because of IntelliSense, which is great. Now I have learned that the VB.NET implementation is not turned around, it's more like SQL, and I wonder why... Are we gonna lose IntelliSense over this?

    /Klaus Enevoldsen
    Tuesday, November 01, 2005 8:06 AM

Answers

  • >Now I have learned that the VB.NET implementation is not turned around, it's more like SQL, and I wonder why...
     
    First, keep in mind that what's out now is just an early preview, and syntax may change before release. I think the reason they did it this way is that they think many existing VB users are familiar with SQL.

    But then you soon realize that it isn't SQL and the similarities don't go very far. That's one of the reasons C# did it differently. And personally I, like you, prefer teh C# way.


    >Are we gonna lose IntelliSense over this?

    No you'll get IntelliSense alright. It may just have to make you jump back and forth a bit in the code to help you complete the statement.

    Tuesday, November 01, 2005 9:20 AM

All replies

  • >Now I have learned that the VB.NET implementation is not turned around, it's more like SQL, and I wonder why...
     
    First, keep in mind that what's out now is just an early preview, and syntax may change before release. I think the reason they did it this way is that they think many existing VB users are familiar with SQL.

    But then you soon realize that it isn't SQL and the similarities don't go very far. That's one of the reasons C# did it differently. And personally I, like you, prefer teh C# way.


    >Are we gonna lose IntelliSense over this?

    No you'll get IntelliSense alright. It may just have to make you jump back and forth a bit in the code to help you complete the statement.

    Tuesday, November 01, 2005 9:20 AM
  • Ok, As a VB.NET developer I prefer the C# way, too. Jumping back and forth is not a good thing. :-)

    Tuesday, November 01, 2005 9:23 AM
  • I don't know if this had anything to do with the C# syntax, but one of the things I really like about having the FROM statement first is that mentally, I think it makes more sense - I know the Source of objects then I know the filters that are placed on them as opposed to SQL where, with large statements, you'll have to scroll to the bottom to find where the source is.
    Wednesday, November 09, 2005 6:19 PM
  • Being an XQuery "guru", I like the C# syntax approach better as well. You may want to let the VB guys know that you prefer the FROM first and SELECT last. As mentioned elsewhere, we can still hope... :-)
     
    Michael
    I don't know if this had anything to do with the C# syntax, but one of the things I really like about having the FROM statement first is that mentally, I think it makes more sense - I know the Source of objects then I know the filters that are placed on them as opposed to SQL where, with large statements, you'll have to scroll to the bottom to find where the source is.
    Thursday, November 17, 2005 8:22 AM
  • Hi

    I think the C# query keyword order is more convenient and probably most of the VB will agree with that. The question is how can we reach the VB language developer team to tell them about our preferences? Is there a forum dedicated to proposals for future language improvements?
    Sunday, November 27, 2005 2:24 PM
  • Hi Martin --

    We're listening right here; this is the forum to deliver feedback to the VB language design team. 

    You guys are right about our motivations -- we want the syntax for LINQ in VB to be very natural for users familiar with SQL to read and write. Of course, there are some challenges ahead regarding Intellisense. One of the pieces of feedback we've heard loud an clear from all the LINQ discussion is that good Intellisense is *critical*. Stay tuned for an upcoming release which will provide a glimpse of what we're planning for Intellisense with regards to LINQ. If the feedback is that the Intellisense experience doesn't cut it and it can't be fixed, then we'll strongly consider changing the syntax. One of the reasons we're getting this out to you all so early is so that we can get feedback and respond to it.

    Thanks for taking the time to play with the preview bits!

    Thanks again,
    Amanda Silver

    Program Manager
    Visual Basic
    Monday, November 28, 2005 7:47 AM
  • Hi AmandaS

    Thank you for your reply.
    My argument was motivated only by the challange of having a good IntelliSense without jumping back and forth on the code. If this problem can even be solved keeping the SQL keyword order it will be fine of course.

    Since I know now that the VB team is listening right here, I would like to aks something about the language future in general:
    Are there any considerations to add some Design by Contract features to the .NET languages in the future like the pre- and postcondition principle proposed in spec#?
    Tuesday, November 29, 2005 4:16 PM
  •  Martin Unterholzner wrote:
    Since I know now that the VB team is listening right here, I would like to aks something about the language future in general:
    Are there any considerations to add some Design by Contract features to the .NET languages in the future like the pre- and postcondition principle proposed in spec#?


    This is definitely something we think about as we think about the future. As you say, it would need to be something supported by the entire platform to be most useful, so it would obviously be a big thing. Time will just tell... :-)

    Paul
    VB Team
    Wednesday, November 30, 2005 1:55 AM
  • Hi Paul

    I can immagine that this feature would be a big thing because it would need the extension of the .NET common intermediate language, since it would require a theorem prover mechanism. However, this feature would probably be worth the huge effort by giving the developers a strong tool for writing quality software. Hopefully we will have something like that in .NET 3.0 ;-)
    Wednesday, November 30, 2005 9:09 AM
  • Now that we're breaking SQL compatability (which doesn't bother me at all) I'm reevaluating what I consider logical.

    I don't consider the C# syntax my best choice, just a better choice that adhering to SQL.

    'SQL-like
    SELECT user.ID
    FROM users
    WHERE user.ConnectionTime > TimeSpan.FromHours(24)
    ORDERBY user.ConnectionTime

    With this syntax my issue is that the source is qualified after the 'user' variable so the 'user' variable type can't be infered from the 'users' collection. As a VB Coder I love me some Intellisense, so this option is strictly forbidden.

    'C#
    FROM user IN users
    WHERE user.ConnectionTime > TimeSpan.FromHours(24)
    ORDERBY user.ConnectionTime
    SELECT user.ID

    While this is functional, I don't like the SELECT being last, nor do I like the 'user IN users'
    because I feel like (SQL haunting me) SELECTing should precede qualifications for the SELECT (WHERE) and definately sorting. But maybe I'm just being petty.

    As for user IN users, FROM should qualify the source collection not the ... temp variable or whatever. and that IN keyword bothers me. But I suppose the heart of it is that it becomes redundant if SELECT is moved second

    'VB9.0 Suggestion
    FROM users
    SELECT user.ID
    WHERE user.ConnectionTime > TimeSpan.FromHours(24)
    ORDERBY User.ConnectionTime

    This solves the intellisense, is a bit closer to SQL (if that's the kinky kinda thing you're into) and gets rid of that IN thing. Come to think of it it's really just switching SELECT and FROM from the SQL order which is sufficient adjustment to me.

    Just an aestetic suggestion I guess...

    Sunday, December 04, 2005 4:43 AM
  • It would be exciting to have a purely object oriented way of doing it:

    users.Where(ConnectionTime > TimeSpan.FromHours(24)).OrderBy(ConnectionTime).Select(ID)

    It would make the code more object oriented like the smalltalk way of doing it.
    Monday, December 05, 2005 9:12 AM
  • LINQ lets you write that type of queries as well. The keywords are mostly "syntactic sugar".

    Monday, December 05, 2005 10:29 AM
  • That would be great, although I don't know how strong typing can be enforced in this type of queries, which involve instance members of the elements of the collection.

    Monday, December 05, 2005 8:25 PM
  • Welcome to the wonderful world of type inference.  It even works with generics and anonymous types... ;)



    users.Where(user => user.ConnectionTime > TimeSpan.FromHours(24))

     

    For example, if users is of type List<User>, then the Where extension method will expect a predicate that accepts type User.  If users was instead a DLinq table of User, the Where extension defined for that would expect an Expression tree whose argument type was User.  This is a difference in the signatures for the Where extension defined for IEnumerable<T> and the Dlinq table -- the compiler sees the type expected in the slot where the lambda exists, and creates the appropriate structure (anonymous delegate, or ExpressionTree) at that point.

     

    Tuesday, December 06, 2005 10:01 AM
  • Sorry to lump all VB9 syntax together but...

    Given some class C
    With a constructor signature New(Integer)
    And some Properties worth setting
    How will the compiler resolve the difference between

    Dim c = New C(3) {.Property = value} 'Object

    And

    Dim c = New C{3} {} 'Array
    ===============================
    On an unrelated note I hate semicolons. No reason in particular. It would be cool if VB could turn off line terminators within a certain context, such as the intializers. This free-style zone needn't apply to everything with the {} only the {} itself.

    Of course I would like to seach such context awareness elsewhere or perhaps better a symbolic way of turning it on for a certain block of code: right now I'm thinking code wrapped in <> since the attributes probably show need of it most.
    ================================
    Relaxed delegates are all good and well.
    But what I need is relaxed interfaces.
    Not in the dynamic late-bound kinda way.

    VB has the fun ability to have a method implement an interface member with a different name, or multiple interfaces members declaratively. This isn't often useful but it happens.

    If I'm to implement IEnumerable(Of T)
    One method of interest is GetEnumerator() As IEnumerator(Of T)
    But IEnumerable(Of T) inherits IEnumerable
    So you must implement GetEnumerator() As IEnumerator

    Since IEnumerator(Of T) inherits IEnumerator
    the generic method should be able to implement both interfaces since any IEnumerator(Of T) is implicitly an IEnumerator

    Function GetEnumerator() As IEnumerator(Of T) Implements IEnumerable(Of T).GetEnumerator, IEnumerable

    And lastly, this method should still work even if my GetEnumerator returns a specific type as long as that type sooner or later inherits IEnumerable(Of T)
    =======================
    Other questions and comments later

    Tuesday, December 06, 2005 12:16 PM
  •  Keith Farmer wrote:

    Welcome to the wonderful world of type inference.  It even works with generics and anonymous types... ;)





    users.Where(user => user.ConnectionTime > TimeSpan.FromHours(24))

     

    For example, if users is of type List<User>, then the Where extension method will expect a predicate that accepts type User.  If users was instead a DLinq table of User, the Where extension defined for that would expect an Expression tree whose argument type was User.  This is a difference in the signatures for the Where extension defined for IEnumerable<T> and the Dlinq table -- the compiler sees the type expected in the slot where the lambda exists, and creates the appropriate structure (anonymous delegate, or ExpressionTree) at that point.

     



    Wonderful ;-)

    Thus, "user =>" means that user is a kind of temporary variable within the block and is updated for every iteration of the loop in the Where method.
    Tuesday, December 06, 2005 2:53 PM
  • Hi Amanda,

    For the sake of consistency and the benefit of the programmers that jump back and forth between C# and VB, it would be nice to keep the LINQ syntax uniform between the 2 languages. This way, there will be less to remember and a shorter learning curve and higher productivity.

    LINQ is a new language enhancement, and is "datasource" neutral. So it should be treated as such. VB programmers are smart enough to catch on and understand a new syntax. There's no reason to keep LINQ syntax simple and "familiar" by making it match SQL syntax.

    Besides, if further down the road... LINQ lends itself to some other future cutting edge idea where it is necessary to introduce another expression (or keyword) which does not exist in any SQL grammer/syntax that is present today, then adding the new keyword will differentiate (todays) VB syntax from SQL syntax, and will be more annoying because it may be deemed to be some sort of a copied hack.

    LINQ is not a replacement and is optional to use. Those that can't handle the C# syntax still have the current normal functional programming programming style to fall back on.

    Please, keep the syntax the same as C#.

    Thanks,

    Fleming

    Thursday, February 15, 2007 6:09 PM
  • Please, keep the syntax the same as C#.

    While I do agree with the decision to make the change I don't agree with a goal of maintaining consistency with C#. Something should be added to VB based on its merit rather than the trendiness of its sister language. I think often the languages will adopt similar features because they do have the same goal as general purpose languages.

    A deeper danger must be considered. The BASIC family of languages have always been a strong and idependant with a following inspired by the features which set them apart. It wasn't the similarities to C* (God no) that made people say "I can use this"  but the differences that made us say "I'd rather use this".

    The Microsoft .NET Languages, Basic, C#, and C++/CLI are interesting and for now independent. When they start being each other plus-or-minus semicolons they loose their purpose for existing and people start saying (Why not just use 'X'). In fact until I saw that C++/CLI despite its awesome power and refined expressiveness over Managed Extensions is ultimately as unintuitive as C++ I thought that it completely negated the usefulness of C#.

    I hear it on the forums and in the channels "Can C# do anything that Basic can't? Oh, pointers - well why would I use a verbose subset?". J# is dead because it just... didn't have a competitive advantage. Now that the WSIWIG, Drag & Drop functionality VB built over a decade has been given to the semicons and they can write and compile programs in comparable time with a clean syntax the playing field is well leveled. VB has to step up its game. And let's not forget the obvious fact that the pressure to use semicolons is overwhelming. The idea that better programmers use semicolons is overwhelming. And the pressure bleeds the Basic user base aiding the stereotypes.

    Let me be more direct - VB has to suck less and rock more and stop trying to live in C#'s shadow or it's dead - plain and simple. From a financial stand point MS is going to invest in a language with a user base which means being attractive. If VB can't be attractive we're going to see a lot more feature cuts from VB (Dynamic Interfaces, Refactoring) and a lot more C# whining and getting anything they wan't with a pink bow no matter if it is like 2 days before RTM (Edit & Continue).

    Friday, February 16, 2007 5:25 AM
  •  

    It doesn't matter to me if C# follows VB syntax, but it would just be nice - for a change - where the programmers don't have to remember so many different language distinctions, especially when it can be helped.

    Besides, the LINQ syntax in C# of is just as VB'ish as anyone can imagine, even if it isn't SQL'ish.

    I'm not intending for another language syntax/comparison thread war but I do like the simpler variable declartion in C#, it's shorter than Dim ... as ...  in VB. I don't care for the semicolons of C#, but I'm more annoyed of the underscore for a line continuation in VB. I don't particularly care for curly braces of C# either, and I like the auto indentation of VS IDE for VB. ... etc. etc... to each his own.

    And I think,  aside from the syntax differences, programming in C# can be considered as easy as VB especially now that programmers need not worry about memory management and pointers which was a pain in C and C++, and probably one of the biggest determining factor for new programmers to select VB over them.

    So, you're right,  if VB has to gain popularity (for lack of a better term) MS has to distinguish it from C#. Maybe make it more useful to a targeted set of audience - more bells and whistles somehow ??. Just like VB6 was clearly different from VC++ and MSACCESS. But they maybe hard pressed to find something they can add to VB that they can't just as easily add to C#. My guess... C# was made to attract the Java (and C++) audience with all the RAD capabilities of (Borland Delphi) and with the benefit of easier compiler technology implementation (I'm assuming this).

    Anyway, my main point was the first line :)

     

    Saturday, February 17, 2007 2:42 AM