On Mon, 25 Nov 2024 01:41:07 -0500, 186282@ud0s4.net wrote:

> The eye doesn't spot indents nearly was well as hard delimiters.

I use both.

On Mon, 25 Nov 2024 04:40:03 -0000 (UTC), candycanearter07 wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 21:40 this Saturday (GMT):
>>
>> 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.
>
> Does it get freed up when the other processes that have it open also
> close it, or is it stuck until shutdown?

POSIX shared memory sections stay in existence until deletion, or system
shutdown.

<https://manpages.debian.org/3/shm_unlink.3.en.html>

On 11/24/24 9:41 PM, rbowman wrote:
> On Sun, 24 Nov 2024 19:35:57 -0500, 186282@ud0s4.net wrote:
>
>> I never learned it until M$ started sneaking it into their OS junk.
>> "What's a .py ???". The good side of that is that it was right near
>> the v2 -> v3 transition and I decided to learn the 'new and
>> improved'.
>
> Good timing. Esri's ArcPy up until Esri 11 was 2.7 so I stayed with it for
> non-Esri scripts. The transition from 10.8 to 11 was bloody, not only for
> going to Python 3.8. Being the 500 lb. gorilla in the GIS field they could
> say "Yeah, this is going to break a lot of stuff you've been doing for
> years. Suck it up." Like Windows 10, Esri 10.8 went on extended life
> support.
>
> I don't think it was a giant conspiracy but several different applications
> I dealt with went from 10.x to 11.x about the same time leading to some
> confusion. "Which 11 are we talking about?"

The v2->v3 transition wasn't THAT horrible. Indeed
most smaller v2 apps only need the print()s fixed up.
More complex apps, yea, some annoying/confusing
changes in function params and such - but still not
all THAT bad.

They PROMISE that p4 will involve almost no re-writing,
the fixes are internal performance changes instead.

ANYway ... Python is kinda nice, easy to read/understand
and can now do almost anything. You can sense a little 'C'
and a little FORTRAN, in there. If you need SPEED though,
go to a proper compiled lang. 'C' does bit-oriented stuff
better, so it's maybe THE choice for exotic coms apps.
Parent/child servers are 'traditionally' in 'C'.

Pascal is sweeter, IMHO - loved it since the multi-pass
compiler days (still have one of those in a DOS VM and
it WORKS). Hey, some langs "just speak" to you .... I've
made as many Free Pascal/Lazarus apps as 'C' apps.

But I still can't envision Perl-lovers.

Hmmm ... just wondering ... what would an 'AI' make
of "The Joy Of Joy" :-)

On 11/24/24 5:25 AM, The Natural Philosopher wrote:
> On 23/11/2024 23:48, Pancho wrote:
>> 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 have already completely lost the plot. And the will to live.

I understand. Just figure that OO means compounded
calls with lots of dots in 'em. JS takes that to
the ultimate extreme - and with LONG names for
all the little 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?
>>
> Mate I havent a clue what *any* of it means. It's classic compSci
> Gobbledygook.

Well, sometimes it DOES sound like that ...

Better to think in terms of "what you need
to DO", functional rather than 'ideological'.

Many langs offer good paths. For the "what"
that may pare down to just a few. Everyone
has "a better plan" - but in the end it's
down to "how easily can I do what I want ?".

Hey, MIGHT be FORTRAN or COBOL - who knows ?
Whatever makes yer synapses tingle.

>>
>> I'm actually quite unconvinced by Python.

Well, TRY it a bit - in the end you'll like it.
Easy to read, nothing TOO horrible. Libs for
*everything* these days. Good docs.

Was a strict 'C'/Pascal guy for a long time - but
now I always at least proto in Python. For many apps
where speed isn't paramount just LEAVE it in Python.

