[COFF] Re: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)

[COFF] Re: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)

[Paul Winalski]

[-- Attachment #1: Type: text/plain, Size: 1344 bytes --]

[moving to COFF as this has drifted away from Unix]

On Sat, Sep 28, 2024 at 2:06 PM Larry McVoy <lm@mcvoy.com> wrote:


> I have a somewhat different view.  I have a son who is learning to program
> and he asked me about C.  I said "C is like driving a sports car on a
> twisty mountain road that has cliffs and no guard rails.  If you want to
> check your phone while you are driving, it's not for you.  It requires
> your full, focussed attention.  So that sounds bad, right?  Well, if
> you are someone who enjoys driving a sports car, and are good at it,
> perhaps C is for you."
>
> If you really want a language with no guard rails, try programming in
BLISS.

Regarding C and C++ having dangerous language features--of course they do.
Every higher-level language I've ever seen has its set of toxic language
features that should be avoided if you want reliability and maintainability
for your programs.  And a set of things to avoid if you want portability.

Regarding managed dynamic memory allocation schemes that use garbage
collection vs. malloc()/free(), there are some applications where they are
not suitable.  I'm thinking about real-time programs.  You can't have your
missle defense software pause to do garbage collection when you're trying
to shoot down an incoming ballistic missile.

-Paul W.

[-- Attachment #2: Type: text/html, Size: 1762 bytes --]

[COFF] Re: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)

[Larry McVoy]

On Mon, Sep 30, 2024 at 11:49:28AM -0400, Paul Winalski wrote:
> [moving to COFF as this has drifted away from Unix]
> 
> On Sat, Sep 28, 2024 at 2:06???PM Larry McVoy <lm@mcvoy.com> wrote:
> 
> 
> > I have a somewhat different view.  I have a son who is learning to program
> > and he asked me about C.  I said "C is like driving a sports car on a
> > twisty mountain road that has cliffs and no guard rails.  If you want to
> > check your phone while you are driving, it's not for you.  It requires
> > your full, focussed attention.  So that sounds bad, right?  Well, if
> > you are someone who enjoys driving a sports car, and are good at it,
> > perhaps C is for you."
> >
> > If you really want a language with no guard rails, try programming in
> BLISS.
> 
> Regarding C and C++ having dangerous language features--of course they do.
> Every higher-level language I've ever seen has its set of toxic language
> features that should be avoided if you want reliability and maintainability
> for your programs.  And a set of things to avoid if you want portability.
> 
> Regarding managed dynamic memory allocation schemes that use garbage
> collection vs. malloc()/free(), there are some applications where they are
> not suitable.  I'm thinking about real-time programs.  You can't have your
> missle defense software pause to do garbage collection when you're trying
> to shoot down an incoming ballistic missile.

That's why I like reference counting.  It doesn't have the long pauses
that other garbage collection systems have, when the variable goes out
of scope, you decrement, last guy frees.  Seems pretty simple.
-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

[COFF] Re: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)

[Dan Cross]

On Mon, Sep 30, 2024 at 2:07 PM Larry McVoy <lm@mcvoy.com> wrote:
> On Mon, Sep 30, 2024 at 11:49:28AM -0400, Paul Winalski wrote:
> > [moving to COFF as this has drifted away from Unix]
> >
> > On Sat, Sep 28, 2024 at 2:06???PM Larry McVoy <lm@mcvoy.com> wrote:
> >
> >
> > > I have a somewhat different view.  I have a son who is learning to program
> > > and he asked me about C.  I said "C is like driving a sports car on a
> > > twisty mountain road that has cliffs and no guard rails.  If you want to
> > > check your phone while you are driving, it's not for you.  It requires
> > > your full, focussed attention.  So that sounds bad, right?  Well, if
> > > you are someone who enjoys driving a sports car, and are good at it,
> > > perhaps C is for you."
> > >
> > > If you really want a language with no guard rails, try programming in
> > BLISS.
> >
> > Regarding C and C++ having dangerous language features--of course they do.
> > Every higher-level language I've ever seen has its set of toxic language
> > features that should be avoided if you want reliability and maintainability
> > for your programs.  And a set of things to avoid if you want portability.
> >
> > Regarding managed dynamic memory allocation schemes that use garbage
> > collection vs. malloc()/free(), there are some applications where they are
> > not suitable.  I'm thinking about real-time programs.  You can't have your
> > missle defense software pause to do garbage collection when you're trying
> > to shoot down an incoming ballistic missile.
>
> That's why I like reference counting.  It doesn't have the long pauses
> that other garbage collection systems have, when the variable goes out
> of scope, you decrement, last guy frees.  Seems pretty simple.

