Hacker News Reader

Comment by ahmedalsudani | Hacker News Reader

You get used to things working the first time when you use a strongly typed language like Haskell or ML. Still need to test for off-by-one errors and that sort of subtle bug, but it really is true that your program will mostly be error-free. Highly recommend investing some time in such a language if you are able to.

View on HN

There's much more to errors than just types. The source of most of my errors are failures to account for corner cases in input data that I have no control over

Most common error in my and teammates code (Ruby, JS) while actively working on it is code being edited is not consistent with the other code in the system.

Thinking I’m dealing with an Object A when I have object B.

Not realizing that nil is a valid thing to be returned from code that at first glance shouldn’t return nil.

Plus, accidentally writing super slow n+1 queries. And accidentally loading too much data.

The comment was about code working when you first run it--not exactly where input outside your control comes in. Also, you'd be surprised how much types can catch, but feel free to completely ignore my opinion if that suits you ¯\_(ツ)_/¯

In my experience, a sufficiently rich type system is extremely similar to TDD in this regard.

Both give you super fast feedback and a lot of issues can be solved before you finally launch your software for the first time. But neither will save you from bad design or misunderstanding your requirements.

+1. I think that's exactly the right way to think about types. They're like integration tests you pay for with some upfront thought about your design (and fighting type system complaints).

Reply on news.ycombinator.com