Live data from Hacker News

Uncle Bob and Silver Bullets

hillelwayne.com

121–130 of 228 posts

Re: Uncle Bob and Silver Bullets

#121

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…

Martin has built up a large following of acolytes, some of whom are very active wherever software development is discussed, in a very dogmatic way (such as the guys for whom TDD is the one true solution to every problem.) He has encouraged this through his didactic style of writing, which focuses on a few of the most basic faults in current development practice, and elevates them to being the roots of all evil, witho…

Agree with this. I like some of his ideas. But a problem I have(possibly of my perception) with uncle Bob is that he gets too aggressive. If you don't have X percent (100%) code coverage, then you are doing it wrong, you are not a craftsman, etc. Well, Dan North put things in perspective a bit- https://dannorth.net/2011/01/11/programming-is-not-a-craft/ The problem is dogma. And it keeps repeating. But probably this aggression helps them in their careers.

(Not a frequent contributor to comments/ here on HN. Mostly like to read.)

Re: Uncle Bob and Silver Bullets

#122
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.

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

Re: Uncle Bob and Silver Bullets

#123

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…

This post is not in response to just that post. It's important to take that post in the larger context of what Bob has said. He has many times implicitly (and some times explicitly) made the claim that typed languages are uninteresting because the type checker merely duplicates the work that unit tests accomplish.

As an aside, I rarely write unit tests, but I often use static analysis tools. I find that for the majority of the software I write, I get more bang for the buck with functional and integration tests than I do with unit tests.

Re: Uncle Bob and Silver Bullets

#124
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.

[deleted]

Re: Uncle Bob and Silver Bullets

#125
post #106
post #104

Earlier quoted context omitted.

What difference does an ORM make?

ORM's by and large do protect your from SQL injection attacks.

They don't. All decent ORMs have a layers architecture, and it's usually some "query builder/processor" or "DAL" or whatever that sits under/above the ORM your app uses (and can usually also be used directly, but has a horrible API since it's not optimized for this use case) that does the simple but tricky tasks of parameter sanitization and all...

The ORM is just an big fat thing that sits on top, and from which you only use 10% of the functionality it provides, but in theory each app uses a different 10% so it justifies itself...

ORMs can be ok... as long as you don't build business logic on top of and inseparable from it!

(As an example of horrible use of ORMs: some frameworks have ORM systems with an events system on top... god have mercy on your soul if you make the mistake of using this system to implement business logic, and end up with it accidentally depending on db connection and caching details, and not having time to refactor when you realize this! ...but if you avoid the trap, you can reap the benefits of the functionality that the ORM provides, while moving your logic at at a whole different layer of the app - hint: just invent a new "XBizLogicServices layer" or whatever and not import framework stuff into it if you can't find a better design, it will at least be easily testable.)

Re: Uncle Bob and Silver Bullets

#126

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…

I can attest: I wrote Ruby for many years, recently I've only been writing in languages with much stronger static analysis capabilities. I had to be much more disciplined when writing and reviewing Ruby code. Inevitably, I slipped up frequently in both disciplines, resulting in lots of bugs in the software and a chronic nagging worry in my psyche. I don't need to be as disciplined now, but I'm creating fewer bugs and…

The benefit of building checks into our languages (like static typing, design by contracts, etc.) is that they let you focus on higher level concerns.

If I have a language that will let me say that a Foo is one of {1,2,3} and will never allow any other integer variable's value to be put into a Foo variable (without explicit casting), I can now focus on my use of Foos and not have to add a type invariant test to every function that consumes or produces a Foo. This doesn't make me less disciplined. It shifts the discipline.

The disciplined programmer can spend all day putting in type invariant checks on their code. Or the disciplined programmer can spend 5 minutes determining what types they need to use, and spend the rest of the day writing out the actual business logic instead of a shit ton of boiler plate code and/or unit tests (which are hopefully comprehensive enough to catch these errors).

Re: Uncle Bob and Silver Bullets

#127

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…

> Lets take for example ORMs and Hibernate in particular. I can't tell you how many times I've seen horrors related to ORMs / Hibernate ... My teams don't use ORMs anymore. I've found that all of the time we "save" by not hand-writing SQL is instead lost fighting with the ORM, and problems with SQL are a lot easier to Google. I've also found that the ability to swap databases quickly is almost totally unimportant. 10…

Having worked on many systems like this, I generally don't really consider it to be better. Most of them just introduced different edge case behavior than Hibernate.

Though, I generally prefer a non-religious approach to ORM mapping anyway. Use Hibernate for the stuff that it is good at. If you find it awkward for some particular service, don't be afraid to grab a DB connection and do a bit of SQL (maybe even using Hibernate's powerful rowmapper functionality) when it is easier.

Any ORM is going to be a little rough in some cases (even ones you write yourself) and none fit all problems perfectly.

Re: Uncle Bob and Silver Bullets

#128
post #96
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 :)

