On 11/25/24 1:47 AM, Lawrence D'Oliveiro wrote:
> 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.

Me too ... but I tend to use only 2-space indents
so complex nestings won't run off the edge of the
page ...

On 11/25/24 4:56 AM, D wrote:
>
>
> 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! ;)

As I said to Larry, I almost always use just 2-space
indents so deeply-nested stuff doesn't tend to run
off the page margin. Object langs make this even worse
with all the something.something.something.something
sorts of lines.

SOME of the IDEs for Python KINDA help, can spot
nestings fairly well, but I mostly just use nano
in one terminal and do test runs from another.
Something like PyCharm or Visual are kinda overkill
most of the time.

On Mon, 25 Nov 2024 21:50:48 -0500, 186282@ud0s4.net wrote:

> ... I tend to use only 2-space indents so complex nestings
> won't run off the edge of the page ...

I typically set the window width in my editor to about 100 columns.

On 11/25/24 4:07 AM, Richard Kettlewell wrote:
> "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.
>

Heh ... much of my 'C' looks like the top example, all
straight-forward and readable. As I said somewhere, 'C'
was the neat-o new lang back when I got started in things
so I strongly trend towards the K&R look and feel even now.
SO easy to write incomprehensible 'C' !

I agree that the optimization tech has become VERY good
these days. That final example shows how tight that
particular bit CAN be made. How the compiler figures
that out - NO idea ! Messing with microcontrollers
can be helpful in teaching how to shrink ASM - ya always
wanna save a few bytes, a few cycles.

"Tight memory" means "Only four gigabytes" to the
Gen-Z/A2 crowd :-)

On Mon, 25 Nov 2024 21:58:51 -0500, 186282@ud0s4.net wrote:

> SOME of the IDEs for Python KINDA help, can spot nestings fairly
> well, but I mostly just use nano in one terminal and do test runs
> from another. Something like PyCharm or Visual are kinda overkill
> most of the time.

It can't fix really mangled code but I like to run ruff to neaten up .py
files, 'ruff check' for errors and 'ruff format' to reformat. It's a
standalone or there is a VS Code extension.

Like black it is opinionated. It's configurable but the default is fine
for me. I haven't written enough Python code to develop a lot of personal
preferences like I have for C. For larger projects ruff's claim to fame is
it's fast being written in rust rather than Python like many of the
linters.

VS Code is overkill and I'm more likely to use vim for one or two Python
files but I've gotten used to using the Code extensions for the
microprocessors I play with so I tend to use it for most things. Anyway
with the vim extension the editor feels like vim.

On Mon, 25 Nov 2024 22:59:29 -0500, 186282@ud0s4.net wrote:

> Heh ... much of my 'C' looks like the top example, all
> straight-forward and readable. As I said somewhere, 'C' was the
> neat-o new lang back when I got started in things so I strongly trend
> towards the K&R look and feel even now.
> SO easy to write incomprehensible 'C' !

Most of them have been 'fixed' but I'm sure there are K&R style
definitions lurking someplace.

#include "stdio.h"

int add_stuff(a, b, c)
int a;
int b;
int c;
{ return a + b +c;
}

int main(void)
{ printf("the sum is %d\n", add_stuff(1, 4, 6));
return 0;
}

still works with gcc 11.4 although with std=c2x it warns

junk.c: In function ‘add_stuff’:
junk.c:3:5: warning: old-style function definition [-Wold-style-
definition]
3 | int add_stuff(a, b, c)
| ^~~~~~~~~

I don't know if gcc will ever default to whining about them. That's
staying power -- 46 years and cointing.

On 11/25/24 2:54 PM, rbowman wrote:
> 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.

PyPy IS snappier ... though not every line. I also
worry about potential little incompatibilities with
the "real" cpython implementation.

On the plus, PyPy has been around long enough so I don't
think it'll just stall and then go away. It's "safe" to
develop in.

We've yet to see what cpython4 will be like. I think
'performance' has been a major goal. PyPy shamed them :-)

As for JIT compilation, well, cpython went with the
model it had, that it knew. Human nature. BOTH are
good for most apps - unless you really NEED the speed.

As for 'regression' - probably the results of de-bugging
and explosion-proofing. 'Safety' can use up a lot of code.

186282@ud0s4.net <186283@ud0s4.net> wrote:
> On 11/25/24 4:07 AM, Richard Kettlewell wrote:
>> "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.
>>
> ...
> That final example shows how tight that particular bit CAN be made.
> How the compiler figures that out - NO idea !

Did you miss the forest for the trees. The final example is incorrect
based upon the plain meaning (albeit incorrect) of the input C source.

The check for a null "xp" value that is present in the C code has
disappeared in the output Assembly. The f() function has become
f(int *xp) { return *xp; }. Zero will only return from it when what xp
points at contains zero.

