4 ms·

I don't think that's right. If you compare bash: ls | sort with some pseudocode: stdin_ls <- empty_read_stream() stdout_ls <- init_write_stream()

I don't think that's right. If you compare bash: ls | sort with some pseudocode: stdin_ls <- empty_read_stream() stdout_ls <- init_write_stream() stdin_sort <- init_read_stream() stdout_sort <- init_write_stream() plug_stream(stdout_ls, stdin_sort) stream_sink(stdout_sort, function_that_processes_lines) handle_ls <- start_proc("ls", stdin_ls, stdout_ls) handle_sort <- start_proc("sort", stdin_sort, stdout_sort) wait_for_both(handle_ls, handle_sort) it seems that "|" is definitely gluing things together. It's true that it doesn't do everything you want. But it's truly glue. It's crazy to imply that there's only one level of glue. You identify other glue: if you want to sort by something that isn't the whole line, you need to write a bunch of glue. But that doesn't mean this isn't glue. > the foolish design decision to make everything “plain” text I don't think you can call it foolish and be taken seriously. You can disagree about whether it was the right design decision, but it was neither the first nor the last system to transfer unstructured data and rely on external programs to interpret them. It seems to have paid off too - systems descended from this design are widespread. You might not like paying the tradeoff, but a lot of people find it productive. Powershell has some improvements on top of the Unix model because it saw the benefits of the Unix model and the costs of it. In either case, the gui world has nothing like the productivity of either system.

nivertech 5y ago
> Powershell has some improvements on top of the Unix model because it saw the benefits of the Unix model and the costs of it. yes, the pattern is to have some internal normalized generic-enough data structure on which pipes will operate. Then all you need is the ability to convert non-normalized input sources into it, and the same with the output formats. BTW: the UNIX pipes forks the processes, but Windows' CMD.com was executing the stages in the pipeline sequentially, not sure about PowerShell. > the gui world has nothing like the productivity of either system. I think Tcl/Tk is kind of GUI glue. It's very easy to build a GUI front-end for an existing CLI commands / scripts. EDIT: also COM/OLE, ActiveX, JavaBeans were promising code re-use for GUIs
- jsmith45 5y ago
  cmd.exe most certainly does execute the pipeline in parallel, much as unixes do. The old MS-DOS command.com would not (since only single process at a time execution was even supported). I have no idea if the Windows 9X/ME version of command.com worked the same way as dos or not, and I don't feel like firing up a VM to find out. Now cmd.exe has maintained a lot of stupidity, and even many obvious bugs from the old command.com executable, in order to ensure that positively ancient script still run as expected. (This includes horribleness like the cmd.exe code not being able to read ahead in the .bat file, in order to support old self-modifying .bat file tricks!). But sequential-only pipelines are not part of the stupidity that was kept in place.
fouric 5y ago
Your example is intentionally and extremely contrived in such a way so as to support your point, and not representative of the real world at all. For instance, if you suddenly ls -l and then want to sort by size instead (yes, I'm aware of -S, and it's irrelevant), then suddenly you have to use far more than just a pipe character. Moreover, the psuedocode is absolutely ridiculous - a more accurate example would be a single function call to list items in a directory, and then another call to sort() with a lambda to pull out the correct field to sort on. In Common Lisp: (sort (ls) :key (lambda (entry) (size entry))) Compare that to your psuedocode snippet. > It's true that it doesn't do everything you want. My point was that it doesn't do anything. It's like function composition in any modern programming language - it's so incredibly trivial that nobody mentions it, because it's both necessary for most operations but also completely insufficient for doing those operations on its own. It's not "glue" in the same way that function composition is not "glue" - it doesn't do any more connection than just enabling things to theoretically exchange data in some way. > But it's truly glue. Maybe according to your own definition, but certainly not in the way that the article (and I) use it, which is "the unglamorous, invisible code that connects two pieces of software, makes sure that data that's in location A reaches location B unscathed (from the datbase to the UI, from the UI to the model, from the model to the backend and so on...)" ...which clearly means that the data is actually transformed into a format that the receiving code can read - which pipe does not do. > I don't think you can call it foolish and be taken seriously. If someone doesn't take me seriously (after I make my point, of course), then that's an indication that their own mind has been blinded by a zealotry for the Unix style, not that my point is invalid. > it was neither the first nor the last system to transfer unstructured data and rely on external programs to interpret them ...which doesn't matter, because it was still a design decision that the Unix architects made, and one of the ones for which Unix is best-known for. > It seems to have paid off too - systems descended from this design are widespread. The idea that popularity implies a good system design is a pretty well-known fallacy. Look at PHP - nearly universally acknowledged to be awfully-designed, and yet extremely popular. Windows, JavaScript, Java, and more - all popular, all poorly-designed. > You might not like paying the tradeoff, but a lot of people find it productive. You can say the same about dynamically-typed programming languages, and weakly-typed programming languages, and even untyped programming languages (Tcl, where everything is a string) - an illusion of productiveness, where you spend much more time down the line debugging mistakes caused by the flaws in your methodology.

