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=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=unavailable 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 0793D227AD for ; Fri, 10 May 2024 18:37:45 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id D0977434B2; Sat, 11 May 2024 02:37:28 +1000 (AEST) Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) by minnie.tuhs.org (Postfix) with ESMTPS id ECA7B434AB for ; Sat, 11 May 2024 02:37:21 +1000 (AEST) Received: by mail-vk1-xa2a.google.com with SMTP id 71dfb90a1353d-4df37a78069so814278e0c.1 for ; Fri, 10 May 2024 09:37:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; t=1715359040; x=1715963840; darn=tuhs.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=7Zacf40PcF44HUUFaFqxZHZEUGxIhrRFeBuYaAmuAJ4=; b=iZ4PRx4i1OOQru17/kJvj7f+PXzUSFBqrbE8R0dq4oqgZwNPr0Wtp++DxyL+GUkmZJ 7LuzipaCd1kIkVD3Qy4LB644+QjJrVZzyYxr8Hrp54ipKH7A1j39AFozc+ChlFesPmkN /bA2O3pqA8W2ik94MWbB+qX7KfRXgMxlKYeus= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715359040; x=1715963840; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=7Zacf40PcF44HUUFaFqxZHZEUGxIhrRFeBuYaAmuAJ4=; b=LnSljrczIk4/+PDKnpXa52VjbBlfuIkvHP9arHDruqdPrz9Z/Ba+nBf0DStk0RlqU1 AgZfpH3Urvefp0egmBUBVGLdjbmKqOqHpYnjFc5JONUKPk10zFKH480W/xgUGL4dxr2I ZCPXkDVFXN4BhPGJo2yq5qkCS3d8CyAKS2IxyRLhiwEE+7fQzWtKEpWNlTJ2qXy8ijlC yB3zNQQcO+SJPXS/9PfMHLd1FKWfZCMlSciFEZnOPZ2SvHmnovcyGVz32SSDPsk980B4 sQIHmTAoYgJ2FoBlbnPdNm51GPcWe2MUf4HvGUFWqL0y/MBDNRVinq1m7rAKlpNrYmsJ acQA== X-Forwarded-Encrypted: i=1; AJvYcCVaJZ5Jg3quX5SJsPPCUGhi60hQlBmc+Xb+zyv7MREYhddQtdwFogBgv0AcAeGbNWvy9L6W32UA0a36CpLt X-Gm-Message-State: AOJu0YzJ9Mr55nAmZaKaqJ3o0AzH2z7jITVxZnjrUPOtkcnjq4t4d3AZ nOvY1ie5LKTJTWuKxaLxKuHNAWojgN3bFFTBMmix8CYi1B25NwQuEvjjXbWBy/i03pQBQd7mtw8 auxoa0FGLyIFsA8YcBH1qlqvceUzRfIewzVac X-Google-Smtp-Source: AGHT+IEn4IjfwG9YiYusjgfljWQOoFNRUPKFp+ohU8/rliBaYLKavd6lOYSj08L/4eI/Uv9U/3gJkISTcgCS2Cst4s0= X-Received: by 2002:a05:6122:1807:b0:4c8:ee1:5a0b with SMTP id 71dfb90a1353d-4df88366153mr3554261e0c.15.1715359039857; Fri, 10 May 2024 09:37:19 -0700 (PDT) MIME-Version: 1.0 From: Clem Cole Date: Fri, 10 May 2024 12:36:43 -0400 Message-ID: To: Rob Pike Content-Type: multipart/alternative; boundary="0000000000003bbfa106181c260f" Message-ID-Hash: ZXOEICXMAUY2RT6EUHJM52WXEZ2N6ZQ5 X-Message-ID-Hash: ZXOEICXMAUY2RT6EUHJM52WXEZ2N6ZQ5 X-MailFrom: clemc@ccc.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 CC: Computer Old Farts Followers X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [COFF] On Bloat and the Idea of Small Specialized Tools List-Id: Computer Old Farts Forum Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000003bbfa106181c260f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable While the idea of small tools that do one job well is the core tenant of what I think of as the UNIX philosophy, this goes a bit beyond UNIX, so I have moved this discussion to COFF and BCCing TUHS for now. The key is that not all "bloat" is the same (really)=E2=80=94or maybe one p= erson's bloat is another person's preference. That said, NIH leads to pure bloat with little to recommend it, while multiple offerings are a choice. Maybe the difference between the two may be one person's view over another. On Fri, May 10, 2024 at 6:08=E2=80=AFAM Rob Pike wrote: > Didn't recognize the command, looked it up. Sigh. > Like Rob -- this was a new one for me, too. I looked, and it is on the SYS3 tape; see: https://www.tuhs.org/cgi-bin/utree.pl?file=3DSysIII/usr/src/man/man1/nl.1 > pr -tn > > seems sufficient for me, but then that raises the question of your > question. > Agreed, that has been burned into the ROMs in my fingers since the mid-1970s =F0=9F=98=80 BTW: SYS3 has pr(1) with both switches too (more in a minute) > I've been developing a theory about how the existence of something leads > to things being added to it that you didn't need at all and only thought = of > when the original thing was created. > That is a good point, and I generally agree with you. > Bloat by example, if you will. I suspect it will not be a popular theory, > however accurately it may describe the technological world. > Of course, sometimes the new features >>are<< easier (more natural *for some people*). And herein lies the core problem. The bloat is often repetitive, and I suggest that it is often implemented in the wrong place - and usually for the wrong reasons. Bloat comes about because somebody thinks they need some feature and probably doesn't understand that it is already there or how they can use it. But they do know about it, their tool must be set up to exploit it - so they do not need to reinvent it. GUI-based tools are notorious for this failure. Everyone seems to have a built-in (unique) editor, or a private way to set up configuration options et al. But ... that walled garden is comfortable for many users and >>can be<< useful sometimes. Long ago, UNIX programmers learned that looking for $EDITOR in the environment was way better than creating one. Configuration was as ASCII text, stored in /etc for system-wide and dot files in the home for users. But it also means the >>output<< of each tool needs to be usable by each other [*i.e.*, docx or xlx files are a no-no). For example, for many things on my Mac, I do use the GUI-based tools -- there is no doubt they are better integrated with the core Mac system >>for some tasks.<< But only if I obey a set of rules Apple decrees. For instance, this email read is easier much of the time than MH (or the HM front end, for that matter), which I used for probably 25-30 years. But on my Mac, I always have 4 or 5 iterm2(1) open running zsh(1) these days. And, much of my typing (and everything I do as a programmer) is done in the shel= l (including a simple text editor, not an 'IDE'). People who love IDEs swear by them -- I'm just not impressed - there is nothing they do for me that makes it easier, and I have learned yet another scheme. That said, sadly, Apple is forcing me to learn yet another debugger since none of the traditional UNIX-based ones still work on the M1-based systems. But at least LLDB is in the same key as sdb/dbx/gdb *et al*., so it is a PITA but not a huge thing as, in the end, LLDB is still based on the UNIX idea of a single well-designed and specific to the task tool, to do each job and can work with each other. FWIW: I was recently a tad gob-smacked by the core idea of UNIX and its tools, which I have taken for a fact since the 1970s. It turns out that I've been helping with the PiDP-10 users (all of the PiDPs are cool, BTW). Before I saw UNIX, I was paid to program a PDP-10. In fact, my first UNIX job was helping move programs from the 10 to the UNIX. Thus ... I had been thinking that doing a little PDP-10 hacking shouldn't be too hard to dust off some of that old knowledge. While some of it has, of course, come back. But daily, I am discovering small things that are so natural with a few simple tools can be hard on those systems. I am realizing (rediscovering) that the "build it into my tool" was the norm in those days. So instead of a pr(1) command, there was a tool that created output to the lineprinter. You give it a file, and it is its job to figure out what to do with it, so it has its set of features (switches) - so "bloat" is that each tool (like many current GUI tools) has private ways of doing things. If the maker of tool X decided to support some idea, they would do it like tool Y. The problem, of course, was that tools X and Y had to 'know about' each type of file (in IBM terms, use its "access method"). Yes, the engineers at DEC, in their wisdom, tried to "standardize" those access methods/switches/features >>if you implemented them<< -- but they are not all there. This leads me back to the question Rob raises. Years ago, I got into an argument with Dave Cutler RE: UNIX *vs.* VMS. Dave's #1 complaint about UNIX in those days was that it was not "standardized." Every program was different, and more to Dave's point, there was no attempt to make switches or errors the same [getopt(3) had been introduced but was not being used by most applications). He hated that tar/tp used "keys" and tools like cpio used switches. Dave hated that I/O was so simple - in his world all user programs should use his RMS access method of course [1]. VMS, TOPS, *etc.*= , tried to maintain a system-wide error scheme, and users could look things like errors up in a system DB by error number, *etc*. Simply put, VMS is very "top-down." My point with Dave was that by being "bottom-up," the best ideas in UNIX were able to rise. And yes, it did mean some rough edges and repeated implementations of the same idea. But UNIX offered a choice, and while Rob and I like and find: pr -tn perfectly acceptable thank you, clearly someone else desired the features that nl provides. The folks that put together System 3 offer both solutions and let the user choose. This, of course, comes as bloat, but maybe that is a type of bloat so bad? My own thinking is this - get things down to the basics and simplest privatives and then build back up. It's okay to offer choices, as long as the foundation is simple and clean. To me, bloat becomes an issue when you do the same thing over and over again, particularly because you can not utilize what is there already, the worst example is NIH - which happens way more than it should. I think the kind of bloat that GUI tools and TOPS et al. created forces recreation, not reuse. But offering choice and the expense of multiple tools that do the same things strikes me as reasonable/probably a good thing. 1.] BTW: One of my favorite DEC stories WRT to VMS engineering has to do with the RMS I/O system. Supporting C using VMS was a bit of PITA. Eventually, the VMS engineers added Stream I/O - which simplified the C runtime, but it was also made available for all technical languages. Fairly soon after it was released, the DEC Marketing folks discovered almost all new programs, regardless of language, had started to use Stream I/O and many older programs were being rewritten by customers to use it. In fact, inside of DEC itself, the languages group eventually rewrote things like the FTN runtime to use streams, making it much smaller/easier to maintain. My line in the old days: "It's not so bad that ever I/O has offer 1000 options, it's that Dave to check each one for every I/O. It's a classic example of how you can easily build RMS I/O out of stream-based I/O, but the other way around is much harder. My point here is to *use the right primitives*. RMS may have made it easier to build RDB, but it impeded everything else. --0000000000003bbfa106181c260f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= font color=3D"#0000ff" style=3D"">While the idea of small tools that do one job well is the core tenant of= what I think of as the UNIX philosophy, this goes a bit beyond UNIX, so I = have moved this discussion to COFF and BCCing TUHS for now.=C2=A0=C2=A0

