Anybody who calls himself Uncle (outside of family context) can't expect to be taken seriously in my book. Maybe it's just me, but that seems like an appeal to authority right there in the name.
Is Uncle Bob serious?
101–110 of 181 posts
Re: Is Uncle Bob serious?
#102Earlier quoted context omitted.
> I don't understand people arguing against type systems on principle I believe these are the people who relate type systems to languages like C++ and Java, and dismiss type systems as a possible solutions because they've only seen the poor ones. Back when I wrote a lot of Java code I mostly used TDD to write software that works. The type system didn't help that much. Robert "Uncle Bob" Martin dismisses type systems…
Well if one can't get a job programming Idris, Coq or Haskell and they're not used in OSS infrastructure software either, what's the point of learning them? Then they literally have zero direct effect on improving the safety of anything. One would be better off learning TLA+ and coding in C, or using Frama-C or Misra etc.
> what's the point of learning them
I personally enjoy learning new languages and I can always apply the concepts I learn in other languages that are used on the job. Not judging others who don't enjoy that, though.
It's more surprising that there's no real incentive from companies to write better software. People seem to accept a whole lot of shit when it comes to their phones and computers, and are happy to pay for it.
Re: Is Uncle Bob serious?
#103Earlier quoted context omitted.
Bob Martin famously tried to write a Sudoku solver using TDD, he gave up after a few blog posts...
Do you have a link to that? This is too funny to pass up.
Just to clarify, it was Ron Jeffries who tried the TDD Sudoku solver, not Bob Martin.
You can find links to all the the blog posts, plus some commentary here:
http://ravimohan.blogspot.ca/2007/04/learning-from-sudoku-so...
I try not to be too hard on Jeffries in this case. Although he failed to write a Sudoku solver, expressing the requirements in the form of tests can be a decent way to start in cases where you know some valid outputs for a series of given inputs.
I tend to solve Leetcode/Hacker Rank problems this way, and it works pretty well. The catch is that the tests won't tell you what algorithm will best solve the problem. And there's of course no guarantee the tests you've thought up will cover all edge cases.
Re: Is Uncle Bob serious?
#104Earlier quoted context omitted.
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.
Sure they do, but how much is because of formalization?
I mean, just look at SQLite, which is a highly reliable software. They bought this stability with a gigantic test suite.
Re: Is Uncle Bob serious?
#105The 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 don't know about that... Doctors famously didn't even wash their hands between patients.
In fact many still don't. The best practices and process-oriented thinking seem to not be uniformly spread.
I'm also reading Normal Accidents by Perrow and what he says about nuclear safety up to the 80s (that's when the book was published) is scary.
My thoughts: our safest endeavours look and feel safe, but they are still more failure-prone than one would assume and making them safer is incredibly hard because of social, technical and human issues exhibiting hidden coupling - system issues.
Re: Is Uncle Bob serious?
#106The 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…
> 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 rush job of this surgery and it will probably work out fine.
Imaging right now. No problem. Humans are humans. Humans sometimes do rush jobs. Or are overworked. Or stressed. Maybe they have private problems, so their mind isn't 100% on the task.
Your suggestion that doctors are all professionals and wouldn't do such things is actually the exact opposite of the medicine professions conclusions: Humans make errors. Doctors, software developers, we all. And what helps to fix these things are better tools and allowing other people to check something (see above, nurses training to question doctors is exactly for this problems).
Re: Is Uncle Bob serious?
#107It is my continued theory that Bob Martin is a double agent, whose mission is to discredit TDD in the wider software community by using an infuriating, backlash-inducing writing style.
Bob Martin famously tried to write a Sudoku solver using TDD, he gave up after a few blog posts...
[deleted]
Re: Is Uncle Bob serious?
#108The 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.…
> My take: give it a few more years, and software, too, probably will follow the same path. I doubt it. The stakes are much lower than people's lives and health.
Agreed. Let's not forget that a huge portion of software written is games.
Re: Is Uncle Bob serious?
#109The 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.…
> My take: give it a few more years, and software, too, probably will follow the same path. I doubt it. The stakes are much lower than people's lives and health.
The Atlantic article that Uncle Bob was writing in response to lists several specific examples of software failures that did, or could have, resulted in loss of life: a failure of the 911 system; air traffic control systems; medical devices.
Re: Is Uncle Bob serious?
#110Earlier 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…
What stops your program data from being modified or tampwered with without ECC ram, bypassing your checks?