On 17/04/2024 04:45, Lawrence D'Oliveiro wrote:
> On Tue, 16 Apr 2024 16:42:43 +0100, Chris Elvidge wrote:
>
>> I use lua to enhance conky ...
>
> I know Lua was designed specifically to be embeddable, as an extension
> language for apps. But surprisingly, you see Python being used a lot for
> that, too.
>
> The most high-profile example has to be Blender. Now *there* is a
> scriptability API ...

Python is higher level, more "powerful" than Lua, and has vastly more
libraries. It is also vastly bigger. When you've got software the size
of Blender, Python is a good choice for an embedded scripting (or
programming :-) ) language. When you have something small, Lua is a
much better choice - it's fine for many microcontrollers. Lua adds
perhaps 100 KB to the program, while Python adds 20 MB (and Forth adds
maybe 5-10 KB, but is much harder to integrate with the C or C++ code).

On Wed, 17 Apr 2024 11:36:15 +0200
David Brown <david.brown@hesbynett.no> wrote:
>On 16/04/2024 18:13, Muttley@dastardlyhq.com wrote:
>> On Tue, 16 Apr 2024 08:59:12 -0700
>> I worked in defense writing software for missiles for a while.
>
>Presumably only for a short while, or very indirectly. People who

A while and very directly, as in working on the code in the missile itself.

>/actually/ work in that kind of system, don't talk about it.

Who told you that? It was a dev job, not the SAS. Got it in the normal way
through a normal job agency. Do you think people who work on these systems
are in government bunkers guarded by an Elite corps upon pain of death if
anyone talks? It was an office in an industrial estate walking distance
from a McDonalds.

>> Also worked
>> on networking code for systems that literally transfered 100s of millions of
>> dollars worth of trades a day.
>
>Ah, so games - just with a different kind of score.

Games that the world relies on.

>> But yeah, I'm sure scripting actions on Fortnite and Call of Duty compare.
>> Even the game engines are written in C++.
>>
>
>And the game data and actions are written in Lua.

Not in most games. In fact the biggest part of the games industry ATM is
mobile and Lua won't be much in evidence there.

>You do realise that the gaming industry is pretty big?

Many industries are pretty big.

John Ames <commodorejohn@gmail.com> wrote or quoted:
>*waits for a Forth-head to chime in*

No Forth aficionado here, but I gotta chime in and say:

Remember those late-model HP calculators (the HP-48 series)
with their UPN shenanigans? Their language ("RPL") was pretty
darn similar to Forth, if you ask me!

On Wed, 17 Apr 2024 08:22:27 -0000 (UTC)
Muttley@dastardlyhq.com wrote:

> >*golf clap*
>
> Whatever that is.

(it means i am engaging in what is nominally a gesture of respect in a
mocking way, so as to indicate that your pompous demands for respect
are being deliberately ignored)

> You aspies need to stop taking things so literally. Quite obviously
> someone uses it, but in the scheme of things Lua has a tiny userbase
> and is pretty irrelevant in most language discussions.

Again, the "the thing I said was not in any meaningful sense 'correct,'
so here's how I've decided that evidence to the contrary doesn't count"
strategy. *chef kiss*

On Wed, 17 Apr 2024 07:34:41 +0200
Andreas Eder <a_eder_muc@web.de> wrote:

> Really? It is a very small language and has almost no syntax.
> I thought it was one of the easiest languages toe learn ib comparison
> to C++ or Java.

*Syntactically* it's very simple, but explicit stack-orientation with
reverse-Polish notation is a *very* different programming paradigm than
practically everything else out there; even Lisp is closer to "normal,"
at least for functional-programming types. And that's before you even
get to the fairly idiosyncratic vocabulary or the type model that's
somehow both explicit and loose...

On Wed, 17 Apr 2024 07:59:43 -0700
John Ames <commodorejohn@gmail.com> wrote:
>On Wed, 17 Apr 2024 08:22:27 -0000 (UTC)
>Muttley@dastardlyhq.com wrote:
>
>> >*golf clap*
>>
>> Whatever that is.
>
>(it means i am engaging in what is nominally a gesture of respect in a
>mocking way, so as to indicate that your pompous demands for respect
>are being deliberately ignored)

Wasn't a demand for respect, just making a point about serious applications
and the languages used for them. Games arn't serious.

