Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Uncle Bob and Silver Bullets

hillelwayne.com

Post reply on HN
Print view View original

141–150 of 228 posts

Re: Uncle Bob and Silver Bullets

#141

Post by mrleinad »

adamlett wrote: post #69
falcolas wrote: post #48

Earlier quoted context omitted.

No tool will ever successfully enforce discipline. If anything, it makes people more lax. "I don't have to reason about whether this can be null, the type system takes care of that for me." "I don't have to worry about leaking memory, valgrind will let me know." "I don't have to pay attention to the road, Tesla's autopilot takes care of it for me." All the tools do is enforce a loop of compile -> make compiler happy…

No tool will ever successfully enforce discipline. If anything, it makes people more lax. But the end goal is not disciplined programmers! It is better, safer and more timely software. Your argument applies just as well to safety equipment in cars and on heavy equipment, and you may be right that the reduced risk of being killed or maimed makes people more lax. But you can’t argue with the results: Far fewer people d…

Fewer errors get deployed to production code because tools help us catch them more often? Yes.

Fewer errors get deployed to production code because programmers have a more rigorous discipline when creating software? Also yes.

Which part should a teacher like Uncle Bob (I consider him as such) should care more about? People using tools or processes, or having them care about the discipline enough?

I'll go with the latter. And if he seems dismissive about the former, is because he's trying to teach about discipline, which is far more difficult to teach, than to use a tool or follow some process.

Re: Uncle Bob and Silver Bullets

#142

Post by bad_user »

milesvp wrote: post #135
Devagamster wrote: post #122

Earlier quoted context omitted.

y tho. you can have safety and expressivity...

it's often not about expressivity, it's about conciseness. It's much easier to say a correct statement than it is to prove the statement correct. This seems to be the main cost to stongly typed static languages, all the time spent proving to the compiler that this thing is actually compatible with that thing.

What strongly typed static languages are you talking about?

> proving to the compiler that this thing is actually compatible with that thing

I used to have this opinion, but nowadays I think that time is actually spent proving to myself that I'm right, which is always a good thing.

Having a compiler to do the hand holding is not such a bad thing, because the alternative is println-development.

What happens in a dynamic language is that you have to load in your head the shape of the data your working with, the API and everything really. Your head can't hold that much for anything that is bigger than a simple script, so you have to constantly execute and verify (in the REPL, in the browser, with a unit test, etc) each line of code that you write, before writing the next line of code.

This is why people complain about compilation speed in Scala, Haskell, etc, even if they miss they point, because even a slow, static compiler will improve efficiency, since you no longer have to compile and execute each line of code before you write the next one.

And yes, in my experience this is exactly what happens in big code bases built in dynamic languages, short of being really sloppy and introducing lots of bugs.

Re: Uncle Bob and Silver Bullets

#143

Post by kibwen »

milesvp wrote: post #135
Devagamster wrote: post #122

Earlier quoted context omitted.

y tho. you can have safety and expressivity...

it's often not about expressivity, it's about conciseness. It's much easier to say a correct statement than it is to prove the statement correct. This seems to be the main cost to stongly typed static languages, all the time spent proving to the compiler that this thing is actually compatible with that thing.

As opposed to the main cost to dynamically-typed languages, all the time spent proving to the test suite and proving to your teammates that this thing is actually compatible with that thing. And I say this as someone who adores Python! Dynamic typing does not magically make problems go away, it just makes them easier to ignore (whether deliberately or accidentally).

Re: Uncle Bob and Silver Bullets

#144

Post by arwhatever »

bad_user wrote: post #63

My problem with Uncle Bob's opinions is that they are pretty common within the industry, even if "discipline" really isn't the issue and all those negative feelings people allude to are warranted. In general, people are made to feel guilty for not being able to use the shitty tools and techniques we are given. Lets take for example ORMs and Hibernate in particular. I can't tell you how many times I've seen horrors re…

Someone help me with the origin of this (paraphrased) quote, which I have not been able to re-find on my own:

"The sooner you admit that you can't fit the whole program's source code in your head, the sooner you can begin incorporating that into your design."

Re: Uncle Bob and Silver Bullets

#145

Post by Ace17 »

shadowmint wrote: post #32

nah. I think you could quite easily quantify the effect various tools have on a code base; adding unit tests, using a repl, static vs. dynamic etc. on the various aspects of your code: - How quick/easy is it to add new features? - How often do you add new bugs? - How long does it take to fix bugs? ...but I think you could also look at the impact individual bad actors (the 'dont care' programmers) have on the same cod…

> Now, if you want to suggest that tools can add enough value to overcome the negatives from having rubbish programmers, I'm all ears, because I've never seen a tool that can do that. The bad programmers just abuse the tools or ignore them.

So much this.

This perfectly matches my experience (and desperation). Bad programmers will do their best to work around tool-imposed limitations that they don't understand. And these workarounds will generally increase code complexity!

- Force a minimum coverage ratio: they will create useless tests that don't check anything (without assertions).

- Force a maximum on function sizes: they will split their methods halfway and pass the whole local state through parameters.

- Force a "no-global variable" policy: they will create singleton classes.

- Force a "no public member variable" policy: they will create set/get methods for their private members.

I'm not advocating for any of the above restrictions, they do more harm than good. Please, give me something I can put into my CI server that checks for bad coding practises, something that checks that the code stays SIMPLE.

Fact: you can inject a new disabled feature into a C codebase with zero risk of introducing any bug ... by wrapping your 50 modifications of the codebase into #if/#endif clauses. Guess what? This will make the code a lot more complex, will slow down every developer, and will increase the likelihood that they create bugs in other features.

