<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>