Live data from Hacker News

Uncle Bob and Silver Bullets

hillelwayne.com

201–210 of 228 posts

Re: Uncle Bob and Silver Bullets

#201

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…

Type systems do not force programmers to be disciplined. Type systems tempt programmers to cheat.

I cannot conceive of how type systems enable "cheating". Mostly, I see people cheating by reducing everything to a handful of types and not exercising the system as much as it might be.

An expressive type system allows me to formally specify parts of my system, and have the language itself enforce those constraints. It's much better for me to be able to say:

  type Byte is mod 256;
And now any instance of Byte cannot end up larger than 256. In this example, most languages can achieve the same thing as they have an 8-bit unsigned int type. But in Ada I can do this for any arbitrary (positive, I assume, never tried negative) integer after the mod (up the the system's Integer'Last). I don't have to test every time I assign into a variable of this type. I don't have to test after every computation to make sure it's still within the range. It just happens for me. This isn't cheating, this is using my tools to enable me to focus on the overall design and not the menial boilerplate of range checking everything.

Re: Uncle Bob and Silver Bullets

#202
post #89

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…

He didn't condemn Kotlin and swift. He is saying that they aren't necessary and don't solve the original problem. That the constant search for a new framework or of language that will fix everything is a futile attempt to avoid learning how to more effectively code with the tools you already have.

Re: Uncle Bob and Silver Bullets

#203
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…

I can see how that would be popular but it's wrong. You can take that same reasoning and say we should build web projects in C or assembly because any defects are our own fault. Let's be honest. That's bollocks. It's just the same old "real programmers use X" line. I'm sure there's an XKCD that parodies it. Sure we need more discipline. Who doesn't? Yet that discipline is far better spent on doing what the compiler c…

Using C as an example is a straw man. There's been A LOT of progress since C. Can you say the same for Java or Python? Not as much.

Re: Uncle Bob and Silver Bullets

#204
post #68

This is unfortunately a very defensive article. The author would do better if he chilled out a bit. I get why he's defensive: Martin calls his baby out in his article. And, although I think that Martin himself comes across as defensive (he is alarmed that the journalists didn't interview 'real' experts like himself), I also don't think he is wrong. In fact, as a practitioner for over 20 years, I've witnessed first-ha…

I can't imagine many other industries as rife with false economies as Software Engineering. There are so incredibly many opportunities to appear to get things done quickly today, only to find that you've hamstrung your future self.

Re: Uncle Bob and Silver Bullets

#206

Earlier quoted context omitted.

I meant automated testing(any kind) vs no automated testing. Most of us don't do any kind of automated testing.

I'm finding it hard to imagine any place that does no automated testing, but then I started my career as a tester and later became a verification engineer before moving to development. I'll agree with you, if you have no automated testing then that should be the first priority for a dev shop. By this I mean, if testing is: follow this instruction sheet and do each step, hopefully we've made enough of these and it's t…

>if you have no automated testing then that should be the first priority for a dev shop

This is the key point.

Re: Uncle Bob and Silver Bullets

#207

Earlier quoted context omitted.

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…

It's the CEO's job to demand the impossible. It's the engineer's job to deal with reality. When the engineer tells the CEO that the impossible is possible, the engineer has forsaken his/her responsibilities.

It's also the engineer's job to make rent and pay their health insurance despite unreasonable demands. But apparently the only part of this labor issue we want to discuss is the nobility of sacrifice.

Re: Uncle Bob and Silver Bullets

#208

Earlier quoted context omitted.

Type systems do not force programmers to be disciplined. Type systems tempt programmers to cheat.

I cannot conceive of how type systems enable "cheating". Mostly, I see people cheating by reducing everything to a handful of types and not exercising the system as much as it might be. An expressive type system allows me to formally specify parts of my system, and have the language itself enforce those constraints. It's much better for me to be able to say: type Byte is mod 256; And now any instance of Byte cannot e…

I don't think he means they enable cheating, I think he means they frustrate developers who then try and find ways around the type system. Types pissing you off, just declare everything object and cast when you need to.

You're talking about leveraging the type system to help you, but that requires fully liking and understanding the type system, many devs don't understand the type systems they're forced to work with, don't understand how to leverage it, and don't like creating new types. Most devs have a primitive obsession and don't much create their own data types.

Re: Uncle Bob and Silver Bullets

#209

Earlier quoted context omitted.

I cannot conceive of how type systems enable "cheating". Mostly, I see people cheating by reducing everything to a handful of types and not exercising the system as much as it might be. An expressive type system allows me to formally specify parts of my system, and have the language itself enforce those constraints. It's much better for me to be able to say: type Byte is mod 256; And now any instance of Byte cannot e…

I don't think he means they enable cheating, I think he means they frustrate developers who then try and find ways around the type system. Types pissing you off, just declare everything object and cast when you need to. You're talking about leveraging the type system to help you, but that requires fully liking and understanding the type system, many devs don't understand the type systems they're forced to work with,…

> You're talking about leveraging the type system to help you, but that requires fully liking and understanding the type system

To the extent this is true (it requires understanding, but not liking—tolerating enough to actually put the effort into use it well, sure) TDD is no different in this regard, it's just that even with that the best case guarantees it provides are weaker.

Re: Uncle Bob and Silver Bullets

#210
post #203

Earlier quoted context omitted.

I can see how that would be popular but it's wrong. You can take that same reasoning and say we should build web projects in C or assembly because any defects are our own fault. Let's be honest. That's bollocks. It's just the same old "real programmers use X" line. I'm sure there's an XKCD that parodies it. Sure we need more discipline. Who doesn't? Yet that discipline is far better spent on doing what the compiler c…

Using C as an example is a straw man. There's been A LOT of progress since C. Can you say the same for Java or Python? Not as much.

No it's not. It's the same argument we've had about any kind of progress in programming languages since we started using higher level languages (I.e Fortran and up).
Post reply on HN