ROTD
-
Note: Before the flamers get their blasters out, this is NOT a programming question. It is just a rant. I hate code like this:
public IResult GetToDoItem(int toDoItemID, Action onSuccess, Action<Exception> onFail)
{
IsReadOnly = true;return CoroutineFns.AsResult( () => \_repository.FindToDoItemByID(toDoItemID, (r) => { Item = r; Item.PropertyChanged += (s, e) => NotifyOfPropertyChange(() => CanSave); if (onSuccess != null) onSuccess(); }, onFail));}
Lambdas in lambdas in lambdas in lambdas. I find that to be nearly incomprehensible. Gaa!! I'm sure it is written very efficiently. X| I must be getting old and turning into a curmudgeon. :~
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
Good god. Not only the lambda's, but the method name "GetToDoItem" is a misnomer, it certainly doesn't return a todo item, instead it implements IoC. And worse, there's a side effect of adding an event handler, which I noticed never gets removed. I wonder how many times that event gets wired up and what effect that has. And not to mention that
onSuccesscan be null, so why would you call "GetToDoItem" if you never DO anything with it? I guess this method can also be used to check if there's a todo item of the particular ID and then throw an exception. Gee, but what if onFail is null? There's no check for that! Freaking insane, when:Dictionary<int, Item> itemsByID;would seem so much simpler. But then again, what do I know? I'm sure I'm missing the bigger picture here. Marc -
Note: Before the flamers get their blasters out, this is NOT a programming question. It is just a rant. I hate code like this:
public IResult GetToDoItem(int toDoItemID, Action onSuccess, Action<Exception> onFail)
{
IsReadOnly = true;return CoroutineFns.AsResult( () => \_repository.FindToDoItemByID(toDoItemID, (r) => { Item = r; Item.PropertyChanged += (s, e) => NotifyOfPropertyChange(() => CanSave); if (onSuccess != null) onSuccess(); }, onFail));}
Lambdas in lambdas in lambdas in lambdas. I find that to be nearly incomprehensible. Gaa!! I'm sure it is written very efficiently. X| I must be getting old and turning into a curmudgeon. :~
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
Well that's just how async programming looks like in C# 4.0 and most other programming languages.
awaitin C# 5.0 will allow writing such code in a much more readable fashion; but until then, continuation passing style using nested lambdas is the way to go. Well, there's also the alternative of using a separate thread for every operation (so that the methods can block and return results directly instead of using callbacks), but that's not very scalable and makes it much more difficult to write correct code (you need locks etc.). -
Note: Before the flamers get their blasters out, this is NOT a programming question. It is just a rant. I hate code like this:
public IResult GetToDoItem(int toDoItemID, Action onSuccess, Action<Exception> onFail)
{
IsReadOnly = true;return CoroutineFns.AsResult( () => \_repository.FindToDoItemByID(toDoItemID, (r) => { Item = r; Item.PropertyChanged += (s, e) => NotifyOfPropertyChange(() => CanSave); if (onSuccess != null) onSuccess(); }, onFail));}
Lambdas in lambdas in lambdas in lambdas. I find that to be nearly incomprehensible. Gaa!! I'm sure it is written very efficiently. X| I must be getting old and turning into a curmudgeon. :~
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
When learning assembly language (oh so long ago!) I used to look at disassemblies to get a feel for techniques, which even if not the greatest were still tips on how things should (might) be done. One thing I learned is that, as a general rule, you can be cheep and delusionally clever with your coding, putting as much into a statement as you wish. The compiler? For the most part, she don't give a damn. The code still needs to be executed stepwise - and so the (disassemblies) looked the same. Just because you didn't declare any intermediate storage doesn't phase the compiler one bit. The obvious lesson is that one might as well make the code human-comprehensible by breaking it down into manageable steps - which is what you really wanted, anyway.* * Turn on the optimizer and you're really pharting into the wind.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"As far as we know, our computer has never had an undetected error." - Weisert
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
I’m with you on this. I rarely use lambdas usually with LINQ (to memory not to SQL of course) and that is. What you have found is not programing, it’s a childish show off. Edit: typo Edit2: spoted second typo. :sigh:
There is only one Vera Farmiga and Salma Hayek is her prophet! Advertise here – minimum three posts per day are guaranteed.
I tend to agree with you. Lambdas have their uses, but that kind of code is just horrible to follow in my opinion. It might be standard practice, but that does not mean that I have to agree with it. X| Edit: DYAC!
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
-
Good god. Not only the lambda's, but the method name "GetToDoItem" is a misnomer, it certainly doesn't return a todo item, instead it implements IoC. And worse, there's a side effect of adding an event handler, which I noticed never gets removed. I wonder how many times that event gets wired up and what effect that has. And not to mention that
onSuccesscan be null, so why would you call "GetToDoItem" if you never DO anything with it? I guess this method can also be used to check if there's a todo item of the particular ID and then throw an exception. Gee, but what if onFail is null? There's no check for that! Freaking insane, when:Dictionary<int, Item> itemsByID;would seem so much simpler. But then again, what do I know? I'm sure I'm missing the bigger picture here. MarcIn fairness to the author (whomever that might be), the code was from a sample project. It was never intended to be production code. Edit: but thanks for pointing out the flaws. This WPF stuff is fairly new to me. I'm trying real hard to follow good MVVM design practices in my code (as soon as I get my head around it).
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
-
Well that's just how async programming looks like in C# 4.0 and most other programming languages.
awaitin C# 5.0 will allow writing such code in a much more readable fashion; but until then, continuation passing style using nested lambdas is the way to go. Well, there's also the alternative of using a separate thread for every operation (so that the methods can block and return results directly instead of using callbacks), but that's not very scalable and makes it much more difficult to write correct code (you need locks etc.).So I am learning. :sigh:
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
-
Welcome to the Curmudgeon Club. Myself, Roger, Nagy and others are long time members, not forgetting the honorary chairman, Henry.
------------------------------------ I will never again mention that I was the poster of the One Millionth Lounge Post, nor that it was complete drivel. Dalek Dave CCC Link[^] Trolls[^]
Henry Minute Do not read medical books! You could die of a misprint. - Mark Twain Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.” I wouldn't let CG touch my Abacus! When you're wrestling a gorilla, you don't stop when you're tired, you stop when the gorilla is.
-
Henry Minute Do not read medical books! You could die of a misprint. - Mark Twain Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.” I wouldn't let CG touch my Abacus! When you're wrestling a gorilla, you don't stop when you're tired, you stop when the gorilla is.
I wanna be like you!
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
-
Holy retardation Batman! Where did you pull that fossil from? :-D
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
-
Note: Before the flamers get their blasters out, this is NOT a programming question. It is just a rant. I hate code like this:
public IResult GetToDoItem(int toDoItemID, Action onSuccess, Action<Exception> onFail)
{
IsReadOnly = true;return CoroutineFns.AsResult( () => \_repository.FindToDoItemByID(toDoItemID, (r) => { Item = r; Item.PropertyChanged += (s, e) => NotifyOfPropertyChange(() => CanSave); if (onSuccess != null) onSuccess(); }, onFail));}
Lambdas in lambdas in lambdas in lambdas. I find that to be nearly incomprehensible. Gaa!! I'm sure it is written very efficiently. X| I must be getting old and turning into a curmudgeon. :~
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
In my experience I have seen new and older programmers. The newer ones have taken to landas more naturally. Not sure if they are crammed down their throats in school or what. But in working with them I find they use them not necessarily to show off, but that is what they know. For example, I have seen code riddled with
public event EventHandler SomeEvent = (s, e) => { };
Where as I have always let the event be null and let the objects needing it build up the event collection (i.e. +=). Then create some wrapper for null check
private void RaiseSomeEvent()
{
if(SomeEvent != null)
{
SomeEvent(this, EventArgs.Empty); //Or pass through the args received
}
}Maybe the new recruits are on to something. Not sure. I did some perf testing a while back and found empty delegates were more expensive than an if, however what about one empty delegate to many ifs. Not sure. But that is not the point really. They did not put this code in to 'show off' nor did they do perf testing. They did it because they knew how, and it took care of some problems (null ref). The same is true with other uses of lambda or any new technologies. A programmer finds a way to get something down, and tends to stick with it. Even if an entire framework comes out simplifying it the programmer will use their old methodolgies. When I first saw lamdas I gagged a little. But I find them quite easy to read now. Espeacially after writting some quite complicated ones that were even more complicated with out. In some cases it is easier for your thought flow in creating. Maybe it is harder for a non-Lamda user to understand after the fact, but that is not likely the programmers initial concern. I am not defending this particular code chunck, as it is not clean at all. But most likely you renamed and lost a little formatting in the post here. I have found that formatting (white space etc.) and proper naming is the key to leaving bread crumbs for your collegues (and yourself for that matter). I am defending lamdas though as I have found them quite usefull and dare I say cleaner in many cases. It just takes proper usage, but this is true with any technology.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
Good god. Not only the lambda's, but the method name "GetToDoItem" is a misnomer, it certainly doesn't return a todo item, instead it implements IoC. And worse, there's a side effect of adding an event handler, which I noticed never gets removed. I wonder how many times that event gets wired up and what effect that has. And not to mention that
onSuccesscan be null, so why would you call "GetToDoItem" if you never DO anything with it? I guess this method can also be used to check if there's a todo item of the particular ID and then throw an exception. Gee, but what if onFail is null? There's no check for that! Freaking insane, when:Dictionary<int, Item> itemsByID;would seem so much simpler. But then again, what do I know? I'm sure I'm missing the bigger picture here. MarcMarc Clifton wrote:
I'm sure I'm missing the bigger picture here.
You and me both. I think it's an under 40 thang.
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
-
Note: Before the flamers get their blasters out, this is NOT a programming question. It is just a rant. I hate code like this:
public IResult GetToDoItem(int toDoItemID, Action onSuccess, Action<Exception> onFail)
{
IsReadOnly = true;return CoroutineFns.AsResult( () => \_repository.FindToDoItemByID(toDoItemID, (r) => { Item = r; Item.PropertyChanged += (s, e) => NotifyOfPropertyChange(() => CanSave); if (onSuccess != null) onSuccess(); }, onFail));}
Lambdas in lambdas in lambdas in lambdas. I find that to be nearly incomprehensible. Gaa!! I'm sure it is written very efficiently. X| I must be getting old and turning into a curmudgeon. :~
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
Hmm... so I'm the only one around here who really likes lambdas.
-
In my experience I have seen new and older programmers. The newer ones have taken to landas more naturally. Not sure if they are crammed down their throats in school or what. But in working with them I find they use them not necessarily to show off, but that is what they know. For example, I have seen code riddled with
public event EventHandler SomeEvent = (s, e) => { };
Where as I have always let the event be null and let the objects needing it build up the event collection (i.e. +=). Then create some wrapper for null check
private void RaiseSomeEvent()
{
if(SomeEvent != null)
{
SomeEvent(this, EventArgs.Empty); //Or pass through the args received
}
}Maybe the new recruits are on to something. Not sure. I did some perf testing a while back and found empty delegates were more expensive than an if, however what about one empty delegate to many ifs. Not sure. But that is not the point really. They did not put this code in to 'show off' nor did they do perf testing. They did it because they knew how, and it took care of some problems (null ref). The same is true with other uses of lambda or any new technologies. A programmer finds a way to get something down, and tends to stick with it. Even if an entire framework comes out simplifying it the programmer will use their old methodolgies. When I first saw lamdas I gagged a little. But I find them quite easy to read now. Espeacially after writting some quite complicated ones that were even more complicated with out. In some cases it is easier for your thought flow in creating. Maybe it is harder for a non-Lamda user to understand after the fact, but that is not likely the programmers initial concern. I am not defending this particular code chunck, as it is not clean at all. But most likely you renamed and lost a little formatting in the post here. I have found that formatting (white space etc.) and proper naming is the key to leaving bread crumbs for your collegues (and yourself for that matter). I am defending lamdas though as I have found them quite usefull and dare I say cleaner in many cases. It just takes proper usage, but this is true with any technology.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
The chunk was from a vendor's sample project. Nothing was renamed. The formatting came out surpringly close (if not identical) to the original . I was not beating up on the use of lambdas in general. Just ranting that to my "old school" way of thinking, somtimes they seem very obtuse. No doubt I just need to get used to them. Getting old and set in my ways. :sigh:
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
-
Hmm... so I'm the only one around here who really likes lambdas.
I didn't say that I never use them...
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
-
Hmm... so I'm the only one around here who really likes lambdas.
-
In my experience I have seen new and older programmers. The newer ones have taken to landas more naturally. Not sure if they are crammed down their throats in school or what. But in working with them I find they use them not necessarily to show off, but that is what they know. For example, I have seen code riddled with
public event EventHandler SomeEvent = (s, e) => { };
Where as I have always let the event be null and let the objects needing it build up the event collection (i.e. +=). Then create some wrapper for null check
private void RaiseSomeEvent()
{
if(SomeEvent != null)
{
SomeEvent(this, EventArgs.Empty); //Or pass through the args received
}
}Maybe the new recruits are on to something. Not sure. I did some perf testing a while back and found empty delegates were more expensive than an if, however what about one empty delegate to many ifs. Not sure. But that is not the point really. They did not put this code in to 'show off' nor did they do perf testing. They did it because they knew how, and it took care of some problems (null ref). The same is true with other uses of lambda or any new technologies. A programmer finds a way to get something down, and tends to stick with it. Even if an entire framework comes out simplifying it the programmer will use their old methodolgies. When I first saw lamdas I gagged a little. But I find them quite easy to read now. Espeacially after writting some quite complicated ones that were even more complicated with out. In some cases it is easier for your thought flow in creating. Maybe it is harder for a non-Lamda user to understand after the fact, but that is not likely the programmers initial concern. I am not defending this particular code chunck, as it is not clean at all. But most likely you renamed and lost a little formatting in the post here. I have found that formatting (white space etc.) and proper naming is the key to leaving bread crumbs for your collegues (and yourself for that matter). I am defending lamdas though as I have found them quite usefull and dare I say cleaner in many cases. It just takes proper usage, but this is true with any technology.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
Collin Jasnoch wrote:
private void RaiseSomeEvent() { if(SomeEvent != null) { SomeEvent(this, EventArgs.Empty); //Or pass through the args received } }
Collin Jasnoch wrote:
They did it because they knew how, and it took care of some problems (null ref).
Oooh, they are close and yet so far as this doesn't cope with null - what happens if SomeEvent becomes null between the test and the call (this does happen)? You end up with a null reference - the trick is to do this:
private void RaiseSomeEvent()
{
MyTypeOfSomeEvent handler = SomeEvent;
if(handler != null)
{
SomeEvent(this, EventArgs.Empty); //Or pass through the args received
}
}Forgive your enemies - it messes with their heads
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
The chunk was from a vendor's sample project. Nothing was renamed. The formatting came out surpringly close (if not identical) to the original . I was not beating up on the use of lambdas in general. Just ranting that to my "old school" way of thinking, somtimes they seem very obtuse. No doubt I just need to get used to them. Getting old and set in my ways. :sigh:
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
Yeah, then your vendor is cruel. It is one thing to write code that way, and an entirely different thing to write sample code that way. And you deffinately got my point. Everyone gets set in their ways. Its more natural than diving into everything new. Most have 'phases' where they dig into the new things. But when it comes down to it, you do your time and want things somewhat stationary. You don't want to come into work every other week and be told "We are going to port this to a different environment" or lets convert everythign to using feature "Yada yadda"... yet every now and then those are words you have been dieing to hear. Other times it takes them to be first 'dreaded' words, yet after some time words you are dieing to hear on a different system. Some older programmers I know had that experience with .Net in general. No one wanted to convert the systems... Until they had the pleasure of using a .Net system.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
Collin Jasnoch wrote:
private void RaiseSomeEvent() { if(SomeEvent != null) { SomeEvent(this, EventArgs.Empty); //Or pass through the args received } }
Collin Jasnoch wrote:
They did it because they knew how, and it took care of some problems (null ref).
Oooh, they are close and yet so far as this doesn't cope with null - what happens if SomeEvent becomes null between the test and the call (this does happen)? You end up with a null reference - the trick is to do this:
private void RaiseSomeEvent()
{
MyTypeOfSomeEvent handler = SomeEvent;
if(handler != null)
{
SomeEvent(this, EventArgs.Empty); //Or pass through the args received
}
}Forgive your enemies - it messes with their heads
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
Yeah I guess that could happen. Never thought about it actually. But to be clear, I am the culperate of that 'bad' code. The 'newer' way (using a lamda with an empty delegate) would not run into the issue, unless you were nulling your SomeEvent within the publisher of the event (it is the one that initializes using an emepty delegate). I have never seen a reason to do this though. Usually your subscribers remove their own subscriptions. I think the idea of it is that it has atleast one subscription (do nothing), rather than being initialized to null (cant do anything) and waiting on subscriptions (do something). Maybe I am missing something though.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
Note: Before the flamers get their blasters out, this is NOT a programming question. It is just a rant. I hate code like this:
public IResult GetToDoItem(int toDoItemID, Action onSuccess, Action<Exception> onFail)
{
IsReadOnly = true;return CoroutineFns.AsResult( () => \_repository.FindToDoItemByID(toDoItemID, (r) => { Item = r; Item.PropertyChanged += (s, e) => NotifyOfPropertyChange(() => CanSave); if (onSuccess != null) onSuccess(); }, onFail));}
Lambdas in lambdas in lambdas in lambdas. I find that to be nearly incomprehensible. Gaa!! I'm sure it is written very efficiently. X| I must be getting old and turning into a curmudgeon. :~
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
Tom Delany wrote:
Lambdas in lambdas in lambdas.
What have you got against The Revenge Of The Nerds?
Michael Martin Australia "I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible." - Mr.Prakash One Fine Saturday. 24/04/2004
-
Tom Delany wrote:
Lambdas in lambdas in lambdas.
What have you got against The Revenge Of The Nerds?
Michael Martin Australia "I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible." - Mr.Prakash One Fine Saturday. 24/04/2004
Ha! I never thought of that. Of course! It all makes sense now... :)
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
