3 ms·

the problem i have with premature type or type obsession is , you commit to a data model without even completely understanding the business model / rules there

the problem i have with premature type or type obsession is , you commit to a data model without even completely understanding the business model / rules there is this myth that you understand the requirements clearly and that it wont change quickly or by a lot . Python gives me the flexibility to whip up a service and check if fits if it doesnt fit throw it and try again, i wouldnt need to start from scratch , i can do well be removing dead or unwanted code and some basic cleanup to have a good start point. I cant comment on ML family cause i have not used it in prod env.

hota_mazi 7y ago
That commitment is very light and easily adjusted, though. Once you have types in your source code, automatic refactorings are not just blazingly fast, they are also safe. These days, dynamically typed languages have realistically zero advantages over a modern statically typed language.
- elisharobinson 7y ago
  "light and easily adjusted" is it though. maybe when you use haskell and functional languages which might not have strong dependency . if i am being honest i cant extract the precise requirement on the first iteration it is only as more feature request come as iterations progress with "small additions" only then do i find the real requirement. from my exp with java/c++ your data model is sacrosanct it cannot be touched especially if you have untraceable down stream dependencies.
nightski 7y ago
What I find is that you commit to the data model either way. Your code has to be written against something. It's just that with a type system it is explicit so that if a change is made which would break something the compiler along with tests where needed can tell you. However with a dynamic language you are much more reliant on hand written tests as there is very little the compiler can verify.

3 ms·

the problem i have with premature type or type obsession is , you commit to a data model without even completely understanding the business model / rules there

by elisharobinson 7y ago

hota_mazi 7y ago
That commitment is very light and easily adjusted, though. Once you have types in your source code, automatic refactorings are not just blazingly fast, they are also safe. These days, dynamically typed languages have realistically zero advantages over a modern statically typed language.
- elisharobinson 7y ago
  "light and easily adjusted" is it though. maybe when you use haskell and functional languages which might not have strong dependency . if i am being honest i cant extract the precise requirement on the first iteration it is only as more feature request come as iterations progress with "small additions" only then do i find the real requirement. from my exp with java/c++ your data model is sacrosanct it cannot be touched especially if you have untraceable down stream dependencies.
nightski 7y ago
What I find is that you commit to the data model either way. Your code has to be written against something. It's just that with a type system it is explicit so that if a change is made which would break something the compiler along with tests where needed can tell you. However with a dynamic language you are much more reliant on hand written tests as there is very little the compiler can verify.