The problem with ref counting is that it's not completely general;
circular data structures will never be collected, even if all external
references to them disappear. That said, reference counting is a
really powerful technique; it's just that it must be used carefully.

        - Dan C.

[COFF] Re: Minimum Array Sizes in 16 bit C (was Maximum)

[Ralph Corderoy]

Hi Larry,

> > You can't have your missle defense software pause to do garbage
> > collection when you're trying to shoot down an incoming ballistic
> > missile.
>
> That's why I like reference counting.  It doesn't have the long pauses
> that other garbage collection systems have, when the variable goes out
> of scope, you decrement, last guy frees.  Seems pretty simple.

It's better, but the free() might cause a varying amount of work,
say due to coallescing.

Garbage collection these days doesn't have to be long-pause ‘stop the
world’.  Go's GC thread runs concurrently with the others, for example.
https://tip.golang.org/doc/gc-guide

-- 
Cheers, Ralph.

[COFF] Re: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)

[Paul Winalski]

[-- Attachment #1: Type: text/plain, Size: 412 bytes --]

On Tue, Oct 1, 2024 at 9:13 AM <arnold@skeeve.com> wrote:

> This goes back to the evolution thing. At the time, C was a huge
> step up from FORTRAN and assembly.
>

Certainly it's a step up (and a BIG step up) from assembly.  But I'd say C
is a step sidewise from Fortran.  An awful lot of HPTC programming involves
throwing multidimensional arrays around and C is not suitable for that.

-Paul W.

[-- Attachment #2: Type: text/html, Size: 718 bytes --]

[COFF] C a step up from Fortran.

[Ralph Corderoy]

Hi Paul,

> Arnold wrote:
> > This goes back to the evolution thing.  At the time, C was a huge
> > step up from FORTRAN and assembly.
>
> Certainly it's a step up (and a BIG step up) from assembly.
> But I'd say C is a step sidewise from Fortran.  An awful lot of HPTC
> programming involves throwing multidimensional arrays around and C is
> not suitable for that.

I expect the structured-programming parts of C were being referred to as
a step up compared to Fortran 77.  Ratfor was a step up in the same
direction.

Don't disagree about the HPTC side.

-- 
Cheers, Ralph.

[COFF] Re: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)

[arnold]

Paul Winalski <paul.winalski@gmail.com> wrote:

> On Tue, Oct 1, 2024 at 9:13 AM <arnold@skeeve.com> wrote:
>
> > This goes back to the evolution thing. At the time, C was a huge
> > step up from FORTRAN and assembly.
> >
>
> Certainly it's a step up (and a BIG step up) from assembly.  But I'd say C
> is a step sidewise from Fortran.  An awful lot of HPTC programming involves
> throwing multidimensional arrays around and C is not suitable for that.
>
> -Paul W.

In my head, FORTRAN is still FORTRAN 66, where there are no while
loops, or else statements, and the only data structure is the array.
For non-HPC stuff, C was a huge step up.

[COFF] Penn State

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]

At 2024-10-02T16:42:59-0400, Dan Cross wrote:
> On Wed, Oct 2, 2024 at 2:27 AM <arnold@skeeve.com> wrote:
> > Also true. In the late 80s I was a sysadmin at Emory U. We had a Vax
> > connected to BITNET with funky hardware and UREP, the Unix RSCS
> > Emulation Program, from the University of Pennsylvania. Every time I
> > had to dive into that code, I felt like I needed a shower
> > afterwards. :-)
> 
> Uh oh, lest the UPenn alumni among us get angry (high, Ron!) I feel I
> must point out that UREP wasn't from the University of Pennsylvania,
> but rather, from The Pennsylvania State University (yes, "The" is part
> of the name). UPenn (upenn.edu) is an Ivy in Philly; Penn State
> (psu.edu) is a state school in University Park, which is next to State
> College (really, that's the name of the town) with satellite campuses
> scattered around the state.

There's another method of distinguishing UPenn from Penn State.  Permit
me to share my favorite joke on the subject, from ten years ago.

"STATE COLLEGE, Pa. -- Construction workers tore down Penn State's
iconic Joe Paterno statue on campus two years ago -- but this town might
not be without one for much longer.

Two alumni already have received the OK from the borough to install a
projected $300,000 life-sized bronze sculpture downtown, about two miles
from the original site." -- ESPN ([1])

"The key difference is that the new statue will look the other way."
-- Chris Lawrence

Regards,
Branden

[1] https://www.espn.com/college-football/story/_/id/10828351/joe-paterno-honored-new-statue-state-college-pennsylvania

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[COFF] Re: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)

