On 23/11/2024 08:26, Pancho wrote:
> On 11/23/24 01:41, Lawrence D'Oliveiro wrote:

>> I’m pretty sure it has been used commercially, back in the 1980s or
>> so, maybe even the 1990s.
>
> Probably, just as some people program in Haskell or Prolog.
>
It has occasionally. Back in the day when I scanned job adverts 'must be
proficient in smalltalk has been seen.

But the reason why the majority of work was 'experienced in C Unix and
vi' was on the job was because it was positive feedback loop. The more
people used it the more people learnt it in order to maintain and extend it.

--
The lifetime of any political organisation is about three years before
its been subverted by the people it tried to warn you about.

Anon.

On 23/11/2024 08:52, Pancho wrote:
> I genuinely like OO design. It is the way I naturally think of program
> structure. It maps well to designing service orientated architectures.

Oh, in terms of keeping things that are closely related in the same
place syntactically, its great.

But the syntax so used is weird arcane and occasionally crap.
You don't need C++ to write object oriented code in.

And thereby hangs the problem. Its Yet Another Computer Scientist
creating a language that tries to enforce an approach, rather than
providing tools to make such an approach possible *if you want it*.

far too much stress on the language and none at all on the software
*engineering* approach of problem analysis, decomposition,
documentation, construction of code and subsequent stress testing.

--
I was brought up to believe that you should never give offence if you
can avoid it; the new culture tells us you should always take offence if
you can. There are now experts in the art of taking offence, indeed
whole academic subjects, such as 'gender studies', devoted to it.

Sir Roger Scruton

On 23/11/2024 09:05, Pancho wrote:
> On 11/23/24 07:44, Lawrence D'Oliveiro wrote:
>> On Sat, 23 Nov 2024 07:09:06 GMT, Charlie Gibbs wrote:
>>
>>> So it's the good old-fashioned way - free
>>> each allocation one by one and hope you don't forget one.
>>
>> One thing that helps is that free(3) is idempotent:
>
> It isn't idempotent.
>
>> calling it on a NULL
>> pointer is a harmless no-op,
>
> OK it is idempotent on NULL, but not in general.
>
As I discovered to my shame. freeing the same pointer twice is not
harmless.

--
For every complex problem there is an answer that is clear, simple, and
wrong.

H.L.Mencken

On 23/11/2024 10:16, Richard Kettlewell wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> On Sat, 23 Nov 2024 07:09:06 GMT, Charlie Gibbs wrote:
>>> So it's the good old-fashioned way - free
>>> each allocation one by one and hope you don't forget one.
>>
>> One thing that helps is that free(3) is idempotent:
>
> It is not. Freeing the same non-null pointer twice is a bug (and a
> common source of vulnerabilities).
>
>> calling it on a NULL pointer is a harmless no-op, so there is no need
>> to check for NULL before calling it. So my standard technique
>> (simplifying somewhat) is
>
> ‘free() and null out all copies of the pointer that can ever reach
> free() in the future’ is idempotent, if you can get it right (which is
> usually not too hard in a well-organized program).
>
I had to read that three times to understand what you said there.

A comma after the first free() would have helped.:-)

Otherwise +100

--
For every complex problem there is an answer that is clear, simple, and
wrong.

H.L.Mencken

On 2024-11-23, Pancho <Pancho.Jones@proton.me> wrote:

> On 11/23/24 07:09, Charlie Gibbs wrote:
>
>> On 2024-11-22, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>>> On Fri, 22 Nov 2024 18:53:28 GMT, Charlie Gibbs wrote:
>>>
>>>> All my programs contain a routine called quit_cleanup(); it takes a
>>>> single argument, which is either an error message or NULL.
>>>> It frees all allocated memory, closes any open files, etc.
>>>
>>> But all that is unnecessary if your program is terminating anyway.
>>>
>>> In *nix C code, a common convention is
>>>
>>> if («call failed»)
>>> {
>>> perror(«doing what»);
>>> exit(«nonzero error code»);
>>> } /*if*/
>>>
>>> <https://manpages.debian.org/3/perror.3.en.html>
>>
>> Perhaps, but I'm a belt-and-suspenders guy - I like
>> to explicitly free everything come hell or high water.
>
> I can see that is nice, to understand what you have,
> but it sounds like hard work.

It's not, actually. Think of it like a mechanic methodically
putting all his tools back where they belong in the box when
he's done, rather than leaving them lying around the shop.