T= he key is that not all "bloat" is the same (really)=E2=80=94or ma= ybe one person's bloat is another person's preference.=C2=A0 That s= aid, NIH leads to pure bloat with little to recommend it, while multiple of= ferings are a choice.=C2=A0Maybe the difference between the two may be one = person's view over another.

On Fri, May 10, 2024 at 6:08=E2= =80=AFAM Rob Pike <robpike@gmail.co= m> wrote:
Didn't re= cognize the command, looked it up. Sigh.
Like Rob -- this was a new one=C2=A0for m= e,=C2=A0too.
I looked, = and it is on the SYS3 tape; see:=C2=A0https://www.= tuhs.org/cgi-bin/utree.pl?file=3DSysIII/usr/src/man/man1/nl.1


=C2=A0 pr -tn <file>

seems sufficient for me, but then that raises the= question of your question.
Agreed, that has been burned into the ROMs in my =C2=A0fin= gers since the mid-1970s =F0=9F=98=80=C2=A0
BTW: SYS3 has pr(1) with both switches too=C2=A0 (more in a m= inute)


I've been devel= oping a theory about how the existence of something leads to things being a= dded to it that you didn't need at all and only thought of when the ori= ginal thing was created.
That is a good point, and I generally agree with you.
<= div>=C2=A0
Bloat by example, if y= ou will. I suspect it will not be a popular theory, however accurately it m= ay describe the technological world.