[Stuff Received]

[-->COFF]

On 2024-10-01 10:56, Dan Cross wrote (in part):
> I've found a grounding in mathematics useful for programming, but
> beyond some knowledge of the physical constraints that the universe
> places on us and a very healthy appreciation for the scientific
> method, I'm having a hard time understanding how the hard sciences
> would help out too much. Electrical engineering seems like it would be
> more useful, than, say, chemistry or geology.

I see this as related to the old question about whether it is easier to 
teach domain experts to program or teach programmers about the domain. 
(I worked for a company that wrote/sold scientific libraries for 
embedded systems.)  We had a mixture but the former was often easier.

S.

> 
> I talk to a lot of academics, and I think they see the situation
> differently than is presented here. In a nutshell, the way a lot of
> them look at it, the amount of computer science in the world increases
> constantly while the amount of time they have to teach that to
> undergraduates remains fixed. As a result, they have to pick and
> choose what they teach very, very carefully, balancing a number of
> criteria as they do so. What this translates to in the real world
> isn't that the bar is lowered, but that the bar is different.
> 
>          - Dan C.

[COFF] Re: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)

[Paul Winalski]

[-- Attachment #1: Type: text/plain, Size: 860 bytes --]

On Tue, Oct 1, 2024 at 10:07 AM <arnold@skeeve.com> wrote:

[regarding writing an Ada compiler as a class project]


> Did you do generics?  That and the run time, which had some real-time
> bits to it (*IIRC*, it's been a long time), as well as the cross
> object code type checking, would have been real bears.
>
> Like many things, the first 90% is easy, the second 90% is hard. :-)
>
> I was in DEC's compiler group when they were implementing Ada for VAX/VMS.
  It gets very tricky when routine libraries are involved.  Just figuring
out the compilation order can be a real bear (part of this is the cross
object code type checking you mention).

From my viewpoint Ada suffered two problems.  First, it was such a large
language and very tricky to implement--even more so than PL/I.  Second, it
had US Government cooties.

-Paul W.

[-- Attachment #2: Type: text/html, Size: 1226 bytes --]

[COFF] Re: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)

[Adam Thornton]

[-- Attachment #1: Type: text/plain, Size: 5814 bytes --]

Moving over to COFF from TUHS.  The following was Larry McVoy:


> I don't consider myself to be that good of a programmer, I can point to
> dozens of people my age that can run circles around me and I'm sure there
> are many more.  But apparently the bar is pretty low these days and I
> agree, that's sad.
>
>
It's hard not to feel like the bar is lower.  I feel like since Steve
Grandi retired at NOIRLab, I and Josh Hoblitt are the only people left who
actually understand how IP networks work.  And I'm not great, never was,
but I know a lot more than...everyone else.

And kids these days, well, I'm not very fluent in TypeScript and I really
don't understand why every damn thing needs to be asynchronous especially
if you're just awaiting its completion anyway.  But, hey, it ain't that
hard to do.

But again, there's a part of me that wonders how relevant the skills I miss
*are* anymore.  I'm a software developer now, but I always thought of
myself as basically a sysadmin.  It's just that we had automated away all
of what I started out doing (which was, what, 35-ish years ago?) by 20
years ago, and staying ahead of the automation has made me, of necessity, a
software developer now.

But I was also thinking of Larry saying he wouldn't last a week in today's
workplace, and I'm not sure that's true.

I mean, there's a lot of stuff that you once COULD say that would these
days get you a quick trip through HR and your crap in a box and a walk to
the curb...but I am a pretty foul-mouthed individual, and I have said nasty
things about people's code, and, indeed, the people who are repeat
offenders with respect to said code, and nevertheless I have had
surprisingly few issues with HR these last couple decades.  So in some
sense it really DOES matter WHAT it is that's offensive that you're saying,
and I am living-and-still-employed proof.

If you generally treat people with respect until they prove they don't
deserve it, and you base your calumny on the bad technical decisions they
make and not their inherent characteristics, then it really ain't that hard
to get along in a woke workplace.  And I say this as an abrasive coworker,
who happens to be a cis het white dude from a fairly-mainstream Christian
background and the usual set of academic credentials.

Let's face it: to do a good job as a software developer or generally an IT
person, you do not need a penis.  You do not need to worship the way most
people at your workplace do.  You do not need a college degree, let alone
in CS.  You do not need to be sexually attracted to the opposite sex.  You
do not need to have the same gender now that you were assigned at birth.
You do not need two (or given the current state of the art, ANY) working
eyes.  Or hands.  You do not need to be under 40.  You do not need to be
able to walk.  You do not need pale skin.  And anyone who's saying shit
about someone else based on THAT sort of thing *should* be shown the curb,
and quickly.  And the fact that many employers are willing to do this now
is, in my opinion, a really good thing.

On the other hand, if someone reliably makes terrible technical decisions,
well, yeah, you should spend a little time understanding whether there is a
structural incentive to steer them that way and try to help them if they're
trainable, but sometimes there isn't and they're not.  And those people,
it's OK to say they've got bad taste and their implementations of their
poor taste are worse.  And at least in my little corner of the world, which
is quasi-academic and scientific, there's a lot of that.  Just because
you're really really good at astronomy doesn't mean you're good at writing
intelligible, testable, maintainable programs.  Some very smart people have
written really awful code that solved their immediate problems, but that's
no way to start a library used by thousands of astronomers.  But whether or
not they're competent software engineers ain't got shit to do with what
they have in their pants or what color their skin is.

And it's not always even obvious bigotry.  I don't want to work with toxic
geniuses anymore.  Even if the only awful things they do and say are to
people that they regard as intellectually inferior and are not based on
bullshit as above...look, I'd much rather work with someone who writes
just-OK code and is pleasant than someone who writes brilliant code and
who's always a quarter-second from going off on someone not quite as smart
as they are.  Cleverness is vastly overrated.  I'd rather have someone with
whom I don't dread interacting writing the stuff I have to interface with,
even if it means the code runs 25% slower.  Machine cycles are dirt cheap
now.  The number of places where you SHOULD have to put up with toxicity
because you get more efficient code and it actually matters has been pretty
tiny my entire adult lifetime, and has been shrinking over that lifetime as
well.  And from a maintainability standpoint...if I encounter someone
else's just-OK code, well, I can probably figure out what it's doing and
why it's there way, way more easily than someone's code that used to be
blazing fast, is now broken, and it turns out that's because it encodes
assumptions about the runtime environment that were true five years ago and
are no longer correct.

That said, it's (again, in my not-necessarily-representative experience)
not usually the nonspecific toxic genius people who get in trouble with
HR.  The ones who do, well, much, MUCH, too often, are the people
complaining about wokeness in the workplace who just want to be able to say
bad things about their coworkers based on their race or gender (or...)
rather than the quality of their work, and I'm totally happy to be in the
"That's not OK" camp, and I applaud it when HR repeats that and walks them
out the door.

Adam

[-- Attachment #2: Type: text/html, Size: 6512 bytes --]

[COFF] Modern programming vs. the Good Ole Days (was Minimum Array Sizes in 16 bit C )(was Maximum)

[Paul Winalski]

[-- Attachment #1: Type: text/plain, Size: 3927 bytes --]

A bit about my background:  The first machine I programmed was ca. 1970 in
high school--a Monroe programmable calculator with four registers and a
maximum of 40 program steps.  The most complicated thing I got it to do was
to iteratively calculate factorials (of course it got arithmetic overflow
pretty quickly).  As an undergrad Biology major I learned BASIC on DTSS and
later Fortran IV and PL/I for an S/360 model 25 (32K max memory).  I
decided to go into computer technology rather than Biology and attended CS
grad school.  I completed all the coursework but never finished my thesis.
After interning at IBM's Cambridge Scientific Center for a few years, I
joined DEC's software development tools group in early 1980, later joining
the GEM compiler team to design and implement the non-compiler parts of the
compiler back end (heap memory management, generating listing files,
command line parsing, object file generation, etc.).  Compaq acquired DEC
and about a year later sold the Alpha chip technology--including the GEM
optimizing compiler back end--to Intel.  Many of the engineers--including
me--went with it.  I retired from Intel in 2016.

One important thing I learned early on in my career at DEC is that there is
a big difference between Computer Science and Software Engineering.  I was
very lucky that many of the top engineers in DEC's compiler group had
studied at CMU--one of the few schools that taught SW Engineering skills as
well as CS.  I learned good SW engineering practices from the get-go.
Unlike CS programming, SW engineering has to worry about things such as:

o design and implementation for testability and maintainability

o test system development

o commenting and documentation so that others can pick up and maintain your
code

o algorithm scalability

This thread has spent a lot of time discussing how programming has changed
over the years.  I bring the SW Engineering skill set up because IMO it's
just as relevant today as it was in the past.  Perhaps even more so.

My observation is that programming style has changed in response to
hardware getting faster and memory capacity getting larger.  If your
program has to fit into 8K or 32K you have to make every byte count--often
at the expense of maintainability and algorithmic efficiency.  As machines
got larger and faster, programming for small size became less and less
important.

The first revolution along these lines was the switch from writing in
machine code (assembler) to higher-level languages.  Machines had become
fast enough that in general it didn't matter if the compiler didn't
generate the most efficient code possible.  In most cases the increase in
productivity (HLLs are less error-prone than assembler) and maintainability
more than made up for less efficient code.

The second revolution was structured programming.  Machines fast enough and
large enough that one didn't have to resort to rat's nest coding to make
the program small and fast enough to be useful.  Structured programming
made code more easily understood--both by humans and by optimizing
compilers.

These days we have machines with several levels of data caching and
multiple processor cores running asynchronously.  If (as in the HPTC world)
you want to get the maximum performance out of the hardware, you have to
worry about framing your program in a way that can be multitasked (to take
advantage of all those cores) and you have to worry about efficient cache
management and interprocessor communication.  The ways to do this are not
always intuitively obvious.  Modern optimizing compilers know all the
(often completely non-intuitive) efficiency rules and can best apply them
when you write your code in an algorithmically clean manner and leave the
grunt work of running it efficiently on the hardware to the compiler.  It's
a very different world than when you had to figure out how to fit your code
and data into 8K!

-Paul W.

[-- Attachment #2: Type: text/html, Size: 4324 bytes --]

[COFF] Re: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)

[Jim Capp]

[-- Attachment #1: Type: text/plain, Size: 1088 bytes --]


Moving to COFF ,.. 




From: "Rich Salz" <rich.salz@gmail.com> 
To: "TUHS main list" <tuhs@tuhs.org> 
Cc: "Douglas McIlroy" <douglas.mcilroy@dartmouth.edu> 
Sent: Monday, September 30, 2024 4:03:15 PM 
Subject: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum) 







On Mon, Sep 30, 2024 at 3:12 PM Steffen Nurpmeso < steffen@sdaoden.eu > wrote 


noone ever told them that even the eldest C can be used in a safe 
way; 

Perhaps we have different meanings of the word safe. 


void foo(char *p) { /* interesting stuff here */ ; free(p); } 

void bar() { char *p = malloc(20); 
foo(p); 
printf("foo is %s\n", p); 
foo(p); 
} 
Why should I have to think about this code when the language already knows what is wrong. 



No one would make the claim that programming in machine "language" is safe. 


No one would make the claim that programming in assembly "language" is safe. 


I've always viewed C as a portable assembler. I think the real issue has nothing to do with the "safety" of C, but rather the "safety" of your-choice-of-C-libraries-and-methods. 


My $.02 


Jim 


[-- Attachment #2: Type: text/html, Size: 2378 bytes --]

[COFF] Re: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)

[Dan Cross]

[TUHS to Bcc:, Cc: COFF]

On Mon, Nov 18, 2024 at 11:47 AM Anton Shepelev <anton.txt@gmail.com> wrote:
> Dan Cross <crossd@gmail.com> wrote:
> >Programmer ability is certainly an issue, but I would suggest that
> >another goes back to what Rob was alluding to: compiler writers have
> >taken too much advantage of UB, making it difficult to write
> >well-formed programs that last.
>
> Following the letter, rather than the spirit, of the standard?

Pretty much!

> [snip]
> >My sense is that tossing in bad programmers is just throwing gasoline
> >onto a dumpster fire. Particularly when they look to charlatans like
> >Robert Martin or Allen Holub as sources of education and inspiration
> >instead of seeking out proper sources of education.
>
> I am a bad one as well, to have liked some things in Martin's books
> /Clean Code/ and /Clean Architecture/ .  True, heis no Wirth, nor
> Dijxtra, nor Knuth, but why a charlatan?

Briefly, because he writes with unwarranted confidence, and just isn't
a very good programmer himself.

He writes with an authoritative voice about things that he doesn't
know very much, if anything, about. For example, the things he's
written about static typing in programming languages are complete
nonsense. Sriram Krishnamurthi called him out on that
(https://x.com/ShriramKMurthi/status/1136411753590472707) and he did
not respond well, doubling down on his unfounded opinions
(https://blog.cleancoder.com/uncle-bob/2019/06/08/TestsAndTypes.html).
Later, he justified his opinion by making allusions to the amount of
time he's been programming
(https://blog.cleancoder.com/uncle-bob/2021/06/25/OnTypes.html). Hey,
when it comes to logical fallacies centered on appeals to length of
experience, well...I swooshed a basketball for the first time more
than 40 years ago, but I've given up any dream I may have ever had of
being a point guard in the NBA. Just doing something for a long time
doesn't mean you're good at it.

Robert Martin doesn't write production-quality code, period. He claims
to "ship" lots of code, but acknowledges that most of that is example
code for his books and personal side-projects. But the code examples
he has publicly available are not particularly well-structured,
readable, or maintainable. For a particular egregious example, see
https://github.com/unclebob/PDP8EmulatorIpad/blob/1eba53c08fb530effb9d29aca8134f7acadfdd5f/src/topt.c
(not the current commit; he modified it somewhat after I sent him
https://github.com/unclebob/PDP8EmulatorIpad/commit/dbfa03e90a084a25992dff79e5064897bce5ef42,
which he did not acknowledge; see
https://github.com/unclebob/PDP8EmulatorIpad/pull/2/commits/84483cd4d60320cd6ca5637f2c062d9d0540cc4a
for the timeline).

And while that small program is a particularly bad example, other bits
of his code are also bad. Ousterhout was asked to comment on his
"extract till you drop" approach and presented with a "refactoring"
Martin did of a program due to Knuth
(https://sites.google.com/site/unclebobconsultingllc/one-thing-extract-till-you-drop).
Ousterhout responded that he was "bewildered and horrified" by the
approach. As Ousterhout put it, "He has taken 25 lines of code that
are pretty straightforward and easy to understand, and turned them
into 38 lines with 9 methods, none of which has a stitch of
documentation. What was the point of this?"
(https://groups.google.com/g/software-design-book/c/Kb5K3YcjIXw/m/qN8txMeOCAAJ)

These are all typical of Martin's approach. Hence why I say the man is
a charlatan. Others have written at length about why, and how, his
advice is generally bad.

        - Dan C.

[COFF] Re: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)

[Dan Cross]

On Tue, Nov 26, 2024 at 8:48 AM Kevin Bowling <kevin.bowling@kev009.com> wrote:
> On Thu, Nov 21, 2024 at 6:53 PM Dan Cross <crossd@gmail.com> wrote:
>> [TUHS to Bcc:, Cc: COFF]
>>
>> On Mon, Nov 18, 2024 at 11:47 AM Anton Shepelev <anton.txt@gmail.com> wrote:
>> > Dan Cross <crossd@gmail.com> wrote:
>> > >Programmer ability is certainly an issue, but I would suggest that
>> > >another goes back to what Rob was alluding to: compiler writers have
>> > >taken too much advantage of UB, making it difficult to write
>> > >well-formed programs that last.
>> >
>> > Following the letter, rather than the spirit, of the standard?
>>
>> Pretty much!
>>
>> > [snip]
>> > >My sense is that tossing in bad programmers is just throwing gasoline
>> > >onto a dumpster fire. Particularly when they look to charlatans like
>> > >Robert Martin or Allen Holub as sources of education and inspiration
>> > >instead of seeking out proper sources of education.
>> >
>> > I am a bad one as well, to have liked some things in Martin's books
>> > /Clean Code/ and /Clean Architecture/ .  True, heis no Wirth, nor
>> > Dijxtra, nor Knuth, but why a charlatan?
>
> And what about Hollub?

Pretty much the same thing.

> A long time ago I came across and seemed to think some of his earlier books (on C) were ok.

Yeah.  He wrote a book about compilers, but as near as I can tell,
it's mostly material regurgitated from the Dragon Book, just a
different presentation, and a less academic focus.

Curiously, he's in the acknowledgements for K&R (I forget which
edition). I guess he read an early draft?

> Looking lately, I don’t tend to care for the metaphysical and ceremonial stuff whence one starts talking about design patterns and scrum instead of doing the work so I haven’t paid attention.
>
> It’s a strong accusation to levy publicly and maybe should be explained.

Many of Hollub's claims are ridiculous on the face of them ("you don't
need a bug tracker!  You don't need schedules!  Code should be written
by 'mobbing'!"

Here's a representative example:
https://twitter.com/allenholub/status/1734661813638459843  In that
tweet he writes, "What we do involves essentially no mathematical
analysis of anything. We are not doing math.If you're building a
system that requires math, then the math is part of the _domain_, not
the development process."  I suppose he's never heard of time or space
complexity analysis of algorithms?

Or how about this one:
https://twitter.com/allenholub/status/1827790079617892675 "A PR [Pull
Request] is necessary only when someone you don't trust writes code in
isolation. It's essential for OS work, for example, or if you're
working using scatter/gather [https://bit.ly/3XYLhb3]. It's also a
complete waste of time if you're working in a mob#/ensemble (or even a
pair) because the code is reviewed as it's written." I suppose he's
never worked someplace with a real, rigorous review culture. Also,
https://x.com/allenholub/status/1634050850434826240

A few others:
https://x.com/allenholub/status/1594859115557232640
https://x.com/allenholub/status/1613609655519019008
https://x.com/allenholub/status/1656811047783899138
https://x.com/allenholub/status/1610708432331632641

He has some code on Github that's relatively recent. It's not very good.

        - Dan C.


>> Briefly, because he writes with unwarranted confidence, and just isn't
>> a very good programmer himself.
>>
>> He writes with an authoritative voice about things that he doesn't
>> know very much, if anything, about. For example, the things he's
>> written about static typing in programming languages are complete
>> nonsense. Sriram Krishnamurthi called him out on that
>> (https://x.com/ShriramKMurthi/status/1136411753590472707) and he did
>> not respond well, doubling down on his unfounded opinions
>> (https://blog.cleancoder.com/uncle-bob/2019/06/08/TestsAndTypes.html).
>> Later, he justified his opinion by making allusions to the amount of
>> time he's been programming
>> (https://blog.cleancoder.com/uncle-bob/2021/06/25/OnTypes.html). Hey,
>> when it comes to logical fallacies centered on appeals to length of
>> experience, well...I swooshed a basketball for the first time more
>> than 40 years ago, but I've given up any dream I may have ever had of
>> being a point guard in the NBA. Just doing something for a long time
>> doesn't mean you're good at it.
>>
>> Robert Martin doesn't write production-quality code, period. He claims
>> to "ship" lots of code, but acknowledges that most of that is example
>> code for his books and personal side-projects. But the code examples
>> he has publicly available are not particularly well-structured,
>> readable, or maintainable. For a particular egregious example, see
>> https://github.com/unclebob/PDP8EmulatorIpad/blob/1eba53c08fb530effb9d29aca8134f7acadfdd5f/src/topt.c
>> (not the current commit; he modified it somewhat after I sent him
>> https://github.com/unclebob/PDP8EmulatorIpad/commit/dbfa03e90a084a25992dff79e5064897bce5ef42,
>> which he did not acknowledge; see
>> https://github.com/unclebob/PDP8EmulatorIpad/pull/2/commits/84483cd4d60320cd6ca5637f2c062d9d0540cc4a
>> for the timeline).
>>
>> And while that small program is a particularly bad example, other bits
>> of his code are also bad. Ousterhout was asked to comment on his
>> "extract till you drop" approach and presented with a "refactoring"
>> Martin did of a program due to Knuth
>> (https://sites.google.com/site/unclebobconsultingllc/one-thing-extract-till-you-drop).
>> Ousterhout responded that he was "bewildered and horrified" by the
>> approach. As Ousterhout put it, "He has taken 25 lines of code that
>> are pretty straightforward and easy to understand, and turned them
>> into 38 lines with 9 methods, none of which has a stitch of
>> documentation. What was the point of this?"
>> (https://groups.google.com/g/software-design-book/c/Kb5K3YcjIXw/m/qN8txMeOCAAJ)
>>
>> These are all typical of Martin's approach. Hence why I say the man is
>> a charlatan. Others have written at length about why, and how, his
>> advice is generally bad.
>>
>>         - Dan C.

[COFF] Re: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)

[Larry McVoy]

On Tue, Nov 26, 2024 at 02:51:38PM -0500, Dan Cross wrote:
> Many of Hollub's claims are ridiculous on the face of them ("you don't
> need a bug tracker!  You don't need schedules!  Code should be written
> by 'mobbing'!"

Why would anyone listen to this guy?  I ran engineering at BitMover for 
18 years, yeah, you need a bug tracker.  If for no other reason than to
track the churn rate.  HP-UX used that metric to decide when to land the
plane.

You need to realize that schedules are a rough idea, but you absolutely
need them, people work better towards a goal.

This guy sounds like he hasn't worked on anything other than small
user space programs.

[COFF] Re: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)

[Steffen Nurpmeso]

Larry McVoy wrote in
 <20241126201503.GJ30570@mcvoy.com>:
 |On Tue, Nov 26, 2024 at 02:51:38PM -0500, Dan Cross wrote:
 |> Many of Hollub's claims are ridiculous on the face of them ("you don't
 |> need a bug tracker!  You don't need schedules!  Code should be written
 |> by 'mobbing'!"
 |
 |Why would anyone listen to this guy?  I ran engineering at BitMover for 
 |18 years, yeah, you need a bug tracker.  If for no other reason than to
 |track the churn rate.  HP-UX used that metric to decide when to land the
 |plane.

Only to mention it, the Linux bugzilla is famous for living "in
the twilight zone":

  https://lore.kernel.org/lkml/6808cd17-b48c-657d-de60-ef9d8bfa151e@leemhuis.info/

  From: Thorsten Leemhuis <linux@leemhuis.info>
  To: Linus Torvalds <torvalds@linux-foundation.org>,
    Greg KH <gregkh@linuxfoundation.org>,
    Konstantin Ryabitsev <konstantin@linuxfoundation.org>
  Date: 2022-04-06
  Subject: A lot of regression reports submitted to bugzilla.kernel.org are apparently ignored, even bisected ones

 |You need to realize that schedules are a rough idea, but you absolutely
 |need them, people work better towards a goal.
 |
 |This guy sounds like he hasn't worked on anything other than small
 |user space programs.

I have not seen or read anything but what was posted here, but ..
honestly i find it overly funny.  In that it sounds to reflect
actual reality of many, if not most, big engineering efforts
i have ever heard of.
Ie, if budget and time limits go down the engineer reality toilet,
why not just leave them alone.  For example, in Germany/Europe we
had the Jäger90 (fighter plane), to which the polish did not want
to .. but that aside .., which then turned to Jäger91, 92, 93, 95,
2000 (i have forgotten the real details mind you, 35+ years since
that was mess of the week -- and it really was exactly that).
Yes, eventually this turned to the Eurofighter, but it was *at
leas* a decade late, and it took even longer thereafter, until
2006 says wikipedia, until it really entered service.

 --End of <20241126201503.GJ30570@mcvoy.com>

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
|
|And in Fall, feel "The Dropbear Bard"s ball(s).
|
|The banded bear
|without a care,
|Banged on himself for e'er and e'er
|
|Farewell, dear collar bear

[COFF] Re: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)

[John Levine]

According to Dan Cross <crossd@gmail.com>:
>> And what about Hollub?
>
>Pretty much the same thing.
>
>> A long time ago I came across and seemed to think some of his earlier books (on C) were ok.
>
>Yeah.  He wrote a book about compilers, but as near as I can tell,
>it's mostly material regurgitated from the Dragon Book, just a
>different presentation, and a less academic focus.

It was terrible because none of the code worked.  There was a fat list of errata
that fixed some of them but it was more trouble than it was worh.

R's,
John
-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

[COFF] [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)

[Douglas McIlroy]

> Curiously, Robert Martin's in the acknowledgements for K&R
> (I forget which edition). I guess he read an early draft?

I didn't find Robert Martin in the long list of acknowledgements
in the preface to the second edition. But any such acknowledgement
would certainly be to Bob Martin, a savvy Bell Labs executive whose
advice was always welcome. He is acknowledged in Aho and
Ullman's "Theory of Parsing, Translation, and Compiling", but not
in the Dragon Book.  I have never seen a Robert Martin book on
programming; I probably would have were it written by Bob.

Doug

[COFF] Re: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)

[Dan Cross]

[-- Attachment #1: Type: text/plain, Size: 806 bytes --]

On Tue, Nov 26, 2024, 4:37 PM Douglas McIlroy <douglas.mcilroy@dartmouth.edu>
wrote:

> > Curiously, Robert Martin's in the acknowledgements for K&R
> > (I forget which edition). I guess he read an early draft?
>
> I didn't find Robert Martin in the long list of acknowledgements
> in the preface to the second edition. But any such acknowledgement
> would certainly be to Bob Martin, a savvy Bell Labs executive whose
> advice was always welcome. He is acknowledged in Aho and
> Ullman's "Theory of Parsing, Translation, and Compiling", but not
> in the Dragon Book.  I have never seen a Robert Martin book on
> programming; I probably would have were it written by Bob.
>

Sorry, I mis-wrote. I meant to say Allen Holub was in the K&R
acknowledgements; not Martin.

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 1461 bytes --]