> However there are some resource you do need to explicitly
> free/release/close, some database locks for instance.

Therefore, why go the bother of having to memorize which
resources you have to explicity free, and which ones you
don't? Get into the habit of freeing them all - you might
avoid tedious debugging sessions when you forget which is which.

--
/~\ Charlie Gibbs | Growth for the sake of
\ / <cgibbs@kltpzyxm.invalid> | growth is the ideology
X I'm really at ac.dekanfrus | of the cancer cell.
/ \ if you read it the right way. | -- Edward Abbey

On 2024-11-23, Richard Kettlewell <invalid@invalid.invalid> wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Sat, 23 Nov 2024 07:09:06 GMT, Charlie Gibbs wrote:
>>
>>> So it's the good old-fashioned way - free
>>> each allocation one by one and hope you don't forget one.
>>
>> One thing that helps is that free(3) is idempotent:
>
> It is not. Freeing the same non-null pointer twice is a bug (and a
> common source of vulnerabilities).
>
>> calling it on a NULL pointer is a harmless no-op, so there is no need
>> to check for NULL before calling it. So my standard technique
>> (simplifying somewhat) is
>
> ‘free() and null out all copies of the pointer that can ever reach
> free() in the future’ is idempotent, if you can get it right (which is
> usually not too hard in a well-organized program).

+1

--
/~\ Charlie Gibbs | Growth for the sake of
\ / <cgibbs@kltpzyxm.invalid> | growth is the ideology
X I'm really at ac.dekanfrus | of the cancer cell.
/ \ if you read it the right way. | -- Edward Abbey

On 2024-11-23, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> On Sat, 23 Nov 2024 07:09:11 GMT, Charlie Gibbs wrote:
>
>> On 2024-11-22, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>>> On Fri, 22 Nov 2024 18:53:28 GMT, Charlie Gibbs wrote:
>>>
>>>> All my programs contain a routine called quit_cleanup(); it takes a
>>>> single argument, which is either an error message or NULL.
>>>> It frees all allocated memory, closes any open files, etc.
>>>
>>> But all that is unnecessary if your program is terminating anyway.
>>
>> Perhaps, but I'm a belt-and-suspenders guy - I like to explicitly free
>> everything come hell or high water.
>
> That actually slows down program termination.

The microsecond or two that is wasted is far less than the
debugging time needed when a shortcut goes wrong. And who
knows, you might someday port the program to a different
environment (hardware, OS, or even language) where the
rules are just different enough to cause lots of headaches.

Different strokes for different folks. Some people like to
write the equivalent of a Ferrari, that goes really fast but
is finicky and might lose a wheel if it hits rough terrain.
My code is more like an ATV: a bit slower, not nearly as
pretty, but it'll go anywhere and not break down when things
aren't perfect.

--
/~\ Charlie Gibbs | Growth for the sake of
\ / <cgibbs@kltpzyxm.invalid> | growth is the ideology
X I'm really at ac.dekanfrus | of the cancer cell.
/ \ if you read it the right way. | -- Edward Abbey

On 2024-11-23, The Natural Philosopher <tnp@invalid.invalid> wrote:

> On 23/11/2024 09:05, Pancho wrote:
>
>> On 11/23/24 07:44, Lawrence D'Oliveiro wrote:
>>
>>> On Sat, 23 Nov 2024 07:09:06 GMT, Charlie Gibbs wrote:
>>>
>>>> So it's the good old-fashioned way - free
>>>> each allocation one by one and hope you don't forget one.
>>>
>>> One thing that helps is that free(3) is idempotent:
>>
>> It isn't idempotent.
>>
>>> calling it on a NULL
>>> pointer is a harmless no-op,
>>
>> OK it is idempotent on NULL, but not in general.
>>
> As I discovered to my shame. freeing the same pointer twice is not
> harmless.

And, IIRC, trying to fclose() a NULL file pointer doesn't work
too well. I like to use a consistent technique that works across
all sorts of resources: memory, file pointers, window handles,
menu handles, etc. But that's just me being too lazy to memorize
a bunch of different cases when a single consistent technique
will work anywhere with neglegible overhead.

--
/~\ Charlie Gibbs | Growth for the sake of
\ / <cgibbs@kltpzyxm.invalid> | growth is the ideology
X I'm really at ac.dekanfrus | of the cancer cell.
/ \ if you read it the right way. | -- Edward Abbey

