4 ms·

`Structured programming' is actually used to refer to two different things: reducing or eliminating the number of gotos, and top-down programming. The former is

`Structured programming' is actually used to refer to two different things: reducing or eliminating the number of gotos, and top-down programming. The former is universally understood to be generally a good thing (though there are still some good uses for gotos); the latter was the fad. The 1970s was the time of HIPO (hierarchy/input/process/output) charts. An early-1980s research project I was acquainted with at the time had an iron-clad rule: each procedure must be in its own source file. At least one well-known book in the 1980s gave definitions of software quality metrics that made object-oriented designs bad. Pretty much every SE methodology has been a fad when it claimed to be the One True Way, and has offered useful ways of solving a certain kind of problem.

flir 5y ago
Top-down/procedural fits really nicely with the unix command line philosophy. Loose coupling and pipes. You can understand why it was the de facto One True Way before GUIs.
- lmm 5y ago
  > Top-down/procedural fits really nicely with the unix command line philosophy. Loose coupling and pipes. 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.
  - flir 5y ago
    But the individual tool itself? It takes a bunch of inputs, does some processing on them, and spits out a bunch of outputs. That doesn't feel like a good fit for procedural to you? I guess what I'm saying is that the complete input state of the program is known the moment you hit enter. As opposed to a GUI where a user could flip a switch at any point during the program's lifetime and mess with its internal state, which feels like it maps better to OOP.
    - lmm 5y ago
      I guess you're saying that if you're writing a small function that's fully understood then procedural top-down is a good way to do it. I don't know. Personally even for a fairly small tool I'd want to build it bottom-up by composing smaller functions, and I think you'd gain a lot of reusability that way - indeed I'd say many of the classic unix tools suffer from being programs rather than libraries, and it's a shame there's such a hard boundary between shell and the tools it uses. If anything I suspect the causality goes in the other direction - if you want to make a big system using procedural programming and C, then you have to split it into processes that are simple enough to comprehend in their entirety, and that have a very simple state model where they essentially just take input and give output and don't have any persistent state between invocations. But when you put it like that, Unix shell-and-pipeline style starts to seem like an effort to invent functional programming, just at a somewhat more coarse-grained level.
      - flir 5y ago
        That's a fair assessment of my position, yes. But I got my start with JSP diagrams, pseudocode and command lines, so decomposition is very natural to me. It's my "first language", like English. And the comparison between good top-down structured and functional is one I've made myself.
- masklinn 5y ago
  > Top-down/procedural fits really nicely with the unix command line philosophy. 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.
regularfry 5y ago
> each procedure must be in its own source file. Funnily enough, this is how GNU libc is organised.

flir 5y ago

Top-down/procedural fits really nicely with the unix command line philosophy. Loose coupling and pipes. You can understand why it was the de facto One True Way before GUIs.

lmm 5y ago
> Top-down/procedural fits really nicely with the unix command line philosophy. Loose coupling and pipes. 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.
- flir 5y ago
  But the individual tool itself? It takes a bunch of inputs, does some processing on them, and spits out a bunch of outputs. That doesn't feel like a good fit for procedural to you? I guess what I'm saying is that the complete input state of the program is known the moment you hit enter. As opposed to a GUI where a user could flip a switch at any point during the program's lifetime and mess with its internal state, which feels like it maps better to OOP.
  - lmm 5y ago
    I guess you're saying that if you're writing a small function that's fully understood then procedural top-down is a good way to do it. I don't know. Personally even for a fairly small tool I'd want to build it bottom-up by composing smaller functions, and I think you'd gain a lot of reusability that way - indeed I'd say many of the classic unix tools suffer from being programs rather than libraries, and it's a shame there's such a hard boundary between shell and the tools it uses. If anything I suspect the causality goes in the other direction - if you want to make a big system using procedural programming and C, then you have to split it into processes that are simple enough to comprehend in their entirety, and that have a very simple state model where they essentially just take input and give output and don't have any persistent state between invocations. But when you put it like that, Unix shell-and-pipeline style starts to seem like an effort to invent functional programming, just at a somewhat more coarse-grained level.
    - flir 5y ago
      That's a fair assessment of my position, yes. But I got my start with JSP diagrams, pseudocode and command lines, so decomposition is very natural to me. It's my "first language", like English. And the comparison between good top-down structured and functional is one I've made myself.
masklinn 5y ago
> Top-down/procedural fits really nicely with the unix command line philosophy. 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.

regularfry 5y ago

> each procedure must be in its own source file. Funnily enough, this is how GNU libc is organised.