Diminishing returns of static typing

Re:Diminishing returns of static typing by jonnytran on Tuesday October 03, 2017 @12:51AM (#15390264)

I do the exact same thing on large codebases of Ruby, but instead of the compiler type-checking errors, it's the test suite errors.

It's true that static type-checking proves the absence of an entire class of errors. But it doesn't prove that the code does the correct thing; it could be well-typed but completely wrong. On the other hand, tests prove that the code does the correct thing in certain cases. ...Of course, it's up to the developers to actually write a good test suite.

The faster we can all accept that there are pros and cons to both, the faster we can come up with a solution that takes advantage of the best of both worlds. That's the whole point of this OP.

I, personally, have always wondered about ways to dial in to the sweet-spot over time as a project matures. At the start of a project, shipping new features faster is often more important. But if the project survives, maintenance (by new developers) and backward compatibility become more and more of a priority.

[ Parent | on HN ]

Re:Diminishing returns of static typing by catnaroek on Tuesday October 03, 2017 @01:16AM (#15390346)

> It's true that static type-checking proves the absence of an entire class of errors. But it doesn't prove that the code does the correct thing;

So prove it yourself. Proving things about programs that rely on dynamism is invariably much harder than proving things about programs that don't.

[ Parent | on HN ]