On 11/24/24 8:46 PM, rbowman wrote:
> On Sun, 24 Nov 2024 21:23:17 +0000, Pancho wrote:
>
>> I'm just making the point that it easier to understand OO if you start
>> with a simple model. Just as it is easy to understand aspects of C if
>> you know an assembler.
>
> https://go.dev/doc/faq#Is_Go_an_object-oriented_language
>
> Just saying...

Note though ... almost NO compu-geeks these days
know ASM. As such they will not be enlightened
about 'C' in that fashion. Today's geeks mostly
start with Python and MIGHT go a little further,
likely Rust.

Just sayin'

Things changed between 1984 and 2024.

We Old Guys can kinda look at 'C' and see
the ASM it's going to become. Later gens
do not.

On 24/11/2024 21:06, D wrote:
>
>
> On Sun, 24 Nov 2024, Rich wrote:
>
>> 186282@ud0s4.net <186283@ud0s4.net> wrote:
>>>   Whatever it is, at least use Python if for no other
>>>   reason than that it's generally comprehensible.
>>
>> Oh good lord no.  The amount for which you hate Perl is the amount that
>> I despise Python.
>>
>
> I see no other way to resolve this but for you two to fight to the death.

Interpreters, at dawn..
--
"It is an established fact to 97% confidence limits that left wing
conspirators see right wing conspiracies everywhere"

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> Richard Kettlewell wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> 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>.
>>
>> Glibc’s double free detection is heuristic, not 100% reliable.

(It’s documented as heuristic in the Glibc internals documentation and a
glance at the implementation does seem to agree with that.)

> If that were true, the examples on the man page wouldn’t work.

No, that doesn’t follow. “Not 100% reliable” doesn’t mean specific
examples don’t work.

Perhaps you’re using private definitions of words that nobody else
shares again?

--
https://www.greenend.org.uk/rjk/

"186282@ud0s4.net" <186283@ud0s4.net> writes:
> Note though ... almost NO compu-geeks these days
> know ASM. As such they will not be enlightened
> about 'C' in that fashion. Today's geeks mostly
> start with Python and MIGHT go a little further,
> likely Rust.
>
> Just sayin'
>
> Things changed between 1984 and 2024.
>
> We Old Guys can kinda look at 'C' and see
> the ASM it's going to become. Later gens
> do not.

It’s a common mental model for C, but it’s not accurate. The language
spec leaves an awful lot of wiggle room for the generated code to
diverge from the “I can see the assembler” model and compilers take full
advantage of it.

A simple example, based on a historical Linux kernel vulnerability
(CVE-2009-1897):

int f(int *xp) {
int x = *xp;
if(!xp)
return 0;
return x;
}

In the “assembler” model it would compile to something like this:

mov eax,dword ptr [rdi]
cmp rdi,0
jne L1
mov eax,0
L1:
ret

In fact at -O2 the test on xp is optimized out:

mov eax, dword ptr [rdi]
ret

https://godbolt.org/z/caKeTMTxf to play further.

--
https://www.greenend.org.uk/rjk/

On Mon, 25 Nov 2024, rbowman wrote:

> On Sun, 24 Nov 2024 21:29:05 +0000, Pancho wrote:
>
>> On 11/24/24 05:01, rbowman wrote:
>>
>>> 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.
>>
>> My niece worked on Python at Twitter. She wasn't complimentary about it
>> either. She then moved onto Go. But that was doing big web-server stuff.
>> Large scale Docker setups, maybe Kubernetes.
>
> Horses for courses. I tasked a new hire with developing an interface to
> Spidertracks.
>
> https://www.spidertracks.com/
>
> I gave him the requirements but didn't specify a language so he did it
> with Go. No big deal other than having to set up a Go environment on the
> build machine. Go is what you would expect from three C programmers who
> hate C++ and I mean that it a good way. Not sure why they put the
> parameter type after the parameter but I can live with that. It's hanging
> in there:
>
> https://www.tiobe.com/tiobe-index/
>
> for whatever worth the index has.