Granted, the C code is also wrong, in that "xp" is dereferenced before
it is checked to see if is null.

How the compiler 'figure[ed] that out' is that the C standard says
dereferencing a null pointer is undefined. So the compiler writers
decided that if the author wrote the dereference, they were also
asserting that "xp" would never be null at that point in their code.
Therefore there was no need to check for "xp" being null on the next
line, as it can't be null there, because the programmer already said it
was not null by dereferencing it on the prior line (because the
programmer should know not to do that). And the optimizer removed the
entire if statement as dead code that can never execute.

On 2024-11-26, rbowman <bowman@montana.com> wrote:

> On Mon, 25 Nov 2024 22:59:29 -0500, 186282@ud0s4.net wrote:
>
>> Heh ... much of my 'C' looks like the top example, all
>> straight-forward and readable. As I said somewhere, 'C' was the
>> neat-o new lang back when I got started in things so I strongly trend
>> towards the K&R look and feel even now.
>> SO easy to write incomprehensible 'C' !
>
> Most of them have been 'fixed' but I'm sure there are K&R style
> definitions lurking someplace.
>
> #include "stdio.h"
>
> int add_stuff(a, b, c)
> int a;
> int b;
> int c;
> {
> return a + b +c;
> }
>
> int main(void)
> {
> printf("the sum is %d\n", add_stuff(1, 4, 6));
> return 0;
> }
>
>
> still works with gcc 11.4 although with std=c2x it warns
>
> junk.c: In function ‘add_stuff’:
> junk.c:3:5: warning: old-style function definition [-Wold-style-
> definition]
> 3 | int add_stuff(a, b, c)
> | ^~~~~~~~~
>
>
> I don't know if gcc will ever default to whining about them. That's
> staying power -- 46 years and cointing.

I wouldn't be surprised if it does soon - after all, it whines
about just about everything else these days. Each new version
spits out tons of new warnings, and I go over my code and get
rid of every one (sometimes correcting questionable code in the
process). And then I started compiling the Windows version of
my stuff with MinGW, and the process began anew.

As for old-style function declarations, my code still contains
my solution that maintains compatibility with the old K&R style:

#ifdef PROTOTYPE
int foo(int bar, char *baz)
#else
int foo(bar, baz) int bar; char *baz;
#endif

--
/~\ 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

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

They do no such thing. They show that one very simple usage pattern is
detected. They tell you nothing about the ability to detect double frees
in a more complex system.

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

On Tue, 26 Nov 2024 05:57:33 GMT, Charlie Gibbs wrote:

> I wouldn't be surprised if it does soon - after all, it whines about
> just about everything else these days. Each new version spits out tons
> of new warnings, and I go over my code and get rid of every one
> (sometimes correcting questionable code in the process). And then I
> started compiling the Windows version of my stuff with MinGW, and the
> process began anew.

I think it was 11 that got stuffy about defining variables in header
files. It never was a good practice but it was done frequently in some of
our legacy code. Luckily yet another switch told it to shut up and go
about its business like it always did. Trying to fix it would have been a
month project for a newbie and we didn't have a newbie handy.

On Tue, 25 Nov 2024, rbowman wrote:

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

Yes, I asked the CTO if he would have chosen Java today, and he said no.
But now they have 10 years of work in java, so there is little point to
switch to something else, since Java works well for them.

I imagine that the fact that they keep external library dependencies to a
minimum makes it easier for them, than if they had a lot of dependencies
on third party libraries.

I wonder if rust would be a good option today? The software is purely
backend software. All the GUI parts are just html + some dynamic stuff.

On Tue, 25 Nov 2024, rbowman wrote:

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

Well put. You are a wise man!

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

> On 11/25/24 4:56 AM, D wrote:
>>
>>
>> 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! ;)
>
> As I said to Larry, I almost always use just 2-space
> indents so deeply-nested stuff doesn't tend to run
> off the page margin. Object langs make this even worse
> with all the something.something.something.something
> sorts of lines.
>
> SOME of the IDEs for Python KINDA help, can spot
> nestings fairly well, but I mostly just use nano
> in one terminal and do test runs from another.
> Something like PyCharm or Visual are kinda overkill
> most of the time.
>

I use four, but since worked as a systems administrator (or what today be
called "devops") I never wrote any programs large enough, or complicated
enough, to run out of line space.

This is what I do not like about power shell. Some of the commands are way
too long to type. I like ls, df, du & co! It would be horrible to have to
type list_files every time.

On 11/25/24 23:55, rbowman wrote:
> 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.

The fundamental characteristic of a good programmer is to be able to
deliver an application that is useful. Everything else is secondary.

