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

161–170 of 181 posts

Re: Is Uncle Bob serious?

#161

Post by blub »

kazinator wrote: post #93
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.

Maybe I'm recalling things wrong (the incident is very old and I last read the details before some HN-ers here were born), but at the heart of the Therac-25 issue was flaky code, written in a language without any type enforcement (assembly language). What's worse, the code was juggling concurrent events with interrupts and whatnot and was laden with race conditions (probably a phrase not even in the developer's vocab…

Pages 42-end of Leveson's report explain the fixes put in place and the contributing causes.

Software bugs are a contributing factor, but the report warns against focusing myopically on the bugs.

Re: Is Uncle Bob serious?

#162

Post by blub »

SomeStupidPoint wrote: post #72
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.

> Or even better how type systems could work around data integrity errors in RAM without ECC. You realize that you can do ECC in software too, right? You just need the statistical bound on a double fault to be similar to that of the hardware case. Type systems can be used to do this by defining an interface for the data, letting you swap between normal datatypes and ECC ones seamlessly. (And in practice, you only nee…

You need to read Leveson's full report. It details quite clearly what role software played.

If you're focusing on software and avoiding bugs you will at best have good quality software, when the goal is to have a safe system. SW is just part of the picture.

Re: Is Uncle Bob serious?

#163

Post by red75prime »

blub wrote: post #87
dkersten wrote: post #73

Earlier quoted context omitted.

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!

OP hasn't said that it's the answer to the hardware problems as well.

Re: Is Uncle Bob serious?

#164

Post by ec109685 »

SomeStupidPoint wrote: post #123
ec109685 wrote: post #110

Earlier quoted context omitted.

What stops your program data from being modified or tampwered with without ECC ram, bypassing your checks?

I'm not sure I understand your question, but the one that most pertains to ECC would be preventing corruption of the routine performing the checks -- It varies greatly by the method you use to ECC in software, since they all feature different mechanisms. In the case of the one I had in mind, the kernel is relatively small (so errors are unlikely), and once loaded, it's stable against bit errors. There are probably be…

I meant tampering via a side channel attack (e.g. forcing a bit flip that ecc would protect). It doesn’t matter if your data types have referential integrity if a hacker could disable that protection.

What I am arguing against is saying a typesafe language obviates the need for ecc memory.

Re: Is Uncle Bob serious?

#165

Post by EdSharkey »

jefe_ wrote: post #70

It is very important to have QA people the engineers respect. What makes a QA person respectable? Strong understanding of the business logic. Clear communication skills. Strong awareness that they cannot build the system, but a strong understanding of how systems operate. They work as hard testing as engineers work building, and deliver their findings efficiently. They can accurately evaluate the magnitude of an issu…

Or, fire your QA team, who are insanely expensive manual test script running human robots.

Professional software developers have control of their code and don't shift the blame for their quality issues onto other teams.

Re: Is Uncle Bob serious?

#166

Post by SAI_Peregrinus »

icebraining wrote: post #83
tptacek wrote: post #33

Earlier quoted context omitted.

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

I think they're both right. You don't learn cryptography by coding, but at the same time you don't attack cryptographic implementations with mathematics. The design of the algorithms is a science, the construction of the programs which use them is engineering. And the even more modern crypto algorithms have started to take into account the engineering side through side-channel resistance and the like.

Re: Is Uncle Bob serious?

#167

Post by koide »

walterstucco wrote: post #137
magice wrote: post #74

The current state of software safety discussion resembles the state of medical safety discussion 2, 3 decades ago (yeah, software is really really behind time). Back then, too, the thoughts on medical safety also were divided into 2 schools: the professionalism and the process oriented. The former school argues more or less what Uncle Bob argues: blame the damned and * who made the mistakes; be more careful, damn it.…

So basically work is safer when done by robots Or if you spend a lot of resources in training people to robotize them I prefer real robots

Except when something unexpected happens, in which case you'd love having had a human. The best is combined teams of man and machines. This also has its own problems, but nothing is ever perfect.

Re: Is Uncle Bob serious?

#168

Post by throwawayReply »

soru wrote: post #153
throwawayReply wrote: post #57

Earlier quoted context omitted.

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.

This is kind of precisely backwards. A survey is like a test; it asks 'will this work'? A good civil engineer will do that as early as possible, rather than produce pages of engineering drawings blindly. A good civil engineer will calculate the stresses and load factors on a bridge as soon as possible, rather than assume things will work. A good architect will hand a sketch of a building to a client as early as possi…

A test is only a test if it can fail.

All the projects I've seen, even the ones where there are "minimum viable projects" have too much pressure from above (or have already been sold) so they aren't allowed to fail.

So I agree testing should happen as early as possible, but too often they're not real tests because failure isn't allowed.

Re: Is Uncle Bob serious?

#169

Post by blub »

red75prime wrote: post #163
blub wrote: post #87

Earlier quoted context omitted.

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!

OP hasn't said that it's the answer to the hardware problems as well.

One needs to consider the safety of the system as a whole in order to build a safe system.

Leaving aside social problems for instance is a bit like saying that one can build perfect software, with the small issue that it can't be used by humans.

Leaving aside hardware is even more suspicious, because the two are inseparable in a system.

Re: Is Uncle Bob serious?

#170

Post by carlmr »

blub wrote: post #160
carlmr wrote: post #27

Earlier quoted context omitted.

I read his books and they're pretty good in showing Junior developers better ways to structure their code. This doesn't mean that Uncle Bob is right on every topic. Safety critical software is completely out of his realm (at least I don't know of any project he worked on that's SC). From my own experience I've seen quite a few safety critical codebases and they're often abhorrent in lack of common sense software stru…

They're not, he doesn't back up his recommendations with data, and instead expects readers to believe that they are appropriate and correct.

Neither do any other coding guidelines I've seen. What data do you want to gather about whether a name could replace a comment? It's like structuring an essay has a lot of rules, that you can break if you know what you're doing, but if you're just starting to write will help you be more clear in conveying your message.

It's all subjective.

Post reply on HN