From: cr88192@gmail.com

On 10/21/2025 7:30 PM, Janis Papanagnou wrote:
> On 21.10.2025 11:27, BGB wrote:
>> On 10/20/2025 9:19 PM, Janis Papanagnou wrote:
>>> On 20.10.2025 23:44, BGB wrote:
>>>> [...]
>>>>
>>>> And the seemingly often overlooked practical distinctions between the
>>>> design of serious/implementation languages and light-duty script
>>>> languages,
>>>
>>> An interesting distinction, though I'm [not] exactly sure what you have in
>>> mind when saying "light-duty" here.
>>>
>>> One commonly used script language that I use on a daily basis is the
>>> Unix Shell. Is that "light-duty" in your categories? (Not for me, to
>>> be sure.)
>>>
>>
>> Well, one can define "Scripting" as well.
>>
>> So, we have:
>> Shell scripts, which typically work with files and invoke programs;
>> Languages like Perl or Python, which are often used for standalone tools;
>
> I'm writing "standalone" shell programs as well. - Of course I may
> thereby be relying on existing functions/programs, as I'm in other
> "non-scripting" languages relying on libraries. I'm using files,
> communication methods, connecting cooperating entities, whatever.
>
>> Languages which are primarily used within the context of some other
>> program to implement behaviors within that program.
>
> ???
>
> I don't think your try to "define scripting" by three languages as
> example, and completely arbitrary statements, is useful in any way.
> (I recall some time ago I had looked up what Wikipedia has to say
> here; the many aspects provided there might give a better feeling
> about some typically considered factors, and its vagueness. - Does
> that justify not applying CS/IT standards when writing programs?)
>

I think there is a disconnect here...

I am not talking about use cases where you would use something like
Python or Node.js or similar like a standalone program, ...

The closest to mainstream example is how Lua is typically used.

Or, say, stuff running in the "Script-Fu" system inside GIMP.


>> [...]
>>
>>> In some courses I gave in the 1990's my dogma had always been (and
>>> still is) to approach "scripting" as [seriously] "programming"!
>>> And apply all the software development principles also when writing
>>> programs in "scripting" languages.
>>>
>>
>> It depends a lot on what you are doing.
>>
>> If it is something where software engineering practice matters,
>
> (Your last statement sounds so horribly absurd!)
>
> This is what I'm actually saying; that "software engineering practice"
> matters in these ("both") cases, because they're not really different
> if you want to write correct, maintainable, effective, efficient, and
> reliable software!
>
> I see that quite some folks obviously have different aspirations, and
> I observe also that software quality varies significantly with that.
>
> One is free to sacrifice methods of "software engineering practice" to
> have a comfortable time when writing "script programs". - If anything
> fails just (re-)defined what you mean by "scripting" and be satisfied.
> It doesn't justify sacrificing professionality in software development.
>
>> [...]
>>
>>>>
>>>> Or, in effect:
>>>>     C, C++, C#, Java, etc:
>>>>       Mostly sensible designs for implementation languages.
>>>>       Where: Language you would actually use for non-trivial code.
>>>>     BASIC, Emacs Lisp, etc:
>>>>       Sensible for script languages.
>>>
>>> (You're probably talking about newer BASIC dialects. - But there's
>>> anyway so many different BASIC dialects existing that it wouldn't
>>> appear to me to choose this thing in the first place.)
>>>
>>
>> The more recent BASIC dialect I dealt with were along the lines of, say:
>>    INPUT "Give number between 1 and 10"; X
>>    IF X<1 THEN GOTO OUTOFRANGE
>>    IF X<=5 THEN GOTO ONETOFIVE
>>    IF X<=10 THEN GOTO SIXTOTEN
>>    GOTO OUTOFRANGE
>>    ONETOFIVE:
>>    PRINT "X is between 1 and 5, X="; X
>>    END
>>    SIXTOTEN:
>>    PRINT "X is between 6 and 10, X="; X
>>    END
>>    OUTOFRANGE:
>>    PRINT "X is not between 1 and 10, X="; X
>>    END
>>
>> [ etc. etc. ]
>
> With your (IMO inapt) distinction above I wonder what sort of
> "scripting" you do with BASIC without sophisticated access to
> files/file-system, programs/processes, signals, OS in general,
> and less "legacy" but contemporary (1970's) control constructs,
> and more powerful methods to organize your data, for example.
>

Granted, not the kinds of scripting that would require these things...

Not every type of scripting requires access to the filesystem, or to the
world outside of a given host application. Nor, even much in the realm
of program structure.


In this case, imagine something sorta like the ACS scripts embedded
inside Hexen maps:
Player enters a new map, so play a sound-effect;
Player hits a certain switch, so set some variables;
Script runs when entering a map, check some state, and open or close
various doors;
...

Or, say:
Player stands in some location and uses a certain item in their
inventory, which triggers a script to run;
The script sets variables which may later effect the dialog trees for
certain NPCs;
...

Generally, it runs for maybe a few lines and stops.
   So, starts at a label, and runs until the next "END".


So, for example, assume we have a 3D world:
Player may go wherever, and use certain commands, etc.

Then, say, there are invisible "info node" entities, which respond to
certain kinds of events.

Player types:
   "look"
Game checks for a "info_look" node nearby, say:
   within line-of-sight of the player's location;
   closest distance;
   Any additional constraints match.
   It provides a generic description of the area.
     Say, for example, mentioning suspicious marks on a closet.
Player types:
   "look in closet"
Process repeats, seeing that the node has an entry for the "in closet"
scenario.
   Prints a generic description of what is in the closet.
Say, it then invokes a script related to the player looking in this
closet, which then sets any variables related to the player having
looked in this closet. Say, there is a rusty knife in the closet.

Say, player then types:
   "take knife"
Process repeats, invokes the script entry point for the "take knife"
event. Then, say, the script adds it to the inventory, and also sets a
variable to say that the knife is no longer in the closet.

Then, if player does "look in closet" again, this time around, the
script can see that the knife is no longer in the closet, and so skips
the description of the knife.

...



[continued in next message]

--- SoupGate-Win32 v1.05
 * Origin: you cannot sedate... all the things you hate (1:229/2)