3 ms·

> I check for all the things that the code allows to happen, because sooner or later they will happen. So if you know it will happen, why don't you fix the bug

> I check for all the things that the code allows to happen, because sooner or later they will happen. So if you know it will happen, why don't you fix the bug instead of "recovering"? > So if something shouldn't happen the best course is to make it impossible in the code. Exactly what I was suggesting. But adding a check is not "making it impossible". You need to go to the call site and fix the invalid call.

lmm 9y ago
Code changes all the time; you can fix the calls you know about, right now, but you're relying on everyone who calls your function to infer some extra context about it and get it right every time. The defect will keep reoccurring. Whereas if you make it part of the function's type that it can't be called that way, then the compiler enforces that it will be used correctly, automatically, and you never have to fix the same problem again.
- jstimpfle 9y ago
  That's programming. Defects come (and often stay) as you type. Yes, it would help a tiny little bit if the compiler would check for nullable pointers. But this comes at a cost of annotation work / maintenance work / worse modularity, and it only helps a bit. There are so many more invariants (is this integer in the range 3-42 and odd or divisible by 12, is that integer a valid index into this other dynamic array...) that you can't practically check with a static system, and they are much much worse because many of them manifest themselves in much subtler ways. All these formalisms work in some toy examples, but adhering to them makes a big mess as soon as it gets a little more complicated. Most basic example, const. I use const almost only for pointers to static const strings, because otherwise it always ends up in a big mess somehow (because const in one place is non-const in another place, guaranteed). And let's not talk about the const-mess in C++ where so many functions are duplicated just for const, without any pracitcal benefit. I probably wouldn't mind a very light-weight opt-in guarantee-not-null syntax. But it doesn't matter for me, at all.
  - aninhumer 9y ago
    >There are so many more invariants [...] that you can't practically check with a static system You can't statically check the invariants directly, but you can make types that statically enforce that the invariants are dynamically checked. That way you can be sure your assumptions hold when the data gets to your code, and any invalid data will be recognised as such, rather than manifesting as weird behaviour.
    - jstimpfle 9y ago
      So that's managed languages? They exist and have their justifications, but come at a performance hit, and much like static types can practically only check a subset of invariants. Just because there are so many of them. The way I think about it is simply that I write a program with code and the compiler statically enforces that what I specified there holds at runtime. Code is a pretty nice way to express invariants :-)
  - lmm 9y ago
    > Yes, it would help a tiny little bit if the compiler would check for nullable pointers. But this comes at a cost of annotation work / maintenance work / worse modularity, and it only helps a bit. There are so many more invariants (is this integer in the range 3-42 and odd or divisible by 12, is that integer a valid index into this other dynamic array...) that you can't practically check with a static system, and they are much much worse because many of them manifest themselves in much subtler ways. Not my experience. It's no more work since you know when you're writing whether it's nullable, it's better for maintenance since you can immediately see which variables are nullable. As for other invariants: look at how often you see a real app you're using fail, or look at the bugs that manifest in production; they're rarely the subtle ones, most of them are the simple stupid cases. > All these formalisms work in some toy examples, but adhering to them makes a big mess as soon as it gets a little more complicated. Most basic example, const. No, const is a poor example; it's a wrong abstraction and it's difficult to use as a result.

lmm 9y ago

Code changes all the time; you can fix the calls you know about, right now, but you're relying on everyone who calls your function to infer some extra context about it and get it right every time. The defect will keep reoccurring. Whereas if you make it part of the function's type that it can't be called that way, then the compiler enforces that it will be used correctly, automatically, and you never have to fix the same problem again.

jstimpfle 9y ago
That's programming. Defects come (and often stay) as you type. Yes, it would help a tiny little bit if the compiler would check for nullable pointers. But this comes at a cost of annotation work / maintenance work / worse modularity, and it only helps a bit. There are so many more invariants (is this integer in the range 3-42 and odd or divisible by 12, is that integer a valid index into this other dynamic array...) that you can't practically check with a static system, and they are much much worse because many of them manifest themselves in much subtler ways. All these formalisms work in some toy examples, but adhering to them makes a big mess as soon as it gets a little more complicated. Most basic example, const. I use const almost only for pointers to static const strings, because otherwise it always ends up in a big mess somehow (because const in one place is non-const in another place, guaranteed). And let's not talk about the const-mess in C++ where so many functions are duplicated just for const, without any pracitcal benefit. I probably wouldn't mind a very light-weight opt-in guarantee-not-null syntax. But it doesn't matter for me, at all.
- aninhumer 9y ago
  >There are so many more invariants [...] that you can't practically check with a static system You can't statically check the invariants directly, but you can make types that statically enforce that the invariants are dynamically checked. That way you can be sure your assumptions hold when the data gets to your code, and any invalid data will be recognised as such, rather than manifesting as weird behaviour.
  - jstimpfle 9y ago
    So that's managed languages? They exist and have their justifications, but come at a performance hit, and much like static types can practically only check a subset of invariants. Just because there are so many of them. The way I think about it is simply that I write a program with code and the compiler statically enforces that what I specified there holds at runtime. Code is a pretty nice way to express invariants :-)
- lmm 9y ago
  > Yes, it would help a tiny little bit if the compiler would check for nullable pointers. But this comes at a cost of annotation work / maintenance work / worse modularity, and it only helps a bit. There are so many more invariants (is this integer in the range 3-42 and odd or divisible by 12, is that integer a valid index into this other dynamic array...) that you can't practically check with a static system, and they are much much worse because many of them manifest themselves in much subtler ways. Not my experience. It's no more work since you know when you're writing whether it's nullable, it's better for maintenance since you can immediately see which variables are nullable. As for other invariants: look at how often you see a real app you're using fail, or look at the bugs that manifest in production; they're rarely the subtle ones, most of them are the simple stupid cases. > All these formalisms work in some toy examples, but adhering to them makes a big mess as soon as it gets a little more complicated. Most basic example, const. No, const is a poor example; it's a wrong abstraction and it's difficult to use as a result.