On Sat, 23 Nov 2024 08:52:20 +0000, Pancho wrote:

> Did it?, there was Objective C too.

I don't know anything about Objective C. That was sort of an Apple thing
and I've never worked on Apple hardware. I'm not trying to start a
religious war but nobody ever wanted to pay me for developing on Apple.

On Sat, 23 Nov 2024 11:16:09 +0000, The Natural Philosopher wrote:

> On 23/11/2024 04:57, 186282@ud0s4.net wrote:
>> On 11/22/24 12:51 AM, Lawrence D'Oliveiro wrote:
>>> On Thu, 21 Nov 2024 20:19:55 -0700, Don_from_AZ wrote:
>>>
>>>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>>>
>>>>> On 21/11/2024 07:20, 186282@ud0s4.net wrote:
>>>>>>
>>>>>> I take it you're also not a fan of Perl  🙂
>>>>>
>>>>> Perfectly Execrable Rubbish Language
>>>>
>>>> I've heard it called:
>>>>
>>>>    "Pathologically Eclectic Rubbish Lister"
>>>
>>> It changed the meaning of the term “high-level language” forever.
>>
>>
>>   Well ... glad to see my opinion of Perl is not unique  :-)
>>
>>   Way back I bought the usual "Learn Perl" book with the camel on the
>>   front. About two chapters in I said "WHY ???".
>>
> I just saw the type of people who created enormous scripts in it, and
> thought 'total wankers' They typically read instruction manuals as a
> hobby...
>
> If a script gets that big it should be in a different language
> altogether.

We had a couple of implementers who used Perl to automate their tasks.
Programming disavowed all knowledge of them. As the years went by and the
original people left they were handed down to successive generations as
some sort of magic tools.

On Sat, 23 Nov 2024 11:31:51 +0000, The Natural Philosopher wrote:

> On 23/11/2024 09:05, Pancho wrote:
>> On 11/23/24 07:44, Lawrence D'Oliveiro wrote:
>>> On Sat, 23 Nov 2024 07:09:06 GMT, Charlie Gibbs wrote:
>>>
>>>> So it's the good old-fashioned way - free each allocation one by one
>>>> and hope you don't forget one.
>>>
>>> One thing that helps is that free(3) is idempotent:
>>
>> It isn't idempotent.
>>
>>> calling it on a NULL pointer is a harmless no-op,
>>
>> OK it is idempotent on NULL, but not in general.
>>
> As I discovered to my shame. freeing the same pointer twice is not
> harmless.

Our legacy software was developed on AIX. As it was moved to Linux we
found that AIX had a much better sense of humor about accessing null
pointers and other indiscretions.

On 11/23/2024 4:16 AM, The Natural Philosopher wrote:
> On 23/11/2024 04:57, 186282@ud0s4.net wrote:
>> On 11/22/24 12:51 AM, Lawrence D'Oliveiro wrote:
>>> On Thu, 21 Nov 2024 20:19:55 -0700, Don_from_AZ wrote:
>>>
>>>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>>>
>>>>> On 21/11/2024 07:20, 186282@ud0s4.net wrote:
>>>>>>
>>>>>> I take it you're also not a fan of Perl  🙂
>>>>>
>>>>> Perfectly Execrable Rubbish Language
>>>>
>>>> I've heard it called:
>>>>
>>>>    "Pathologically Eclectic Rubbish Lister"
>>>
>>> It changed the meaning of the term “high-level language” forever.
>>
>>
>>    Well ... glad to see my opinion of Perl is
>>    not unique  :-)
>>
>>    Way back I bought the usual "Learn Perl" book with
>>    the camel on the front. About two chapters in I
>>    said "WHY ???".
>>
> I just saw the type of people who created enormous scripts in it, and
> thought 'total wankers' They typically read instruction manuals as a
> hobby...
>
> If a script gets that big it should be in a different language altogether.
>
There was a time when Python was still at version 1.something, Ruby
hadn't been introduced, so the choices were limited to shells (like sh
and its relatives), compiled languages like C, and Perl. Perl did the
job, and it was enough like C to seem familiar, so here we are.

It could have been worse.

Louis

