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