undefined | Better HN

0 pointslmm5y ago0 comments

> Type issues are about 0% of my Ruby bugs

Doubt.

In my experience at least 70% of bugs are ones that you'd catch by using types - things like x instead of y, possibly-empty list instead of known-nonempty list, user ID instead of group ID. Logic errors that couldn't be caught by typing do exist, but they're very much the minority.

0 comments

sparker726785y ago

Maybe we just work on different kinds of problems.

70%+ of bugs I deal with are business logic issues that no type system could solve.

Sure, as I code I run into an occasional nil object or NoMethod error, but those last as long in Ruby as they do in Swift (about 2-5 minutes while working on that specific part of the code).

lmmOP5y ago

I've worked across a wide range of industries over several years, and it's always been pretty similar. You should be building the business constraints into your types so that errors in the business logic become errors in the types - in my experience if you actually work with the type system then most errors become type errors. If you've got examples of the kind of errors you're talking about then I could try to be more specific.

sigmaml5y ago

Not the GP, but here is a scenario that I am interested in understanding from the perspective of types.

A calculation that involves 21 parameters (in a particular insurance industry underwriting) yields a number. A threshold is read from the database. This threshold could change every month.

Suppose that the current value of the threshold is 0.78. The calculation above can yield an `x` with the following cases: (i) x <= 0.78, (ii) x > 0.78.

We have hundreds of test cases for the combinations of the 21 parameters, leading to hundreds of values for `x`. It is a bug for `x` to be > 0.78 when it should be the other way.

Is there a way this can be encoded in types? That would be very interesting.

Thanks.

2 more replies

j / k navigate · click thread line to collapse