[COFF] Shadowing variables in Go.

[COFF] Shadowing variables in Go.

[Ralph Corderoy]

Taken to COFF...

Hi Arnold,

> In main(), I *think* I'm assigning to the global clientSet so that
> I can use it later.  But because of the 'err' and the :=, I've
> actually created a local variable that shadows the global one, and in
> otherfunc(), the global clientSet is still nil. Kaboom!
>
> The correct way to write the code is:
>
> 	var err error
> 	clientSet, err = cluster.MakeClient()	// or whatever

I think this is a common problem when learning Go, like assigning
getchar()'s value to a char in C.  It was back in ’14 anyway, when I saw
https://www.qureet.com/blog/golang-beartrap/ which has an ‘err’ at an
outer scope be unwritten by the ‘:=’ with the new, assigned-to ‘err’
going un-checked.

The author mentions ‘go vet’ highlights these cases with -shadow, which
is off by default.
https://pkg.go.dev/github.com/golangci/govet#hdr-Shadowed_variables
suggests that's still the case.

-- 
Cheers, Ralph.

[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