On 11/23/24 19:16, Charlie Gibbs wrote:
> On 2024-11-23, Pancho <Pancho.Jones@proton.me> wrote:
>
>> On 11/23/24 07:09, Charlie Gibbs wrote:
>>
>>> On 2024-11-22, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>
>>>> On Fri, 22 Nov 2024 18:53:28 GMT, Charlie Gibbs wrote:
>>>>
>>>>> All my programs contain a routine called quit_cleanup(); it takes a
>>>>> single argument, which is either an error message or NULL.
>>>>> It frees all allocated memory, closes any open files, etc.
>>>>
>>>> But all that is unnecessary if your program is terminating anyway.
>>>>
>>>> In *nix C code, a common convention is
>>>>
>>>> if («call failed»)
>>>> {
>>>> perror(«doing what»);
>>>> exit(«nonzero error code»);
>>>> } /*if*/
>>>>
>>>> <https://manpages.debian.org/3/perror.3.en.html>
>>>
>>> Perhaps, but I'm a belt-and-suspenders guy - I like
>>> to explicitly free everything come hell or high water.
>>
>> I can see that is nice, to understand what you have,
>> but it sounds like hard work.
>
> It's not, actually. Think of it like a mechanic methodically
> putting all his tools back where they belong in the box when
> he's done, rather than leaving them lying around the shop.
>

It's more like carefully packing up a set of disposable tools into their
disposable box, and then throwing the whole lot in the bin.

>> However there are some resource you do need to explicitly
>> free/release/close, some database locks for instance.
>
> Therefore, why go the bother of having to memorize which
> resources you have to explicity free, and which ones you
> don't? Get into the habit of freeing them all - you might
> avoid tedious debugging sessions when you forget which is which.
>

It's hard for me to remember, because I'm so used to C# IDisposable
"using" blocks, Java "try-with-resources", even try/catch/finally, etc.
I see even C++ has "Resource Acquisition Is Initialization".

My memory is that in practice you normally want to hold critical
(unmanaged) resources open for as short at time as possible, and hence
you tend to deal with disposal locally to allocation rather than having
long lived stuff that needs to be cleaned on exit. But that is just a
gut felling, I can't really remember enough to talk sensibly on the
subject. I'm sure there are usecases where this doesn't in apply, but in
general I think it does.

On Sat, 23 Nov 2024 08:26:26 +0000, Pancho wrote:

> On 11/23/24 01:41, Lawrence D'Oliveiro wrote:
>>
>> “Metaclasses” were just a bit of a hack to implement what Python would
>> call “classmethods”.
>
> I think the Smalltalk idea of treating classes as objects, is the
> opposite of a hack.

That is an elegant idea, but I don’t think it’s what Smalltalk did -- not
with metaclasses, anyway. If you look at the draft (abandoned) ANSI
Smalltalk spec <https://github.com/johnwcowan/smalltalk-standard>, it says
“because classes are not specified as the implementers of behavior,
metaclasses are not needed to provide the behavior of class objects”.

This is in contrast to Python, where metaclasses are very much an integral
part of the behaviour of classes.

> I would say C++ static methods and static variables are a hack.

They are there to provide access to the innards of a private/protected
class, without having to go through instances of that class. In a language
like Python, which doesn’t bother constraining visibility to the innards
of a class, they are just a convenience for grouping purposes, nothing
more.

Much more useful are classmethods, which get passed the class object
itself as an argument. But that’s only possible in a dynamic language, not
like C++, or even Java or C♯.

> C# type reflection is a hack.

Is that like the convoluted “reflection” API in Java? (Mind you, most APIs
in Java seem to be convoluted ...)

> Just as value types are a hack in C#. Things that
> are sensible for performance reasons, but that add complexity.

Presumably, like Java, these mechanisms are there to avoid the need for
the services of the full language compiler at runtime.

> It was easy to see where Python metaclasses came from.

Not really. Which language used metaclasses to instantiate classes before
Python?

Python also does multiple inheritance. And it does it quite nicely,
benefiting from lessons learned in earlier attempts at “linearization”
(coming up with a consistent and minimally-surprising method resolution
order across all the base classes).

On Sat, 23 Nov 2024 11:20:59 +0000, The Natural Philosopher wrote:

> I dislike the use of malloc and friends in daemons that run forever.

It does take some discipline to make sure allocations are managed
properly. Structured programming is your friend.

On Sat, 23 Nov 2024 19:16:04 GMT, Charlie Gibbs wrote:

