To LinQ or not LinQ

  • Thread starter Thread starter Michael C
  • Start date Start date
M

Michael C

Hi Guys and Gals,

I wondering what people's opinions on using the "shorthand" syntax of linq
vs the
longer hand versions, eg

var x = from item in items where item.SomeDate.Year = 2008 select
item.SomeProperty;

vs

var x = items.Where(i => i.SomeDate.Year = 2008).Select(i =>
item.SomeProperty);

The first seems a bit neater etc but somehow it seems to break every rule in
the book as far as oop style syntax goes. What are you thoughts?

Cheers,
Michael
 
The first seems a bit neater etc but somehow it seems to break every rule in
the book as far as oop style syntax goes. What are you thoughts?
Click to expand...

To which book are you referring? Why is using the linq keywords not
oop?

Chris
 
Chris Dunaway said:
To which book are you referring? Why is using the linq keywords not
oop?
Click to expand...

I can only hope you're joking with your first question. Lame joke. With
regard to the second, he didn't say it's not OO, he said it's not "OO style
syntax", which is correct. (It's SQL style syntax, which to a certain
extent is the point.)
 
Hi Michael,
I wondering what people's opinions on using the "shorthand" syntax of linq
vs the longer hand versions, eg

var x = from item in items where item.SomeDate.Year = 2008 select
item.SomeProperty;
vs
var x = items.Where(i => i.SomeDate.Year = 2008).Select(i =>
item.SomeProperty);
Click to expand...

The advantages of both syntax versions can be argued, and I believe there
are valid points in both. In my opinion, the first syntax (the SQL-like one)
is clearer, and probably more familiar to most developers, at least in the
corporate landscape.

The latter reminds me of functional programming, which might not be as
well-known style of programming. But once F# is here and native part of the
next Visual Studio version 2010 (hopefully), I'm sure we are going to see
more and more these kind of syntaxes, and thus get more used to it.

For an maintainability perspective, I'd say that the first syntax is easier
to deal with, no matter what kind of background developers have (except
maybe statistical/mathematics, and so on).

Either one you choose, I'd suggest that you stick to one way of accessing
data in your applications.

Hope this helps!

--
Regards,

Mr. Jani Järvinen
C# MVP
Vantaa, Finland
(e-mail address removed)
http://www.saunalahti.fi/janij/
 
proxyuser said:
I can only hope you're joking with your first question. Lame joke. With
regard to the second, he didn't say it's not OO, he said it's not "OO style
syntax", which is correct. (It's SQL style syntax, which to a certain
extent is the point.)
Click to expand...

It's not SQL syntax either, I wished it was. It's a technique to
process sequences using methods.

FB
 
Frans Bouma said:
It's not SQL syntax either, I wished it was.
Click to expand...

I didn't say it was "SQL syntax", I said it was "SQL style syntax". From
the context, it should be clear this means the same thing that Jani said,
i.e. "the SQL-like" syntax.

For being programmers, you guys aren't paying much attention to detail here
:-)
 
proxyuser said:
I didn't say it was "SQL syntax", I said it was "SQL style syntax". From
the context, it should be clear this means the same thing that Jani said,
i.e. "the SQL-like" syntax.

For being programmers, you guys aren't paying much attention to detail
here :-)
Click to expand...

But what is an OO Syntax style ? Is there any syntax style shared by all OO
languages ?

The new version is a break with the C-family syntax, and we could discuss
wether it's a good thing or not, but it has nothing to do with being OO
style or not.

Would the foreach instruction be compliant with a so-called OO Syntax style
? The answer is the same : it's irrelevant.
 
proxyuser said:
I didn't say it was "SQL syntax", I said it was "SQL style syntax". From
the context, it should be clear this means the same thing that Jani said,
i.e. "the SQL-like" syntax.
Click to expand...

there's nothing SQL like about the syntax, despite the similar looking
keywords. SQL is set oriented, Linq is sequence oriented. That's a big
difference as sets don't have an ordering, sequences do.
For being programmers, you guys aren't paying much attention to detail here
:-)
Click to expand...

Heh, well, I think you missed a detail or two as well ;)

FB
 
        there's nothing SQL like about the syntax, despite the similar looking
keywords. SQL is set oriented, Linq is sequence oriented. That's a big
difference as sets don't have an ordering, sequences do.
Click to expand...

That's the semantics though, not the syntax.

I think it's reasonable to suggest that the *syntax* is at least "SQL-
like". To give a specific example, the operators are joined together
implicitly rather than requiring anything explicitly delimiting them.

