[COFF] [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 at kev009.com> wrote:
> On Thu, Nov 21, 2024 at 6:53 PM Dan Cross <crossd at gmail.com> wrote:
>> [TUHS to Bcc:, Cc: COFF]
>>
>> On Mon, Nov 18, 2024 at 11:47 AM Anton Shepelev <anton.txt at gmail.com> wrote:
>> > Dan Cross <crossd at 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.