Of course, sometimes the new features >>= are<< easier (more natural for some people).=C2=A0=C2=A0And herei= n lies the core problem. The bloat is often repetitive, and I suggest that = it is often implemented in the wrong place - and usually for the wrong reas= ons.

Bloat comes about because somebody=C2=A0thinks they need som= e=C2=A0feature and probably doesn't understand that it is already there= or how they can use it. But they do know about it, their tool must be set = up to exploit it - so they do not need to reinvent it.=C2=A0 GUI-based tool= s are notorious for this failure. Everyone seems to have a built-in (unique= ) editor, or a private way to set up configuration options et al. But ... t= hat walled garden is comfortable for many users and >>can be<< = useful sometimes.

<= /div>
Long ago, UNIX programmers learned=C2=A0th= at looking for $EDITOR in the environment was way better than creating one.= =C2=A0 Configuration was as ASCII text, stored in /etc for system-wide and = dot files in the home for users.=C2=A0 But it also means the >>output= << of each tool needs to be usable by each other [i.e., docx o= r xlx=C2=A0files are a no-no).

=
For example, for many things = on my Mac, I do use the GUI-based tools -- there is no doubt they are bette= r integrated with the core Mac system >>for some tasks.<< But o= nly if I obey a set of rules Apple decrees.=C2=A0 For instance, this email = read is easier much of the time than MH (or the HM front end, for that matt= er), which I used for probably 25-30 years.=C2=A0But on my=C2=A0Mac, I always have 4 or 5 iterm2(1) open running zsh(1) = these days. And, much of my typing (and everything I do as a pro= grammer) is done in the shell (including a simple text edito= r, not an 'IDE').=C2=A0 People who love IDEs swear by them -- I'= ;m just not impressed - there is nothing they do for me that makes it easie= r, and I have learned yet another scheme.