As for what's appropriate: I vary it on a case-by-case basis. If I'm
using more than a couple of operators, and they're all available in
the query expression syntax, I'll use a query expression. For just a
couple of operators, or if you need to do a lot of mixing and matching
between query expression syntax and normal "dot notation" I use the
latter.

The clearest case is when there's either a single non-select operator
followed by a degenerate projection, or just a projection. For
example:

var x = from item in list
where item.Name == "fred"
select item;

var y = from item in list
select item.Name;

are better written as:

var x = list.Where(item => item.Name == "fred");
var y = list.Select(item => item.Name);

All in my opinion of course. I think it's worth being familiar with
both ways of expressing a query, so you can choose the most readable
one for any particular situation.

Jon
 
Christophe Lephay said:
But what is an OO Syntax style ? Is there any syntax style shared by all
OO languages ?
Click to expand...

Yes, more or less. You don't need to be obtuse here. We all know what
we're talking about, and everyone knows it when they see it.

A.B(x) is OO syntax style, SELECT x FROM A is SQL syntax style.
 
proxyuser said:
Yes, more or less. You don't need to be obtuse here. We all know what
we're talking about, and everyone knows it when they see it.
Click to expand...

Someone being obtuse on usenet? I've never heard of such a thing! ;-)
 
Frans Bouma said:
there's nothing SQL like about the syntax, despite the similar looking
keywords. SQL is set oriented, Linq is sequence oriented. That's a big
difference as sets don't have an ordering, sequences do.
Click to expand...

That's pretty gray imo. In a sequence the ordering can be unimportant so it
becomes like a set and in sql you can order a set so it becomes a sequence.

Michael
 
Michael said:
That's pretty gray imo. In a sequence the ordering can be unimportant so it
becomes like a set and in sql you can order a set so it becomes a sequence.
Click to expand...

a sequence has always an order, namely the order in which you traverse
the sequence. Applying an order action onto a set doesn't make it a
sequence: I can pick items from the set at random from the set even if
it's ordered in a different order. That's a key difference, albeit
theoretical.

The importancy of the difference comes to life when you try to convert
a Linq query to a SQL query. That's not a 1:1 projection, and not all
developers using linq realize that.

FB
 
proxyuser said:
Yes, more or less. You don't need to be obtuse here. We all know what
we're talking about, and everyone knows it when they see it.

A.B(x) is OO syntax style.
Click to expand...

Because someone doesn't assume as much as you do doesn't mean he is obtuse.

Smalltalk syntax is not OO, according to your assumption, and it wouldn't be
difficult to find other examples.

Moreover, a language can have non OO functionalities and still be OO. Are
generics OO ? Is reflection OO ? If they are not, how relevant would it be
for them to have a "OO syntax" ?

I could state as well that static methods are not OO unless a type is an
object, which is not the case in c#.

Syntax being OO or not (whatever it means) is irrelevant. What is relevant
is whether or not it is practicle.
 
Frans Bouma said:
a sequence has always an order, namely the order in which you traverse the
sequence.
Click to expand...

What about the case of the hash table which is meant to have no defined
order?

Michael
 
Peter said:
There may be no well-defined order, but the hash table still does have
order. As long as you don't modify the hash table (or any other
collection in .NET), the elements in the collection will always be
returned in the same order.

That said, I'm a bit puzzled by the direction this debate's taken. The
assertion that SQL is _strictly_ set-based doesn't make sense to me
either, since when you query the database, records always have to be
returned in _some_ order. Even if the database doesn't impose a
specific order on the data, it still has some inherent order, just as a
theoretically orderless collection in .NET still has order.
Click to expand...

By definition, a set returned by sql has an undefined order, unless you
specify the ordering. So running the same unordered query on a database
can result in different orderings.

the consumption of the set you see returned by the RDBMS seems to have
an order, but that's just the result of sequential traversing a cursor.
The set the cursor points to is a set without order.

Linq is based on the consumption of sets which is always done in some
order, as you say, so the set becomes a sequence. In haskell, the Monad
concept is a concept that describes this closely. It's not a surprise
that the lead designer of linq is also the founder of haskell ;)

That said, it's IMHO wrong to state that sql is sequence based just
because the results are consumed sequentially. The _operations_ in sql
aren't sequence based, although internally the operations might be
performed using sequence consuming functions. In linq they are, and this
is a fundamental difference: it makes it tough to project a linq query
onto sql, as linq can assume that a set IS ordered, but in sql you can't.
Likewise, while it's true that the LINQ syntax is very much centered
around the IEnumerable<T> interface, there's nothing about the interface
that requires the sequences to be well-defined. A collection _could_ in
fact return elements in random order for consecutive iterations. It's
only practicality that causes that not to happen in practice. :)

So, saying that LINQ and SQL are two entirely different beasts doesn't
make sense to me.
Click to expand...

