"Bahnhof verstehen" 😉

No I wasn't!

Yes he was!

I’m going to give it a shot!

for #inktober with their prompt list?

I can't wait to listen to the episode, but since I didn't notice a link to the most important rebuttal to this paper in the show notes, Ima just leave this here.

Structured Programming with go to Statements DONALD E. KNUTH pic.plover.com/knuth-GOTO.pdf

I don't know if you touch on tail calls in the episode, but I didn't see anything about it in the show notes, so I'll also leave this:

dspace.mit.edu/handle/1721.1/5790

dspace.mit.edu/handle/1721.1/6091

Also, Peter Naur had some good things to say on this subject as well, some of it predating Dijkstra. See Go To Statements and Good ALGOL Style (1963), Proof of Algorithms by General Snapshots (1966), and Programming by Action Clusters (1969).

And there is, of course, the most elegant way of avoiding goto's, by using COME FROM.

web.archive.org/web/20180716171336/http://www.fortran.com/fortran/come_from.html

en.m.wikipedia.org/wiki/COMEFROM

Every time someone re-listens to our INTERCAL episode because the nonsense is so good, they're implicitly following a COME FROM.

And every time someone bails on our Considered Harmful episode because the nonsense is just too much, they're implicitly following a GOTO.

There's just no denying the power of podcasts.

The editor who changed the name was Nicklaus Wirth, the inventor of Pascal, and one of the other great historical proponents of structured programming.

There were absolutely intermediate representations by 1968. For example, see:

The Design of the Gier ALGOL Compiler by Peter Naur (1963)

ALGOL 60 Implementation by B. Randell and L. J. Russell (1964)

I'm pretty sure there are older examples, but I don't have access to my library right now so I am limited to my memory and the pale shadow of truth that can be found online.

Personally, I never really liked the whole concept of "where we are in the program" that he builds up in this paper. I think his discussion of how to reason clearly about the different structured statement types in Notes on Structured Programming

(cs.utexas.edu/users/EWD/ewd02xx/EWD249.PDF) is both easier to understand and far more useful from a practical perspective.

In Perl, goto will search the call stack for a matching label, like with exceptions. In Algol 60 and Pascal, since you are able to nest procedures within other procedures, you can use goto to jump to an error handler in a high level procedure regardless of how many intermediate procedure calls you are jumping out of.

Jimmy's argument against dependency injection, based on the fact that you don't know what code you are calling or what it will do, reminds me of the argument in Polymorphism considered harmful (dl.acm.org/doi/pdf/10.1145/181628.181635), and to some extent is also an argument against late binding, closures, function pointers, execution tokens, and ultimately object-oriented programming and functional programming as paradigms. [Later note: Ha ha! Jimmy claims OO considered harmful later in the episode! I disagree, but I respect your consistency! 😂 Oh wait, you like functional programming? 🤔]

wiki.c2.com/?ClosuresAndObjectsAreEquivalent

For the advantages of hiding implementation details within modules, and not making everything public, I believe Parnas provided an excellent argument.

dl.acm.org/doi/10.1145/361598.361623

Your arguments against black boxes sound a lot like arguments against abstraction and even potentially code reuse in general. You might enjoy some of Charles Moore's early writings about Forth. One of his goals was to reduce the number of levels of abstraction and allow the programmer to work in a convenient environment while still having easy access to the lower level reality.

Unfortunately, I think many modern programmers do not grasp the level of chaos that used to exist in many Fortran and Basic programs, and so they don't really understand the type of madness that Dijkstra was trying to reduce in the world. They assume that any goto is terrible and confusing, while sometimes a single goto in the right place can eliminate several flags and pieces of convoluted loop logic, making a piece of code much easier to understand.

There are empirical studies showing that for certain types of problems, more students can write correct solutions if they are allowed to use break statements, which are a type of goto that Dijkstra did not approve of.

dl.acm.org/doi/10.1145/182.358436

doi.acm.org/10.1145/199691.199815

I don't think Hopkins made as good of an argument as Knuth, but his paper still deserves a place in the cannon.

doi.acm.org/10.1145/800194.805860

Furthermore, in the Knuth paper that I linked above, he actually gives an example that Dijkstra admitted was a good use of a goto.

My favorite quote about goto comes from the original wiki at wiki.c2.com/?GoTo

"The apprentice uses it without thinking. The journeyman avoids it without thinking. The master uses it thoughtfully."

After two years in the public sector, I have zero evidence against the argument that "rules are scar tissue." A very insightful take. Do you have a source for that or can I attribute it to you, Ivan Reese?

@Personal Dynamic Media the wealth of references you bring is always a treat. The considerable length of my reading list continues to increase, harmfully.

Jason Morris pretty sure "bureaucracy is institutional scar tissue" is something I read somewhere, probably a tweet, but I have no specific recollection. Regardless, feel free to point people at our podcast :)

Ivan Reese when i’ve listen to both the song you released and the interlude in this podcast it brings me back to the Avalanches.

(p.s. TIL the genre they pioneered is called Plunderphonics, which is such a fun name for a genre!)