IT department standards for good "production code" were often dogmatic
nonsense, labour intensive, often failures. Perhaps it has improved, but
in my day corporate IT management was dominated by snake-oil salesman
using a team of very poor drone programmers. Management liked drone
programmers, because they were easier to manage, interchangeable. The
trouble was that getting an app to work took a higher level of
understanding and skill, rather than just joining the dots.

vallor wrote this post while blinking in Morse code:

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

I've dabbled (babbled?) in Perl, Java, Python, and done some work-work with
C#/ASP.NET/Javascript, but C/C++ is my goto (get it? get it?).

Of course, my early C++ code was pretty awful.

I do think Python is a good language for scripting, and it's also the
source for the Meson build system.

Then there's Zoidberg, a Perl-based shell, long dead:

https://github.com/jberger/Zoidberg

--
This universe shipped by weight, not by volume. Some expansion of the
contents may have occurred during shipment.

Pancho <Pancho.Jones@proton.me> wrote:
> On 11/25/24 23:55, rbowman wrote:
>> 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.
>
> The fundamental characteristic of a good programmer is to be able to
> deliver an application that is useful. Everything else is secondary.
>
> IT department standards for good "production code" were often dogmatic
> nonsense, labour intensive, often failures. Perhaps it has improved, but

It has not. For "enterprise" style software at least.

> in my day corporate IT management was dominated by snake-oil salesman

Still present (ClownStrike anyone?).

> using a team of very poor drone programmers. Management liked drone

Also still present. I've described it as "they can assemble lego's
if given the instruction book -- ask them to create a lego model
without the instruction book and they are lost"

> programmers, because they were easier to manage, interchangeable. The
> trouble was that getting an app to work took a higher level of
> understanding and skill, rather than just joining the dots.

Yep, exactly. If they can be given instructions that match their "lego
brick set" they can snap something together. Ask them to do anything
that requires creativity or research and understanding, and you get
back a turd that has had hours of polishing applied.

Rich wrote this post while blinking in Morse code:

> Pancho <Pancho.Jones@proton.me> wrote:
>>
>> <snip>
>>
>> The fundamental characteristic of a good programmer is to be able to
>> deliver an application that is useful. Everything else is secondary.

Nah, the application must also be maintainable.

>> IT department standards for good "production code" were often dogmatic
>> nonsense, labour intensive, often failures. Perhaps it has improved, but
>
> It has not. For "enterprise" style software at least.

Our group had good practices, including design review, code-review, and
plenty of documentation.

>> in my day corporate IT management was dominated by snake-oil salesman
>
> Still present (ClownStrike anyone?).
>
>> using a team of very poor drone programmers. Management liked drone
>
> Also still present. I've described it as "they can assemble lego's
> if given the instruction book -- ask them to create a lego model
> without the instruction book and they are lost"
>
>> programmers, because they were easier to manage, interchangeable. The
>> trouble was that getting an app to work took a higher level of
>> understanding and skill, rather than just joining the dots.
>
> Yep, exactly. If they can be given instructions that match their "lego
> brick set" they can snap something together. Ask them to do anything
> that requires creativity or research and understanding, and you get
> back a turd that has had hours of polishing applied.

I feel sorry for you guys.

--
Cleanse area thoroughly before applying.

On Tue, 26 Nov 2024 13:17:08 -0000 (UTC), Rich wrote:

> Yep, exactly. If they can be given instructions that match their "lego
> brick set" they can snap something together. Ask them to do anything
> that requires creativity or research and understanding, and you get back
> a turd that has had hours of polishing applied.

The holy grail for management is a design methodology that gets adequate
results from a workforce of varying aptitudes. Particularly for larger
corporations you'll get a normal distribution, a few very good, a few
completely useless, and a lot of mediocrity. That's what you have to work
with.

What I've seen over the years is a company will luck out, get a better
than average distribution, and achieve success. Whatever they're doing is
taken as an example of the right way and copied mechanically. Top down
structured programming, agile, devops, and so forth have their day.

TI lucked out in the '70s and used something they called 'matrix
management' that became the new Wunderkind. The '80s brought 'In Search of
Excellence'.

https://en.wikipedia.org/wiki/In_Search_of_Excellence

Good money was made from book sales and training sessions from independent
snake oil salesmen preaching the gospel. The company I worked for had one
of the sessions. Not too many of the 'excellent' corporations are around
today.

About 10 years ago the company I now work for had a 'pair programming'
session. That was hilarious. The 'experts' were only familiar with Apple
machines and other than the one they brought there wasn't an Apple in the
building. Having been through required attendance things before my team
carefully stayed to the back of the room where we could slink away and get
back to business.

I'm sure the next methodology will wrap itself around AI, spin off
training companies, and mostly fail to deliver on the promises.

On Tue, 26 Nov 2024 10:09:37 +0100, D wrote:

> I imagine that the fact that they keep external library dependencies to
> a minimum makes it easier for them, than if they had a lot of
> dependencies on third party libraries.