nivertech 5y ago

> Powershell has some improvements on top of the Unix model because it saw the benefits of the Unix model and the costs of it. yes, the pattern is to have some internal normalized generic-enough data structure on which pipes will operate. Then all you need is the ability to convert non-normalized input sources into it, and the same with the output formats. BTW: the UNIX pipes forks the processes, but Windows' CMD.com was executing the stages in the pipeline sequentially, not sure about PowerShell. > the gui world has nothing like the productivity of either system. I think Tcl/Tk is kind of GUI glue. It's very easy to build a GUI front-end for an existing CLI commands / scripts. EDIT: also COM/OLE, ActiveX, JavaBeans were promising code re-use for GUIs

jsmith45 5y ago
cmd.exe most certainly does execute the pipeline in parallel, much as unixes do. The old MS-DOS command.com would not (since only single process at a time execution was even supported). I have no idea if the Windows 9X/ME version of command.com worked the same way as dos or not, and I don't feel like firing up a VM to find out. Now cmd.exe has maintained a lot of stupidity, and even many obvious bugs from the old command.com executable, in order to ensure that positively ancient script still run as expected. (This includes horribleness like the cmd.exe code not being able to read ahead in the .bat file, in order to support old self-modifying .bat file tricks!). But sequential-only pipelines are not part of the stupidity that was kept in place.

fouric 5y ago

Your example is intentionally and extremely contrived in such a way so as to support your point, and not representative of the real world at all. For instance, if you suddenly ls -l and then want to sort by size instead (yes, I'm aware of -S, and it's irrelevant), then suddenly you have to use far more than just a pipe character. Moreover, the psuedocode is absolutely ridiculous - a more accurate example would be a single function call to list items in a directory, and then another call to sort() with a lambda to pull out the correct field to sort on. In Common Lisp: (sort (ls) :key (lambda (entry) (size entry))) Compare that to your psuedocode snippet. > It's true that it doesn't do everything you want. My point was that it doesn't do anything. It's like function composition in any modern programming language - it's so incredibly trivial that nobody mentions it, because it's both necessary for most operations but also completely insufficient for doing those operations on its own. It's not "glue" in the same way that function composition is not "glue" - it doesn't do any more connection than just enabling things to theoretically exchange data in some way. > But it's truly glue. Maybe according to your own definition, but certainly not in the way that the article (and I) use it, which is "the unglamorous, invisible code that connects two pieces of software, makes sure that data that's in location A reaches location B unscathed (from the datbase to the UI, from the UI to the model, from the model to the backend and so on...)" ...which clearly means that the data is actually transformed into a format that the receiving code can read - which pipe does not do. > I don't think you can call it foolish and be taken seriously. If someone doesn't take me seriously (after I make my point, of course), then that's an indication that their own mind has been blinded by a zealotry for the Unix style, not that my point is invalid. > it was neither the first nor the last system to transfer unstructured data and rely on external programs to interpret them ...which doesn't matter, because it was still a design decision that the Unix architects made, and one of the ones for which Unix is best-known for. > It seems to have paid off too - systems descended from this design are widespread. The idea that popularity implies a good system design is a pretty well-known fallacy. Look at PHP - nearly universally acknowledged to be awfully-designed, and yet extremely popular. Windows, JavaScript, Java, and more - all popular, all poorly-designed. > You might not like paying the tradeoff, but a lot of people find it productive. You can say the same about dynamically-typed programming languages, and weakly-typed programming languages, and even untyped programming languages (Tcl, where everything is a string) - an illusion of productiveness, where you spend much more time down the line debugging mistakes caused by the flaws in your methodology.