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

171–180 of 228 posts

Re: Uncle Bob and Silver Bullets

#171

Post by Jtsummers »

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?

There is no best tool or technique because there is no silver bullet.

And what do you mean by automated testing? What kind of tests? Unit, integration, regression, black box, white box?

Automated testing is only one tool, that every system should be using. Manual testing is obviously too tedious (though sometimes required) to do for all test sequences for most systems so of course we need to automate.

But what do we test? How do we develop the tests?

Do we test type invariance constraints? In a dynamically typed language you absolutely should! In a statically typed language, you might need to. In C I need to test that my int foo is within the expected range. In Ada I can define a new type Foo which will always be within the right range. Both are statically typed, one offers more than the other.

How do we define a unit? Do I want tests of every class, of every function? Do I write unit tests for private portions of classes? What should be hidden from users as "implementation details", but actually matters to me as the implementer.

How do we actually test out concurrency bugs? I might have a concurrency bug that shows up in 1 of 20 potential traces of the concurrent system. But practically only shows up 1 time in 1,000,000. That's impossible to show with tests with any reliability, but almost trivial to show with TLA+ and some other formal methods (if you can abstract the concurrent algorithm properly). Maybe the bug only occurs when I have at least 10 users on the system, but is still rare or hard to force into existence.

The alternative: Learn static typing. Learn math. Learn formal methods. Learn multiple concurrency paradigms. Learn multiple languages. Internalize their concepts. When you write a program, design the program. Maybe not a full formal spec, but you need to know what it should do or you cannot verify it. You cannot have any confidence in it.

You use a dynamic language like Ruby? Guess what, you can make it do something like Ada's type system! Create a new class instead of using a generic integer that redefines + and - and other ops so that you get the desired properties (like range constraints or modular arithmetic) but still otherwise acts like an integer. You use a language like C that lets you clobber all over the memory in other threads. Great, learn about channels, semaphores, and message queues. Pick the appropriate subset (or library if viable) and design your concurrent algorithms in a disciplined fashion.

Re: Uncle Bob and Silver Bullets

#172

Post by jdmichal »

thomascgalvin wrote: post #87
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…

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

I'm actually a big fan of myBatis [0] for this very reason. You still write all the SQL, including stored procedures. All it does is map objects to input parameters, and map result sets to objects. Which is awesome, because that's the part of database processing that is actually tedious and sucks. Writing SQL is not.

I think StackExchange's Dapper [1] works similarly in the .NET world.

[0] https://github.com/mybatis/mybatis-3

[1] https://github.com/StackExchange/Dapper

Re: Uncle Bob and Silver Bullets

#173

Post by mwj »

Can we stop talking about Uncle Bob? He's like the old, weird, drunk, racist uncle at a wedding. His ideas haven't really been relevant for about 10 years, and he is increasingly posting ranty, politicised, attention-seeking diatribes...

Re: Uncle Bob and Silver Bullets

#174

Post by lgunsch »

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…

> 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).

I disagree strongly. Sure, there are a very few parts that are more relevant to Java. However, the vast majority of the book is easily applied to almost any language. There aren't many languages that don't have variable names, function/method names, modules, etc. Some of the OOP principles wouldn't easily apply to C, or other languages like it, but a lot of the other advice applies easily.

Re: Uncle Bob and Silver Bullets

#175

Post by mishkovski »

Jtsummers wrote: post #171
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?

There is no best tool or technique because there is no silver bullet. And what do you mean by automated testing? What kind of tests? Unit, integration, regression, black box, white box? Automated testing is only one tool, that every system should be using. Manual testing is obviously too tedious (though sometimes required) to do for all test sequences for most systems so of course we need to automate. But what do we…

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

Re: Uncle Bob and Silver Bullets

#176

Post by benmmurphy »

jdmichal wrote: post #172
thomascgalvin wrote: post #87

Earlier quoted context omitted.

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

I'm actually a big fan of myBatis [0] for this very reason. You still write all the SQL, including stored procedures. All it does is map objects to input parameters, and map result sets to objects. Which is awesome, because that's the part of database processing that is actually tedious and sucks. Writing SQL is not. I think StackExchange's Dapper [1] works similarly in the .NET world. [0] https://github.com/mybatis/…

