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.

You call it Raku and go post-apocalyptic. With Wall's religious background
he uses apocalypse in its original meaning but I think most of the world
takes it it the walking dead context.

On 11/23/24 9:06 PM, Lawrence D'Oliveiro wrote:
> 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.
>

Yea, "Raku"

https://en.wikipedia.org/wiki/Raku_(programming_language)

https://dev.to/lizmat/migrating-perl-to-raku-1c47

It is distant enough to kinda need a new name.

But I'm still not gonna bother.

It still seems to be a lang without any real POINT.
Whatever it is, better and clearer in Python.

There are a lot of langs like that - 95% like some
older lang, but with more pointlessly weird syntax.

There was one neat phrase I saw though - "In Perl 6, we
decided it would be better to fix the language than
fix the user" :-)

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

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

I'm not sure how I feel about the _ and *_ introduced in Python 3. I
suppose it's handy. Then there is the whole dunder etiquette and the
'please don't screw with this but I can't stop you' idea.

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

>
> I'm actually quite unconvinced by Python.

--
The urge to save humanity is almost always a false front for the urge to
rule.
– H. L. Mencken, American journalist, 1880-1956

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> 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”,

It’s what everyone else means by it.

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

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

Louis Krupp <lkrupp@invalid.pssw.com.invalid> wrote:
> On 11/23/2024 4:16 AM, The Natural Philosopher wrote:
>> On 23/11/2024 04:57, 186282@ud0s4.net wrote:
>>>    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.

This is the part that seems to get forgotten most often today, given
the fog of history.

There was a day, in the not so distant past, where one's choices for
'language' for "custom ad. hoc. tool" on a Unix machine were:

1) C
2) /bin/sh
3) Perl

And, if "custom ad. hoc. tool" needed to do any manipulation of
string data beyond the most trivial of output printf'ing then the code
overhead in C for handing those strings vs. one line of Perl, meant
Perl got called in to do the jobs that were "too much for /bin/sh" and
"not performance critical enough (yet)" to write out all the needed C
code.

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.

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.

--
WOKE is an acronym... Without Originality, Knowledge or Education.

The Natural Philosopher <tnp@invalid.invalid> 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 written quick scripts (and not so quick scripts for Perl) in both.

I prefer neither, but given a choice between only Perl or Python would
prefer Perl (unless Python had a required library interface available
that Perl did not).

On Sun, 24 Nov 2024 12:46:46 +0000, 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.

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

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.

On Sun, 24 Nov 2024, Rich wrote:

> The Natural Philosopher <tnp@invalid.invalid> 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 written quick scripts (and not so quick scripts for Perl) in both.
>
> I prefer neither, but given a choice between only Perl or Python would
> prefer Perl (unless Python had a required library interface available
> that Perl did not).
>
>

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.
2. The built in documentation.

On 11/24/24 00:31, Lawrence D'Oliveiro wrote:
> 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.
>

What?, Classes do have methods, e.g. they should handle a "new" message
to create a new instance object of that class.

In my previous post I didn't understand the meaning of implementation.
Informally I think of implementation as my code, my definition of a
function, as opposed to declaration. For instance I might say a class
implements an interface. However I think the article you cited was using
the word implementation to mean compiler. i.e. implementation of the
Smalltalk language.

From my perspective this is irrelevant, because my understanding of
Smalltalk was conceptual. The Smalltalk-80 Bluebook spoke of classes as
normal objects which had methods, responded to messages. The class which
created instance objects of type class was a metaclass.

The fact that a compiler/interpreter might handle (implementation
detail) all class behaviour, as it does in C++, doesn't matter. It is
helpful to think of classes as objects in their own right.

The problem is that the OO model for C++ is more complex. It is easy to
not be able to see the wood for the tress. That is why I was lucky to
have the Smalltalk conceptual model before being introduced to C++,

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

static has many usages in C++. You seem to be confusing the C definition
of a static variable with internal linkage, with the idea of a C++ class
static member variable or method.

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

Possibly. Reference types are like pointers. Value types can live only
on the stack.

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

In practice I didn't care. Generics solved the main problem of using
value types in container classes, without having to box 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.
>

Like an interface, IEnumerable (Chsarp), Iterable(Java)? or are you back
to some special use for Enums.

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

Python is very pretty, the problem is that I tried to write some
programs using it and the libraries were buggy. With CSharp and Java the
standardish libraries seem more reliable.

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

