If one is doing software development, then a good book to
read, that goes beyond simply learning a language or tool,
is "A Philosophy of Software Design", by John Ousterhout.
Ousterhout is a professor at UC Berkeley, and inventor of
the Tcl programming language. The book goes into the why
and what of modern software development, more than just
the how.

Ousterhout also recently had a lively debate with Robert
C Martin, another popular author of programming books,
which is somewhat illuminating. One may read the exchange
here:
https://github.com/johnousterhout/aposd-vs-clean-code/blob/main/README.md

Note that the primary programming example for both is a
program to generate prime numbers. Both provide implementations
that have serious deficiencies; my own take on this is here: https://github.com/dancrossnyc/literatePrimes

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Ousterhout also recently had a lively debate with Robert
C Martin, another popular author of programming books,
which is somewhat illuminating. One may read the exchange
here: https://github.com/johnousterhout/aposd-vs-clean-code/blob/main/README.md

Thanks for sharing, interesting discussion recorded over there.

I'll grab the book. I have and read Clean Code.

-h1

... Xerox Alto was the thing. Anything after we use is just a mere copy.

--- Mystic BBS v1.12 A49 2024/05/29 (Linux/64)
* Origin: 2o fOr beeRS bbs>>>20ForBeers.com:1337 (21:2/150)

On 07 Mar 2025 at 12:02a, hollowone pondered and said...

Thanks for sharing, interesting discussion recorded over there.

I'll grab the book. I have and read Clean Code.

Great. I must confess, however; at this point, I despise
"Clean Code". It's bad advice, and my opinion is that Robert
Martin is a blowhard and a charlatan. He's just not a very
good programmer.

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Re: Re: Software development book recommendation
By: tenser to hollowone on Fri Mar 14 2025 10:50:58

Great. I must confess, however; at this point, I despise
"Clean Code". It's bad advice, and my opinion is that Robert
Martin is a blowhard and a charlatan. He's just not a very
good programmer.

Come on, tenser - stop beating around the bush and tell us what you really think :)

BobW
--- SBBSecho 3.23-Linux
* Origin: >>> Magnum BBS <<< - magnumbbs.net (21:1/205)

On 14 Mar 2025 at 10:48a, Bob Worm pondered and said...

"Clean Code". It's bad advice, and my opinion is that Robert
Martin is a blowhard and a charlatan. He's just not a very
good programmer.

Come on, tenser - stop beating around the bush and tell us what you
really think :)

Well, in fairness, I don't think he kicks puppies or anything. :-)

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

"Clean Code". It's bad advice, and my opinion is that Robert Martin is a blowhard and a charlatan. He's just not a very
good programmer.

Come on, tenser - stop beating around the bush and tell us what you really think :)

Well, in fairness, I don't think he kicks puppies or anything. :-)

Perhaps there's already something later, but I was hoping there'd be something describing why it's bad advice.

The rest of it I don't particularly care about, since there are plenty of blowhards, charlatans, and bad programmers.

And, heck, most of us probably do those things to some extent from time to time regardless.

Anyway, I haven't read Clean Code, but I'm very pro commenting. Yes, there are such things as too much commenting, but aside from in school when people were commenting, "//adds 1 to x", it's not something I've ever seen.

But random blocks of code where I'm supposed to just _know_ what the heck the previous programmer was supposed to mean, based off of variables? Yeah, those I've seen plenty of.

Especially when it's something where I don't understand the code base, and I'm looking for _anything_ to help me to latch on what's going on in a certain section.

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Storm BBS (21:2/108)

On 17 Mar 2025 at 02:09p, Adept pondered and said...

"Clean Code". It's bad advice, and my opinion is that Robert Martin is a blowhard and a charlatan. He's just not a very good programmer.

Come on, tenser - stop beating around the bush and tell us what really think :)

Well, in fairness, I don't think he kicks puppies or anything. :-)

Perhaps there's already something later, but I was hoping there'd be something describing why it's bad advice.

Others can probably say it better than I can. Something like https://qntm.org/clean is a good reference.

The rest of it I don't particularly care about, since there are plenty of blowhards, charlatans, and bad programmers.

And, heck, most of us probably do those things to some extent from time
to time regardless.

Anyway, I haven't read Clean Code, but I'm very pro commenting. Yes,
there are such things as too much commenting, but aside from in school when people were commenting, "//adds 1 to x", it's not something I've
ever seen.

Then you probably wouldn't like "Clean Code." :-) Martin describes
a comment as a "failure".

I certainly think that there are times when a better name or a
temporary variable or something can make a comment completely
redundant, and that's good, but he goes entirely too far.

One of John Ousterhout's criticisms of Martin is that he doesn't
balance his advice: he goes to an extreme, so far as to call
comments failures, but doesn't discuss when they may be necessary.
The advice is thus not usefully weighted in situations where
things are ambiguous.

But random blocks of code where I'm supposed to just _know_ what the
heck the previous programmer was supposed to mean, based off of
variables? Yeah, those I've seen plenty of.