Finding bugs is only the tip of the iceberg. What I want is to decrease the probability of their apparition, by keeping the code simple. Bugs and code complexity are correlated. Only targetting bugs will break this correlation, and we will be left with correct rigid code (very hard to modify). Even if my compiler perfectly prevents me from breaking anything, I still want to be able to add a feature in a reasonnable time.

Let me summon Rich Hickey here: Simplicity Matters, and "nobody drives on the highway by bumping into the guard rails".

Re: Uncle Bob and Silver Bullets

#146

Post by erik_seaberg »

mrleinad wrote: post #141
adamlett wrote: post #69

Earlier quoted context omitted.

No tool will ever successfully enforce discipline. If anything, it makes people more lax. But the end goal is not disciplined programmers! It is better, safer and more timely software. Your argument applies just as well to safety equipment in cars and on heavy equipment, and you may be right that the reduced risk of being killed or maimed makes people more lax. But you can’t argue with the results: Far fewer people d…

Fewer errors get deployed to production code because tools help us catch them more often? Yes. Fewer errors get deployed to production code because programmers have a more rigorous discipline when creating software? Also yes. Which part should a teacher like Uncle Bob (I consider him as such) should care more about? People using tools or processes, or having them care about the discipline enough? I'll go with the lat…

I complain about quality a lot. I might almost have this superhuman level of discipline on my best days, and only then if business allows me to indulge it. But think about the worst programmer you've ever worked with. In his hands the tool is a much bigger win.

Re: Uncle Bob and Silver Bullets

#147

Post by adamlett »

mrleinad wrote: post #141
adamlett wrote: post #69

Earlier quoted context omitted.

No tool will ever successfully enforce discipline. If anything, it makes people more lax. But the end goal is not disciplined programmers! It is better, safer and more timely software. Your argument applies just as well to safety equipment in cars and on heavy equipment, and you may be right that the reduced risk of being killed or maimed makes people more lax. But you can’t argue with the results: Far fewer people d…

Fewer errors get deployed to production code because tools help us catch them more often? Yes. Fewer errors get deployed to production code because programmers have a more rigorous discipline when creating software? Also yes. Which part should a teacher like Uncle Bob (I consider him as such) should care more about? People using tools or processes, or having them care about the discipline enough? I'll go with the lat…

You’re creating a false dilemma. It’s entirely possible to be a disciplined programmer and use good tools.

And, yes, a teacher should care more about the skills than the tools, but Uncle Bob is actively against the tools, claiming that they impede learning the skills. Which is no more true than claiming that automatic transmissions or anti-spin in modern race cars impedes learning how to race.

Re: Uncle Bob and Silver Bullets

#148

Post by blktiger »

oblio wrote: post #96
_wc0m wrote: post #89

Earlier quoted context omitted.

Completely agree with this. The post where Martin derides modern, type-safe languages (Kotlin and Swift) [0] was just unbelievable to me. "Ask yourself why we are trying to plug defects with language features. The answer ought to be obvious. We are trying to plug these defects because these defects happen too often. Now, ask yourself why these defects happen too often. If your answer is that our languages don’t preve…

Somebody should show Uncle Bob this: https://youtu.be/fPF4fBGNK0U My point being: yes, if we'd be perfect drivers at all times and in all weather conditions there would be no more accidents. Luckily for us auto designers haven't adopted this perspective :)

This is a video of a crash _test_. Personally, I'm not sure TDD is necessarily the answer but even with typed code you should still have tests. You just don't need tests for things covered by the type system.

Of course, it also depends on what the software is being used for. If I create a script for automating something just for me, I don't see any reason to add repeatable tests.

Re: Uncle Bob and Silver Bullets

#149

Post by Terretta »

dtauzell wrote: post #102
mannykannot wrote: post #81

Earlier quoted context omitted.

> So you have two camps. People who believe correctness is important, and people who think continuous deployment is an answer to bugs. I am curious as to how the people of the second group (if they do, in fact, exist) think that the continuous deployment of serially faulty code is a solution to anything.

I don't think there is such a group (or at least it is very small). What continuous deployment does do is help you find bugs faster as they get shipped sooner. It also promotes more automated testing which can help as well since manual testing is less likely to fully regress everything.

> What continuous deployment does do is help you find bugs faster as they get shipped sooner.

Yep, that's the thinking that stresses me in the second group.

Re: Uncle Bob and Silver Bullets

#150

Post by dep_b »

halostatue wrote: post #130
dep_b wrote: post #21

I think Uncle Bob is a great read just because he'll challenge some of your opinions and at least forces you to reason against his arguments. You won't have that if you only visit https://swiftisfreakingawesomeblog.com or http://www.igetpaidtolikethislanguage.org where everybody repeats your opinion. There's not a lot in Clean Code that I wouldn't recommend to most programmers.

I strongly recommend against reading Clean Code, because it only applies to Java-like languages, and it doesn't really make good advice anyway. It doesn’t even properly apply to C++, and certainly doesn’t apply to languages with different models (like Ruby or Python). Uncle Bob has made a very successful business out of saying things that sound profound, become popular, but are at best the technical equivalent of for…

I read that. I disagree with his opinion. But that's not from Clean Code. And sure the book is about Java but I don't remember it's a great idea to have unreadable names or classes that do a million things in PHP for example. I never program in Java and I'm really happy about that but a lot of principles apply.

The unit test zealotism is the part I ignore about Clean Code. But the rest? Most of it is solid advice.

Post reply on HN