What can be learned from studying long gone development practices?

I am a big fan of Jackson Structured Programming (the other JSP), from the 70s, and have used it many times. When it is the right a match for a given problem, the design and implementation will work first time, every time.

And that problem is where the input can be modelled as a stream of structured events.

This may sound too abstract, but it includes, for instance, pretty much any file. But the value lies more in that it makes it trivial to design a file format that is easy to parse, and process.

For me the value lies in that in the old days techniques were developed to systematically solve programming problems that will always we relevant, in this case processing a stream of events.

It is very well explained in the follwing MIT ocw lecture (it uses Java, but is actually language agnostic):

"Designing stream processors

Stream processing programs; grammars vs. machines; JSP method of program derivation; regular grammars and expressions"

https://ocw.mit.edu/courses/electrical-engineering-and-compu...

To practice it, you could try "Project 1: Multipart data transfer" in the link below:

https://ocw.mit.edu/courses/electrical-engineering-and-compu...

Well puppet doesn't have loops. I hope that's not because the "fad" is ending.

"... I can't remember the last time I saw a program with a complicated control flow done by gotos."

Perhaps not "complicated" enough, but here's a fizzbuzz in spitbol (a fast SNOBOL interpreter). This is an unstructured, goto based language for non-numeric computation developed at Bell Labs. Would love to see a faster version in some popular, "structured" scripting language in the same number of characters. I find I can write scripts in more aesthetically pleasing ways than with "structured" languages. But of course aesthetics is subjective. (The term "subjective" here means what looks good to you might not look good to me, and vice versa.)

   ;var a = 0
   ;start a = a + 1
   ;break lt(a,101) :f(end)
   ;x01  y = remdr(a,3)
   ;x02  z = remdr(a,5)
   ;x03  x = y + z 
   ;x01a eq(x,0) :s(x06)
   ;x02a eq(y,0) :s(x04)
   ;x03a eq(z,0) :s(x05)f(x07)
   ;x04  output = 'fizz' :(start)
   ;x05  output = 'buzz' :(start)
   ;x06  output = 'fizzbuzz' :(start)
   ;x07  output = a :(start)
   ;end

Perhaps the unintended benefit of gotos is that it becomes foolish to try to construct overly complex control flow. Whereas stuctured programmming seems to encourage control flow complexity. The use of the phrase "complicated control flow" in the parent comment is a great example. It suggests for the author structured programming allows and arguably therefore encourages such complexity. But what benefit is served by creating "complicated control flow". Why not aim for simpler control flow.

This is the opposite of aesthetically pleasing to my eye.

"structured programming" is not the use of flow-control but a way to design programs.

Even if most language have structured flow-control, a lot of people NOT do structured programming.

This is how I remember it back in the day and how I do it (curiously, much better on Rust, where it match better how was done on Pascal! ie: Not OOP, big on structs, functions, enums) and is a mix of:

- Define the major components of the app and put it on "modules" (aka their own file or folder if truly large)

- Define the major structures according to the domain (aka: make tables in sql). This is what POCOs are used today or plain Rust structs.

- Make procedures that operate on the above with a clear in/out discipline. Also, document that (this one, I always forget!)

So, is not that far away from functional, inmutable programming, only that:

- A lot was mutable and pass references. This is also a big part of how you discipline to define the flow make this tractable or not

- You don't have generics or classes, so you stick to plain data, plain vectors or lists and duplicate stuff (algos) here and there (no way to abstract "map/filter/folds" that I remember)

- You must be disciplined with the naming of "modules", "POCOs" and functions. Also limited in the length of names (like files only being 8 chars), causing the rise of Hungarian notation (that was misunderstood/misused badly!)

- All your pipeline are eager (not chance of iterators and stuff) so you repeat "loops" everywhere

- Everything was more self-contained, that is great... as long you don't forget the discipline.

"The discipline" was the key here, for make this actually "structured programming".

The MAJOR point is how you STRUCTURED the program, not the use of structured control flow!