Martin's own example code is awful in this regard; he wrote a copy
of a prime number generator program he read about in a paper by
Donald Knuth, and ends up with a ton of silly little functions with
names like, `isLeastRelevantMultipleOfLargerPrimeFactor`. Yeah, I
don't know what the hell that means, either, and I'm positive that
Martin has no clue. Moreover, his code is just wrong in some places
(it doesn't handle integer overflow, for example, and fails for 2).
My own implementation of that program is here, btw; caveat that I am
not a Java programmer: https://github.com/dancrossnyc/literatePrimes/blob/main/Primes.java

Especially when it's something where I don't understand the code base,
and I'm looking for _anything_ to help me to latch on what's going on in
a certain section.

This is the thing that clinches it for me. Martin's advice is all
extremely tactical: "here's how you should write this (class|function)."
It doesn't help with building larger systems at all.

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Great. I must confess, however; at this point, I despise
"Clean Code". It's bad advice, and my opinion is that Robert
Martin is a blowhard and a charlatan. He's just not a very
good programmer.

Well, Maybe I'll return to it when I complete the Philosophy of Software Design first. I've got myself onto Chapter 11 already ("Design twice").

I find some of the insights and findings interesting, good for aspiring tech leads and architects to remember, but nothing truly revolutionary for experienced seniors.. Just put some wording well to structurize some rules.

But I can't clearly agree with all rules, or blindly... it really has a lot of space for "it depends"... which makes it a bit academic with a failed effort to over generalize the problem.

I don't blame it, it's good high level intro to kick off discussion in subject.

I'll keep reporting my findings when I complete the book.

-h1

... Xerox Alto was the thing. Anything after we use is just a mere copy.

--- Mystic BBS v1.12 A49 2024/05/29 (Linux/64)
* Origin: 2o fOr beeRS bbs>>>20ForBeers.com:1337 (21:2/150)

One of John Ousterhout's criticisms of Martin is that he doesn't
balance his advice: he goes to an extreme, so far as to call
comments failures, but doesn't discuss when they may be necessary.
The advice is thus not usefully weighted in situations where
things are ambiguous.

Well Ousterhout writes you shouldn't worry about error handling related to memory management. Computers today have enough ram to handle malloc just fine... :> which if read without careful consideration of the context is like... of fuck... come on John...

I could not also blindly agree with his exception handling tactics. Generally there are better ways to handle corner cases than raising exceptions anyway...

Deep modules vs. shallow functions is huge it depends to me.

but I really liked the strategic vs. tactical programming terminology.
It well describes AI aided programming today (so focused on task definition that it often forgets the system to be built... highly tactical), vs. human processed AI code at the end to ensure it never forgets about system architecture while realizing task formulated by a question or user story....

-h1

... Xerox Alto was the thing. Anything after we use is just a mere copy.

--- Mystic BBS v1.12 A49 2024/05/29 (Linux/64)
* Origin: 2o fOr beeRS bbs>>>20ForBeers.com:1337 (21:2/150)

Others can probably say it better than I can. Something like https://qntm.org/clean is a good reference.

I did like your breakdown of it, though, as it did seem to well explain why you feel the way you do toward the idea.

Then you probably wouldn't like "Clean Code." :-) Martin describes
a comment as a "failure".

Yeah, I'm sure I'd fundamentally disagree.

I tend to code by first commenting, then refining the code and comments as I go along.

But even after things are pretty tight, I _still_ want the comments in there, because it'll explain what was in my head as I wrote the code, and give me a chance of explaining the code in a second way that might make more sense to the next person to come by.

Obviously, I'll try to use good variable names, have easy-to-follow code, and so on, but even with perfect code, it's a guarantee that all but the simplest situations will have people with a different mindset coming through and wondering what the heck was going on.

I certainly think that there are times when a better name or a
temporary variable or something can make a comment completely
redundant, and that's good, but he goes entirely too far.

Yeah. It does sound like it's combining a good idea (make things readable) with a bad idea (if variable names aren't enough in all situations, it's bad code).

comments failures, but doesn't discuss when they may be necessary.
The advice is thus not usefully weighted in situations where
things are ambiguous.

Beyond that, what I like about comments is that it's a way for a coder to say, "this is what was going through my head when making this, and what I was trying to do". Even with perfect variable names, you'd have to infer that info.

names like, `isLeastRelevantMultipleOfLargerPrimeFactor`. Yeah, I
don't know what the hell that means, either, and I'm positive that

Oof, yeah, if that's in the example...

This is the thing that clinches it for me. Martin's advice is all extremely tactical: "here's how you should write this (class|function)." It doesn't help with building larger systems at all.

I guess he's all set for Leetcode...

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Storm BBS (21:2/108)

Re: Re: Software development book recommendation
By: Adept to tenser on Tue Mar 18 2025 09:14 pm

But even after things are pretty tight, I _still_ want the comments in there, because it'll explain what was in my head as I wrote the code, and give me a chance of explaining the code in a second way that might make more sense to the next person to come by.

Obviously, I'll try to use good variable names, have easy-to-follow code, and so on, but even with perfect code, it's a guarantee that all but the simplest situations will have people with a different mindset coming through and wondering what the heck was going on.

Yeah, I feel like comments are important. Even if you can follow the code, you'll get an idea of what the code is doing, but not really the why, or the intent behind the code.

Nightfox
--- SBBSecho 3.23-Linux
* Origin: Digital Distortion: digdist.synchro.net (21:1/137)

Re: Re: Software development book recommendation
By: tenser to hollowone on Fri Mar 14 2025 10:50 am

Great. I must confess, however; at this point, I despise
"Clean Code". It's bad advice, and my opinion is that Robert
Martin is a blowhard and a charlatan. He's just not a very
good programmer.

I agree: "Uncle Bob" seems to be more of a personality than an engineer.
--
digital man (rob)

Steven Wright quote #33:
Everyone has a photographic memory; some just don't have film.
Norco, CA WX: 70.7°F, 55.0% humidity, 7 mph W wind, 0.00 inches rain/24hrs