From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from minnie.tuhs.org (minnie.tuhs.org [50.116.15.146]) by inbox.vuxu.org (Postfix) with ESMTP id B8ED8215AD for ; Sat, 18 May 2024 22:12:53 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 851DD4367A; Sun, 19 May 2024 06:12:47 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuhs.org; s=dkim; t=1716063167; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-owner:list-unsubscribe:list-subscribe:list-post; bh=940/kIsn75Gy9YZjs0KPamoZu+pyBnrUr4QNpkuvIa8=; b=DVgJ8wpYXlj6SO9KHpD8owETAvk99C/WhRkEFW60aN2/0G7MNDtGmrQVF3hTJFy6gDjMRM LIk8WUcJB9eZtzWeaEdlLs4/TgJYfxA3wwiFfXqGV9Jwiyr95qlbQTyd0AVS/te6BIao45 EpcS1e809w5QTgt8G1mDTP/12mA42l0= Received: from mail-4325.protonmail.ch (mail-4325.protonmail.ch [185.70.43.25]) by minnie.tuhs.org (Postfix) with ESMTPS id 910D843679 for ; Sun, 19 May 2024 06:12:43 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1716063161; x=1716322361; bh=940/kIsn75Gy9YZjs0KPamoZu+pyBnrUr4QNpkuvIa8=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=rHPbITg42B9FAY1aQuKG3W6xqTqZtYRnoCbQvIONrSyY/AyWzi4Ay3mtGdu4XpsOz 8Z6tZXtRnoC+4IH9PFNhcUVsZuomnA+sfuPteSC4BcbSxQ1k487dpfXV4FBZD5rff0 9aebh1m/+EMVKwOtGluwpkfs+bUwMObRbFjmCSvUx6LBCLPt5SmKgNM/dwXg3fvabp Kicx6QfVibxrEiAPN9rKKPTE6ESYE27meY7sHj/5JkXLnvbiy5S0hpEm10ZtzStqHI EN0Bs0sIZU5PE+N+HdvIDlRhwG+dqmmLVitLN8RrajsfQYFoh+dfX9FxRZzD/YZJjw IyuG91GoC1hRw== Date: Sat, 18 May 2024 20:12:38 +0000 To: The Eunuchs Hysterical Society Message-ID: In-Reply-To: <0309bfd8-3f85-e687-1500-c1e447599e83@makerlisp.com> References: <20240518181825.GT9216@mcvoy.com> <0309bfd8-3f85-e687-1500-c1e447599e83@makerlisp.com> Feedback-ID: 35591162:user:proton X-Pm-Message-ID: e287ac414a1713252b9956edf2dc04f77563faaa MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: RVSKTJ2DPO5NZO3URSRY6JF4TVFFABO2 X-Message-ID-Hash: RVSKTJ2DPO5NZO3URSRY6JF4TVFFABO2 X-MailFrom: segaloco@protonmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: On Bloat and the Idea of Small Specialized Tools List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: segaloco via TUHS Reply-To: segaloco On Saturday, May 18th, 2024 at 12:19 PM, Luther Johnson wrote: > Complexity is entropy. It occurs naturally in all human endeavor. It take= s work to keep things small, orderly, and rational. But there is also a poi= nt where although a tool may be perfect in its conception and execution, fr= om its own perspective, it is not as useful as a slightly more disorderly v= ersion that does what people want it to do. "Well they shouldn't want that = !" is a common response. Then people write scripts to do for themselves wha= t the tool doesn't do. Which might be right, but it might lead to a whole b= unch of similar scripts to do the same thing, just a little differently And= that's when we discover that it would have been better to have it in the o= ne tool in the first place. >=20 > So it's a back and forth, trial and error process. Eventually new balance= s get struck, and people of like minds and tastes find a new center, like P= lan 9, or other things. >=20 > Myself, I do tend to like tools that are smaller and more single-minded i= n their function (and that makes it possible to have documentation that is = clearer and more concise), but as an example, sometimes I want the "-u" swi= tch on diff, to make a patch, sometimes I don't, the default display is bet= ter for a quick review (but I think or expect that the essential diff engin= e is being shared). It's all a matter of judgment, but you can't apply good= judgment until you have the experience gained from trying several alternat= ives. So things will get bloated up, and then they will need to be pruned a= nd re-engineered, but hopefully we don't throw out the most helpful excepti= ons to the rule just because they don't fit with some sort of consistency a= esthetic. >=20 > On 05/18/2024 11:52 AM, Clem Cole wrote: >=20 > >=20 > >=20 > > On Sat, May 18, 2024 at 2:18=E2=80=AFPM Larry McVoy wrot= e: > >=20 > > > But I'm ok with a terse man page with a SEE ALSO that points to a use= r guide. > >=20 > > Only if the SEE ALSO has more complete and relevant information - other= wise, it degrades to VMS's famous "see figure 1" SPR. > >=20 > > >=20 > > > Docs should be helpful. > >=20 > > And easy to extract information. > >=20 > >=20 > > The issue to be comes back to the type of information each document is = designed to give. I believe there at least three types of docs: > >=20 > > 1. Full manuals explain how something is built and it it used. It help= s to have theory/principles of operations behind it and enough detail when = done, you can understand why and how to use it. > > 2. Tutorials are excellent for someone trying to learn a new tool. Les= s theory - and more -- examples, showing off the features and how to do som= ething. > > 3. References pages - need to be quick look-ups to remind someone how = to use something - particularly for tools you don't use every day/generally= don't memorize. > >=20 > >=20 > >=20 > > There are at least two more: an academic paper which might be looked at= as a start of #1 and full books which take #1 to even more details. Some a= cademic papers indeed are fine manuals, and I can also argue the "manual" f= or some tools like awk/sed or, for that matter, yacc(1) are full books. But= the idea is the >>complete<< review here. > >=20 > >=20 > > Tutorials and reference pages are supposed to easy helpful things -- bu= t often miss the mark for the audience. To me, the problem is the wrong typ= e of information is put in each one and, more importantly, people's expecta= tions from the document. I love properly built manual pages - I detest thin= gs like the VMS/TOPS help command or gnu info pages. What I really hate is = when there is no manual, but they tell you see the HELP command -- but whic= h command or "subtopic" -- Yikes. The traditional man system is simple quic= k reminders, basic reference and I can move on. For instance, I needed to r= emember which C library has the definition these days for some set of funct= ions and what are its error return codes -- man 3 functions, I'm done. > >=20 > >=20 > > Tutorials are funny. For some people, what they want to learn the ideas= behind a tool. Typically, I don't need that as much as how this toll does = some function. For instance, Apple is forcing me the learn lldb because the= traditional debuggers derived from UCB's DBX are not there. It's similar t= o different. The man page is useful only for the command lines switches. It= turns out the commands are all really long, but they have abbreviations an= d can be aliases. I found references to this in an lldb tutorial - but the = tutorial is written to teach people more how to use a debugger to debug the= re code, and less how this debugger maps into the traditional functions. He= y I would like to find an cheat sheet or a set of aliases that map DBX/GDB = into it -- but so far I've found nothing. > >=20 > >=20 > > So Larry -- I agree with you ... "Docs should be helpful," but I fear s= aying like that is a bit like the Faber College Motto/Founder's Quote: "Kno= wledge is good." > >=20 > >=20 > >=20 > >=20 > > =E1=90=A7 Facing ever-growing complexity, I often find myself turning strictly to the= POSIX/SUS manpages for anything that has one, not only due to an interest = in keeping things as portable as possible, but also admittedly out of some = trepidation that the cool shiny specific feature of the week for a specific= implementation doesn't have quite the same stabilizing standard behind it,= and as such has the unlikely but real potential to change right out from u= nder you in a new major version. Issuing 'man 1p' or 'man 3p' before most = studying has become habit, turning to a vendors' docs only when necessary. Granted, no standardization of debuggers, assemblers, linkers, etc. makes t= his much trickier when working with embedded stuff or intensive diagnostics= , so in that regard I've thus far been aligned with the GNU family of these= components. For the sake of embedded devs, it would be nice if the as/ld/= db set of utilities had some sort of guiding light driving disparate implem= entations. A particular example of divergent behavior wearing a familiar m= ask is the cc65 suite. The assembler and linker smell of predictable UNIX = fare, but differ in a number of little, quite annoying ways, among them "ex= port" instead of "globl", cheap labels based strictly on counts forward and= backward rather than recyclable numeric labels, just little things. While= a standard isn't the end all be all solution to everything, it certainly d= ecreases at least some of the cognitive load, giving you a subset of behavi= ors to learn once, only turning to specifics when you've exhausted your opt= ions (or patience) with the intersections of various implementations. I see a domino effect in this sort of thing too, one basal tool diverges a = bit from other versions, then folks who only ever use that implementation h= ead down a new fork in the road, those in their "camp" follow, before long = whatever that difference is happens to be entrenched in a number of folks' = vocabularies. Like linguistic divergence, eventually the dialectical bits = of how they work are no longer mutually intelligible. The Tower of Babel g= rows ever higher, only time will tell whether the varied, sometimes contrad= ictory styles of architecture are a strength or weakness. Like evolution, = oft times the most successful, sensible approaches prevail, but nature has = a funny way of lapsing on our narrow understanding of "fitness" too. After= all, most of what many of us use on the regular guarantees no "fitness for= a particular purpose". Does this make stability an organic consequence or= a happy accident? I know I couldn't say. - Matt G.