>> You aspies need to stop taking things so literally. Quite obviously
>> someone uses it, but in the scheme of things Lua has a tiny userbase
>> and is pretty irrelevant in most language discussions.
>
>Again, the "the thing I said was not in any meaningful sense 'correct,'
>so here's how I've decided that evidence to the contrary doesn't count"
>strategy. *chef kiss*

Have another go aspie.

On Wed, 17 Apr 2024 16:15:14 -0000 (UTC)
Muttley@dastardlyhq.com wrote:

> >(it means i am engaging in what is nominally a gesture of respect in
> >a mocking way, so as to indicate that your pompous demands for
> >respect are being deliberately ignored)
>
> Wasn't a demand for respect, just making a point about serious
> applications and the languages used for them. Games arn't serious.

Your definition of "serious applications" seems to coincide pretty
substantially with "fields I, personally, have worked in," particularly
since you've conveniently ignored the passel of non-game applications
that have also been cited in order to focus on the one you feel most
prepared to trivialize and discount in pursuance of your "argument."
And in addition to habitually slagging on applications and tools you
don't consider "serious" for no particular reason and with zero
provocation, you name-call like a grade-schooler. So it's difficult
*not* to parse your overall behavior as simian chest-thumping and
expecting to be treated as Le Fromage Grande on the basis of standards
conveniently set by yourself.

> Have another go aspie.

Case in point. But for the sake of argument, let's review:

Person: "This thing exists."
Muttley: "Nobody uses that."
People: "Here's all these things that use that."
Muttley: "Those don't count."
People: "Come again?"
Muttley: "They're not serious."
People: "What's your definition of 'serious' here?"
Muttley: "Things that I've worked on."
People: "...Um."
Muttley: "Also you're a poopiehead."

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Tue, 16 Apr 2024 20:47:47 +0000, Javier wrote:
>
>> But for system automation tasks in a Posix OS, when you want to go above
>> the level of a simple shell script and use complex data structures, Perl
>> is the only language that fills that gap, any other language is
>> oververbose (lacks conciseness).
>
> Still some limitations in its data structures, though.

Such as? (I'm not disagreeing -- every languages have "limitations" --
I'm just trying to find out what you mean by a limitation in Perl's data
structures.)

> I see Perl 5.38 has
> added an “experimental” class feature, but it doesn’t do multiple
> inheritance or metaclasses.

Perl has had support for object-oriented programming (with multiple
inheritance) for many years -- too many for me to remember.

> Also I’m not sure if classes are first-class
> objects or not.

--
Ben.

On 17/04/2024 17:05, John Ames wrote:
> On Wed, 17 Apr 2024 07:34:41 +0200
> Andreas Eder <a_eder_muc@web.de> wrote:
>
>> Really? It is a very small language and has almost no syntax.
>> I thought it was one of the easiest languages toe learn ib comparison
>> to C++ or Java.
>
> *Syntactically* it's very simple, but explicit stack-orientation with
> reverse-Polish notation is a *very* different programming paradigm than
> practically everything else out there; even Lisp is closer to "normal,"
> at least for functional-programming types. And that's before you even
> get to the fairly idiosyncratic vocabulary or the type model that's
> somehow both explicit and loose...
>

Another thing about Forth is that it gives C a run for its money in
potential for obfuscation :

: 1 2 ;
1 1 + .

Redefine "1". That'll keep the reader on his/her toes!

On Wed, 17 Apr 2024 21:05:03 +0200
David Brown <david.brown@hesbynett.no> wrote:

> Another thing about Forth is that it gives C a run for its money in
> potential for obfuscation :
>
> : 1 2 ;
> 1 1 + .
>
> Redefine "1". That'll keep the reader on his/her toes!

Redefinitions *stack,* too, so "foo" can mean multiple completely
different things in different contexts depending on which definition
was current at the time.

: foo 2 * ;
: double foo ;
3 foo .

: foo 1 + ;
3 foo .
3 double .

Genuine Forth-heads do staggering things (implementing OOP, etc.) with
this; personally, it gives *me* the willies.