Yeah, I find not having explicit types very difficult to handle. Maybe
that is prejudice, maybe not.

On 11/24/24 10:25, The Natural Philosopher wrote:

>
> I have already completely lost the plot. And the will to live.
>

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.

It is easier to understand software concepts with baby steps, as opposed
to getting thrown in at the deep end.

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.

On Sun, 24 Nov 2024 21:19:51 +0000, Pancho wrote:

> On 11/24/24 00:31, Lawrence D'Oliveiro wrote:
>>
>> 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.
>>
> What?, Classes do have methods, e.g. they should handle a "new" message
> to create a new instance object of that class.

Looking again at that draft spec, “new” is handled as a special case.
If you look at the syntax for a class definition, the initializer
(section 3.4.3) is not defined as a method that handles a message
named “new”, it is just an unnamed block.

This is quite different from Python, where “__new__” is a classmethod,
and you can customize class-instantiation behaviour by defining a
custom method by that name.

This on top of the extra possibilities afforded by metaclasses.
Metaclasses are classes (and hence objects) in their own right, and
have their own method/member definitions.

> The fact that a compiler/interpreter might handle (implementation
> detail) all class behaviour, as it does in C++, doesn't matter. It is
> helpful to think of classes as objects in their own right.

Not really. Consider C++, where templates are handled in a separate
language that only exists at compile time, separate from the regular
language code that executes at run time.

In Python, there is no separate language for generics, since classes
(and functions) are objects, and all object construction happens at
run time.

(Code is generated at compile time, of course; but an object consists
of data as well as a pointer to shared code, and the data is
constructed at run time.)

>>> 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.
>>
> Like an interface, IEnumerable (Chsarp), Iterable(Java)? or are you back
> to some special use for Enums.

Here’s one example, a decoder for MagicaVoxel files I was playing with
a while back. An enumeration for the available material properties:

class MATT_PROPS(enum.IntEnum) :
PLASTIC = 0
ROUGHNESS = 1
SPECULAR = 2
IOR = 3
ATTEN = 4
POWER = 5
GLOW = 6
ISTOTALPOWER = 7

@property
def has_value(self) :
return \
self != type(self).ISTOTALPOWER
#end has_value

#end MATT_PROPS

used in decoding and extraction of same:

...if chunk.id == b"MATT" :
chunk.assert_no_children()
if len(chunk.content) < 16 :
raise Failure("MATT chunk initial too short")
#end if
matt_id, matt_type, matt_weight, prop_mask = struct.unpack("<IIfI", chunk.content[:16])
props_present = set(celf.MATT_PROPS(i) for i in range(32) if 1 << i & prop_mask != 0)
value_props = list(i for i in sorted(props_present) if i.has_value)
if len(chunk.content) < 16 + len(value_props) * 4 :
raise Failure("MATT chunk rest too short")
#end if
propvalues = struct.unpack("<" + "f" * len(value_props), chunk.content[16:])
props = dict(zip(value_props, propvalues))
for i in props_present :
if not i.has_value :
props[i] = None
#end if
#end for
self.materials.append \
(
celf.Material
(
id = matt_id,
type = celf.MATT_TYPE(matt_type),
weight = matt_weight,
props = props
)
)
#end if

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?

On 11/24/24 12:01 AM, rbowman wrote:
> 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.

For almost anything, it's good enough - or more than
good enough. The large number of libs has left little
beyond its (relatively easy) reach. It's also READABLE,
nothing too mysterious about the syntax or defining/using
vars and such.

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.

However it's NOT as fast as the true compiled langs.
Yea, yea, there's Python compilers - turn it into 'C' -
but with sometimes difficult barriers and the final exe
tends to be pretty fat - VERY VERY fat if you get past
version issues by encapsulating all the needed libs
inside the exe.

In any case, it's become the "new BASIC" for good reasons
and I don't see that being changed anytime soon. It's
in *everything* now from microcontrollers on up.

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

Anyway, I do full apps and utils in Python and almost
always use it to proto stuff before re-writing in 'C'
or Pascal.

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.

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.

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

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.

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

Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 21:40 this Saturday (GMT):
> 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.

Does it get freed up when the other processes that have it open also
close it, or is it stuck until shutdown?
--
user <candycane> is generated from /dev/urandom

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.