From mboxrd@z Thu Jan 1 00:00:00 1970 From: bakul@bitblocks.com (Bakul Shah) Date: Fri, 05 May 2017 23:07:27 -0700 Subject: [TUHS] Discuss of style and design of computer programs from a user stand point [was dmr note on BSD's sins] In-Reply-To: Your message of "Sat, 06 May 2017 12:16:53 +1000." References: <1C6D6D3E-058F-4743-8DA0-17CEC09B64E9@bitblocks.com> Message-ID: <20170506060727.A00C0124AEFE@mail.bitblocks.com> On Sat, 06 May 2017 12:16:53 +1000 Noel Hunt wrote: > > What you call 'composability' is nothing more than the 'software > tools' approach. Composable components can have a much tigher coupling. vi, rsync, git and gdb are s/w tools but they are not composable in the sense of sed, grep, uniq, awk, head, tail, tr, sort, ls, find etc. > I recall reading an interview with Dennis Ritchie, but can no > longer find it, where he talks about this approach versus the > monolithic program model, as for example demonstrated by > 'perl', which does everything. Dennis remarked that the > 'tools' approach required careful thought (which programs to > use, how to connect them with pipes) and so was more difficult > to use, hence the popularity of 'perl'. This is the "modularity" approach, where one program does one thing well rather than doing everything (e.g IDE). But moudlarity does not necessarily give you composability. Also, it is not enough to have composable components; you need a language/environment in which they can be used. > A most beautiful example of this approach is from Doug McIlroy > in his critique of Donald Knuth's solution to a problem posed > by Jon Bentley in his 'Programming Pearls' column: > > Read a file of text, determine the n most frequently used > words, and print out a sorted list of those words along with > their frequencies. > > Donald Knuth wrote a long, beautifully crafted program in some > pseudo-code. Doug McIlroy provided an alternative solution: > > tr -cs A-Za-z '\n' | > tr A-Z a-z | > sort | > uniq -c | > sort -rn | > sed ${1}q > > This is real genius. Indeed. Note that a similar approach was implemented by Iverson in APL. In fact a shell pipeline has a lot in common with array programming! Iverson in essence built a whole workshop with a set of simple but powerful standard tools (functions and higher order functions). The same has been carried on in follow on array languages such as j and k and q languages. Many of these array functions are directly applicable to stream processing. In contrast unix shells provide a very shallow glue layer. > On Sat, May 6, 2017 at 1:37 AM, Bakul Shah wrote: > > > I think the key issue is not as much minimalism as composability. BSD > > often prioritized convenience over composability. Each command doing one > > thing well and doing line oriented makes them more composability. You can > > always package up convenient combinations in a script. Plan9 has lc which > > prints like unix ls -C but it is an rc script. Trying to achieve > > composability can result in leaner systems.