this is pretty close to the sweet spot for me. being able to map rows to object easily + being able to easily compose queries are what i want from my 'ORM'. if your SQL layer doesn't support chaining conditions you end up writing it anyway so being able to do .and(condition).and(condition).and(condition), etc is pretty useful. ActiveRecord in rails comes close to this but it also manages relationships as well which makes things a bit more complicated but not as complicated as what hibernate or other ORMs do.

Re: Uncle Bob and Silver Bullets

#177

Post by [deleted] »

bad_user wrote: post #137
agentultra wrote: post #107

Earlier quoted context omitted.

Disclosure: I didn't like the talk. In Uncle Bob's view, which I assume has some popularity, unit-tests are a form of software specification. It's informal as the specification can only test specific examples of behavior based on a determined state and the people responsible for its maintenance are the programmers. And if you're not disciplined enough with how you write these tests you end up in a situation where you…

Building houses is not the right analogy to building software, because the used techniques are known and most new buildings are going to be exactly like the millions of other buildings that came before it, even when speaking of sky-scrapers. There's very little innovation in it. Building a new building is usually akin to copying/downloading software , only more expensive. Art is involved in designing buildings someti…

[deleted]

Re: Uncle Bob and Silver Bullets

#178

Post by mbizzle88 »

newsreader wrote: post #160

After reading the post by Hillel Wayne I decided to read Uncle Bob's article that is mentioned in the post ( http://blog.cleancoder.com/uncle-bob/2017/10/04/CodeIsNotThe... ). After reading both posts, and after reading most of the comments on this thread, I have to admit that my inclination is in favor of Uncle Bob. I agree with most of the points Uncle Bob made in his blog post. Tools are not the answer. TDD is not…

I disagree. Neither of them is saying anything is "the answer". They are merely putting emphasis on different things.

From that perspective, I would say that Uncle Bob is more wrong. It doesn't make sense to emphasise discipline before best practices. Discipline is about following through on things and avoiding short cuts. That means in order to have discipline, you first have to have a procedure you are meant to follow in the first place.

Additionally, Uncle Bob seems to look at things from the perspective: "If you're undisciplined, better tools can't make up for that." Sure.

But, IMO, Hillel's perspective is a lot more useful: "If you are disciplined, better tools will help you do better work."

Re: Uncle Bob and Silver Bullets

#179

Post by elihu »

mrleinad wrote: post #139
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…

That's quite a common issue when you're trying to emphasize a specific point. Uncle Bob's trying to make software developers care about their craft. He seems dismissive of any other techniques, but I think that's because he really wants people who read his posts and watch his videos to understand that specific point. If you already understand that point, then you're not the audience he's trying to talk to, and you're…

From "The Dark Path":

> Now, ask yourself why these defects happen too often. If your answer is that our languages don’t prevent them, then I strongly suggest that you quit your job and never think about being a programmer again; because defects are never the fault of our languages. Defects are the fault of programmers. It is programmers who create defects – not languages.

http://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath....

I think that software defects happen too often because the most widely used programming languages don't do enough to prevent them. That makes me the audience of this statement. And he says that I should abandon programming. I think that's rather presumptuous of him.

(I also think that on average programmers aren't careful enough and don't spend enough time making sure their stuff doesn't break, but I see that as primarily an economic problem. Most software companies are rewarded more for delivering features than closing the security holes. We can attack that problem either by finding some way to convince software vendors to pay for the tremendously expensive effort of testing software, or we can reduce the effort required by using stronger type systems and formal methods. The latter seems more realistic and attainable.)

Re: Uncle Bob and Silver Bullets

#180

Post by etblg »

jerf wrote: post #43
rootlocus wrote: post #40

Earlier quoted context omitted.

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

Bill Gates was actually a pretty decent programmer. His technical insights peter out somewhere in the 1980s or early 90s at most, but he's had some interesting things to say about those eras. (Interesting in the sense that it's someone speaking about the eras that was there in a big way, not necessarily because he's got surprising insights into software engineering or something.)

Do you have any links to his insights? They sound pretty interesting but I'm not sure what to search for to find them.
Post reply on HN