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

161–170 of 228 posts

Re: Uncle Bob and Silver Bullets

#161

Post by mishkovski »

bad_user wrote: post #155
mishkovski wrote: post #152

I think that automated testing is superior to any other tool/technique that we can use to avoid mistakes in programming. Can anyone argue with this? What is the alternative?

Static typing combined with functional programming is superior to automated testing, although the three are actually complementary, because automatic, property-based testing works better if you have type info (such that the library knows what values to generate) and referential transparency, because side effects can be awkward to specify as laws. So it is not a coincidence that Haskell developers have innovated testi…

Static typing or functional programming can protect you only from some types of problems. With automated tests you have the flexibility to define the problem you are verifying your code against.

Re: Uncle Bob and Silver Bullets

#162

Post by s73ver_ »

_wc0m wrote: post #89
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…

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…

I agree with both, really. Those defects are our fault, and they are there because we aren't careful enough with the code we write. We know about these things, and yet, we don't work to prevent them. We either handwave them away, or we give into management pressures to just get the thing out the door.

Now, that said, one of the ways you can work to prevent these things is to use better tools. Like languages that don't let you make those kinds of mistakes as easily.

Re: Uncle Bob and Silver Bullets

#163

Post by s73ver_ »

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…

I want both: Better tools and more disciplined programmers. The tools will catch errors, and that's great. But they won't catch all the errors, whereas disciplined programmers will work to minimize the potential of them.

Re: Uncle Bob and Silver Bullets

#164

Post by s73ver_ »

eradicatethots wrote: post #74
gregmac wrote: post #59

Earlier quoted context omitted.

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.

I don’t see why we should make this a requirement of every programmer.

I don't see why we shouldn't.

Re: Uncle Bob and Silver Bullets

#165

Post by s73ver_ »

eradicatethots wrote: post #80
a-saleh wrote: post #73

Earlier quoted context omitted.

There are nuances. With this reasoning taken to extreme, would you in the end got rid of the compiler just force yourself to be more careful? And I kinda get your point, because I got in to the past to a point where I had passed through all of the checks for my PR with code that didn't actually work. I still think that checks I put in place for myself help me more than they make me more lax.

I don’t get why being lax is a bad thing lol. You’re not being lax randomly, you’re being lax because you learned that empirically you can afford it. Instead of wasting that energy on whatever discipline you used to have to apply, you can spend it on something of value. I don’t think it’s smart to get upset about life getting easier.

Because being lax leads to bugs.

Re: Uncle Bob and Silver Bullets

#166

Post by hannofcart »

If all we needed to write robust software was discipline, we wouldn't need high level programming languages. All we'd need is the documentation of the instruction set that we want to target.

Why are we still taking this geezer seriously?

Re: Uncle Bob and Silver Bullets

#167

Post by s73ver_ »

Stranger43 wrote: post #64
Terretta wrote: post #10

Here is the post this post is in response to: http://blog.cleancoder.com/uncle-bob/2017/10/04/CodeIsNotThe... I don’t interpret the original piece as saying any of these tools and techniques are not useful. I interpret it as saying average developer mindset needs to shape up. I tend to agree. I work with guys who believe in formal reasoning tools (we collaborated with Amazon’s ARG for example[1]), and use all these t…

It's Clear from that that it's been a while since Bob Martin worked in the real world with real bosses, budgets and deadlines. The problem is that the business tend to drive the "if it compiles, ship it culture" but also want to blame some lowly replaceable coder for any mistake so the organization and it's leaders can avoid any responsibility for any damage done due to their decisions to ship first and test later. A…

Because Uncle Bob isn't speaking to the CXO. He's speaking to those first line developers. And he's saying that those people need to push back, they need to stand up and tell the bosses that what they're doing is unsustainable.

Re: Uncle Bob and Silver Bullets

#168

Post by lkitching »

mishkovski wrote: post #161
bad_user wrote: post #155

Earlier quoted context omitted.

Static typing combined with functional programming is superior to automated testing, although the three are actually complementary, because automatic, property-based testing works better if you have type info (such that the library knows what values to generate) and referential transparency, because side effects can be awkward to specify as laws. So it is not a coincidence that Haskell developers have innovated testi…

Static typing or functional programming can protect you only from some types of problems. With automated tests you have the flexibility to define the problem you are verifying your code against.

By the same token, tests can only verify certain properties of a function. How could you test that a function is free from side-effects? How could you test it never returns null?

Re: Uncle Bob and Silver Bullets

#169

Post by AlexDenisov »

smacktoward wrote: post #116
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…

Or alternately: we can improve developers, but doing so is hugely expensive and time-consuming, and while we can improve them we can never make them perfect . So making tools that can be used safely by imperfect developers is always going to be simpler and more cost-effective.

Exactly, this is what I mean by "do not scale." It takes many years, if not decades for one to become a decent developer. We simply cannot afford this.

Re: Uncle Bob and Silver Bullets

#170

Post by jhayward »

eradicatethots wrote: post #110
_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…

Personally I’d prefer my language to let me fuck up.

> Personally I’d prefer my language to let me fuck up.

And as a (completely hypothetical) competitor of yours, I would support you using a language that encourages you to fuck up frequently.

Post reply on HN