3 ms·

> But the hard part really is coming up with the invariants, Surely. But if you have to write them down it becomes hard to change them because then you will ha

> But the hard part really is coming up with the invariants, Surely. But if you have to write them down it becomes hard to change them because then you will have to rewrite them, and you may need to do that many times if your initial invariants are not the final correct ones. The initial ones are likely not to be the final correct ones because as you say coming up with the invariants is ... the hard part.

roca 7y ago
I don't think "change" is a good reason not to write them down. I think I'd rather have them written down so I have a history of those changes.
- galaxyLogic 7y ago
  Good point. Keep them under version control. What I'm trying to think about is that in a language that requires you to write the types down they have to be always written down correctly. So if you have to change the types you use or something about them you may have a lot of work to do because not only do you have to rewrite the types you will also have to rewrite all code that uses those types. That does allow you to catch many errors but it can also mean a lot of extra work. The limitation is that types and executable code must always agree. Whereas in a dynamic language you might have some parts of your program that would not even compile as such, if you used a compiler, but you don't care because you are currently focusing on another part of your program. You want to test it fast to get fast feedback without having to make sure all parts of your program comply with the current version of your types. A metaphor here could be something like trying to furnish a house trying out different color curtains in one room. In a statically typed language you could not see how they look and feel until all rooms have curtains of the same new color, until they all follow the same type type-constraints.

3 ms·

> But the hard part really is coming up with the invariants, Surely. But if you have to write them down it becomes hard to change them because then you will ha

by galaxyLogic 7y ago

roca 7y ago
I don't think "change" is a good reason not to write them down. I think I'd rather have them written down so I have a history of those changes.
- galaxyLogic 7y ago
  Good point. Keep them under version control. What I'm trying to think about is that in a language that requires you to write the types down they have to be always written down correctly. So if you have to change the types you use or something about them you may have a lot of work to do because not only do you have to rewrite the types you will also have to rewrite all code that uses those types. That does allow you to catch many errors but it can also mean a lot of extra work. The limitation is that types and executable code must always agree. Whereas in a dynamic language you might have some parts of your program that would not even compile as such, if you used a compiler, but you don't care because you are currently focusing on another part of your program. You want to test it fast to get fast feedback without having to make sure all parts of your program comply with the current version of your types. A metaphor here could be something like trying to furnish a house trying out different color curtains in one room. In a statically typed language you could not see how they look and feel until all rooms have curtains of the same new color, until they all follow the same type type-constraints.