You just reminded me of my old driving instructor.

"All accidents are your fault. Got rear-ended? Shouldn't have been driving so slowly, or shouldn't have stopped. Got t-boned? Should have looked more closely at the intersection. Skidded on ice? Shouldn't have been driving so quickly, or turned so sharply. Yes, you avoided the pedestrian, but that isn't an excuse. In extremis, you shouldn't have been driving that day at all, and you do always have that option, so it's your fault regardless."

The line between empowerment and victim blaming is surprisingly thin. ;)

Re: Uncle Bob and Silver Bullets

#129
post #125
post #106

Earlier quoted context omitted.

ORM's by and large do protect your from SQL injection attacks.

They don't. All decent ORMs have a layers architecture, and it's usually some "query builder/processor" or "DAL" or whatever that sits under/above the ORM your app uses (and can usually also be used directly, but has a horrible API since it's not optimized for this use case) that does the simple but tricky tasks of parameter sanitization and all... The ORM is just an big fat thing that sits on top, and from which you…

I wasn't defending ORM's.

I was just pointing out that if you use one you do receive protection from injection attacks. Just because only part of the ORM is actually performing the protection doesn't change the fact that you have it as a consequence of using the ORM.

You can also get the same protection by using a SQL library that supports prepared statements. But ORM's still provide that benefit.

Re: Uncle Bob and Silver Bullets

#130
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 fortune cookies, and at worst are profoundly bad advice.

Seriously, in TypeWars[1], he says “My own prediction is that TDD is the deciding factor. You don’t need static type checking if you have 100% unit test coverage. And, as we have repeatedly seen, unit test coverage close to 100% can, and is, being achieved. What’s more, the benefits of that achievement are enormous.”

This is so profoundly wrong on so many levels that it isn’t funny. How do you measure coverage? If you’re doing it by lines hit (which is how most dynamic language coverage tools do it), then you’re not getting any sense of how good your boundary conditions or branch coverage is. If you have a better way of measuring coverage (typically branch coverage), then maybe aiming toward 100% is good, but hitting 100% coverage is a complete waste of time. (I aim for ~85% coverage, depending on the code base and how much is boilerplate code.)

In Ruby, do you really need a unit test for:

    attr_accessor :foo
If you don’t at least access `foo`, SimpleCov will say that line isn’t covered. You know what? It doesn’t need coverage, because when you write a unit test for that you’re writing a unit test for the language.

Unless you’re actively adding “attack tests” to make sure you have all of your boundary conditions covered, and at least know you can abort or recover from an error condition properly, your 100% coverage means absolutely nothing. Property Checks are better for this. Fuzzing and mutation tests matter to help find this. Even static typing (of which I’m not actually a fan, because 15 years with C++ makes it clear that static typing is not that useful in weakly typed languages) can help find certain types of boundary conditions (look to Ada, where if you declare a type as a range 1..100, only values within that range, or variables that can never exceed that range, can be used with that range).

And people take Uncle Bob seriously, even when he posts things that are just asinine attacks on people who have taken him to task when he is wrong (which, IMO, is far more often than he’s right).

[1] http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.htm...

Post reply on HN