We’re supposed to encourage students to use “proper” OOP in a C++ class I’m TAing and I think it may kill me. I really want to say “no don’t do that, do this instead”, but that would be a disservice to the students who need to pass their exams.
There is also the confounding fact that I haven’t actually done proper OOP in half a decade. Super rusty on that, and loathe to brush up on it.
(This is related because Java-style classes are 100% a damaging tool in my opinion)
As someone that tends to deal with the kernel and c often, how is goto damaging?
Doing contortions with if statements or break or whatever in functions is a worse option most often. It can be abused but this whole idea that goto is nothing but a bad thing strikes me more of bandwagoning.
Granted goto in c and kernel stuff tends to amount to: goto error_cleanup statements. That and generally the entire function is designed to be a succeed or fail affair, but that is the entire point of goto. Could you goto a completely separate function’s error handler? Well sure, but then flying monkeys would descend upon you and take you to the underworld once your coworkers find out.
But honestly, goto is a tool, yeah it can be abused and misused but we have things to help us, static analyzers, code review, valgrind etc….
I’ll keep this damaging tool thanks, for its purpose goto is a great option. Especially once you start looking at assembly that compilers generate, maybe only then will people disavow themselves that “structured programming” is the best choice. It may be, but without context that is a meaningless distinction.
It’s important to remember the climate Dijkstra was writing in. At the time, goto was still the way of structuring control flow. And while goto is quite powerful, it is also quite easy to get wrong. His point was that it is often better to more directly encode what you mean via something like if, else, or while rather than use the unnecessarily powerful tool goto. (Basically, I’m saying I agree with you, and people should read Dijkstra’s original essay. Also, Dijkstra didn’t pick the original title, and honestly didn’t care for it).
Yes GOTO is harmful, but guns are harmful, and all but the nuttiest of anti-gun-nuts would agree the SWAT team should have a few.
But another factor is that GOTO in kernel code tends to be mainly about circumventing the limits of C. Some higher-level constructs might make most of those usages go away, without necessarily making things slower. Think of golang’s defer for example.
Go famously leaves a lot of stuff out–beyond the couple of omissions that people talk about a lot, there are also, for instance, no circular imports or implicit conversions of typed numeric values.
What are some technologies you’ve found that you’re better off not using?
I like the spirit of the question, but not the wording. The case of goto wasn’t so much that it was banished, but moreso that its use was greatly curtailed. (And no, the point here isn’t to get into the pros/cons of goto. Please don’t.) More importantly, the “taking away” of goto was more about noting that its use was mostly inappropriate for the task at hand. I found the wording of the question and the post to be more along the lines of “what should we banish” instead of “what should we avoid”.
That said, I’d say explicit managing of state is one thing. I’m starting to think that threading and callbacks are a couple more.
I also consider a debugger to be a crutch that you should tuck away and only drag out when absolutely necessary, but apparently that’s an unpopular view among those I have voiced it to.
there are no “damaging tools”. there are only “tools” which are harmful depending on who uses them.
“goto” is a scapegoat for the big camp of programmers who don’t really know what the code they write does on the low level.
Unsurprisingly, this camp consists mostly of OOP-programmers and the functional camp, both unwilling to learn and understand and repeating the “no goto”-mantra indefinitely.
to make it short, there are no technical reasons to abolish goto. in many cases, it is the only way to solve cleanup situations elegantly and properly (e.g. LibreSSL changes).
ASCII-in-files as the canonical storage of, and API to, our source code.
Text is fine* as a user-interface to source code, but we’re throwing away and (poorly) recreating so much semantic information constantly when we treat source code as a flat stream of characters. It’s just nuts. Yes it allows piecemeal evolution of tools up to a point, but we’re missing out on so much possibility, and wasting a boatload of both hardware and meatware cycles because of it.
We’re supposed to encourage students to use “proper” OOP in a C++ class I’m TAing and I think it may kill me. I really want to say “no don’t do that, do this instead”, but that would be a disservice to the students who need to pass their exams.
There is also the confounding fact that I haven’t actually done proper OOP in half a decade. Super rusty on that, and loathe to brush up on it.
(This is related because Java-style classes are 100% a damaging tool in my opinion)
As someone that tends to deal with the kernel and c often, how is goto damaging?
Doing contortions with if statements or break or whatever in functions is a worse option most often. It can be abused but this whole idea that goto is nothing but a bad thing strikes me more of bandwagoning.
Granted goto in c and kernel stuff tends to amount to: goto error_cleanup statements. That and generally the entire function is designed to be a succeed or fail affair, but that is the entire point of goto. Could you goto a completely separate function’s error handler? Well sure, but then flying monkeys would descend upon you and take you to the underworld once your coworkers find out.
But honestly, goto is a tool, yeah it can be abused and misused but we have things to help us, static analyzers, code review, valgrind etc….
I’ll keep this damaging tool thanks, for its purpose goto is a great option. Especially once you start looking at assembly that compilers generate, maybe only then will people disavow themselves that “structured programming” is the best choice. It may be, but without context that is a meaningless distinction.
It’s important to remember the climate Dijkstra was writing in. At the time,
gotowas still the way of structuring control flow. And whilegotois quite powerful, it is also quite easy to get wrong. His point was that it is often better to more directly encode what you mean via something likeif,else, orwhilerather than use the unnecessarily powerful toolgoto. (Basically, I’m saying I agree with you, and people should read Dijkstra’s original essay. Also, Dijkstra didn’t pick the original title, and honestly didn’t care for it).Yes GOTO is harmful, but guns are harmful, and all but the nuttiest of anti-gun-nuts would agree the SWAT team should have a few.
But another factor is that GOTO in kernel code tends to be mainly about circumventing the limits of C. Some higher-level constructs might make most of those usages go away, without necessarily making things slower. Think of golang’s defer for example.
Removing part of an existing tool does yield a new and different tool. Its a straightforward application of S.C.A.M.P.E.R.
Similarly pure functional programming can be viewed as imperative programming with extra discipline to eliminate mutable state.
Useful-sounding things that are discouraged in some environments:
evalandargumentsin JavaScript: security and performance issues.Go famously leaves a lot of stuff out–beyond the couple of omissions that people talk about a lot, there are also, for instance, no circular imports or implicit conversions of typed numeric values.
I like the spirit of the question, but not the wording. The case of
gotowasn’t so much that it was banished, but moreso that its use was greatly curtailed. (And no, the point here isn’t to get into the pros/cons ofgoto. Please don’t.) More importantly, the “taking away” ofgotowas more about noting that its use was mostly inappropriate for the task at hand. I found the wording of the question and the post to be more along the lines of “what should we banish” instead of “what should we avoid”.That said, I’d say explicit managing of state is one thing. I’m starting to think that threading and callbacks are a couple more.
I also consider a debugger to be a crutch that you should tuck away and only drag out when absolutely necessary, but apparently that’s an unpopular view among those I have voiced it to.
there are no “damaging tools”. there are only “tools” which are harmful depending on who uses them. “goto” is a scapegoat for the big camp of programmers who don’t really know what the code they write does on the low level. Unsurprisingly, this camp consists mostly of OOP-programmers and the functional camp, both unwilling to learn and understand and repeating the “no goto”-mantra indefinitely.
to make it short, there are no technical reasons to abolish goto. in many cases, it is the only way to solve cleanup situations elegantly and properly (e.g. LibreSSL changes).
ASCII-in-files as the canonical storage of, and API to, our source code.
Text is fine* as a user-interface to source code, but we’re throwing away and (poorly) recreating so much semantic information constantly when we treat source code as a flat stream of characters. It’s just nuts. Yes it allows piecemeal evolution of tools up to a point, but we’re missing out on so much possibility, and wasting a boatload of both hardware and meatware cycles because of it.
*For now