Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is Uncle Bob serious?

dev.to

Post reply on HN
Print view View original

81–90 of 181 posts

Re: Is Uncle Bob serious?

#81

Post by magice »

coldtea wrote: post #56
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 o…

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

That's purely guesswork. Seriously! My observation is that as the size of the project grows, type system switches from hindrances to actually speed up development and save developer time. Ever try to grep weakly typed system for name definition? Yeah, you don't have that problem in strongly typed system. Lots of other reasoning are easier to do with types than without.

Re: Is Uncle Bob serious?

#82

Post by notacoward »

Part of being a professional is listening to the experts and, even more importantly, paying attention to the data. This applies to criticism of the software industry as much as to the industry itself. I think what rubbed a lot of people the wrong way about Uncle Bob's piece is that even as it called for greater professionalism none was evident in the article's own construction, and that seems rather hypocritical.

Re: Is Uncle Bob serious?

#83

Post by icebraining »

tptacek wrote: post #33
maaaats wrote: post #16

Earlier quoted context omitted.

Couldn't the same be said of yours or any other's comments here on HN?

Of course. I don't see a lot of stories written about me being wrong about stuff, and I'm like 96% sure that's not because I'm right all the time.

You can thank cperciva for the honor :)

http://www.daemonology.net/blog/2013-06-17-crypto-science-no...

Re: Is Uncle Bob serious?

#84

Post by blub »

gipp wrote: post #68
blub wrote: post #50

Earlier quoted context omitted.

Type systems are not enough. I'm not sure they're even a good starting point for safety critical software, but they might be good for e.g browsers. You're thinking at code level, people like Leveson, Knight and others are thinking at system level. The end goal is to have a safe system, not e.g avoid null pointer exceptions through optional types.

I'm not sure you're familiar enough with what a sufficiently powerful type system can accomplish. A full dependent type system is sufficient to statically prove that code meets a given specification. We're not just talking about ints and strings and optionals when we talk about type systems for correct software. See Curry-Howard correspondence.

Do I need to know more than what you said - that they can prove that code meets a spec?

This can work awesome for small programs and clear algorithms, but as is hinted in the article, one has to first create a correct specification.

I gave an example in another post, here's another: unforeseen interactions between two components built to spec.

Re: Is Uncle Bob serious?

#85

Post by naasking »

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…

> That's the thing though, the "social problems" are the important problems.

And yet, we still seem bogged down with bugs and vulnerabilities caused by non-social problems. So use types to get rid of those problems, and then we can worry about the social problems.

> Lack of strong typing does not seem to be the issue. Lacking domain understanding/logical errors is the problem.

Types help with this too. Formalizing a property that is inconsistent, underspecified, or over-constrained is a natural part of designing a type to represent that property.

Re: Is Uncle Bob serious?

#86

Post by wyager »

blub wrote: post #60
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'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.

Sounds like the Therac incident was caused by a concurrency error. Type systems can prevent this via type-level ownership systems (a la Rust) or safe concurrency types (a la Haskell’s STM).

Re: Is Uncle Bob serious?

#87

Post by blub »

dkersten wrote: post #73
blub wrote: post #60

Earlier quoted context omitted.

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.

So because a tool can't prevent all possible faults or problems, that tool isn't worthwhile? I see it like this: we have a number of different tools to minimise problems (various types of testing, theorem provers, type systems etc). Non of them catch every problem and many of the tools overlap in the types of problems they do catch, but if you use many of these techniques together, then you minimise the surface area…

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

Pay attention, please!

Re: Is Uncle Bob serious?

#88

Post by dkersten »

blub wrote: post #71
zoul wrote: post #63

Earlier quoted context omitted.

Optional types are a good example of how types make a system safer.

I think they're great! I am pushing to use them in our C++ code base and they empirically do improve safety by transforming UB into a nice exception. But they won't prevent a programmer from using MD5 for RSA signature verification.

But if all of these things are correctly typed, then it would be visually more likely for someone to notice that the algorithm doesn't return the type it says.

Also, C++ static types are rather weak. Its optional types are useful, but its not like in SML where the compiler ensures that you handled all possible cases.

A good type system can't catch all kinds of errors though.

Re: Is Uncle Bob serious?

#89

Post by [deleted] »

dkersten wrote: post #73
blub wrote: post #60

Earlier quoted context omitted.

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.

So because a tool can't prevent all possible faults or problems, that tool isn't worthwhile? I see it like this: we have a number of different tools to minimise problems (various types of testing, theorem provers, type systems etc). Non of them catch every problem and many of the tools overlap in the types of problems they do catch, but if you use many of these techniques together, then you minimise the surface area…

[deleted]

Re: Is Uncle Bob serious?

#90

Post by planteen »

blub wrote: post #84
gipp wrote: post #68

Earlier quoted context omitted.

I'm not sure you're familiar enough with what a sufficiently powerful type system can accomplish. A full dependent type system is sufficient to statically prove that code meets a given specification. We're not just talking about ints and strings and optionals when we talk about type systems for correct software. See Curry-Howard correspondence.

Do I need to know more than what you said - that they can prove that code meets a spec? This can work awesome for small programs and clear algorithms, but as is hinted in the article, one has to first create a correct specification. I gave an example in another post, here's another: unforeseen interactions between two components built to spec.

I completely agree - most often the spec is wrong. For example, it doesn't matter if you have a completely correct implementation of Euler angles for a control system. If gimbal lock wasn't considered in the spec, you are going to have issues.
Post reply on HN