> On 2024-11-23, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> On Sat, 23 Nov 2024 07:09:11 GMT, Charlie Gibbs wrote:
>>
>>> On 2024-11-22, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>
>>>> On Fri, 22 Nov 2024 18:53:28 GMT, Charlie Gibbs wrote:
>>>>
>>>>> All my programs contain a routine called quit_cleanup(); it takes a
>>>>> single argument, which is either an error message or NULL.
>>>>> It frees all allocated memory, closes any open files, etc.
>>>>
>>>> But all that is unnecessary if your program is terminating anyway.
>>>
>>> Perhaps, but I'm a belt-and-suspenders guy - I like to explicitly free
>>> everything come hell or high water.
>>
>> That actually slows down program termination.
>
> The microsecond or two that is wasted is far less than the debugging
> time needed when a shortcut goes wrong.

Actually, thinking about it, there are some things -- shared memory
sections come to mind -- that are not automatically freed when a process
terminates. But everything else -- memory, open files, network connections
-- will go away automatically.

If you have those persistent things that you want to clean up, your
technique won’t be reliable anyway.

On Sat, 23 Nov 2024 10:16:46 +0000, Richard Kettlewell wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>> One thing that helps is that free(3) is idempotent:
>
> It is not. Freeing the same non-null pointer twice is a bug (and a
> common source of vulnerabilities).

That’s not what I meant by “idempotent”, and that particular case is easy
to catch anyway, and glibc does so by default. See
<https://manpages.debian.org/3/mallopt.3.en.html>.

On Sat, 23 Nov 2024 19:16:06 GMT, Charlie Gibbs wrote:

> And, IIRC, trying to fclose() a NULL file pointer doesn't work too well.

Yes, that is an irritation. You need to create your own wrapper that
ignores a “null” file descriptor value (e.g. -1).

But then, you often need to create a wrapper object for managing file I/O
anyway, and it is normally the object disposal routine that closes the
file descriptors in this case. So if it is passed a NULL pointer to
dispose, it doesn’t need to close any file descriptor or do anything else.

On Sat, 23 Nov 2024 11:16:09 +0000, The Natural Philosopher wrote:

> I just saw the type of people who created enormous scripts in [Perl],
> and thought 'total wankers' They typically read instruction manuals as a
> hobby...

It’s amazing what you can find out when you RTFM. There was a command just
the other day, in comp.lang.python I think it was, where somebody said
“I’ve been using Python for 20 years, and I never knew that”.

On 11/23/24 21:36, Lawrence D'Oliveiro wrote:
> On Sat, 23 Nov 2024 08:26:26 +0000, Pancho wrote:
>
>> On 11/23/24 01:41, Lawrence D'Oliveiro wrote:
>>>
>>> “Metaclasses” were just a bit of a hack to implement what Python would
>>> call “classmethods”.
>>
>> I think the Smalltalk idea of treating classes as objects, is the
>> opposite of a hack.
>
> That is an elegant idea, but I don’t think it’s what Smalltalk did -- not
> with metaclasses, anyway. If you look at the draft (abandoned) ANSI
> Smalltalk spec <https://github.com/johnwcowan/smalltalk-standard>, it says
> “because classes are not specified as the implementers of behavior,
> metaclasses are not needed to provide the behavior of class objects”.
>

The full quote...

"Class objects have no special significance other than having names and
having behaviors and state distinct from that of
their associated instance objects. Unlike classic Smalltalk definitions
[Goldberg83], they are not defined as being the
containers or implementers of their instances' behavior. The techniques
used to implement the behavior of objects is left to
the implementers. Finally, because classes are not specified as the
implementers of behavior, metaclasses are not needed
to provide the behavior of class objects. "

I learnt Smalltalk nearly 40 years ago, needless to say I learnt from
the Goldberg Smalltalk-80 bluebook, not the current spec.

To be honest, I don't have an idea what classes not being the
implementers of instance behaviour means. Where is instance behaviour
implemented?

> This is in contrast to Python, where metaclasses are very much an integral
> part of the behaviour of classes.
>
>> I would say C++ static methods and static variables are a hack.
>
> They are there to provide access to the innards of a private/protected
> class,

No, C++ static means class method or class variable.

> without having to go through instances of that class. In a language
> like Python, which doesn’t bother constraining visibility to the innards
> of a class, they are just a convenience for grouping purposes, nothing
> more.
>
> Much more useful are classmethods, which get passed the class object
> itself as an argument. But that’s only possible in a dynamic language, not
> like C++, or even Java or C♯.
>
>> C# type reflection is a hack.
>
> Is that like the convoluted “reflection” API in Java? (Mind you, most APIs
> in Java seem to be convoluted ...)
>

