3 ms·
Lately, I've been thinking a lot about interfaces, operating systems and procedure composition and this are some of my "ruminations": - None of the modern oper
by gosub 16y ago
Lately, I've been thinking a lot about interfaces, operating systems and procedure composition and this are some of my "ruminations":
- None of the modern operating systems is really orthogonal: neither linux nor the BSDs embrace the real "Unix philosophy"
- CLIs are monodimensional, and suffer from the same problems that dataflow programming has: it's easy to split the flow of data into two pipes, but is really hard (semantically) to rejoin them.
- GUIs are imperative in nature, and that hurts composability.
- Shells and REPLs have too many overlapping features (like OSs and ProgrammingLanguages+Libraries): the de facto standard for shells, bash, has a syntax that, for a programmer, feels really unclear. Every non trivial bash script that I wrote has turned really fast into escaping hell.
- dexen 16y ago> - CLIs are monodimensional, and suffer from the same problems that dataflow programming has: it's easy to split the flow of data into two pipes, but is really hard (semantically) to rejoin them. That's not hard if the text streams are line-oriented * append one to another, if order is not important * append one to another and then sort again, if order is important, * JOIN the streams using the `join' command (it's a standalone text utility, does pretty much what SQL JOIN does) To compute sum (in set theory sense), use ` | sort | uniq', to take intersection, use ` | sort | uniq -d'. Or use the `comm' utility. If using Bourne shell derivative, you may end up using temporary files. With the Rc shell, you may use the <{COMMAND} syntax, like: cat <{foo | bar | baz} <{frob | knob | bob} <{some | more} | subsequent | processing to catenate output of three pipes and do subsequent processing.