Is Uncle Bob serious? • Hacker News Board

Re: Is Uncle Bob serious?

#61

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

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…

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

I wish they'd stop writing shitty, ad hoc type systems into our production code, then.

Re: Is Uncle Bob serious?

#62

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

shadowmint wrote: post #24

We already have tools that let us do the 'right thing' if we spend enough time and money on it. Another relevant quote from that paper, with regard to formal verification methods: > Any new software technology in this field must address both the cost and time issues. The challenge here is daunting because a reductions of a few percent is not going to make much of an impact. > Something like an order of magnitude is r…

> ...if we spend enough time and money on it.

This is a much deeper thought than it's getting credit for.

The tools and discipline are all there. People just don't want to spend the money for them. Developers and their leaders don't get raises and promotions for meeting quality metrics. Product owners don't listen to people who produce exceptionally quality products (they listen to people who say 'yes' to unrealistic plans a lot, regardless of quality).

Why don't people want to spend the money? Sometimes they literally can't afford it. The suits are still iterating on their business plans and haven't factored in the true cost of developing the product they will ship (which, as all software professionals know, is different than the product they think they're making).

Sometimes people can but don't afford the work necessary to product a quality product. Way too often I see developers give a reasonable estimate that gets stripped down because a deadline (usually arbitrary) budget or deadline has already been set. Likewise, I see estimates get pared down because they seem too big. I also see (probably unintentional) budget shopping, where managers ask for estimates from a few places and then (surprise!) think the smallest estimate is probably the accurate one.

So we can go on and on about tools versus discipline, but it all boils down to incentives and selection bias. We need to figure out how to communicate quality to stakeholders. Or, if that's to technically difficult, we at least need to figure out how to impart reputation to people who can provide subjective (but better) evaluations of quality for experts to rely on.

Re: Is Uncle Bob serious?

#63

Post by zoul » Tue, Oct 10, 2017, 1:15 PM UTC

blub wrote: post #50

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

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

Re: Is Uncle Bob serious?

#64

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

crdoconnor wrote: post #51

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

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

That seems a little unfair. The biggest challenge with reasoning about performance in Haskell is usually its non-strict semantics. That issue is only incidentally related to Haskell's type system being significantly more capable than those of many other programming languages.

Re: Is Uncle Bob serious?

#65

Post by pryelluw » Tue, Oct 10, 2017, 1:18 PM UTC

gaius wrote: post #40

jacques_chester wrote: post #5

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

Do you have a link to that? This is too funny to pass up.

Re: Is Uncle Bob serious?

#66

Post by raverbashing » Tue, Oct 10, 2017, 1:18 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,…

Division by zero is not a type problem, though it could be solved by creating a 'integer but not zero' type

I'm sure if you spent the day creating types your software would be very reliable. It would also probably not do much

"Relying on the power of type checking" is just wishful thinking that breaks down in the face of any moderately complex problem

The problem of course is not the type system, the problem is people creating types that contain one int/string only when a boolean would suffice, or 10 types of almost similar containers because for some people "ifs are forbidden"

Also reality likes to mess with well-oredered hierarchies

Re: Is Uncle Bob serious?

#67

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

bjpbakker wrote: post #45

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

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

Re: Is Uncle Bob serious?

#68

Post by gipp » Tue, Oct 10, 2017, 1:21 PM UTC

blub wrote: post #50

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

Re: Is Uncle Bob serious?

#69

Post by tpush » Tue, Oct 10, 2017, 1:22 PM UTC

crdoconnor wrote: post #51

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

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

The (depending on perspective) weaker ability to reason about performance in Haskell stems from laziness, which itself has nothing to do with type systems. It's clashes with side-effects are solved _via_ the type system (The IO type).

Regarding development velocity: _The developers_ are choosing how much time they spent on proving things to the type checker.

Sure, writing a function that requires of its argument the type { n % 2 == 0 } or something is more labor intensive than just using Int and runtime panicking on invalid values. But you can choose do just that instead!

There is no decree that on has to be as precise in their types as possible, no matter how much a given type system is able to express.

Re: Is Uncle Bob serious?

#70

Post by jefe_ » Tue, Oct 10, 2017, 1:23 PM UTC

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 issue. The analogy I think of is like an offensive line to a quarterback. The engineers get the headlines, but without a solid QA team that doesn't happen. If QA is doing a good job, make sure everybody knows it.