That said, sadly, Apple is forcing me to learn yet another d= ebugger since none of the traditional UNIX-based ones still work on the M1-= based systems. But at least LLDB is in the same key as sdb/dbx/gdb et al= .,=C2=A0so it is=C2=A0a PITA but not a huge thing as, in the end= , LLDB is=C2=A0still based on the UNIX idea of a single well-designed and s= pecific to the task tool, to do each job and can work with each other.

FWIW: I was recently= a tad gob-smacked by the core idea of UNIX and its tools, which I have tak= en for a fact since the 1970s.

It turns out that I've been helping with the PiDP-10 use= rs (all of the PiDPs are cool, BTW). Before I saw UNIX, I was paid to progr= am a PDP-10. In fact, my first UNIX job was helping move programs from the = 10 to the UNIX.=C2=A0 Thus ... I had been thinking that doing a little PDP-= 10 hacking shouldn't be too hard to dust off some of that old knowledge= .=C2=A0 While some of it has, of course, come back.=C2=A0 = But daily, I am discovering small things that are so natural with a few sim= ple tools can be hard on those systems.

I am realizing (rediscovering) that the "buil= d it into my tool" was the norm in those days.=C2=A0 =C2=A0So instead = of a pr(1) command, there was a tool that created output to the lineprinter= . You give it a file, and it is its job to figure out what to do with it, s= o it has its set of features (switches) - so "bloat" is that each= tool (like many current GUI tools) has private ways of doing things. If th= e maker of tool=C2=A0X decided to support some idea, they would do it like = tool Y.=C2=A0 The problem, of course, was that tools X and Y had to 'kn= ow about' each type of file (in IBM terms, use its "access method&= quot;).=C2=A0 Yes, the engineers at DEC, in their wisdom, tried to "st= andardize" those access methods/switches/features >>if you imple= mented them<< -- but they are not all there.
= <= span class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri= f">
This leads me back to the question Rob r= aises.=C2=A0 Years ago, I got into an argument with Dave Cutler=C2=A0RE: UN= IX vs. VMS. Dave's #1 complaint about UNIX in those days was tha= t it was not "standardized."=C2=A0 Every program was different, a= nd more to Dave's point, there was no attempt to make switches or error= s the same [getopt(3) had been introduced but was not being used by most ap= plications).=C2=A0 He hated that tar/tp used "keys" and tools lik= e cpio used switches.=C2=A0 Dave hated that I/O was so simple - in his worl= d all user programs should use his RMS access method of course [1].=C2=A0 V= MS, TOPS,=C2=A0etc., tried to maintain a system-wide error scheme, a= nd users could look things like errors up in a system DB by error number,= =C2=A0etc.=C2=A0 Simply put, VMS is very "top-down."

My point with Dave wa= s that by being "bottom-up," the best ideas in=C2=A0 UNIX were a= ble to rise. And yes, it did mean some rough edges and repeated implementat= ions of the same idea.=C2=A0 But UNIX offered a choice, and while Rob and I= like and find: pr -tn perfectly acceptable thank you, clearly someone else= desired the features that nl provides. The folks that put together System = 3 offer both solutions and let the user choose.
=
This, of course, comes as bloat, but maybe = that is a type of bloat so bad?=C2=A0 =C2=A0
My own thinking is thi= s - get things down to the basics and simplest privatives and then build ba= ck up.=C2=A0 It's okay=C2=A0to offer choices, as long as the foundation= is simple and clean.=C2=A0 To me, bloat becomes an issue when you do the s= ame thing over and over again, particularly because you can not utilize wha= t is there already, the worst example is NIH - which happens way more than = it should.


I = think the kind of bloat that GUI tools and TOPS et al. created forces recre= ation, not reuse. But offering choice and the expense of multiple tools tha= t do the same things strikes me as reasonable/probably a good thing.=C2=A0<= /span>


1.]=C2=A0 BTW: One of my favorite DEC stories WRT to VMS en= gineering has to do with the RMS I/O system.=C2=A0 Supporting C using VMS w= as a bit of PITA.=C2=A0 =C2=A0Eventually, the=C2=A0VMS engineers added Stre= am I/O - which simplified the C runtime, but it was also made available for= all technical languages.=C2=A0 Fairly soon after it was released, the DEC = Marketing folks discovered almost all new programs, regardless of language,= had started to use Stream I/O and many older programs were being rewritten= by customers to use it. In fact, inside of DEC itself, the languages group= eventually rewrote things like the FTN runtime to use streams, making it m= uch smaller/easier to maintain.=C2=A0 =C2=A0My line in the old days: "= It's not so bad that ever I/O has offer 1000 options, it's that Dav= e to check each one for every I/O. It's a classic example of how you ca= n easily build RMS I/O=C2=A0out of stream-based I/O, but the other way arou= nd is much harder.=C2=A0 =C2=A0My point here is to=C2=A0use the right pr= imitives. RMS may have made it easier to build RDB, but it impeded ever= ything else.
--0000000000003bbfa106181c260f--