5 ms·

The article says: > Today, structured programming appears remarkably simplistic, great for writing tiny programs (it has an academic pedigree), but not for any

• dhosek 5y ago
  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.
  • nine_k 5y ago
    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.
    • theodorethomas 5y ago
      > 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?
    • int_19h 5y ago
      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#.
  • dhosek 5y ago
    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.
• mamcx 5y ago
  "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!
  • anyfoo 5y ago
    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?