just because you consume a set sequentially? Linq operators and
functions operate sequential on the sources, in sql this isn't defined:
they operate on sets, and how that's done (e.g. using sequences
internally) isn't known nor important. Because linq uses sequences and
not sets like sql, it can do more on the functionality level but less on
the overall algorithmic O level.
LINQ clearly has borrowed quite a lot from SQL and
can behave very similarly to SQL in many ways. This whole "one deals in
sets, the other deals with sequences" things seems like a complete
non-starter.
Click to expand...

Perhaps you should read more into set-oriented algebra vs. sequence
operations then. Or for example try to project linq queries onto sql and
you'll then see that for many queries a conversion has to take place
which isn't obvious.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
 
Hi Guys and Gals,

I wondering what people's opinions on using the "shorthand" syntax of linq
vs the
longer hand versions, eg

var x = from item in items where item.SomeDate.Year = 2008 select
item.SomeProperty;

vs

var x = items.Where(i => i.SomeDate.Year = 2008).Select(i =>
item.SomeProperty);

The first seems a bit neater etc but somehow it seems to break every rule in
the book as far as oop style syntax goes. What are you thoughts?
Click to expand...

The first example does look neater, and doesn't look like regular OOP
code. Is that a bad thing though? It resembles the declarative code of
SQL to a great extent - and in this case, it seems to me that that is
the more expressive and readable form.

The question of whether it's a good idea for a single language to mix
and match styles of syntax traditionally used in separate languages is
a different one - as can be seen from many peoples strong reactions to
the use of "var".

C#, ASP.NET development and contracting services, London, UK
http://www.sgat-computing-services.co.uk/
 

Indeed - it's the introduction into C# of features more traditionally
seen in declarative languages. That doesn't mean "SQL syntax", but it
resembles SQL more than it resembles OO syntaxes.
But what is an OO Syntax style ? Is there any syntax style shared by all OO
languages ?
Click to expand...

Most OO languages use a syntax which closely resembles C. A more
important point than the syntax itself is that when we write OO code,
we generally write out how we want an operation to be performed - our
OO code is essentially derived from prodedural programming techniques.
With declarative languages we write a description of the data we want,
and leave the compiler to work out the best way to get it (SQL is a
fine example of this).

SQL does of course contain procedural constructs (as do various
functional languages), and now we're seeing functional and declarative
features introduced into our procedural or object oriented languages.

What this means in the long term, I'm not sure - I don't want C# to
become very complex, but on the other hand, there are things which can
be expressed much more elegantly using the LINQ syntax than in the
regular OO way.

C#, ASP.NET development and contracting services, London, UK
http://www.sgat-computing-services.co.uk/
 
Smalltalk syntax is not OO, according to your assumption, and it wouldn't be
difficult to find other examples.
Click to expand...

The equation of a syntax with a particular programming model is
flawed. One could construct an infinite number of OO programming
languages each with a very different syntax (although it would take
time (-; ). C style syntaxes happen to be associated with OO
languages because most of the commonly used OO languages use that sort
of syntax (others of course use pascal style syntax, smalltalk style),
and of course the C style syntax is used in non-OO languages (like C,
or even javascript - which more closely resembles a functional
programming language in some ways).
Syntax being OO or not (whatever it means) is irrelevant. What is relevant
is whether or not it is practicle.
Click to expand...

I agree to an extent - but, syntax aside, LINQ and SQL have more in
common than LINQ (or SQL) and most languages based on C style syntax.
There is also the question of whether accommodating many different
programming styles (and syntaxes) within a single programming language
is a good idea. So far, I'm liking it - although I tend to isolate my
use of LINQ to particular layers in my apps. I've always liked the
simplicity of C#. I'd hate to see it grow more and more complex.


C#, ASP.NET development and contracting services, London, UK
http://www.sgat-computing-services.co.uk/
 
there's nothing SQL like about the syntax, despite the similar looking
keywords.
Click to expand...

surely that *is* syntax.
SQL is set oriented, Linq is sequence oriented. That's a big
difference as sets don't have an ordering, sequences do.
Click to expand...

while that is symantics.
Heh, well, I think you missed a detail or two as well ;)
Click to expand...

Too many details here for me :-). For one thing - the relational
database model is set oriented (although "relation" seems to be the
preferred term). SQL gets a pretty bad slating from most of the
relational database gurus though - on the grounds that it's based on
tables, not relations (the former can have duplicate rows, the latter
can't), and that "ORDER BY" does tend to sink the "sets don't have an
ordering" argument.

C#, ASP.NET development and contracting services, London, UK
http://www.sgat-computing-services.co.uk/
 
Back
Top