this post was submitted on 10 Aug 2024
540 points (97.0% liked)

Programmer Humor

19154 readers
2012 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 1 year ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 47 points 1 month ago (3 children)

But is he rewriting in Rust?

[–] [email protected] 29 points 1 month ago* (last edited 1 month ago) (7 children)

Unlikely, unless his view has changed substantially in the last seven years: https://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.html

I think his views on how to achieve good quality software are nearly antithetical to the goals of Rust. As expressed in that blog post and in Clean Code, he thinks better discipline, particularly through writing lots and lots of explicit unit tests, is the only path to reliable software. Rust, on the other hand, is very much designed to make the compiler and other tooling bear as much of the burden of correctness as possible.

(To be clear, I realize you're kidding. But I do think it's important to know just how at odds the TDD philosophy is from the "safe languages" philosophy.)

[–] [email protected] 11 points 1 month ago

Ahhhh, the ol' "dynamic languages are better than static languages because I have tests that check for different types" argument.

[–] [email protected] 6 points 1 month ago* (last edited 1 month ago)

This is an absolute terrible post :/ I cannot believe he thinks that is a good argument at all. It basically boils down to:

Here is a new feature modern languages are starting to adopt.

You might thing that is a good thing. Lists various reasonable reasons it might be a good thing.

The question is: Whose job is it to manage that risk? Is it the language’s job? Or is it the programmer’s job?

And then moves on to the next thing in the same pattern. He lists loads of reasonable reasons you might want the feature gives no reasons you would not want it and but says everything in a way to lead you into thinking you are wrong to think you want these new features while his only true arguments are why you do want them...

It makes no sense.

[–] [email protected] 5 points 1 month ago

His take strangely acknowledges that defects are caused by programmers, yet doesn’t want to improve the tools we use to help us not make these mistakes. In summary, git gud.

Experience has taught me that I’m awfully good at finding and firing foot guns, and when I use a language that has fewer foot guns along with good linting, I write reliable code because I tend to focus on what I want the code to do, not how to get there.

Declarative functional programming suits me down to the ground. OOP has been friendly to me, mostly, but it also has been the hardest to understand when I come back to it. Experience has given me an almost irrational aversion to side effects, and my simple mind considers class members as side effects

[–] [email protected] 5 points 1 month ago* (last edited 1 month ago) (1 children)

To my knowledge, the Rust's book actually encourages writing as many automated tests as you can, as the compiler can't catch every type of bug in existance.

[–] [email protected] 2 points 1 month ago

Yes. True. But Uncle Bob literally complains about non-nullable types in the linked blog post.

I'm not saying testing isn't important. I'm saying that hand-written unit tests are not the end-all be-all of software quality, and that Uncle Bob explicitly believes they are.

[–] [email protected] 5 points 1 month ago* (last edited 1 month ago)

rather strongly typed Java.

[In Java] you can also violate many of the type rules whenever you want or need to

Okay. Well maybe being able to not spell out types every single time would also count as not burdening the programmer ¯\_(ツ)_/¯

I bought Clean Code when I started learning programming, some of it was useful, but now I understand that it was too opinionated for a beginner

Edit: also

Whose job is it to manage that risk? Is it the language’s job? Or is it the programmer’s job[?]

It is language's job to enforce risk management wherever possible, humans are demonstrated time and time again to be poor at risk management (same for the other questions like 'whose job it is to check for nulls'

Edit2:

Defects are the fault of programmers. It is programmers who create defects

… and that is why he proposes to not help programmers with language means. I never thought that views of how problems should be tackled might differ so much while having in mind the same reasons and goals.

Albeit I do agree that one must write tests, even if language helps, not everything can reasonably be automatically checked

[–] [email protected] 3 points 1 month ago

Funny how he is actually now a fan of Clojure yet the examples in his book are actually full of mutating data and side effects. And Rich Hickey also stressed that tests are no silver bullet.

[–] [email protected] 2 points 1 month ago (1 children)
[–] [email protected] 2 points 1 month ago

The blog post? Yeah, that was the moment I lost most of my remaining respect for his tech opinions.

[–] [email protected] 15 points 1 month ago (1 children)

You can write an unmaintainable fucking mess in any language. Rust won't save you from cryptic variable naming, copy-paste code, a complete absence of design patterns, dreadful algorithms, large classes of security issues, unfathomable UX, or a hundred other things. "Clean code" is (mostly) a separate issue from choice of language.

Don't get me wrong - I don't like this book. It manages to be both long-winded and facile at the same time. A lot of people seem to read it and take the exact wrong lessons about maintainability from it. I think that it would mostly benefit from being written in pseudocode - concentrating on any particular language might distract from the message. But having a few examples of what a shitfest looks like in a few specific languages might help

[–] [email protected] 2 points 1 month ago (1 children)

Java is a fine choice. Much prefer it over pseudocode.

[–] [email protected] 1 points 1 month ago

As an example of a language that many people are familiar with, which is likely to be in long-term use where maintainability is most important, and which can almost read like pseudocode anyway, sure - probably the best 'real language' choice.

[–] [email protected] 1 points 1 month ago

Prolly Clojure. He's heavily on Clojure these days.