Comment by anyfoo | Hacker News Reader

Comment by anyfoo | Hacker News Reader

The article says:

> Today, structured programming appears remarkably simplistic, great for writing tiny programs (it has an academic pedigree), but not for anything larger than a thousand lines.

Curious. I rather think that structured programming became so ultra-pervasive in any high level programming language younger than 50 years old or so[1], that we've lost the extra name for it. Practically every programming language that isn't either pure functional (rarer than it seems), low level (i.e. assembly), or very very domain specific (e.g. SQL[2]) is a structural programming language.

Examples for "structural programming languages" are C, C++, C#, Java, JavaScript, python, Go, Swift, Scala, PHP, perl, Rust, D, ... You get the idea. If a general purpose language does not follow it, it's something notable, like Haskell.

So rather, I think this is an example of something that was so utterly successful that it became absorbed into the general fabric of mainstream programming. It's true that we don't draw as many flowcharts as we used to, because we got more comfortable with everyday programming, but they are still how we think about code a lot, and for complex processes that we want to visualize we still do draw them.

[1] Not a scientific estimate. Substitute "not very very old" if you like.

[2] Funnily that stands for "Structured Query Language", but not necessarily for significant reason: https://en.wikipedia.org/wiki/SQL#History

"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!

But then you (and the author?) talk about different things than the Wikipedia entry that the author linked to, because that entry (and what I remember about structured programming--but I was very young, so might have missed a lot) specifically talks about "making extensive use of the structured control flow constructs [...], block structures, and subroutines", also mentioning Dijkstra's "Go To Statement Considered Harmful" and some debate around that.

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?

As a Wikipedia editor who's poked around in our articles on programming paradigms, there's a decent amount of strange stuff going on -- and I'm not sure how much of that writing I'd take as authoritative, if you catch my drift.

I get it, but if the author means a different thing, then they should link to a source that actually defines what they mean (and that I myself could not find, except for the mention of modular programming), instead of to the Wikipedia article that refers to what we have been talking about here.

As it stands, what they link to, and what most seem to understand as structured programming, was not a fad at all.

Is possible we are talking about different stuff. Back in the day we don't wikipedia (and I learn programming before I have Internet, around 1998 so the idea was more developed?) so this is how I understand the idea as teached to me and by examples from my peers.

Also, a lot of good practiques was from books or conferences (mostly sponsored by MS).

TeX was Knuth's first “real” programming in a few years. His comments on structured programming are a bit eyebrow raising. He had high praise for it and said that it allowed him to write the whole program without having to test small parts of the program (the book with the exact quote is upstairs and I'm too lazy to go get it).

That said, I'm pretty sure that TeX is more than a 1000 lines of code.

Often functional tests provide more bang for the buck than unit tests. Concentrating on functional tests allows to move faster.

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.

> If you have a `then` clause, you know it will only run when the `if` condition is true.

Can someone please tell the clang compiler folks?

You can goto inside a conditional statement in pretty much any language I can think of that has goto.

Loops are sometimes more restricted, but even then, neither C nor Pascal prohibit it (Algol-60 did, curiously), and many languages derived from them that retained goto do the same. Off the top of my head, the only mainstream language I can think of that specifically prohibits goto into inner blocks is C#.

Here's the actual quote, which is illuminating:

“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.

Reply on news.ycombinator.com