Uncle Bob and Silver Bullets • Hacker News Board

Re: Uncle Bob and Silver Bullets

#51

Post by wasted_intel » Fri, Oct 06, 2017, 1:45 PM UTC

falcolas wrote: post #48

tom_mellior wrote: post #33

Earlier quoted context omitted.

> First, do no harm, then use like Light Table, Model Driven Engineering, and TLA+. Looking at some of Uncle Bob's other posts linked from this article, I don't think that's what he's saying. He (Uncle Bob) goes on and on about discipline, but at the same time dismisses anything that might actually force programmers to be disciplined, like type systems that force you to check references for null before dereferencing…

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…

So, you're advocating removing the "make compiler happy" step and you think that will lead to greater discipline?

If the tool automatically fixed it, you'd have a point, but most if not all of the static analysis tools I've come across simply point to the error and leave it up to the developer to fix, which is the right thing to do, reinforcing good habits.

Re: Uncle Bob and Silver Bullets

#52

Post by cloverich » Fri, Oct 06, 2017, 1:46 PM UTC

falcolas wrote: post #48

tom_mellior wrote: post #33

Earlier quoted context omitted.

> First, do no harm, then use like Light Table, Model Driven Engineering, and TLA+. Looking at some of Uncle Bob's other posts linked from this article, I don't think that's what he's saying. He (Uncle Bob) goes on and on about discipline, but at the same time dismisses anything that might actually force programmers to be disciplined, like type systems that force you to check references for null before dereferencing…

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…

This overgeneralizes. When I started using strict null checking (in Typescript) I found it had an unexpected impact: I started writing code differently. Slowly, I also began _thinking_ about it differently. Ultimately you can't _make_ someone care if they don't want to. But if they already do care, some of these tools will make them better.

Re: Uncle Bob and Silver Bullets

#53

Post by marcosdumay » Fri, Oct 06, 2017, 1:47 PM UTC

rootlocus wrote: post #40

chrisseaton wrote: post #14

Earlier quoted context omitted.

There's definitely two types of very well known speakers. People who have worked on some really notable project. Linus Torvalds, David Heinemeier Hansson, Joel Spolsky and so on. I know these people are worth listening to because I can see that their code is a success. Then there are people who I have no idea what they have ever written at all. Robert Martin, Martin Fowler and so on. I don't know if I should listen t…

> People who have worked on some really notable project. Linus Torvalds, David Heinemeier Hansson, Joel Spolsky and so on. I know these people are worth listening to because I can see that their code is a success. I agree with your examples, Linus Torvalds in particular. However, I would not consider Mark Zuckerberg, Steve Jobs or Bill Gates worth listening to on a technical level just because their products are a su…

They are worth listening when talking about the kind of thing they used to make their products a success.

Re: Uncle Bob and Silver Bullets

#54

Post by dustingetz » Fri, Oct 06, 2017, 1:49 PM UTC

Uncle Bob (2017)

I stood before a sea of programmers a few days ago. I asked them the question I always ask: “How many of you write unit tests on a regular basis?” Not one in twenty raised their hands.

Rich Hickey (2011)

It passed all the tests. Okay. So now what do you do? Right? I think we're in this world I'd like to call guardrail programming. Right? It's really sad. We're like: I can make change because I have tests. Who does that? Who drives their car around banging against the guardrail saying, "Whoa! I'm glad I've got these guardrails because I'd never make it to the show on time."

https://github.com/matthiasn/talk-transcripts/blob/master/Hi... incremental search "passed all" for the rest

Re: Uncle Bob and Silver Bullets

#55

Post by steego » Fri, Oct 06, 2017, 1:49 PM UTC

zbentley wrote: post #9

I'm usually pretty skeptical of Uncle Bob's stuff, but in this case I think that both Hillel and Bob are a little right. Tools do make a difference, as Hillel says, and can be used to mitigate risk. The key word there is mitigate , though. Bob is right in that the root cause of that risk is a lack of discipline. Such risk will persist, mitigated by tools or not, so long as that lack of discipline persists. I think th…

