Yes, exactly, that what I was trying to say.
Still the fact remains that there are times when goto is a good idea, can be used in a pretty well ordered manner and may make something possible that is otherwise impossible.
I point to my full duplex serial driver in C as a potential example. I don't think it is possible to get that speed with C without the goto's. They have also been introduced in a very structured fashion.
Yes, exactly, that what I was trying to say.
Still the fact remains that there are times when goto is a good idea, can be used in a pretty well ordered manner and may make something possible that is otherwise impossible.
I point to my full duplex serial driver in C as a potential example. I don't thing it is possible to get that speed with C without the goto's. They have also been introduced in a very structured fashion.
C, Assembler and similar lower level languages depend on branching (which makes them more complicated to design and debug) but Basic, SPIN (does not support GOTO), (and good ol' COBOL) suffer from unstructured branching.
I don't know that try/catch exception handling and error classes being included and passes and so-on was always really making things *more* understandable. At times it certainly seemed to add far more complication to handling some illegal condition that a GOTO could force a re-do on fairly easily. Then again I remember reading the GOTO-ridden programs of early BASIC and can easily understand where the bad taste came from. I agree though, there are times when you see some if-then-else nested messes that rival those of GOTO spaghetti code being used to try to avoid what a GOTO could have easily handled. I'm not a fan of 'enlightened' people who like to not only suggest it should be thus but also want to dictate that it must be thus.
... I'm not a fan of 'enlightened' people who like to not only suggest it should be thus but also want to dictate that it must be thus.
If you work for a company that has programming standards, it is dictated and you follow the standards or hit the road.
When I read a job applicant's resume` or interviewed him/her, I attempted to discern their understanding and attitude toward structured programming.
If it was insufficient, I would not consider them. My team and I had cleaned up enough spaghetti code problems to know the hazards...
I don't work for one and I'm answering as an individual who programs in a hobby. There is nothing to keep your company from enforcing standards of whatever practice you see fit and whatever subset of elements and statements you choose. I don't personally appreciate having options taken off the table at the language level because the commitee sees no need. Invariably what one sees as irrelevant and useless someone else may find indespensible. Then again, what I do or don't appreciate has no bearing on much so I just use what's at hand and suits my mood.
I don't work for one and I'm answering as an individual who programs in a hobby.
... Then again, what I do or don't appreciate has no bearing on much so I just use what's at hand and suits my mood.
Programming as a hobby is certainly much more fun.
I got out of the rat race almost 10 years ago.
I don't miss the office politics and back stabbing one bit.
All these negative GOTO vibes inspire my contrary nature to write a program consisting mainly of GOTO statements that does something useless, but cool.
Sometimes nothing (but GOTOs) can be a real cool hand, Luke.
As for the hobby vs. company discussion - when I do my (sometimes substantial) hobby programming I follow the same company standards as I do while programming for the company. To an even higher degree than what's seen generally in the company code I would say. Because it pays off. My code is much more enjoyable to re-visit and improve and extend, years after I wrote it, exactly because I use those standards. There's no reason to think differently just because it's a hobby.
I think a lot of it has to do with hobbyists who get hacked off that some of their coding practices are looked down up by those in work(ed) professionally and academics. Hence their animus towards those who don't use GOTO's.
It wouldn't surprise me to see a thread dealing with the evils of strong type and array bounds checking showing up soon.
Comments
Yes, exactly, that what I was trying to say.
Still the fact remains that there are times when goto is a good idea, can be used in a pretty well ordered manner and may make something possible that is otherwise impossible.
I point to my full duplex serial driver in C as a potential example. I don't think it is possible to get that speed with C without the goto's. They have also been introduced in a very structured fashion.
C, Assembler and similar lower level languages depend on branching (which makes them more complicated to design and debug) but Basic, SPIN (does not support GOTO), (and good ol' COBOL) suffer from unstructured branching.
If you work for a company that has programming standards, it is dictated and you follow the standards or hit the road.
When I read a job applicant's resume` or interviewed him/her, I attempted to discern their understanding and attitude toward structured programming.
If it was insufficient, I would not consider them. My team and I had cleaned up enough spaghetti code problems to know the hazards...
Programming as a hobby is certainly much more fun.
I got out of the rat race almost 10 years ago.
I don't miss the office politics and back stabbing one bit.
Just poking that hornet's nest.
OK, kicking it.
They appear to have intermittent problems with RETURNs.
I resisted commenting on jetman's loop - could've been a disaster if it was a GOTO
Sometimes nothing (but GOTOs) can be a real cool hand, Luke.
http://www.youtube.com/watch?v=TftZYLkJcyU
-Tor
I think a lot of it has to do with hobbyists who get hacked off that some of their coding practices are looked down up by those in work(ed) professionally and academics. Hence their animus towards those who don't use GOTO's.
It wouldn't surprise me to see a thread dealing with the evils of strong type and array bounds checking showing up soon.
In this case, to GOTO would be the choice.