C# + Linq = Perl?

(Rant starting)
 Is it me, or is all the new linq stuff making C# more complex for no real reason?

Now, I know that Perl has it's fans and that it's very powerful and flexible, but it's a real (I need to watch my language) to learn (IMHO).

One thing I really like about C# is it's simplicity -- OK, I know that it looks odd to a non-C programmer but there are only a few shorthand declarations to learn.

I can understand that people want to do stuff with fewer lines of code, but isn't that was class libraries are for?  Do we really need a syntax extension to allow queries? Couldn't someone have come up with an ADO.NET class that queries collections?

Unfortunately the linq syntax is slightly different from SQL, so were going to have to get used to another query syntax. Why? Whats wrong with SQL?

Somehow I'm getting the idea the some of the newer language features are a case of 'What a clever idea, now lets find a use for it', rather than solving any particular problem.

(Rant Ending)

So, can anyone gove me a compelling reasong for linq, other that 'fewer lines of code' (reduced lines of code can also be done by extending the framework, not the syntax)?

 Dr Herbie (grumpy old git).

Read this article for some insight on their motivation for LINQ

http://msdn.microsoft.com/netframework/future/linq/default.aspx?pull=/library/en-us/dndotnet/html/linqprojectovw.asp

The point of LINQ is in its name:  Language INtegrated Query.  They are adding query syntax to C# and VB.NET for metadata services, compile-time syntax checking, static typing, and IntelliSense.

DLINQ is going to be the successor to ADO.NET so "coming up with an ADO.NET that can query collections" is one way of describing what they are doing with LINQ.

The problem with SQL is that it is totally separate from C# or VB.NET so any time you build an SQL query and write C# or VB.NET code to execute that query, you have to bind its results to C# and VB.NET variables and usually without the benefit of metadata, syntax checking, static typing, and IntelliSense.  Microsoft has tried numerous approaches in the past to enable this without significant changes to the languages -- data binding in its various incarnations -- with varying degress of success and failure.

I agree that the LINQ stuff can and probably will make C# and VB.NET more complex.  However, Microsoft gave reasons why they're doing this.

JChung2006 wrote:

Read this article for some insight on their motivation for LINQ

http://msdn.microsoft.com/netframework/future/linq/default.aspx?pull=/library/en-us/dndotnet/html/linqprojectovw.asp

The point of LINQ is in its name:  Language INtegrated Query.  They are adding query syntax to C# and VB.NET for metadata services, compile-time syntax checking, static typing, and IntelliSense.

DLINQ is going to be the successor to ADO.NET so "coming up with an ADO.NET that can query collections" is one way of describing what they are doing with LINQ.

The problem with SQL is that it is totally separate from C# or VB.NET so any time you build an SQL query and write C# or VB.NET code to execute that query, you have to bind its results to C# and VB.NET variables and usually without the benefit of metadata, syntax checking, static typing, and IntelliSense.  Microsoft has tried numerous approaches in the past to enable this without significant changes to the languages -- data binding in its various incarnations -- with varying degress of success and failure.

I agree that the LINQ stuff can and probably will make C# and VB.NET more complex.  However, Microsoft gave reasons why they're doing this.

Ok, starting to make better sense now, looking at the code:

var x = new XElement("People",
                  from p in people 
                  where p.CanCode
                  select 
                    new XElement("Person", 
                                   new XAttribute("Age", p.Age),
                                   p.Name));

I can start to see where this could be useful.

Not having to use the 'var' keyword makes me feel like I'm on firmer ground:

IEnumerable<Person> persons =
    from e in x.Descendants("Person")
    select new Person { 
        Name = e.Value,
        Age = (int)e.Attribute("Age") 
    };

The VB syntax of

Dim expr As IEnumerable(Of String) = _
                   Select s.ToUpper() _
                   From s in names _
                   Where s.Length = 5 _
                   Order By s

seems to read more like SQL than the C# syntax of

IEnumerable<string> expr = from s in names 
                           where s.Length == 5
                           orderby s
                           select s.ToUpper();

Could we make C# put the select at the front, please? If VB can do it, why can't C#?

I guess it's early days yet, maybe it's all in the intellisense and you only see the real magic when using it in the IDE.

Thanks for the article link.

Dr Herbie

http://blogs.msdn.com/cyrusn/archive/2005/09/16/469953.aspx

http://blogs.msdn.com/aalialikoski/archive/2005/09/18/470929.aspx

>>Do we really need a syntax extension to allow queries? Couldn't someone have come up with an ADO.NET class that queries collections?
no, you don't really need it, you can still do it in other ways, if you don't like LINQ, you have the choice NOT to use it, but I think there are more people that like LINQ than there are people that think like you


>>Unfortunately the linq syntax is slightly different from SQL, so were going to have to get used to another query syntax. Why? Whats wrong with SQL?
Anders H already explained this, SQL syntax was designed to make it easier to read for the user, now we are programmers, and if you want features like autocomplete, etc, LINQ syntax is the way to go, again, you don't have to use it if you don't want, that's the beauty of it

If you haven't already watched the video on LINQ Herbie, have a look at it as it does explain some questions. With respect to LINQ not looking like SQL? They covered that in the video. It turns out that SQL has been doing things the weird way all along. The LINQ query format is much more natural and easier to process as you've got to narrow down your query before you can start pulling fields.

Edit: Someone beat me to it. Drats...

OK, my bad.

I watched the LINQ video and started to see the sense in it.  I can see that when the Intellisense is working the queries will be easier to debug.

I'm slightly worried that people will start using the 'var' keyword indiscriminately though.  I would only use it for the new anonymous types and not for 'normal' type declarations.  If you know the type, declare it! It makes the code more clear.
Maybe I'm still scarred from the messes I saw with people using variant in VB -- I know it's different from var, but I suspect people will try and use it the same way.

Still, time will tell and no, I don't have to use the new features if I don't want to.

if you are constructing an object, you won't make it more clear by writing the type twice

Dictionary<string, List<int>> bleee = new Dictionary<string, List<int>>();

var blee = new Dictionary<string, List<int>>();

but i wouldn't use it in case like

var wtf = DoSomething(WithSomething(Else));