That helps. We did an Angular app and package.json wound up with over 80
dependencies. Downloading them all was painful and sometimes introduced
problems. One example was using Protobuf 2.0. Protobuf 3.0 was not
backward compatible.

We got good at the semantics of package-lock when it became clear that not
everyone played by the rules of not breaking stuff in minor versions.

I'd done a web map using node for the backend. It had 8 dependencies, all
of which were stable. Increase that by a factor of 10 and it gets chewy.

On Tue, 26 Nov 2024 07:09:33 -0500, Chris Ahlstrom wrote:

> Of course, my early C++ code was pretty awful.

Early C++ was pretty awful. I understand iterators and other arcane bits
have been cleaned up a lot but I have no need to use general C++.
Arduino, Pico, and other microcontrollers use C/C++ but it's a limited
subset of C++.

On Tue, 26 Nov 2024, rbowman wrote:

> On Tue, 26 Nov 2024 13:17:08 -0000 (UTC), Rich wrote:
>
>> Yep, exactly. If they can be given instructions that match their "lego
>> brick set" they can snap something together. Ask them to do anything
>> that requires creativity or research and understanding, and you get back
>> a turd that has had hours of polishing applied.
>
> The holy grail for management is a design methodology that gets adequate
> results from a workforce of varying aptitudes. Particularly for larger
> corporations you'll get a normal distribution, a few very good, a few
> completely useless, and a lot of mediocrity. That's what you have to work
> with.
>
> What I've seen over the years is a company will luck out, get a better
> than average distribution, and achieve success. Whatever they're doing is
> taken as an example of the right way and copied mechanically. Top down
> structured programming, agile, devops, and so forth have their day.
>
> TI lucked out in the '70s and used something they called 'matrix
> management' that became the new Wunderkind. The '80s brought 'In Search of
> Excellence'.
>
> https://en.wikipedia.org/wiki/In_Search_of_Excellence
>
> Good money was made from book sales and training sessions from independent
> snake oil salesmen preaching the gospel. The company I worked for had one
> of the sessions. Not too many of the 'excellent' corporations are around
> today.
>
> About 10 years ago the company I now work for had a 'pair programming'
> session. That was hilarious. The 'experts' were only familiar with Apple
> machines and other than the one they brought there wasn't an Apple in the
> building. Having been through required attendance things before my team
> carefully stayed to the back of the room where we could slink away and get
> back to business.
>
> I'm sure the next methodology will wrap itself around AI, spin off
> training companies, and mostly fail to deliver on the promises.
>
>

Ahh... and today you have agile snakeoil salesmen! I heard a story from
the girlfriend of one of my consultants. Her company, a computer game
company, hired an "agile coach" who was workshopping away like a madman.

One programmer said... "but this agile thing, it seems to me like it will
become less efficient and more work, that's bad", the snakeoil salesman
responded "I hear you and appreciate your concern, but if agile makes
things worse, you're not doing it right, and that's why we are here"! ;)

On Tue, 26 Nov 2024, rbowman wrote:

> On Tue, 26 Nov 2024 10:09:37 +0100, D wrote:
>
>> I imagine that the fact that they keep external library dependencies to
>> a minimum makes it easier for them, than if they had a lot of
>> dependencies on third party libraries.
>
> That helps. We did an Angular app and package.json wound up with over 80
> dependencies. Downloading them all was painful and sometimes introduced
> problems. One example was using Protobuf 2.0. Protobuf 3.0 was not
> backward compatible.
>
> We got good at the semantics of package-lock when it became clear that not
> everyone played by the rules of not breaking stuff in minor versions.
>
> I'd done a web map using node for the backend. It had 8 dependencies, all
> of which were stable. Increase that by a factor of 10 and it gets chewy.
>

Shudder!

On Tue, 26 Nov 2024 08:32:32 +0000, Richard Kettlewell wrote:

>> The examples show that freeing the same pointer twice can be
>> detected reliably.
>
> They do no such thing.

free(p);
printf("%s(): returned from first free() call\n", __func__);

free(p);
printf("%s(): returned from second free() call\n", __func__);

Is that or is that not freeing the same pointer twice?

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

> On Tue, 26 Nov 2024 08:32:32 +0000, Richard Kettlewell wrote:
>
>>> The examples show that freeing the same pointer twice can be
>>> detected reliably.
>>
>> They do no such thing.
>
> free(p);
> printf("%s(): returned from first free() call\n", __func__);
>
> free(p);
> printf("%s(): returned from second free() call\n", __func__);
>
> Is that or is that not freeing the same pointer twice?

Obviously you are not arguing in good faith. As a reminder of the full
paragraph:

They do no such thing. They show that one very simple usage pattern is
detected. They tell you nothing about the ability to detect double frees
in a more complex system.

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