I tried a bit of go, and setting up the environment as an amateur was dead
simple.

Is this also the case for professionals?

On Mon, 25 Nov 2024, rbowman wrote:

> On Sun, 24 Nov 2024 22:07:40 +0100, D wrote:
>
>> I dabbled a bit in perl out of curiosity and I find the following two
>> points to be in its favour:
>>
>> 1. Backwards compatibility. Much better than python.
>
> Well, that's true. Looking over at the bookshelf I see 'Programming the
> Perl DBI' from 2000. It probably works just as well in 5.40.0 as it did in
> 5.6.0.
>
> https://www.oreilly.com/library/view/programming-the-perl/1565926994/
>
> There isn't a newer version. That's remarkable for close to 25 years. Most
> of my other books from 2000 are suitable for propping up mismatched table
> legs.
>
> I did appreciate the concept of a uniform DBI with specific DBDs in the
> back end.
>
>> 2. The built in documentation.
>
> Python offers a lot of built in documentation, assuming the modules follow
> the PEP guidelines.

The problem with python is the quality of the ecosystem and the 2 to 3
shift. I find the quality of python libraries lower than in perl. But I
imagine that is due to there simply being more of them, and that it is a
"live" language. Perhaps I found the quality better in perl, since the
libraries that remain are old and mature.

On Mon, 25 Nov 2024, 186282@ud0s4.net wrote:

> On 11/24/24 7:36 PM, Lawrence D'Oliveiro wrote:
>> On Sun, 24 Nov 2024 19:35:57 -0500, 186282@ud0s4.net wrote:
>>
>>> Do kinda pref "{ }" or "begin end" over the dangling depth thing ...
>>> get six or eight levels into something and it's a total bitch to spot
>>> what's inside what without using comments.
>>
>> So use the comments. That’s what I do.
>
> Only good way ...
>
> Not a killer, but kinda annoying. The eye doesn't
> spot indents nearly was well as hard delimiters.
>

You can have indents _and_ delimiters for the ultimate in eye spotting
capability! ;)

On Mon, 25 Nov 2024, The Natural Philosopher wrote:

> On 24/11/2024 21:06, D wrote:
>>
>>
>> On Sun, 24 Nov 2024, Rich wrote:
>>
>>> 186282@ud0s4.net <186283@ud0s4.net> wrote:
>>>>   Whatever it is, at least use Python if for no other
>>>>   reason than that it's generally comprehensible.
>>>
>>> Oh good lord no.  The amount for which you hate Perl is the amount that
>>> I despise Python.
>>>
>>
>> I see no other way to resolve this but for you two to fight to the death.
>
> Interpreters, at dawn..
>

Exactly! And if I could just get the information about how tall the
combatants are, I can prepare some beautiful coffins!

On 11/24/24 22:37, Lawrence D'Oliveiro wrote:
> On Sun, 24 Nov 2024 21:29:05 +0000, Pancho wrote:
>
>> My niece worked on Python at Twitter. She wasn't complimentary about it
>> either.
>
> What was her previous experience? Not (splutter) PHP, by any chance?

No, she wasn't originally employed as a programmer. Python was her first
language.

On 25/11/2024 09:55, D wrote:
> The problem with python is the quality of the ecosystem and the 2 to 3
> shift. I find the quality of python libraries lower than in perl. But I
> imagine that is due to there simply being more of them, and that it is a
> "live" language. Perhaps I found the quality better in perl, since the
> libraries that remain are old and mature.

The problem with Python is it seems to be the new BASIC.
An entry point for PWCP
People Who Cant Program.

--
"Strange as it seems, no amount of learning can cure stupidity, and
higher education positively fortifies it."

