[TUHS] Re: most direct Unix descendant

[Marc Donner <marc.donner@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5003 bytes --]

Totally correct - in the words of the immortal Beatles - "Strings is all
you need."
=====
nygeek.net
mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home>


On Mon, Jun 10, 2024 at 3:40 PM Steffen Nurpmeso <steffen@sdaoden.eu> wrote:

> Marc Donner wrote in
>  <CALQ0xCCNYP26Crv6m6Xp7efBL-wzfTB=fgZa9cKkVFvNacv-tw@mail.gmail.com>:
>  |The architectural alternative to powershell-style extension has been
> around
>  |in various guises for a while.  In particular things like TCL and Lua are
>  |engineered to be add-on extension languages.  Integrating them just
>  |involves adding a few callouts (dispatch a “program”, scan directories
> in a
>  |designated “path” for programs, render internal structures into text).
>  |
>  |This style of design has been around for a long time - all Unix shells,
>  |EMacs, many video games.
>  |
>  |It enables an elegant approach to performance management - build it first
>  |as a script and only reimplement it as a binary if needed.
>  |
>  |Doing this enables automation, but it does require the designers and
>  |product managers to want automation.
>
> Let me be the one who feed the silent head shakers with the
> Rob Pike quote "[just] make it strings".
>
> Of course lua hooks are faster, and i am looking forward myself,
> but other than that textual input/output communication with
> a program is language-neutral and somehow humanic.
>
> So now the time has come to point to an influential -- for me --
> manual from 2001, that goes into assembler programming for x86:
>
>   https://docs.freebsd.org/en/books/developers-handbook/x86/
>
> And there you read things like
>
>   A.12. One-Pointed Mind
>
>   As a student of Zen, I like the idea of a one-pointed mind: Do
>   one thing at a time, and do it well.
>
>   This, indeed, is very much how UNIX® works as well. While
>   a typical Windows® application is attempting to do everything
>   imaginable (and is, therefore, riddled with bugs), a typical
>   UNIX® program does only one thing, and it does it well.
>
>   The typical UNIX® user then essentially assembles his own
>   applications by writing a shell script which combines the
>   various existing programs by piping the output of one program to
>   the input of another.
>
>   When writing your own UNIX® software, it is generally a good
>   idea to see what parts of the problem you need to solve can be
>   handled by existing programs, and only write your own programs
>   for that part of the problem that you do not have an existing
>   solution for.
>
> And going over
>
>   A.13.2. Excursion to Pinhole Photography
>
> we come to the
>
>   A.13.3.1. Processing Program Input
>
> which was a stunning read for me (the 15+ years before i came via
> Commodore 64 and its Basic, over Windows 3.1 and Windows 95 and,
> alongside, DOS, later 4DOS (then perl etc.)), because when doing
> really, really important things like calculating the cubic
> capacity of ones penis' in cubic millimeters (to end up with large
> numbers, say), i would never have thought by myself that the
> program accept and parse running text!  (There you see that
> something "big" can actually be pretty "small" indeed.)
>
>   Personally, I like to keep it simple. Something either is
>   a number, so I process it. Or it is not a number, so I discard
>   it. I do not like the computer complaining about me typing in an
>   extra character when it is obvious that it is an extra
>   character. Duh.
>
>   Plus, it allows me to break up the monotony of computing and
>   type in a query instead of just a number:
>
>     What is the best pinhole diameter for the focal length of 150?
>
>   There is no reason for the computer to spit out a number of complaints:
>
>     Syntax error: What
>     Syntax error: is
>     Syntax error: the
>     Syntax error: best
>
>   Et cetera, et cetera, et cetera.
>
> And this (assembler!) then goes to
>
>     % pinhole
>
>     Computer,
>
>     What size pinhole do I need for the focal length of 150?
>     150 490     306     362     2930    12
>     Hmmm... How about 160?
>     160 506     316     362     3125    12
>     Let's make it 155, please.
>     155 498     311     362     3027    12
>     Ah, let's try 157...
>     157 501     313     362     3066    12
>     156?
>     156 500     312     362     3047    12
>     That's it! Perfect! Thank you very much!
>     ^D
>
> which is not even handled by GNU getopt with its
> argument-resorting behaviour!
> But it is likely that you all do not need that no more anyway,
> since you likely just speak out (silently at "Hal" level) "Hey
> computer bla bla", and the AI does the rest itself.
>
> --steffen
> |
> |Der Kragenbaer,                The moon bear,
> |der holt sich munter           he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)
>

[-- Attachment #2: Type: text/html, Size: 6247 bytes --]