3 ms·

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

• opportune 8y ago
  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
  • joevandyk 8y ago
    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.
  • ahmedalsudani 8y ago
    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 ¯\_(ツ)_/¯
    • revvx 8y ago
      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.
      • ahmedalsudani 8y ago
        +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).