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

121–130 of 181 posts

Re: Is Uncle Bob serious?

#121

Post by maxxxxx »

sheepmullet wrote: post #100
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.…

> Back then, too, the thoughts on medical safety also were divided into 2 schools: the professionalism and the process oriented The key difference is in the medical world safety has been a primary concern from day one. I.e. There has always been a high level of professionalism. That is not true in the software world. Imagine a doctor saying it's 5pm on a Friday and I'm meeting a friend in an hour so I'll just do a ru…

"I've seen devs happily check in shoddy work just to be finished hundreds of times in my career"

From my experience a developer who does everything the correct way and takes his time do so has no chance of surviving in most companies. There is a lot of pressure from leadership to get things done quickly even if quality is compromised.

Re: Is Uncle Bob serious?

#122

Post by kazagistar »

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

> I'm not sure you're familiar enough with what a sufficiently powerful type system can accomplish. A sufficiently powerful type system can compute any partial recursive function at type check time. That's pretty much the upper bound.

The upper bound is arbitrary code, and validating arbitrary proofs.

Re: Is Uncle Bob serious?

#123

Post by SomeStupidPoint »

ec109685 wrote: post #110
SomeStupidPoint wrote: post #72

Earlier quoted context omitted.

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

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 better answers, I'm not an expert on software ECC.

(Tampering is a different issue -- if they can tamper with the program, ECC won't save you from them writing garbage to memory. So that a hack which can write memory can bypass memory safety isn't really interesting.)

Re: Is Uncle Bob serious?

#124

Post by masklinn »

maxxxxx wrote: post #120
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.…

I don't think you can compare software to other disciplines like medical, air transportation or architecture. These areas are well understood and pretty mature and move pretty slowly. If we ran air transportation like software somebody would already have self flying airplanes in service. They would crash from time to time though. I personally like the imperfection of software development and the freedom to imagine ne…

> I don't think you can compare software to other disciplines like medical, air transportation or architecture. These areas are well understood and pretty mature and move pretty slowly.

Architecture maybe. Air transportation is barely a century old, though you could make the argument that it's a offshoot of other industrial engineering disciplines.

When it comes to medicine however, while modern medicine is older than computer science it's not by much, and what's called medicine until the late 19th or early 20th century is as similar to modern medicine as computers of the early 20th century (aka rooms of people with rulers and mechanical calculators) are to computers of the second half.

And medicine has in fact changed at a pretty frenetic pace, the "miasma theory" was only vanquished circa 1880~1890, and we can now sample and edit living beings at coffee-cup price levels.

Re: Is Uncle Bob serious?

#125

Post by mannykannot »

sgift wrote: post #117
mannykannot wrote: post #53

Earlier quoted context omitted.

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

> NASA writes highly reliable software, as do the organizations producing the software for fly-by-wire airplanes, so your assertion is empirically false. What I find interesting is that both of your examples (and many others) are for software which controls physical systems, i.e. which is pretty well defined due to the nature of the machines it controls. Do you have comparable examples which aren't defined by the phy…

So are you arguing that very well-defined and carefully thought-out requirements are, in practice, essential to the development of high-quality software?

Re: Is Uncle Bob serious?

#126

Post by sbergot »

sheepmullet wrote: post #100
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.…

> Back then, too, the thoughts on medical safety also were divided into 2 schools: the professionalism and the process oriented The key difference is in the medical world safety has been a primary concern from day one. I.e. There has always been a high level of professionalism. That is not true in the software world. Imagine a doctor saying it's 5pm on a Friday and I'm meeting a friend in an hour so I'll just do a ru…

This an interesting article about medical processes: https://www.newyorker.com/magazine/2007/12/10/the-checklist

The gist of it is that introducing a checklist for bloodline infection prevention had an enormous impact on survival. It was still difficult to introduce the process.

Re: Is Uncle Bob serious?

#127

Post by EdSharkey »

planetjones wrote: post #38

This article by Uncle Bob has generated a lot of debate. I read it for the first time today and, I have to say, I am not impressed. too many programmers think that schedule pressure makes it OK to do a half-assed job This is solely blaming the programmer . I have been on software projects where someone is basically told deliver what you can by this date and then move onto something else. Then leave someone else to fi…

As the only experts on the code, Programmers need to learn to say 'no' when appropriate. When they stay silent like code monkeys, they deserve all the blame Uncle Bob and I can heap on them.

Re: Is Uncle Bob serious?

#128

Post by maxxxxx »

masklinn wrote: post #124
maxxxxx wrote: post #120

Earlier quoted context omitted.

I don't think you can compare software to other disciplines like medical, air transportation or architecture. These areas are well understood and pretty mature and move pretty slowly. If we ran air transportation like software somebody would already have self flying airplanes in service. They would crash from time to time though. I personally like the imperfection of software development and the freedom to imagine ne…

> I don't think you can compare software to other disciplines like medical, air transportation or architecture. These areas are well understood and pretty mature and move pretty slowly. Architecture maybe. Air transportation is barely a century old, though you could make the argument that it's a offshoot of other industrial engineering disciplines. When it comes to medicine however, while modern medicine is older tha…

I still would argue that medical is moving much slower than software. I work in medical devices and simple experiments can take years to get done once humans are involved. In software we would get the result in a few days or weeks. I am not advocating easing the restrictions in human experimentation but these rules definitely slow down progress.

Re: Is Uncle Bob serious?

#129

Post by sgift »

mannykannot wrote: post #125
sgift wrote: post #117

Earlier quoted context omitted.

> NASA writes highly reliable software, as do the organizations producing the software for fly-by-wire airplanes, so your assertion is empirically false. What I find interesting is that both of your examples (and many others) are for software which controls physical systems, i.e. which is pretty well defined due to the nature of the machines it controls. Do you have comparable examples which aren't defined by the phy…

So are you arguing that very well-defined and carefully thought-out requirements are, in practice, essential to the development of high-quality software?

That would be quite the no-brainer, wouldn't it be?

All the dancing around waterfall, agile or what ever turns around the problem that people usually don't know what their requirements are, are not able to formulate what their requirements are, but hopefully know when they see something it if something helps them or not. If we could just get people to define their requirements in all the detail needed we would take a great step forward, but looking around .. I don't see this happening in the near future.

Re: Is Uncle Bob serious?

#130

Post by jlg23 »

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.

Only in the first day or so. In my experience, that time is gained again several times over in the first medium refactoring.

Post reply on HN