3 ms·

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 fo

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

3 ms·

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 fo

by flir 5y ago

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.