3 ms·
> GOTOs and line numbers would turn you into a bad programmer for life Dijkstra will go down in history as one of the great algorithm designers, but this will
by phendrenad2 3y ago
> GOTOs and line numbers would turn you into a bad programmer for life
Dijkstra will go down in history as one of the great algorithm designers, but this will always be a black mark on his legacy, possibly overshading his contributions. There's a lesson here about not pontificating outside of your field.
- johannes1234321 3y agoIn his text he argued for higher level constructs, as they are established now. I think there he was right. Unrestricted goto often isn't good for complexer programs.
- skocznymroczny 3y agoMy understanding is that when "GOTO consider harmful" came out, the typical code flow was to put values into global variables, goto to some piece of code then goto back and continue. Nowadays we have functions with arguments and you should just use that. But harmful goto was about the specific type of coding that happened at the time, but people assume it's any goto use in general.
- Brian_K_White 3y agoAnd notably the famously provocative title did not come from him. You could say "he never even said that".
- Someone 3y agoDijkstra wrote that in 1968. At the time, quite a few languages didn’t support recursion (ten years later, FORTRAN 77 didn’t, officially), and lots of hardware didn’t have a call stack (a word that Dijkstra invented, and described in 1960. See https://ics.uci.edu/~jajones/INF102-S18/readings/07_dijkstra.pdf https://ics.uci.edu/~jajones/INF102-S18/readings/07_dijkstra...), so if they needed one, they’d have to write it in code. Using a language that supported structured programming would get rid of such scaffolding code that hid the logic of the actual program. Many languages also allowed code to jump out of and into loops, and programmers (ab)used that to cram their code into the small amounts of memory they had at their disposal. The resulting code could be quite hard to understand. > There's a lesson here about not pontificating outside of your field. How was that outside of his field, which was about thinking logically about programming?
- phendrenad2 3y ago'Goto considered harmful' really brings nothing new to the table. It just states that gotos are hard to reason about. Well yes, that's true. Computer programs are hard to reason about as a baseline. Everyone knew that goto was hard to reason about before he wrote about it, but for some reason his letter became a reference for people who wanted to abolish GOTO from their codebases. > How was that outside of his field, which was about thinking logically about programming? Language design falls under human-machine interfaces, and while basically everyone in that era dabbled in that field, it wasn't really his forte.
- zaphar 3y agoModern Goto's are nothing like what Djikstra was writing about. Reading it in the context of the time it was written it is a fairly good write up.
- phendrenad2 3y agoNever said that they were...
- deleted 3y ago[deleted]
- bigbillheck 3y ago> Dijkstra will go down in history as one of the great algorithm designers, but this will always be a black mark on his legacy, possibly overshading his contributions. There's a lesson here about not pontificating outside of your field I am begging of you, please do a little bit of investigation into the historical context in which Dijkstra wrote that memo.
- phendrenad2 3y agoYour comment was likely inspired by other replies to my comment, but please, don't assume someone who has an opinion other than yours simply hasn't done enough research to agree with you.
- bigbillheck 3y agoIn one 1971 dataset fully 13% of all executable statements were "GOTO": https://www.cs.tufts.edu/~nr/cs257/archive/don-knuth/empirical-fortran.pdf https://www.cs.tufts.edu/~nr/cs257/archive/don-knuth/empiric...
- phendrenad2 3y agoIn 1971 people really cared about binary density.
- bigbillheck 3y agoReading that paper it's hard to believe that the typical programmer cared all that much beyond getting something to work. Whatever you mean by "binary density", the subjects were programming for an IBM Model 67 which was a pretty hefty system for the time. The programs weren't all that big by modern standards either, with "number of executable statements" in the hundreds; when you have megabytes of memory it doesn't seem like spending a few extra bytes on instructions would be that big a deal. By and large the ancients couldn't have been all that concerned about optimizations. Take a look at their "Example 6" in which the authors were able to significantly improve an inner loop thru such advanced techniques as "use 0.0 instead of 0 if you want a REAL" and "don't make extra assignments".