Is Uncle Bob serious? • Hacker News Board

Re: Is Uncle Bob serious?

#51

Post by crdoconnor » Tue, Oct 10, 2017, 1:01 PM UTC

tpush wrote: post #26

Curiously, in the list of possible future tools for more reliability type systems are absent. Looking at the authors bio: "I love solving tough problems with Python and PHP". Type systems to me seem to be (I'm not exaggerating) the answer to all software reliability problems (barring social ones). If you want a property to uphold, formulate it as a type. The compiler verifies. If formulating the type is to laborious,…

>Personally, I don't understand people arguing against type systems on principle.

Even Uncle Bob wasn't, I don't think. He just said that certain languages had type systems with a level of strictness that he considered too extreme.

>Type systems to me seem to be (I'm not exaggerating) the answer to all software reliability problems

No, not all, only certain classes.

With haskell, for example, that comes at the expense of development velocity and performance (or at least, the ability to reason about performance).

>There has to be something I'm missing since there are so many people arguing against types, notably Bob Martin himself.

I think the key part people miss in the "more strictness" argument is that stricter types lengthen development and if your biggest risk is errors in specification (the article makes assertion and in my domains, that's been my experience too), so you are risking a vast amount of wasted time spent on perfecting the wrong thing.

Re: Is Uncle Bob serious?

#52

Post by Silhouette » Tue, Oct 10, 2017, 1:03 PM UTC

erokar wrote: post #37

tpush wrote: post #26

Curiously, in the list of possible future tools for more reliability type systems are absent. Looking at the authors bio: "I love solving tough problems with Python and PHP". Type systems to me seem to be (I'm not exaggerating) the answer to all software reliability problems (barring social ones). If you want a property to uphold, formulate it as a type. The compiler verifies. If formulating the type is to laborious,…

> Type systems to me seem to be (I'm not exaggerating) the answer to all software reliability problems (barring social ones). That's the thing though, the "social problems" are the important problems. I think it's a given you should use strong type systems in safety critical software — Haskell, for instance. But look at the quote from Dr Nancy Leveson: I've been doing this for thirty-six years. I've read hundreds of…

I've been doing this for thirty-six years. I've read hundreds of accident reports and many of them have software in them. And every someone (sic) that software was related, it was a requirements problem. It was not a coding problem.

That part put me off, because while awareness of problems with the requirements themselves is much lower than IMHO it could beneficially be, the casual dismissal of coding errors as another cause of failures makes me question where this "expert" has any idea what they're talking about at all, thirty-six years or not. There is a reason that Tony Hoare called inventing null references his billion-dollar mistake!

Edit: Having watched the original presentation by that speaker, in context and without any emphasis or commentary added by anyone else, the above criticism is unfair and I apologise for it. I think the subsequent discussions of it here may be putting more weight on that line than is justified, though, as you still have to have enough other mechanisms in place to avoid the coding errors making it into production before Dr Leveson's comments would apply.

Re: Is Uncle Bob serious?

#53

Post by mannykannot » Tue, Oct 10, 2017, 1:03 PM UTC

k__ wrote: post #43

mannykannot wrote: post #23

Earlier quoted context omitted.

In principle, 'agile' is so weakly defined that it is possible to follow a process that produces quality software and describe it as agile. In practice, insofar as agile stands for anything at all, one of its pillars is what might be called an 'active disinterest' in doing much thinking ahead, and in practice, it is very hard to produce quality software without doing some serious thinking ahead.

Is this really true? I have the feeling "producing software" is a highly volatile process. First, software can do almost everything. You have WhatsApp, DOOM, Photoshop, Ableton Live, Google, Linux etc. which are hugely different systems and it was just the stuff that came to my mind in 10 seconds. Second, the requirements change and change. One person thinking ahead and getting a brilliant idea may end up with produc…

> I think the reason for the fact, that it hasn't been formalized and regulated like, for example, building cars, is simply that it can't be.

NASA writes highly reliable software, as do the organizations producing the software for fly-by-wire airplanes, so your assertion is empirically false. You are extrapolating too far from your personal level of knowledge and experience.

Re: Is Uncle Bob serious?

#54

Post by solatic » Tue, Oct 10, 2017, 1:04 PM UTC

erokar wrote: post #37

tpush wrote: post #26

Curiously, in the list of possible future tools for more reliability type systems are absent. Looking at the authors bio: "I love solving tough problems with Python and PHP". Type systems to me seem to be (I'm not exaggerating) the answer to all software reliability problems (barring social ones). If you want a property to uphold, formulate it as a type. The compiler verifies. If formulating the type is to laborious,…

> Type systems to me seem to be (I'm not exaggerating) the answer to all software reliability problems (barring social ones). That's the thing though, the "social problems" are the important problems. I think it's a given you should use strong type systems in safety critical software — Haskell, for instance. But look at the quote from Dr Nancy Leveson: I've been doing this for thirty-six years. I've read hundreds of…

There is the school of thought though that type-driven development, by forcing domain understanding to be expressed in terms of types, helps to create common domain understanding among the different stakeholders.

Re: Is Uncle Bob serious?

#55

Post by agentultra » Tue, Oct 10, 2017, 1:05 PM UTC

My hunch is that tools like TLA+ and Lean[0] are bringing down the total cost of developing more reliable software.

And developing software that is reliable shouldn't be relegated to the safety-critical applications. There are ways that software failures can still cause significant harm even without putting human lives at risk: security errors allowing bad actors to steal personally identifying information, funds, or otherwise disrupt services that could harm people. This costs people their livelihoods, affects insurance rates for everyone, etc, etc.

I think the software industry needs to be more accountable for the influence we're having over the lives of the public and in order to write more secure, safer systems we need better tools to check our specifications, constrain our implementations, and help us manage complexity.

[0] https://leanprover.github.io/

Re: Is Uncle Bob serious?

#56

Post by coldtea » Tue, Oct 10, 2017, 1:09 PM UTC

tpush wrote: post #26

Curiously, in the list of possible future tools for more reliability type systems are absent. Looking at the authors bio: "I love solving tough problems with Python and PHP". Type systems to me seem to be (I'm not exaggerating) the answer to all software reliability problems (barring social ones). If you want a property to uphold, formulate it as a type. The compiler verifies. If formulating the type is to laborious,…

>Type systems to me seem to be (I'm not exaggerating) the answer to all software reliability problems (barring social ones).

Yes, but they increase delivery time problems and developer time problems.

In the end, the industry has decided getting something out cheaper and faster is worth more than getting it out correct code-wise but later or more expensively.

Which might make perfect sense -- what's correct depends on business needs -- and some layers might be totally irrelevant (e.g. program design) as to that.

>Personally, I don't understand people arguing against type systems on principle. Sure, they are type systems that suck (e.g. Java) or are otherwise very verbose and thus straining. But that doesn't have to be the case, it's not an intrinsic property of type systems.

No, but not liking type systems might be an intrisic property of some programmers.

Re: Is Uncle Bob serious?

#57

Post by throwawayReply » Tue, Oct 10, 2017, 1:09 PM UTC

sgift wrote: post #8

_pmf_ wrote: post #6

Earlier quoted context omitted.

> They have higher standards and whatnot Note that "higher standards" in civil engineering usually boils down to a) having standards at all instead of fuzzy process management frameworks b) these standards often boil down to "do this task/product with this regulatory mandated large margin of error" and c) building according to specification (i.e. having a reliable specification in the first place), which is exactly h…

> Embracing agile (as his ThoughtWorks contract requires him to do) while lamenting quality and lack of professionalism, as Mr Martin does, is extremely dishonest. Why exactly? I fail to see the connection between lack of quality and embracing agile.

Civil engineers don't I suppose agree to build a bridge before they've surveyed the land and then begin construction before knowing the loads.

Contrast that to software engineering, where beginning before you have requirements is seen as a requirement of being agile.

Re: Is Uncle Bob serious?

#58

Post by coldtea » Tue, Oct 10, 2017, 1:12 PM UTC

Silhouette wrote: post #52

erokar wrote: post #37

Earlier quoted context omitted.

> Type systems to me seem to be (I'm not exaggerating) the answer to all software reliability problems (barring social ones). That's the thing though, the "social problems" are the important problems. I think it's a given you should use strong type systems in safety critical software — Haskell, for instance. But look at the quote from Dr Nancy Leveson: I've been doing this for thirty-six years. I've read hundreds of…

I've been doing this for thirty-six years. I've read hundreds of accident reports and many of them have software in them. And every someone (sic) that software was related, it was a requirements problem. It was not a coding problem. That part put me off, because while awareness of problems with the requirements themselves is much lower than IMHO it could beneficially be, the casual dismissal of coding errors as anoth…

>the casual dismissal of coding errors as another cause of failures makes me question where this "expert" has any idea what they're talking about at all, thirty-six years or not

They don't dismiss them casually. She dismisses them because of actual experience on not having seen those matter much for 36 years, in all kinds of scenarios where she was explicitly looking for such things.

>There is a reason that Tony Hoare called inventing null references his billion-dollar mistake!

Which is neither here nor there, as in the domain we're she works, they don't allow those mistakes to go through to begin with.

Re: Is Uncle Bob serious?

#59

Post by fsloth » Tue, Oct 10, 2017, 1:12 PM UTC

Silhouette wrote: post #52

erokar wrote: post #37

Earlier quoted context omitted.

> Type systems to me seem to be (I'm not exaggerating) the answer to all software reliability problems (barring social ones). That's the thing though, the "social problems" are the important problems. I think it's a given you should use strong type systems in safety critical software — Haskell, for instance. But look at the quote from Dr Nancy Leveson: I've been doing this for thirty-six years. I've read hundreds of…

I've been doing this for thirty-six years. I've read hundreds of accident reports and many of them have software in them. And every someone (sic) that software was related, it was a requirements problem. It was not a coding problem. That part put me off, because while awareness of problems with the requirements themselves is much lower than IMHO it could beneficially be, the casual dismissal of coding errors as anoth…

"casual dismissal of coding errors as another cause of failures"

It'd not casual dismissal. What she says that despite how good a job developers do, not understanding the basic domain where the software operates will lead to a failure in production environment.

Which, really, makes sense. Requirements drive the test envelope. Generally, people try to test the product they are releasing - but if they do not foresee a testable scenario then that is not tested.

The best way to let bugs slip through is not to test against them.

Re: Is Uncle Bob serious?

#60

Post by blub » Tue, Oct 10, 2017, 1:14 PM UTC

erokar wrote: post #37

tpush wrote: post #26

Curiously, in the list of possible future tools for more reliability type systems are absent. Looking at the authors bio: "I love solving tough problems with Python and PHP". Type systems to me seem to be (I'm not exaggerating) the answer to all software reliability problems (barring social ones). If you want a property to uphold, formulate it as a type. The compiler verifies. If formulating the type is to laborious,…

> Type systems to me seem to be (I'm not exaggerating) the answer to all software reliability problems (barring social ones). That's the thing though, the "social problems" are the important problems. I think it's a given you should use strong type systems in safety critical software — Haskell, for instance. But look at the quote from Dr Nancy Leveson: I've been doing this for thirty-six years. I've read hundreds of…

I'm curious how OP would prevent the Therac incident through type systems...

Key quote: "Previous models had hardware interlocks in place to prevent this, but Therac-25 had removed them, depending instead on software interlocks for safety."

Or even better how type systems could work around data integrity errors in RAM without ECC.