Imagine teaching someone BASIC or FORTRAN...
IF (IA .GT. 0 .AND. IB .GT. 0 .AND. IC .GT. 0) GOTO 10
WRITE (6, 602)
602 FORMAT (42H IA, IB, AND IC MUST BE GREATER THAN ZERO.)
STOP 1
10 CONTINUE
Or for something more complicated... https://github.com/ArthurFerreira2/STARTREK/blob/master/star... ... and arguably, that's well structured (its not doing a GOTO into the middle of a subroutine... I think). Tangent to that source code https://meatfighter.com/startrek1971/ for a port to C# (with line numbered goto).Dijkstra's approach to programming help take software development from a craft where each woodworker did things their own way and going from one shop to another meant relearning everything to something were one could more easily reason about how an application worked by removing some of the ability to write unstructured code. You can still write it... and I'm sure you can find some code that is convoluted ("... the determined Real Programmer can write FORTRAN programs in any language." https://www.ee.torontomu.ca/~elf/hack/real-programmers.html ).
Structured programming is also easier to teach. Yes, you can teach people how to write line numbered BASIC but the challenge is also teaching them discipline to not cut off their fingers when doing it. The structured programming approach it becomes easier to enforce that discipline as part of teaching ... and if they go and do dangerous things after they graduate from college, that's up to them.
Several years later, there was a series of articles as a reaction to the misguided extreme interpretation of the title put by an editor to the article written by Dijkstra, i.e. the interpretation that GOTO should be avoided completely. Such articles were written by people like Zahn and Knuth and they demonstrated that while unrestricted GOTO is dangerous and unnecessary and it should not be allowed, a restricted form of GOTO (i.e. jumping only forwards and without entering nested blocks) is absolutely necessary if maximally efficient program structures must be implemented. Those conclusions from the early seventies have become even more relevant today, because when essential GOTOs are removed from a program structure, that is possible only by adding extra Boolean variables and extra conditional branches (i.e. "if" or "while" statements), which can be mispredicted, so their cost is many times higher in modern computers than it was in the computers from a half of century ago.
The language Xerox Mesa was designed according to the conclusions of those articles, so it included a restricted GOTO. Unfortunately, being a proprietary language of Xerox, Mesa has not seen widespread use, even if it was superior to most of the languages designed later than it.
Far more important contributions of Dijkstra are that in 1960 he taught everybody how to implement recursive functions and procedures and also how to allocate the parameters and local variables of the ALGOL 60 blocks, using stacks, stack pointers and stack frames, and then in the following years he taught everybody how to implement mutual exclusion when concurrent processes access shared resources.
In computing science it is hard to say with certainty who invented first some technique, because many of the early uses of some programming techniques have never been published.
Nonetheless, if someone had discovered earlier some programming trick and they kept it to themselves, that does not really count, what matters is only who published first the technique, teaching everybody how to use it.
Dijkstra is certainly the one who popularized during the sixties and early seventies many of the programming techniques that are now among the most fundamental and which are now implemented in any operating system, in any compiler and in any executable program.
Other examples of people with similarly important contributions to programming are John McCarthy and C.A.R. Hoare. As a coincidence (or not), all 3 were supporters of allowing the procedures and functions of ALGOL 60 to be recursive, as there was a camp who wanted to prohibit recursion, fearing that allowing recursion may lead to complex and inefficient compilers and executable programs.
Dijkstra's Rallying Cry for Generalization: the Advent of the Recursive Procedure, late 1950s - early 1960s - https://www.dijkstrascry.com/node/4
This paper describes some early contributions of E.W. Dijkstra by elaborating on his involvement in putting forward and implementing the recursive procedure as an ALGOL60 language construct. Particular attention is paid to Dijkstra's generalizing style of solving problems.
Two messages lie at the heart of this paper: (i) the early history of programming languages, and the ALGOL60 effort in particular, can be perceived as a dichotomy between specialization and generalization, and (ii) Dijkstra's continual appeal for generalization led to practical breakthroughs in compiler technology. Specialization, as promoted by Bauer, Samelson, Strachey, and Wilkes, refers to language restrictions, static solutions, and the exploitation of machine-specific facilities --in the interest of efficiency. Generalization, as promoted by Van Wijngaarden and Dijkstra, refers to general language constructs, dynamic solutions, and machine-independent language design --in the interest of correctness and reliability.
Read David Tribble's Go To Statement Considered Harmful: A Retrospective which annotates the original paper with historical details for better understanding - http://david.tribble.com/text/goto.html
This is a discussion and analysis of the letter sent to Communications of the Association for Computing Machinery (CACM) in 1968 by Edsger W. Dijkstra, in which he calls for abolishing the goto statement in programming languages.
The letter has become quite famous (or infamous, depending on your feelings about goto statements) in the 40 years since it was first published, and is probably the most often cited document about any topic of programming. It is also probably the least read document in all of programming lore.
Most programmers have heard the adage "Never use goto statements", but few of today's computer science students have the benefit of the historical context in which Dijkstra made his declaration against them. Modern programming dogma has embraced the myth that the goto statement is evil, but it is enlightening to read the original tract and realize that this dogmatic belief entirely misses the point.
This paper was written at a time when the accepted way of programming was to code iterative loops, if-thens, and other control structures by hand using goto statements. Most programming languages of the time did not support the basic control flow statements that we take for granted today, or only provided very limited forms of them. Dijkstra did not mean that all uses of goto were bad, but rather that superior control structures should exist that, when used properly, would eliminate most of the uses of goto popular at the time. Dijkstra still allowed for the use of goto for more complicated programming control structures.
The original ACM paper was titled A Case against the GO TO Statement (EWD215: https://www.cs.utexas.edu/~EWD/transcriptions/EWD02xx/EWD215...) but this original title was changed by CACM editor Niklaus Wirth to Goto Statement Considered Harmful which then became a meme (https://en.wikipedia.org/wiki/Considered_harmful).