Christopher Shank That's high praise — thank you! John Oswald (among other early electronic era Canadian experimental music heroes), Ergo Phizmiz, Avalanches, DJ Shadow, the early Danger Mouse mashups, Girl Talk, and countless others were on heavy rotation in the music scene where I spent my 20s. One of my closest friends pushed us all to take up Plunderphonics as one of our main genres, but I gravitated hard in the other direction. All the music I make is 99.9% actual recordings of me playing real instruments (with a virtual synthesizer once in a blue moon). Still, I appreciate the aesthetic viewpoint, and it sure beats the usual "hey this sounds like Radiohead" :)

Incidentally, the Peter Naur papers that I reference above are reprinted in his amazing book Computing: A Human Activity, along with countless other wonderful and amazing papers, many of which I have referenced here before.

This is one of my favorite books in the whole world.

This is a very difficult book to find, but you can search for a copy on pretty much all of the used book sites here:

vialibri.net/searches?author=Naur&title=computing+a+human+activity

Many of the papers that are most relevant to the goto controversy are included in the excellent compendium Classics in Software Engineering edited by Ed Yourdon.

This is a much easier book to find.

vialibri.net/searches?author=Yourdon&title=Classics+in+software+engineering

Ivan Reese you’ll have to add “Samples considered harmful” to your list :grinning_face_with_one_large_and_one_small_eye:

Christopher Shank samples "considered harmful": mastodon.social/@spiralganglion/111163714377501441

great episode! glad I showed up before the 16 minute mark this time

Tailwind discourse considered harmful.

Programmer bums considered harmful.

Efficiency considered harmful.

Definitions considered harmful.

Lu Wilson Fantastic links.

@Personal Dynamic Media

I haven't read the Knuth or those Naur papers. Thanks for the references! I'll definitely check those out. Also happy to have polymorphism considered harmful so I can point people to something that isn't just me saying it :)

Charles Moore's early writings about Forth could be interesting to you.

I definitely want to do some forth as some point. Everything I know is just a bit long, any recommendations?

"We should do ... our utmost ... to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible." The rest of the paper amounts to a dated example, well, unless your program happens to run a step-by-step process.

I'll bite. Doesn't most programming in the small consist of a step-by-step process? Is there some more specific meaning I'm missing?

Sure. When small enough that the process doesn't get interrupted and large (or awkward) enough that no single expression won't do. Whether the semantics of the program are imperative or not, you'll want to name intermediate results. It shouldn't be too hard to find an example of pure functional "step-by-step" programming... Here hackage.haskell.org/package/base-4.18.1.0/docs/src/GHC.IO.Exception.html#untangle:

{-

(untangle coded message) expects "coded" to be of the form

        "location|details"

It prints

        location message details

-}

untangle :: Addr# -> String -> String

untangle coded message

  =  location

  ++ ": "

  ++ message

  ++ details

  ++ "\n"

  where

    coded_str = unpackCStringUtf8# coded



    (location, details)

      = case (span not_bar coded_str) of { (loc, rest) ->

        case rest of

          ('|':det) -> (loc, ' ' : det)

          _         -> (loc, "")

        }

    not_bar c = c /= '|'

Consider that order of expressions in the where clause doesn't matter, but even then the awkward nested case expressions might benefit from even more intermediate steps:

   (location, rest) = span not_bar coded_str

   details | null rest = ""

           | otherwise = ' ':(tail rest)

And maybe text is to blame for some awkwardness here. Is jamming message between location and details intrinsically non-linear?

Jimmy Miller

The original paper by Charles Moore, FORTH – A Language for Interactive Computing, begins with a long complaint about the hierarchy of languages and abstractions between the programmer and the computer. The paper itself is a historical document that does not describe the way modern, or even old school Forth systems were implemented, but it is a fun read.

1strecon.org/downloads/Forth_Resources/CM_ForthLanguageInteractiveComputing_1970.pdf

Starting Forth is an excellent introduction to old school Forth.

forth.com/starting-forth

Thinking Forth is an amazing software engineering book filled with interviews and philosophy that would be a widely studied classic if it were not written through the lens of a less popular language. Within its pages one can find foreshadowing of Extreme Programming and Agile Programming.

thinking-forth.sourceforge.net

Threaded Interpretive Languages: Their Design and Implementation by R. G. Loeliger is the classic guide to implementing Forth on a Z80.

archive.org/details/R.G.LoeligerThreadedInterpretiveLanguagesTheirDesignAndImplementationByteBooks1981

Jonesforth is an x86 assembly language Forth implementation that is written as a tutorial with extensive comments. Or is it a Forth implementation tutorial that includes executable x86 assembly language code?

rwmj.wordpress.com/2010/08/07/jonesforth-git-repository

This Byte Magazine article has an excellent discussion of how threaded code works (no relation to multi-threaded parallelism or concurrency).

archive.org/details/byte-magazine-1980-09/page/n207/mode/1up

As you learn Forth, pay special attention to the concepts of immediate words, defining words, and compiling words. That is where you will find a level of magic roughly equivalent to that of Lisp macros, but implemented and used in a completely different manner.

And of course, no discussion of Forth would be complete without some mention of Forth on the Atari. It's not a particularly good read, but it has one of the most amazing covers of any programming book.

Ivan Reese I guess that depends on how much heavy lifting the word "most" is doing there, but I'd say that some domain-specific languages like CSS and CellPond often don't involve step-by-step instructions (and try to actively avoid them).