A programming observation...
-
When Linq first raised it's head I was delighted, here is TSQL for datatables in C#, I'll be able to do queries against a datatable in the business logic layer without resorting to the database. What a frikking nightmare we have ended up with. I like TSQL and its brother PLSQL, I know SQL syntax, I'm comfortable with SQL, it is a tried and true way of manipulating data. If I could do that in C# it would save me endless time, but no we get Linq. What a PITA.
10!
Mycroft Holmes wrote:
do queries against a datatable
I don't know why I'd want to do that.
-
When Linq first raised it's head I was delighted, here is TSQL for datatables in C#, I'll be able to do queries against a datatable in the business logic layer without resorting to the database. What a frikking nightmare we have ended up with. I like TSQL and its brother PLSQL, I know SQL syntax, I'm comfortable with SQL, it is a tried and true way of manipulating data. If I could do that in C# it would save me endless time, but no we get Linq. What a PITA.
It looks like you have understanding problem of what Linq does. Most people thinks Linq to SQL is the only possibility that Linq offers. Linq is much more than that and it's not an equivalent of TSql. I like it and IMO, it produces more readable code. The only disadvantage I felt with Linq is, it makes tough to calculate the algorithm complexity. Improper use of Linq queries can result in worst complexity (I am not talking about Linq to Sql). If you are interested, take a look at this wiki[^].
Mycroft Holmes wrote:
I'll be able to do queries against a datatable in the business logic layer without resorting to the database.
:confused:
Best wishes, Navaneeth
-
It looks like you have understanding problem of what Linq does. Most people thinks Linq to SQL is the only possibility that Linq offers. Linq is much more than that and it's not an equivalent of TSql. I like it and IMO, it produces more readable code. The only disadvantage I felt with Linq is, it makes tough to calculate the algorithm complexity. Improper use of Linq queries can result in worst complexity (I am not talking about Linq to Sql). If you are interested, take a look at this wiki[^].
Mycroft Holmes wrote:
I'll be able to do queries against a datatable in the business logic layer without resorting to the database.
:confused:
Best wishes, Navaneeth
N a v a n e e t h wrote:
If you are interested, take a look at this wiki[^].
One of my reference sites - there are a lot of them. The main problem may have been my expectation, to me SQL is simple, having used it for so many years. I was looking forward to being able to do a select sum() against a list of objects or a datatable. The syntax and debugging of Linq queries is just painful and if you throw in lambda expressions then it is even worse. I know most of these things can be done but it is a very different paradigm and certainly is not simple. Try and OUTER JOIN bah!
-
It looks like you have understanding problem of what Linq does. Most people thinks Linq to SQL is the only possibility that Linq offers. Linq is much more than that and it's not an equivalent of TSql. I like it and IMO, it produces more readable code. The only disadvantage I felt with Linq is, it makes tough to calculate the algorithm complexity. Improper use of Linq queries can result in worst complexity (I am not talking about Linq to Sql). If you are interested, take a look at this wiki[^].
Mycroft Holmes wrote:
I'll be able to do queries against a datatable in the business logic layer without resorting to the database.
:confused:
Best wishes, Navaneeth
-
Yikes. I don't know what that is and I don't want to know as it appears to be one of those modern sytactic sugar type things designed save a few minutes of typing at the complete sacrifice of maintainability and readability.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
-
Yikes. I don't know what that is and I don't want to know as it appears to be one of those modern sytactic sugar type things designed save a few minutes of typing at the complete sacrifice of maintainability and readability.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
and what is the maintainable solution?
-
Yikes. I don't know what that is and I don't want to know as it appears to be one of those modern sytactic sugar type things designed save a few minutes of typing at the complete sacrifice of maintainability and readability.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
The second example is a really elegant and simple solution to the issue posed by Miszou. Just because you don't understand it doesn't make it at all less maintainable or readable to someone current with the .NET framework. The only syntactic sugar is the lambda expression, which is a lot more readable and maintainable than an anonymous delegate.
-
Imagine a set of numbers, and you need to determine if they are all unique. (Slightly contrived example, but it'll work for now). In C# for example, you might do a simple foreach loop and break/set a flag if the previous number was different from the current one. But I had to do this in SQL, and for about 30 seconds, my brain was in the looping/counting mode of C#, and what a ghastly mess I was going to end up with... Then suddenly my brain engaged itself fully, slipped into SQL mode and I realized (of course) that I could do exactly the same thing with a trivial select count( distinct id ) from #t, where a result of anything greater than 1 would indicate that the numbers were not unique. I'm not sure why I posted this, other than to marvel at two completely different methods of accomplishing the exact same thing. I'm sure there are hundreds of ways of solving this simple problem, and hundreds more languages in which to do so. Many of them I imagine would be similar, but some of the more esoteric methods/languages could be really interesting. :cool: Anyway, just something to think about...
The StartPage Randomizer - The Windows Cheerleader - Twitter
You can do that with LINQ too, right?
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001 -
and what is the maintainable solution?
Hire a contractor to write a proper method - with comments - and no
goto's. :).45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001 -
The second example is a really elegant and simple solution to the issue posed by Miszou. Just because you don't understand it doesn't make it at all less maintainable or readable to someone current with the .NET framework. The only syntactic sugar is the lambda expression, which is a lot more readable and maintainable than an anonymous delegate.
It may be clever but it's far from elegant or simple and has no place in professionally written code unless you think dense, unreadable, no more performant code that can't be understood by anyone with a programming background in any language who may be brought in to maintain it in future has a place in a professional shop.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
-
It may be clever but it's far from elegant or simple and has no place in professionally written code unless you think dense, unreadable, no more performant code that can't be understood by anyone with a programming background in any language who may be brought in to maintain it in future has a place in a professional shop.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
It borrows heavily from widely accepted concepts used in functional languages as well as basic set theory. Pretty soon "a programming background in any language" will include C#3, which plays a significant role in exposing the set based extension method library that is the bulk of pure LINQ. The future will yield more and more C# developers versed in LINQ and more exposed to the functional concept of programming. I utterly fail do grasp the supposed density of this single line of code:
int count = objs.DistinctBy(o=> o.ID).Count();If the lambda is foreign to you, how about a plainobjs.Distinct().Count()call on a set of records? Just how dense is that compared tobool DistinctList()
{
List uniqueList = new List();
for (int i = 0; i < objs.Count; i++)
{
if (sortedSet[i] != sortedSet[i-1])
{
uniqueList .Add(sortedSet[i];
}
return uniqueList;
}Which one says most about what is does in the most succinct way?
-
You can do that with LINQ too, right?
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001Yep! :-D
-
Hire a contractor to write a proper method - with comments - and no
goto's. :).45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001Pick me! Pick me. My solution is to generate a SQL query that uses distinct and pass the collection to that before returning the results as an IEnumerable. :cool:
-
It borrows heavily from widely accepted concepts used in functional languages as well as basic set theory. Pretty soon "a programming background in any language" will include C#3, which plays a significant role in exposing the set based extension method library that is the bulk of pure LINQ. The future will yield more and more C# developers versed in LINQ and more exposed to the functional concept of programming. I utterly fail do grasp the supposed density of this single line of code:
int count = objs.DistinctBy(o=> o.ID).Count();If the lambda is foreign to you, how about a plainobjs.Distinct().Count()call on a set of records? Just how dense is that compared tobool DistinctList()
{
List uniqueList = new List();
for (int i = 0; i < objs.Count; i++)
{
if (sortedSet[i] != sortedSet[i-1])
{
uniqueList .Add(sortedSet[i];
}
return uniqueList;
}Which one says most about what is does in the most succinct way?
I remember similar discussions about the ?: operator in C/C++/C# many years ago. Some people will always fear the new stuff they don't have the time to learn. I think it's fear of becoming obsolete. Also, you must not forget that John's words are law. All he says is the truth, and nothing but the truth. I for one love lambdas in C#, because they make life MUCH easier, and quite frankly, the code is more readable. No more essays, just one liners! Heck, you can even throw in a one line comment just above the code, explaining what it does (in case the lambda-impaired have to read/maintain the code).
-
You can do that with LINQ too, right?
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001Only an unprofessional programmer would do that, or so they say...
-
I remember similar discussions about the ?: operator in C/C++/C# many years ago. Some people will always fear the new stuff they don't have the time to learn. I think it's fear of becoming obsolete. Also, you must not forget that John's words are law. All he says is the truth, and nothing but the truth. I for one love lambdas in C#, because they make life MUCH easier, and quite frankly, the code is more readable. No more essays, just one liners! Heck, you can even throw in a one line comment just above the code, explaining what it does (in case the lambda-impaired have to read/maintain the code).
Jörgen Sigvardsson wrote:
Also, you must not forget that John's words are law. All he says is the truth, and nothing but the truth.
As I've said probably a zillion times on this site and qualified a zillion other times: we all come from our own perspective and what we say reflects that. What you're really saying here is that you don't like a forceful argument and that's a shame but not my concern.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
-
It borrows heavily from widely accepted concepts used in functional languages as well as basic set theory. Pretty soon "a programming background in any language" will include C#3, which plays a significant role in exposing the set based extension method library that is the bulk of pure LINQ. The future will yield more and more C# developers versed in LINQ and more exposed to the functional concept of programming. I utterly fail do grasp the supposed density of this single line of code:
int count = objs.DistinctBy(o=> o.ID).Count();If the lambda is foreign to you, how about a plainobjs.Distinct().Count()call on a set of records? Just how dense is that compared tobool DistinctList()
{
List uniqueList = new List();
for (int i = 0; i < objs.Count; i++)
{
if (sortedSet[i] != sortedSet[i-1])
{
uniqueList .Add(sortedSet[i];
}
return uniqueList;
}Which one says most about what is does in the most succinct way?
Brady Kelly wrote:
Pretty soon "a programming background in any language" will include C#3,
WTF? Do you ever re-read what you've typed to see if it makes sense? :) Here's my reasoning on this as it applies to me: LINQ brings nothing of benefit to my end users of my software and anything that brings no benefit to my end users doesn't get used because I make software for others not my own amusement. LINQ provides nothing that isn't possible without using LINQ. LINQ may or may not be a fad, I have yet to see any real world code that uses it which doesn't mean no one is using it, it just means in my area of work and areas I'm concerned about and responsible for, no one is using it. It's of fundamental importance to me that any code I write be as clear as possible, as widely understandable as possible. To me you are doing the equivalent of an author throwing in french language jokes in an english language novel simply because they seem more clever written in french. Example 2 in your post is clear, easy to understand at a glance and could be understood and worked with by anyone from nearly any programming background and it's future proof, it doesn't rely on a possible fad. Most importantly of all it doesn't rely on any "tricks" that might get changed in the future causing the code to need to be rewritten.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
-
Jörgen Sigvardsson wrote:
Also, you must not forget that John's words are law. All he says is the truth, and nothing but the truth.
As I've said probably a zillion times on this site and qualified a zillion other times: we all come from our own perspective and what we say reflects that. What you're really saying here is that you don't like a forceful argument and that's a shame but not my concern.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
A modest human being says or writes "I think that..." or "I believe so and so, because...". You don't. Maybe your intent is to say what you think or believe is right, but it doesn't come across. You see, you're not arguing forcefully. You're being a dickhead, denying everybody else of having an opinion. Yes. I think you are a dickhead when you argue that other people are less productive if they use more than one monitor. If I have to explain why I believe so, then you're more narrow minded than I thought. And don't start to whine about "douchebaggery", because you're the douche bag belittling others with your "I am the law"-rhetoric.
-
A modest human being says or writes "I think that..." or "I believe so and so, because...". You don't. Maybe your intent is to say what you think or believe is right, but it doesn't come across. You see, you're not arguing forcefully. You're being a dickhead, denying everybody else of having an opinion. Yes. I think you are a dickhead when you argue that other people are less productive if they use more than one monitor. If I have to explain why I believe so, then you're more narrow minded than I thought. And don't start to whine about "douchebaggery", because you're the douche bag belittling others with your "I am the law"-rhetoric.
-
Brady Kelly wrote:
Pretty soon "a programming background in any language" will include C#3,
WTF? Do you ever re-read what you've typed to see if it makes sense? :) Here's my reasoning on this as it applies to me: LINQ brings nothing of benefit to my end users of my software and anything that brings no benefit to my end users doesn't get used because I make software for others not my own amusement. LINQ provides nothing that isn't possible without using LINQ. LINQ may or may not be a fad, I have yet to see any real world code that uses it which doesn't mean no one is using it, it just means in my area of work and areas I'm concerned about and responsible for, no one is using it. It's of fundamental importance to me that any code I write be as clear as possible, as widely understandable as possible. To me you are doing the equivalent of an author throwing in french language jokes in an english language novel simply because they seem more clever written in french. Example 2 in your post is clear, easy to understand at a glance and could be understood and worked with by anyone from nearly any programming background and it's future proof, it doesn't rely on a possible fad. Most importantly of all it doesn't rely on any "tricks" that might get changed in the future causing the code to need to be rewritten.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
John C wrote:
Example 2 in your post is clear, easy to understand at a glance and could be understood and worked with by anyone from nearly any programming background and it's future proof, it doesn't rely on a possible fad.
Example 2 in my post is also doomed to failure, as is. Now I didn't write a buggy example because I'm dependent on LINQ for such simple tasks, but because I was coding for example, not for a product, but the LINQ example will work as long as IEnumerable and the LINQ assemblies are available, which in most probably cases will be a very long time.