What can be learned from studying long gone development practices? (shape-of-code.coding-guidelines.com)

That is the gist of one of the essays in The Mythical Man Month mentioned in the parent.

Does not invalidate your actual point, though.

In 1960, it was the only way to do "if" in the most popular programming language that existed at the time. Today, I bet that most programmers haven't even heard of it.

What's the difference between :(label) / :s(label) / :f(label) / :s(label1)f(label2) ?

Bullshit. There's so much that objectively deficient about that piece of code that I'm having trouble taking you seriously. If that comes at all close to being a representative sample of someone trying to make clear, readable code in that language, then the language was clearly deliberately designed to have an excess of visual noise. But I suspect you're not actually trying to make that code look as clean as the language allows.

The semicolons serve no apparent purpose. Having labels like x01 and x01a with no functional relationship between those lines is outright hostile to the reader. Using x as the prefix for almost all of your label names and as one of your variables is mildly confusing, especially when most of those lines don't relate to the variable x and don't appear to need labels at all. "output" seems to be a magic variable for which assignment has side effects, but nothing in the syntax differentiates it from any other variable. Grouping all the conditionals together, then grouping all their consequences together forces the reader to jump back and forth between lines more than if you put the consequence of each conditional immediately after the corresponding test (in this instance, your way does have the advantage of making the conditional fall-through pattern more readily apparent, but on the other hand that wouldn't be as necessary if you could use more than one line of code to write a single line of output).

You can claim all you want that aesthetics is subjective, but at the very least you must recognize that visual noise you've trained yourself to ignore is objectively different from code which doesn't have those distractions in the first place.

The goto's you've used here are within the set of allowable uses, so can be mapped directly onto structured constructs. There's literally no advantage either way, other than introducing the possibility to the reader that there could be something weird going on in your code.

> Would love to see a faster version in some popular, "structured" scripting language in the same number of characters.

How's this?

    #include <stdio.h>

    void main(){
      for(int a=1; a<100; a++){
        int y = a % 3;
        int z = a % 5;
        int x = y + z;
        if(!x) puts("fizz");
        else if(!y) puts("buzz");
        else if(!z) puts("fizzbuzz");
        else printf("%d\n",a);
      }
    }

If C doesn't meet the "scripting language" constraint (which I find arbitrary, but not insurmountable), I'd throw Julia or FORTH at it and probably shave a considerable number of bytes off.

There's an enormous amount of accidental/inessential complexity in the code you provided, and that's a big part of the reason no-one seriously uses SNOBOL or similarly primitive languages for anything serious today. Code like the above can't remotely scale to larger programs, and attempts to do so were notorious for their failure.

Here's a version of FizzBuzz in e.g. Haskell:

    fizz n | n `mod` 15 == 0  = "FizzBuzz"
           | n `mod` 3  == 0  = "Fizz"
           | n `mod` 5  == 0  = "Buzz"
           | otherwise        = show n
 
    mapM_ putStrLn $ map fizz [1..100]

Even versions with more explicit control flow (i.e. without map) can be similarly readable, but if your goal is to minimize complex control flow, then rather than reverting to intractable gotos, go read "Lambda: The Ultimate GOTO" (http://dspace.mit.edu/handle/1721.1/5753), published in 1977, and learn to use functions for control flow.

In languages like Java that want to hide everything memory related I also was struggling with grasping what a function really is. Is it even allowed to return a function?

Languages that hide memory locations and direct memory access are one of the reasons that some programmers are struggling with functions returning functions.

In the 90s it took a (very friendly) FOIA request, a $5 processing fee, and three weeks to get my hands on that handbook.

This is because most modern languages allow you to write in structural style which is impossible to get wrong without noticing. If you have a loop, you know it repeats for its condition, and does not otherwise. If you have a `then` clause, you know it will only run when the `if` condition is true. If you have a function, you know it's only computed when called.

Compare it to pre-structural languages like Fortran IV or Basic, where you can freely jump into the middle of the loop, inside of what constitutes an undelimited `then` clause, or even into the middle of a function, without "calling" it properly.

This allows for potentially very clever code that saves every last byte and cycle. It also allows for totally mind-boggling, insidious bugs in code we'd now consider plain and foolproof to write.

“TeX was the first faily large program I had written since 1970; so it was my first nontrivial ‘structured program,’ in the sense that I wrote it while consciously applying the methodology I had learned in the early 70s from Dijkstra, Hoare, Dahl, and others. I foudn that structural programming greatly increased my confidence in the correctness of the code, while the code still existed only on paper. Therefore I could wait until the whole program was written, before trying to debug any of it. This saved lots of time, because I din't have to prepare ‘dummy’ versions of nonexistent modules while testing modules that were already written; I could test everything in its final environment.”

That said, there are still 337 instances of goto in tex.web by my quick and dirty count (grep goto tex.web | grep -v '@' | wc -l), which is perhaps an undercount since there are modules that might be included multiple times thanks to how the WEB system builds its Pascal output and I don't have a Pascal reformatter to make analyzing tex.p manageable.¹

1. The choice to "compress" the Pascal output of tangle is one of the most inexplicable choices made in the development of the TeX ecosystem.

The structured program theorem is also about specific control structures, essentially proving that they are Turing complete by themselves. I remember that we had to prove in university that as a result, you can transform any program into a program with one big while loop. (I think that's equivalent to "μ-recursion", whereas the simpler "LOOP" statement only implements "primitive recursion" which is not Turing complete, but it's been a while.)

What you talk about sounds like it could be "modular programming", of which Wikipedia states: "Modular programming per se, with a goal of modularity, developed in the late 1960s and 1970s, as a larger-scale analog of the concept of structured programming (1960s)."

Of course, Wikipedia is not a good source, I wasn't there when it started, and it's entirely possible that structured programming meant more back then than it seems to mean today, or meant different things in different circles. A quick Google search seems to confirm that nowadays structured programming primarily seems to be the use of control structures, though maybe that's just what survived?

I don't think that follows at all. Unix shell programming is very much a bottom-up philosophy where you write a bunch of generic tools and then string them together to solve your actual problem at the last minute.

It’s the exact opposite. Unix was if not a reaction at least and antithesis: top-down programming is BDUF, you first decide what the entire thing does, then you go down a level and define / implement what’s supposed to be there.

Unix is about starting from small utilities at the bottom and jury-rigging them until you get something you like.

Setting goals and delegating responsibility is how things are supposed to be led.

Substituting that with project management is a pathology.

Do you really think branch prediction has significantly reduced the difficulties in developing software, or altered the way software developers work? Bringing up things that have changed behind a compatibility layer that makes us program against an emulated PDP-11 sounds to me like support of my thesis, if anything: the only changes to the way we work are faster computers and higher level languages.