On 17/04/2024 21:19, John Ames wrote:
> On Wed, 17 Apr 2024 21:05:03 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>
>> Another thing about Forth is that it gives C a run for its money in
>> potential for obfuscation :
>>
>> : 1 2 ;
>> 1 1 + .
>>
>> Redefine "1". That'll keep the reader on his/her toes!
>
> Redefinitions *stack,* too, so "foo" can mean multiple completely
> different things in different contexts depending on which definition
> was current at the time.
>
> : foo 2 * ;
> : double foo ;
> 3 foo .
>
> : foo 1 + ;
> 3 foo .
> 3 double .
>
> Genuine Forth-heads do staggering things (implementing OOP, etc.) with
> this; personally, it gives *me* the willies.
>

That's why mastering Forth takes a lot longer than just learning the
language!

I think that when finding the definition of a word, Forth just searches
back through the stack of definitions until it gets a hit. And if that
word definition uses other non-primitive words, it goes backwards from
where it currently is, looking only at definitions from before the
current word was defined. Is that right? And if so, can you do
"forward declarations", and mutual recursion somehow?

(I guess this is getting way off-topic for comp.unix.shell, and pretty
questionable for comp.unix.programmer - I don't know how much the
regulars there try to stay on-topic, or if they like threads like this.
I'll happily remove those groups from posts if there is objection to it,
but I don't want to cut out people who are interested if they want the
posts there.)

On Wed, 17 Apr 2024 21:52:06 +0200
David Brown <david.brown@hesbynett.no> wrote:

> I think that when finding the definition of a word, Forth just
> searches back through the stack of definitions until it gets a hit.
> And if that word definition uses other non-primitive words, it goes
> backwards from where it currently is, looking only at definitions
> from before the current word was defined. Is that right? And if so,
> can you do "forward declarations", and mutual recursion somehow?

That's my understanding, yes; essentially, it's a consequence of the
fact that definitions are stored as a list of pointers, and re-
definitions are simply appended to the dictionary without going back
through the rest of it to update any pointers to the prior definition.
A strange design choice, but they're consistent with it.

Forward declarations are possible using the CREATE ... DOES> construct,
which creates a definition that invokes a function pointer which can be
changed later. I dunno about mutual recursion, but it wouldn't shock me
if the same trick could be applied for that.

(And yes, if we ought to pare this back to comp.lang.misc we certainly
can.)

On Wed, 17 Apr 2024, John Ames wrote:

> On Wed, 17 Apr 2024 16:15:14 -0000 (UTC)
> Muttley@dastardlyhq.com wrote:
>
>>> (it means i am engaging in what is nominally a gesture of respect in
>>> a mocking way, so as to indicate that your pompous demands for
>>> respect are being deliberately ignored)
>>
>> Wasn't a demand for respect, just making a point about serious
>> applications and the languages used for them. Games arn't serious.
>
> Your definition of "serious applications" seems to coincide pretty
> substantially with "fields I, personally, have worked in," particularly
> since you've conveniently ignored the passel of non-game applications
> that have also been cited in order to focus on the one you feel most
> prepared to trivialize and discount in pursuance of your "argument."
> And in addition to habitually slagging on applications and tools you
> don't consider "serious" for no particular reason and with zero
> provocation, you name-call like a grade-schooler. So it's difficult
> *not* to parse your overall behavior as simian chest-thumping and
> expecting to be treated as Le Fromage Grande on the basis of standards
> conveniently set by yourself.
>
>> Have another go aspie.
>
> Case in point. But for the sake of argument, let's review:
>
> Person: "This thing exists."
> Muttley: "Nobody uses that."
> People: "Here's all these things that use that."
> Muttley: "Those don't count."
> People: "Come again?"
> Muttley: "They're not serious."
> People: "What's your definition of 'serious' here?"
> Muttley: "Things that I've worked on."
> People: "...Um."
> Muttley: "Also you're a poopiehead."

Sorry Muttley, I have to give this one to John. His argument is flawless
and spot on.

On Wed, 17 Apr 2024 18:04:57 +0100, Ben Bacarisse wrote:

> Perl has had support for object-oriented programming (with multiple
> inheritance) for many years -- too many for me to remember.

Then why this new “class” thing in 5.38?

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Wed, 17 Apr 2024 18:04:57 +0100, Ben Bacarisse wrote:
>> Perl has had support for object-oriented programming (with multiple
>> inheritance) for many years -- too many for me to remember.
>
> Then why this new “class” thing in 5.38?

It's explained reasonably well at the top of the "perldoc perlclass"
documentation in Perl 5.38:

History
Since Perl 5, support for objects revolved around the concept of
*blessing* references with a package name. Such reference could then be
used to call subroutines from the package it was blessed with (or any of
its parents). This system, while bare-bones, was flexible enough to
allow creation of multiple more advanced, community-driven systems for
object orientation.

Class feature is a core implementation of class syntax which is familiar
to what one would find in other programming languages. It isn't a
"bless" wrapper, but a completely new system built right into the perl
interpreter.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On Wed, 17 Apr 2024 16:59:06 -0700, Keith Thompson wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>> On Wed, 17 Apr 2024 18:04:57 +0100, Ben Bacarisse wrote:
>>>
>>> Perl has had support for object-oriented programming (with multiple
>>> inheritance) for many years -- too many for me to remember.
>>
>> Then why this new “class” thing in 5.38?
>
> It's explained reasonably well at the top of the "perldoc perlclass"
> documentation in Perl 5.38:

It says there is already supposed to be a mechanism for this, it doesn’t
explain why that isn’t good enough.

On 2024-04-17, John Ames <commodorejohn@gmail.com> wrote:
> On Wed, 17 Apr 2024 21:52:06 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>
>> I think that when finding the definition of a word, Forth just
>> searches back through the stack of definitions until it gets a hit.
>> And if that word definition uses other non-primitive words, it goes
>> backwards from where it currently is, looking only at definitions
>> from before the current word was defined. Is that right? And if so,
>> can you do "forward declarations", and mutual recursion somehow?
>
> That's my understanding, yes; essentially, it's a consequence of the
> fact that definitions are stored as a list of pointers, and re-
> definitions are simply appended to the dictionary without going back
> through the rest of it to update any pointers to the prior definition.
> A strange design choice, but they're consistent with it.

I don't know at all whether Forth does this or not, but this design
choice allows the list to be restored to a prior state, whereby the
recent definitions are forgotten, and the old ones revealed again,
similarly to shadowed lexicals being revealed again upon the terminaton
of an inner scope.

It sounds reminiscent of the assoc list representation of the lexical
environment in a rudimentary Lisp interpreter.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On Wed, 17 Apr 2024 09:55:12 -0700
John Ames <commodorejohn@gmail.com> wrote:
>On Wed, 17 Apr 2024 16:15:14 -0000 (UTC)
>Muttley@dastardlyhq.com wrote:
>
>> >(it means i am engaging in what is nominally a gesture of respect in
>> >a mocking way, so as to indicate that your pompous demands for
>> >respect are being deliberately ignored)
>>
>> Wasn't a demand for respect, just making a point about serious
>> applications and the languages used for them. Games arn't serious.
>
>Your definition of "serious applications" seems to coincide pretty
>substantially with "fields I, personally, have worked in," particularly

There are plenty of fields I haven't worked in that I would also consider
serious eg agriculture, automotive, energy.

Games arn't on that list.

>provocation, you name-call like a grade-schooler. So it's difficult

I simply descended to the level that the argument had been brought to so
don't complain.

>Muttley: "Also you're a poopiehead."

Are you expecting to be taken seriously?

On Wed, 17 Apr 2024 23:05:34 +0200
D <nospam@example.net> wrote:
>Sorry Muttley, I have to give this one to John. His argument is flawless
>and spot on.

Says a sock puppet who's never posted before. Nice try John.

On Wed, 17 Apr 2024 08:05:23 -0700, John Ames wrote:

> *Syntactically* it's very simple, but explicit stack-orientation with
> reverse-Polish notation is a *very* different programming paradigm than
> practically everything else out there ...

The only really tricky part of stack-based programming is keeping track of
what’s on the stack.

I did some messing about with a reboot of PostScript which tried to add
some niceties, like stack guards and lexical binding. Here’s an example of
the sort of thing I was able to get working (“ddef” and “dstore” define
and assign to dynamically-bound variables, while “ldef” and “lstore”
correspondingly work on lexically-bound ones):

/Count 99 ddef

/metatry
{ % provides context for nonlocals
dup
/Name exch ldef
/Count 0 ldef
{ % actual proc
/Count dup lload 1 add lstore
/Count dup dload 1 add dstore
Name =
(local Count = ) print /Count lload =
(global Count = ) print /Count dload =
(whichever Count = ) print Count =
}
}
ddef

/try1 metatry ddef
/try2 metatry ddef

try1
try2
try1
try2

Output:

try1
local Count = 1
global Count = 100
whichever Count = 1
try2
local Count = 1
global Count = 101
whichever Count = 1
try1
local Count = 2
global Count = 102
whichever Count = 2
try2
local Count = 2
global Count = 103
whichever Count = 2

On 18/04/2024 06:18, Kaz Kylheku wrote:
> On 2024-04-17, John Ames <commodorejohn@gmail.com> wrote:
>> On Wed, 17 Apr 2024 21:52:06 +0200
>> David Brown <david.brown@hesbynett.no> wrote:
>>
>>> I think that when finding the definition of a word, Forth just
>>> searches back through the stack of definitions until it gets a hit.
>>> And if that word definition uses other non-primitive words, it goes
>>> backwards from where it currently is, looking only at definitions
>>> from before the current word was defined. Is that right? And if so,
>>> can you do "forward declarations", and mutual recursion somehow?
>>
>> That's my understanding, yes; essentially, it's a consequence of the
>> fact that definitions are stored as a list of pointers, and re-
>> definitions are simply appended to the dictionary without going back
>> through the rest of it to update any pointers to the prior definition.
>> A strange design choice, but they're consistent with it.
>
> I don't know at all whether Forth does this or not, but this design
> choice allows the list to be restored to a prior state, whereby the
> recent definitions are forgotten, and the old ones revealed again,
> similarly to shadowed lexicals being revealed again upon the terminaton
> of an inner scope.
>

I suppose it also makes it a great deal easier to have small local
functions. Forth programming, as I understand it (I've only done very
small tests in Forth - I've never written a "real" program) generally
involves breaking code down into very small pieces. So your
implementation of "foo" might involve defining words like "get_next",
"double", "set_x", or whatever. (In Forth style these would probably be
shorter names, and perhaps include symbols.) Your implementation of
"bar" might want to re-use these same names but with different
definitions. With the list of pointers design of Forth, you can just
redefine these "local" words as you need to, and ignore any previous
definitions.

> It sounds reminiscent of the assoc list representation of the lexical
> environment in a rudimentary Lisp interpreter.
>

On Thu, 18 Apr 2024 10:30:49 +0200, David Brown wrote:

> With the list of pointers design of Forth, you can just
> redefine these "local" words as you need to, and ignore any previous
> definitions.

So, they reinvented local variables, and thought it was some great
innovation ...

On 18/04/2024 09:55, Lawrence D'Oliveiro wrote:
> On Wed, 17 Apr 2024 08:05:23 -0700, John Ames wrote:
>
>> *Syntactically* it's very simple, but explicit stack-orientation with
>> reverse-Polish notation is a *very* different programming paradigm than
>> practically everything else out there ...
>
> The only really tricky part of stack-based programming is keeping track of
> what’s on the stack.
>
> I did some messing about with a reboot of PostScript which tried to add
> some niceties, like stack guards and lexical binding. Here’s an example of
> the sort of thing I was able to get working (“ddef” and “dstore” define
> and assign to dynamically-bound variables, while “ldef” and “lstore”
> correspondingly work on lexically-bound ones):
>

I think I have only ever heard of one person who actually uses
PostScript for programming by hand, rather than as a print output
format. That is Don Lancaster, an electronics engineer who is a big fan
of "magic sines" (binary strings with low harmonics) and does all his
coding in PostScript. Anyone wanting to see a significant library of
PostScript code might be interested.

<https://www.tinaja.com/magsn01.shtml>

On Thu, 18 Apr 2024 10:37:47 +0200, David Brown wrote:

> I think I have only ever heard of one person who actually uses
> PostScript for programming by hand, rather than as a print output
> format. That is Don Lancaster ...

I know, I have seen his site.

The PostScript graphics model has long been superseded by worthy
successors, like Cairo. I did my own Python binding for Cairo
<https://gitlab.com/ldo/qahirah>, which adds things like vectors, matrices
and colours as first-class objects--beyond what Cairo itself, as a C-
language-based library, can do.

What I am interested in here is the PostScript language itself, and how it
can be modernized.

On Thu, 18 Apr 2024, Muttley@dastardlyhq.com wrote:

> On Wed, 17 Apr 2024 23:05:34 +0200
> D <nospam@example.net> wrote:
>> Sorry Muttley, I have to give this one to John. His argument is flawless
>> and spot on.
>
> Says a sock puppet who's never posted before. Nice try John.

Please keep the jokes coming. I find you most entertaining! =)