[TUHS] most direct Unix descendant
Marc Donner
marc.donner at gmail.com
Tue Jun 11 06:09:47 AEST 2024
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 at sdaoden.eu> wrote:
> Marc Donner wrote in
> <CALQ0xCCNYP26Crv6m6Xp7efBL-wzfTB=fgZa9cKkVFvNacv-tw at 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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20240610/f9ba7a40/attachment-0001.htm>
More information about the TUHS
mailing list