> If anything, Hillel's article pushes a bit far (understandably) in the other direction, hinting that a failure of discipline is so inevitable as to be a waste of time to fight against.

I think you're mischaracterizing Hillel and putting words into his mouth. Hillel isn't saying discipline is a waste of time to fight against. He's arguing that focusing exclusively on discipline at the expense of everything else is foolish and narrow minded.

Re: Uncle Bob and Silver Bullets

#56

Post by [deleted] » Fri, Oct 06, 2017, 1:51 PM UTC

AlexDenisov wrote: post #42

Discipline is a good thing, but it does not scale. I work on a tool for mutation testing for C/C++[1] for a few years now. During this time I was thinking about tests, tools, people, etc. a lot. Here is the summary of my musings: Quality of software depends on several factors such as hardware, operating system, programming language and tooling used to build the software in the first place, etc. For decades we try to…

[deleted]

Re: Uncle Bob and Silver Bullets

#57

Post by bjpbakker » Fri, Oct 06, 2017, 1:51 PM UTC

I stopped reading Uncle Bob's articles a few years back, after he started making money by telling programmers they need to be more disciplined to prevent bugs.

While he's not exactly wrong, he does dismiss any other solution than testing (such strong type systems). One reason could be that he doesn't make any money out of these solutions.

All his blogs and talks seem to send the message: "pay for my content and learn how to be a good programmer by writing tests". Again, not necessarily a bad thing, but there might be other ways than only hand-crafted tests.

Re: Uncle Bob and Silver Bullets

#58

Post by bjpbakker » Fri, Oct 06, 2017, 1:53 PM UTC

dustingetz wrote: post #54

Uncle Bob (2017) I stood before a sea of programmers a few days ago. I asked them the question I always ask: “How many of you write unit tests on a regular basis?” Not one in twenty raised their hands. Rich Hickey (2011) It passed all the tests. Okay. So now what do you do? Right? I think we're in this world I'd like to call guardrail programming. Right? It's really sad. We're like: I can make change because I have t…

While I'm not a major fan of Clojure, I /loved/ this talk :)

Re: Uncle Bob and Silver Bullets

#59

Post by gregmac » Fri, Oct 06, 2017, 1:55 PM UTC

wasted_intel wrote: post #51

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…

So, you're advocating removing the "make compiler happy" step and you think that will lead to greater discipline? If the tool automatically fixed it, you'd have a point, but most if not all of the static analysis tools I've come across simply point to the error and leave it up to the developer to fix, which is the right thing to do, reinforcing good habits.

Not OP, but I interpreted that as implying your goal should not be "make compiler happy" but "think about and write reasonable code that also of course compiles".

If one's assumption is that because of a type system and other built-in protections a successful compile means no bugs, then that person is doomed to fail.

Re: Uncle Bob and Silver Bullets

#60

Post by marcosdumay » Fri, Oct 06, 2017, 1:56 PM UTC

taneq wrote: post #4

neilwilson wrote: post #3

The problem is that the more tools you add, the more mistakes you make in the tools. This is the same debate we had previously about formal methods. They don't eliminate errors, they just move them to the testing systems and where there are several the gaps between them. Communication becomes more difficult between the people involved and you rapidly start looking for the Chief Programmer Solomon who knows everything…

I don't get why automated testing is a "domain specific type system checker". Not saying it's not, I just don't get it. Maybe that's because my automated tests are pretty free-form and tend to be more about throwing mud at an algorithm and seeing if the results stick. Your last line is bang on, though. We build a system, and a compiler (or processor) for that system. It doesn't matter if everything is "data driven" i…

> I don't get why automated testing is a "domain specific type system checker".

That's because he was talking about formal verification. Testing like the name is normally used is a "adhock domain specific heuristic type system checker".