Dunno, I very rarely used it. It was more for things like generic
serialisation to JSON.

>> Just as value types are a hack in C#. Things that
>> are sensible for performance reasons, but that add complexity.
>
> Presumably, like Java, these mechanisms are there to avoid the need for
> the services of the full language compiler at runtime.
>

No they are there for performance, because you don't want to have to do
a malloc and instance initialisation for every number you use.

>> It was easy to see where Python metaclasses came from.
>
> Not really. Which language used metaclasses to instantiate classes before
> Python?
>

erm!, erm! I know this one... Smalltalk. Smalltalk-80 if you want to be
picky.

> Python also does multiple inheritance. And it does it quite nicely,
> benefiting from lessons learned in earlier attempts at “linearization”
> (coming up with a consistent and minimally-surprising method resolution
> order across all the base classes).

Yeah, we discussed this in the past. I'm totally unconvinced of the
desirability of complex multiple inheritance linearization.

I'm actually quite unconvinced by Python.

On Sat, 23 Nov 2024 23:48:59 +0000, Pancho wrote:

> To be honest, I don't have an idea what classes not being the
> implementers of instance behaviour means. Where is instance behaviour
> implemented?

From further up: “A behavior is the set of methods used by an object to
respond to messages”. Since a class itself has no such “behavior”, it
doesn’t need to be an instance of anything, unlike Python.

>>> I would say C++ static methods and static variables are a hack.
>>
>> They are there to provide access to the innards of a private/protected
>> class,
>
> No, C++ static means class method or class variable.

There are no “class methods” or “class variables” as such in C++: in C
terms, they have “static linkage”. The “class” part is just a visibility
restriction.

>>> Just as value types are a hack in C#. Things that are sensible for
>>> performance reasons, but that add complexity.
>>
>> Presumably, like Java, these mechanisms are there to avoid the need for
>> the services of the full language compiler at runtime.
>>
> No they are there for performance, because you don't want to have to do
> a malloc and instance initialisation for every number you use.

Ah, like the distinction between “primitive types” and “reference types”
in Java.

Python manages to avoid this arbitrary separation: “int”, “float”, “str”,
“dict” etc are builtin types, and they are classes almost exactly like
classes you define yourself; and in particular you can subclass them.

>> Python also does multiple inheritance. And it does it quite nicely,
>> benefiting from lessons learned in earlier attempts at “linearization”
>> (coming up with a consistent and minimally-surprising method resolution
>> order across all the base classes).
>
> Yeah, we discussed this in the past. I'm totally unconvinced of the
> desirability of complex multiple inheritance linearization.

It is useful, for example, for creating enumerations of fixed instances of
some particular base class. You inherit from both your particular base
class as well as the generic “enum.Enum” base class, to get suitable
properties of both.

> I'm actually quite unconvinced by Python.

Python manages to provide a small, powerful language core that includes
features that, for example, Java and C♯ had to leave out: lexical binding,
functions and classes as first-class objects, operator overloads,
arbitrary-precision integers, list comprehensions, dictionary and set
expressions, descriptors, metaclasses ... this then allows for library
modules to build on this core to provide powerful facilities in the form
of “domain-specific (sub)languages” (DSLs) that are specialized to
particular problem areas.

For example, you don’t need “generics” or “templates”, à la Java/C++ etc,
because you can define a “class factory” function that constructs new
classes at runtime.

On 11/23/24 6:16 AM, The Natural Philosopher wrote:
> On 23/11/2024 04:57, 186282@ud0s4.net wrote:
>> On 11/22/24 12:51 AM, Lawrence D'Oliveiro wrote:
>>> On Thu, 21 Nov 2024 20:19:55 -0700, Don_from_AZ wrote:
>>>
>>>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>>>
>>>>> On 21/11/2024 07:20, 186282@ud0s4.net wrote:
>>>>>>
>>>>>> I take it you're also not a fan of Perl  🙂
>>>>>
>>>>> Perfectly Execrable Rubbish Language
>>>>
>>>> I've heard it called:
>>>>
>>>>    "Pathologically Eclectic Rubbish Lister"
>>>
>>> It changed the meaning of the term “high-level language” forever.
>>
>>
>>    Well ... glad to see my opinion of Perl is
>>    not unique  :-)
>>
>>    Way back I bought the usual "Learn Perl" book with
>>    the camel on the front. About two chapters in I
>>    said "WHY ???".
>>
> I just saw the type of people who created enormous scripts in it, and
> thought 'total wankers' They typically read instruction manuals as a
> hobby...
>
> If a script gets that big it should be in a different language altogether.

