3 ms·

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

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

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