- Stephen Vizinczey

Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 06:50 this Monday (GMT):
> On Mon, 25 Nov 2024 04:40:03 -0000 (UTC), candycanearter07 wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 21:40 this Saturday (GMT):
>>>
>>> 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.
>>
>> Does it get freed up when the other processes that have it open also
>> close it, or is it stuck until shutdown?
>
> POSIX shared memory sections stay in existence until deletion, or system
> shutdown.
>
><https://manpages.debian.org/3/shm_unlink.3.en.html>

So that's something you should definitely be careful of if you're using
em.
--
user <candycane> is generated from /dev/urandom

On Sun, 24 Nov 2024 14:39:26 +0000, The Natural Philosopher wrote:

> On 24/11/2024 14:37, Rich wrote:
>> 186282@ud0s4.net <186283@ud0s4.net> wrote:
>>> Whatever it is, at least use Python if for no other
>>> reason than that it's generally comprehensible.
>>
>> Oh good lord no. The amount for which you hate Perl is the amount that
>> I despise Python.
>>
> I can't say a good word for either, having never written a line in
> either, I am disnclined to learn.

I've been learning Python, off-and-on, but my go-to languages
are still Perl or C.

(I learned OO programming with Perl. Please don't hate me.)

--
-Scott System76 Thelio Mega v1.1 x86_64 NVIDIA RTX 3090 Ti
OS: Linux 6.12.1 Release: Mint 21.3 Mem: 258G
""Keyboard? How quaint!" - Scotty"

On Mon, 25 Nov 2024 10:53:43 +0100, D wrote:

> I tried a bit of go, and setting up the environment as an amateur was
> dead simple.
>
> Is this also the case for professionals?

Sure. Compared to setting up for the Java application it was a walk in the
park. Part of it was brought on by ourselves but getting the Java app
built and packaged was convoluted.

I don't know how well the Go app would have worked out in the long term,
including maintenance after the original programmer left. It never saw the
light of day. That happens sometimes when the client decides to take
another path.

On Mon, 25 Nov 2024 02:33:32 -0500, 186282@ud0s4.net wrote:

> Was a strict 'C'/Pascal guy for a long time - but now I always at
> least proto in Python. For many apps where speed isn't paramount just
> LEAVE it in Python.

https://blog.miguelgrinberg.com/post/is-python-really-that-slow

Simplistic but I found the comparisons of the different Python 3 versions
interesting. For a while it was slower than 2.7, not a good thing, but
3.11 caught up. I don't know why the bubble sort regressed.

PyPy looks promising. I don't know why they were able to implement the JIT
that is hanging fire in CPython.

On Mon, 25 Nov 2024, The Natural Philosopher wrote:

> On 25/11/2024 09:55, D wrote:
>> The problem with python is the quality of the ecosystem and the 2 to 3
>> shift. I find the quality of python libraries lower than in perl. But I
>> imagine that is due to there simply being more of them, and that it is a
>> "live" language. Perhaps I found the quality better in perl, since the
>> libraries that remain are old and mature.
>
> The problem with Python is it seems to be the new BASIC.
> An entry point for PWCP
> People Who Cant Program.

I see that as elitist. The more people who can learn to do simple
programming, and simplify their lives, the better!

On Mon, 25 Nov 2024 11:48:41 +0000, Pancho wrote:

> On 11/24/24 22:37, Lawrence D'Oliveiro wrote:
>>
>> On Sun, 24 Nov 2024 21:29:05 +0000, Pancho wrote:
>>
>>> My niece worked on Python at Twitter. She wasn't complimentary about
>>> it either.
>>
>> What was her previous experience? Not (splutter) PHP, by any chance?
>
> No, she wasn't originally employed as a programmer. Python was her first
> language.

I wonder what her standard of comparison was, then ...

On Mon, 25 Nov 2024 08:57:09 +0000, Richard Kettlewell wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>> Richard Kettlewell wrote:
>>>
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>
>>>> 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>.
>>>
>>> Glibc’s double free detection is heuristic, not 100% reliable.
>
> (It’s documented as heuristic in the Glibc internals documentation and a
> glance at the implementation does seem to agree with that.)
>
>> If that were true, the examples on the man page wouldn’t work.
>
> No, that doesn’t follow. “Not 100% reliable” doesn’t mean specific
> examples don’t work.

Why not? The examples show that freeing the same pointer twice can be
detected reliably.

On Mon, 25 Nov 2024 12:04:11 +0000, The Natural Philosopher wrote:

> The problem with Python is it seems to be the new BASIC.

No, it is not. It is a far superior basis on which to build on than BASIC
ever was.

> An entry point for PWCP People Who Cant Program.

There is a “new BASIC” that fits that description: it’s PHP.

On Mon, 25 Nov 2024, rbowman wrote:

> On Mon, 25 Nov 2024 10:53:43 +0100, D wrote:
>
>> I tried a bit of go, and setting up the environment as an amateur was
>> dead simple.
>>
>> Is this also the case for professionals?
>
> Sure. Compared to setting up for the Java application it was a walk in the
> park. Part of it was brought on by ourselves but getting the Java app
> built and packaged was convoluted.
>
> I don't know how well the Go app would have worked out in the long term,
> including maintenance after the original programmer left. It never saw the
> light of day. That happens sometimes when the client decides to take
> another path.
>

This is the truth!

One of my customers has an in house developed, huge, java program. They
have been developing it, based on a ph.d. thesis for the last 10 years,
and they also tried to shun libraries but have written a lot of
functionality from scratch.

I almost started to work there 7 years ago, but that would have been too
early. It is absolutely fascinating how much they achieved in the past 7
years and how much their program has matured.

On Mon, 25 Nov 2024 23:21:21 +0100, D wrote:

> One of my customers has an in house developed, huge, java program. They
> have been developing it, based on a ph.d. thesis for the last 10 years,
> and they also tried to shun libraries but have written a lot of
> functionality from scratch.
>
> I almost started to work there 7 years ago, but that would have been too
> early. It is absolutely fascinating how much they achieved in the past 7
> years and how much their program has matured.

Those things tend to grow. There is a small town that is handled by the
county sheriffs department but it's about 50 miles from the dispatch
station. The original Java app allowed the substation to have some idea
what was going on in town, but there was no interaction. It was simple to
set up and to update. Over the years it grew into a fully functional
interface with parts being reused to build an Android app.

I did a few minor enhancements over the years for GIS related
functionality with great care since I am not a competent Java programmer.
I was interested in Java in the late '90s. In my edition of 'Java in a
Nutshell' it still fit in a nutshell rather than a whole damn walnut tree.

My first disillusionment came when Swing was added on top of AWT. "your
app runs like a herniated sloth? You need a bigger, faster machine!"

I have the media for Visual J++. It showed promise before it was
kneecapped by Sun. imho C# is Java done right.

On Mon, 25 Nov 2024 22:20:02 +0100, D wrote:

> On Mon, 25 Nov 2024, The Natural Philosopher wrote:
>
>> On 25/11/2024 09:55, D wrote:
>>> The problem with python is the quality of the ecosystem and the 2 to 3
>>> shift. I find the quality of python libraries lower than in perl. But
>>> I imagine that is due to there simply being more of them, and that it
>>> is a "live" language. Perhaps I found the quality better in perl,
>>> since the libraries that remain are old and mature.
>>
>> The problem with Python is it seems to be the new BASIC.
>> An entry point for PWCP People Who Cant Program.
>
> I see that as elitist. The more people who can learn to do simple
> programming, and simplify their lives, the better!

Python doesn't have a lock on the domain. I worked with a PhD chemist who
programmed in Fortran. He knew his chemistry but his Fortran looked like a
train wreck. The math was good and could be extracted into production
code. Many People Who Can't Program evolve into People Who Can Program or
have valuable expertise in a field where being able to express it, however
awkwardly, is valuable.

One of the job descriptions of a good manager is the ability to tell the
difference.