Well .... MAYbe they caught "The Joy Of Perl" - though
it's hard to imagine such a thing ......

I've seen huge scripts in Bash as well. There was someone
in these groups who always said they didn't need 'C' or
Python or whatever because, no matter, they could and
wanted to do it with Bash and any other approach proved
you were stupid and incompetent.

But yea ... there soon comes a point where you ought
to implement in a better, more proper, language.
Whatever it is, at least use Python if for no other
reason than that it's generally comprehensible. They
kept expanding Bash with more obscure squiggles and
bars and "two spaces, not one" almost to the point
where you may as well be using BrainFuck or similar.

The biggest Bash script I ever did was about 300 lines,
for backing up all the drives shared on the system. The
saving point was that what I was doing was very 'modular',
maybe 25 lines for each share, almost perfectly repeated
on down the tree. Confirm share exists, try to create
a tempshare, confirm that exists, read file, encrypt
file, fix-up the tree, transfer file ..." that
sort of thing. Copy, tweak and insert module if some new
share had been made.

But I soon re-did it in Python. MUCH better.

> It reminds me of a cartoon picture of a nerd saying 'I use a Unix based
> operating system. My computers crash about as often as I get laid'

It's tough life being a nerd.

On 11/23/24 12:31 AM, Lawrence D'Oliveiro wrote:
> On Fri, 22 Nov 2024 23:57:58 -0500, 186282@ud0s4.net wrote:
>
>> Way back I bought the usual "Learn Perl" book with the camel on the
>> front. About two chapters in I said "WHY ???".
>
> Perl was designed by a bunch of clever people, who understood the sort of
> features they wanted to add. The trouble is, they did it in kind of an ad-
> hoc way, so the syntax, like Topsy, “just growed”.

"Feature creep" ... you keep having to figure out how
to jam new stuff into the middle of the old stuff until
you just have a total MESS. That's when you're supposed
to totally re-do, or abandon, but Perl was already too
well 'established' so they were stuck with what/how '
came before.

As the Frog Guy said - "It's a TRAP !"

"Organic evolution" is fine - but sometimes you wind up
with a platypus.

On Sat, 23 Nov 2024 20:23:47 -0500, 186282@ud0s4.net wrote:

> "Feature creep" ... you keep having to figure out how to jam new
> stuff into the middle of the old stuff until you just have a total
> MESS. That's when you're supposed to totally re-do, or abandon, but
> Perl was already too well 'established' so they were stuck with
> what/how ' came before.

Which is where the Perl 6 project came in. But it took so long to come to
fruition, and was such a radical change, that it was decided to stop
calling it “Perl” altogether, and make it an entirely new language --
“Raku”, I think is the name now.

On Sat, 23 Nov 2024 23:48:59 +0000, Pancho wrote:

> I'm actually quite unconvinced by Python.

For many things it provides a convenient level of abstraction if
performance isn't a major concern. It's not so much the language itself as
that the language has become very popular and the range of modules has
greatly expanded.

For example, the Esri Python API makes common GIS manipulations less
painful than using C++. Similarly if you're into machine learning while
TensorFlow and PyTorch have C++ bindings almost all tutorials will use
Python. In data science Python is starting to overtake R and is actually
faster for some operations. For REST APIs you have flask, django, and
several other frameworks.

For embedded work as Arm microprocessors have become the norm and SRAM has
greatly increased a Python interpreter, either MicroPython or
CircuitPython can be loaded on the device. Again you can work in C++ and
get greater speed and control but it comes at a cost. Controlling a servo
with PWM is easy in Python. Doing it in C++ means you need to determine
the slice and channel for the GPIO pin, decide what to load into the
counter to get the desired frequency from the 125 MHz clock,determine if
you need to use the divider for lower frequencies, and make other
decisions.

Using Python means you get uniformity across many disciplines and it's
good enough for most things. It could have been Perl if it hadn't gotten
stuck in the tar pits, or Ruby, or Go but from whatever twist of fate
occurred it was Python.