The new GOTO Statement?
-
After coming down off of the "That's pretty cool" factor and as members on my team have increasingly been using anonymous methods, lambda expressions and new Func<> routines embedded in methods. The complexity (IMO) as increased significantly. I've begun to question this seemingly popular approach as; What's the difference between using embedded functions and a goto statement? It seems to me it's no different and just as difficult to follow and maintain. I'd be curious on other opinions of this practice.
KISS
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
After coming down off of the "That's pretty cool" factor and as members on my team have increasingly been using anonymous methods, lambda expressions and new Func<> routines embedded in methods. The complexity (IMO) as increased significantly. I've begun to question this seemingly popular approach as; What's the difference between using embedded functions and a goto statement? It seems to me it's no different and just as difficult to follow and maintain. I'd be curious on other opinions of this practice.
Yes, you can abuse lambda's and make a mess. You can abuse goto and make a mess. You can abuse boolean variables to simulate some forms of goto and make just as big a mess. You can abuse operator overloading and make a mess, and when James Gosling says you can't have operator overloading in Java, you can make just as big a mess with method overloading and virtual methods if you set your mind to it. You can abuse switch in atrocious ways in C and C++ (case goes pretty much anywhere, it doesn't even look like valid syntax but it is), which is like a goto where you don't even know for sure where it will go. You can abuse pretty much every aspect of a general purpose programming language.
-
Yes, you can abuse lambda's and make a mess. You can abuse goto and make a mess. You can abuse boolean variables to simulate some forms of goto and make just as big a mess. You can abuse operator overloading and make a mess, and when James Gosling says you can't have operator overloading in Java, you can make just as big a mess with method overloading and virtual methods if you set your mind to it. You can abuse switch in atrocious ways in C and C++ (case goes pretty much anywhere, it doesn't even look like valid syntax but it is), which is like a goto where you don't even know for sure where it will go. You can abuse pretty much every aspect of a general purpose programming language.
You've just abused of your own post... and you've made a mess when you've painted some words in blue like links without being true links... :rolleyes:
[www.tamautomation.com] Robots, CNC and PLC machines for grinding and polishing.
-
Yes, you can abuse lambda's and make a mess. You can abuse goto and make a mess. You can abuse boolean variables to simulate some forms of goto and make just as big a mess. You can abuse operator overloading and make a mess, and when James Gosling says you can't have operator overloading in Java, you can make just as big a mess with method overloading and virtual methods if you set your mind to it. You can abuse switch in atrocious ways in C and C++ (case goes pretty much anywhere, it doesn't even look like valid syntax but it is), which is like a goto where you don't even know for sure where it will go. You can abuse pretty much every aspect of a general purpose programming language.
Amen to that!
"With sufficient thrust, pigs fly just fine."
Ross Callon, The Twelve Networking Truths, RFC1925
-
Yes, you can abuse lambda's and make a mess. You can abuse goto and make a mess. You can abuse boolean variables to simulate some forms of goto and make just as big a mess. You can abuse operator overloading and make a mess, and when James Gosling says you can't have operator overloading in Java, you can make just as big a mess with method overloading and virtual methods if you set your mind to it. You can abuse switch in atrocious ways in C and C++ (case goes pretty much anywhere, it doesn't even look like valid syntax but it is), which is like a goto where you don't even know for sure where it will go. You can abuse pretty much every aspect of a general purpose programming language.
Yes, I agree. Every element of a language has it's use - even
gotoandvarin C#- it's just that if you use them inappropriately you get less readable code instead of more. Personally, I find lambdas are useful in their place, but I avoid using them most of the time.varshould be banned outside Linq!Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
-
KISS
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
God gave rock and roll to you. Rock and roll to you. Put it in the soul of everyone.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier
-
After coming down off of the "That's pretty cool" factor and as members on my team have increasingly been using anonymous methods, lambda expressions and new Func<> routines embedded in methods. The complexity (IMO) as increased significantly. I've begun to question this seemingly popular approach as; What's the difference between using embedded functions and a goto statement? It seems to me it's no different and just as difficult to follow and maintain. I'd be curious on other opinions of this practice.
-
After coming down off of the "That's pretty cool" factor and as members on my team have increasingly been using anonymous methods, lambda expressions and new Func<> routines embedded in methods. The complexity (IMO) as increased significantly. I've begun to question this seemingly popular approach as; What's the difference between using embedded functions and a goto statement? It seems to me it's no different and just as difficult to follow and maintain. I'd be curious on other opinions of this practice.
sisnaz wrote:
What's the difference between using embedded functions and a goto statement?
:~ How are they similar? One is a flow control statement and another is a scope for a function. Or am I missing something?
-
God gave rock and roll to you. Rock and roll to you. Put it in the soul of everyone.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier
Me and the boys will be playing all night.
-
After coming down off of the "That's pretty cool" factor and as members on my team have increasingly been using anonymous methods, lambda expressions and new Func<> routines embedded in methods. The complexity (IMO) as increased significantly. I've begun to question this seemingly popular approach as; What's the difference between using embedded functions and a goto statement? It seems to me it's no different and just as difficult to follow and maintain. I'd be curious on other opinions of this practice.
sisnaz wrote:
What's the difference between using embedded functions and a goto statement? It seems to me it's no different and just as difficult to follow and maintain. I'd be curious on other opinions of this practice.
:doh: A GoTo breaks the flow where as a embedded function becomes part of the flow. Here is some psuedo code to show you the difference
bool flag = GetFlag() //Embedded but the point is made elsewhere
if flag
GOTO: SomeLabelEmbeddedMethod();
SomeOtherEmbeddedMethod();
OK, so this code will ONLY run the
EmbeddedMethodif theflagis false. One would think in that case it will also run theSomeOtherEmbeddedMethodand here is lies the evil of GoTo. What if theEmbeddedMehtodis defined in the same manner using a GoTo? i.e.bool flag = GetSomeOtherFlag()
if flag
GoTo: SomeOtherLabelNow as a user when I am looking at the first code snippet I have to account for that extra GoTo that could happen. Maybe I must run some logic if the
EmbeddedMethodruns. How do I ensure it in the most simple manner? Solution, Dont't use GoTo!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.
-
Yes, I agree. Every element of a language has it's use - even
gotoandvarin C#- it's just that if you use them inappropriately you get less readable code instead of more. Personally, I find lambdas are useful in their place, but I avoid using them most of the time.varshould be banned outside Linq!Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
Hear hear!
-
Yes, you can abuse lambda's and make a mess. You can abuse goto and make a mess. You can abuse boolean variables to simulate some forms of goto and make just as big a mess. You can abuse operator overloading and make a mess, and when James Gosling says you can't have operator overloading in Java, you can make just as big a mess with method overloading and virtual methods if you set your mind to it. You can abuse switch in atrocious ways in C and C++ (case goes pretty much anywhere, it doesn't even look like valid syntax but it is), which is like a goto where you don't even know for sure where it will go. You can abuse pretty much every aspect of a general purpose programming language.
-
After coming down off of the "That's pretty cool" factor and as members on my team have increasingly been using anonymous methods, lambda expressions and new Func<> routines embedded in methods. The complexity (IMO) as increased significantly. I've begun to question this seemingly popular approach as; What's the difference between using embedded functions and a goto statement? It seems to me it's no different and just as difficult to follow and maintain. I'd be curious on other opinions of this practice.
-
Yes, I agree. Every element of a language has it's use - even
gotoandvarin C#- it's just that if you use them inappropriately you get less readable code instead of more. Personally, I find lambdas are useful in their place, but I avoid using them most of the time.varshould be banned outside Linq!Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
-
After coming down off of the "That's pretty cool" factor and as members on my team have increasingly been using anonymous methods, lambda expressions and new Func<> routines embedded in methods. The complexity (IMO) as increased significantly. I've begun to question this seemingly popular approach as; What's the difference between using embedded functions and a goto statement? It seems to me it's no different and just as difficult to follow and maintain. I'd be curious on other opinions of this practice.
I don't know if the complexity increases significantly, but people well versed in imperative languages, like the majority of C#, may not be familiar with functional programming constructs, making it a little tougher to figure out just from lack of exposure. And they are harder to debug, can't seem to put breakpoints inside of them. But I probably abuse them a little, some sections of my code look more like LISP than a C-family language...especially when I realized I could use them to make wrappers out of certain loops and similar constructs that were being used over and over again in my code...
-
After coming down off of the "That's pretty cool" factor and as members on my team have increasingly been using anonymous methods, lambda expressions and new Func<> routines embedded in methods. The complexity (IMO) as increased significantly. I've begun to question this seemingly popular approach as; What's the difference between using embedded functions and a goto statement? It seems to me it's no different and just as difficult to follow and maintain. I'd be curious on other opinions of this practice.
sisnaz wrote:
What's the difference between using embedded functions and a goto statement?
Because one is cool and the other isn't. It is of course related to the difference between understanding the syntax of a language and being able to write syntax that is maintainable.
-
Yes, you can abuse lambda's and make a mess. You can abuse goto and make a mess. You can abuse boolean variables to simulate some forms of goto and make just as big a mess. You can abuse operator overloading and make a mess, and when James Gosling says you can't have operator overloading in Java, you can make just as big a mess with method overloading and virtual methods if you set your mind to it. You can abuse switch in atrocious ways in C and C++ (case goes pretty much anywhere, it doesn't even look like valid syntax but it is), which is like a goto where you don't even know for sure where it will go. You can abuse pretty much every aspect of a general purpose programming language.
harold aptroot wrote:
You can abuse switch in atrocious ways in C and C++ (case goes pretty much anywhere, it doesn't even look like valid syntax but it is)
Are you saying that you can have a case statement without an enclosing switch? :wtf: What does THAT look like, and what would one use it for?
-
Yes, I agree. Every element of a language has it's use - even
gotoandvarin C#- it's just that if you use them inappropriately you get less readable code instead of more. Personally, I find lambdas are useful in their place, but I avoid using them most of the time.varshould be banned outside Linq!Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
-
sisnaz wrote:
What's the difference between using embedded functions and a goto statement? It seems to me it's no different and just as difficult to follow and maintain. I'd be curious on other opinions of this practice.
:doh: A GoTo breaks the flow where as a embedded function becomes part of the flow. Here is some psuedo code to show you the difference
bool flag = GetFlag() //Embedded but the point is made elsewhere
if flag
GOTO: SomeLabelEmbeddedMethod();
SomeOtherEmbeddedMethod();
OK, so this code will ONLY run the
EmbeddedMethodif theflagis false. One would think in that case it will also run theSomeOtherEmbeddedMethodand here is lies the evil of GoTo. What if theEmbeddedMehtodis defined in the same manner using a GoTo? i.e.bool flag = GetSomeOtherFlag()
if flag
GoTo: SomeOtherLabelNow as a user when I am looking at the first code snippet I have to account for that extra GoTo that could happen. Maybe I must run some logic if the
EmbeddedMethodruns. How do I ensure it in the most simple manner? Solution, Dont't use GoTo!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.
Perhaps embedded method is a loose term. This is what I'm referring to. In my opinion it reflects the same goto example you posted.
public string ReturnSomething()
{
// ... some logic
// ...
var compare = new Func<string, string, string, string, bool>((compare1, compare2, compare3, compare4) =>
{
return (compare1.Equals(compare2, StringComparison.InvariantCultureIgnoreCase) &&
compare3.Equals(compare4, StringComparison.InvariantCultureIgnoreCase));
});// some more logic flow // .... if (compare("a", "b", "c", "d")) { // some logic } return "Something"; }
