3 ms·

I just wish people shitting on statically typed languages would remember they came to solve the mess that arose from dynamic typing.

waheoo 6y ago
Im sorry you feel like i was shitting on statically typed languages. I can assure you I do beleive they have their purpose and place in the world where raw performance or closer to metal abstractions can take place. Personally, my brain much prefers to use a dynamic type system to infer what i mean leaving the thinking part up to me. I just find defining a string is a string when im only ever going to put a string in there kind of redundant. There are other arguments about readability, refactorability, and similar and I think they have some weight in large doverse systems with many many teams interacting. Personally, that isnt a large issue for me. Im working at the scope I can maintain a standard and a level of consitency that alleviates these problems to the point the type safety is simply not wareanted from a return on investment point of view. I do not, for instance, think the kernel or chrome should be rewritten in javascript. Despite what some react developers seem to think.
- entha_saava 6y ago
  > I just find defining a string is a string when im only ever going to put a string in there kind of redundant. There are 2 problems with this kind of thinking. 1) you aren't going to be so sure. Humans are imperfect and as codebase grows, everyone commits such errors. Eg comparing a string to int without converting it to int in python. It always returns false (IIRC) and it is hard to detect where the problem is. 2) Most type systems aren't that verbose. I guess you got the impression from java / mediaeval C++. But most statically typed languages have local variable type inference. OCaml / Haskell / F# / Swift etc.. have varying degrees of type inference. At this point, types in method signatures, in languages that require it, serve as documentation. And many of these languages are terser than python/javascript.
  - waheoo 6y ago
    Thanks for taking the time to respond. 1) I work on a typescript codebase for work. There is a real need for types in this case because the definitions are about 3 layers of abstraction away from their use. It drives me up the wall because I know when you keep definitions close to use, or have some basic conventions this problem melts away. At least to the point of diminishing returns where types are no longer relevant. So, i guess over the years ive been caught out by int + string = 0 all of like, 1-2 times in production, maybe a few more while in dev. Either way its rare enough for me to call FUD on the argument. Stop mixing types and this really doesnt happen. To be fair to your point, at work, i know of a recurring error in production where this is almost certainly the same class of error. Nobody can be bothered fixing it because its too hard to track down and the cost benefit isnt there. 2) Type inference is problematic for me. Doesnt it just open you up to type errors of a different class? 2.5) terse code is not the point, I find rust cryptic and dense to say the least. I prefer something like go wgere readability is a priority over density.
    - tluyben2 6y ago
      > 2) Type inference is problematic for me. Doesnt it just open you up to type errors of a different class? It's at compile time, so not really? It will tell you exactly what it expects vs what you provided at compile time. These kind of languages read like dynamic languages (for the most part) but they are completely static.

waheoo 6y ago

Im sorry you feel like i was shitting on statically typed languages. I can assure you I do beleive they have their purpose and place in the world where raw performance or closer to metal abstractions can take place. Personally, my brain much prefers to use a dynamic type system to infer what i mean leaving the thinking part up to me. I just find defining a string is a string when im only ever going to put a string in there kind of redundant. There are other arguments about readability, refactorability, and similar and I think they have some weight in large doverse systems with many many teams interacting. Personally, that isnt a large issue for me. Im working at the scope I can maintain a standard and a level of consitency that alleviates these problems to the point the type safety is simply not wareanted from a return on investment point of view. I do not, for instance, think the kernel or chrome should be rewritten in javascript. Despite what some react developers seem to think.

entha_saava 6y ago
> I just find defining a string is a string when im only ever going to put a string in there kind of redundant. There are 2 problems with this kind of thinking. 1) you aren't going to be so sure. Humans are imperfect and as codebase grows, everyone commits such errors. Eg comparing a string to int without converting it to int in python. It always returns false (IIRC) and it is hard to detect where the problem is. 2) Most type systems aren't that verbose. I guess you got the impression from java / mediaeval C++. But most statically typed languages have local variable type inference. OCaml / Haskell / F# / Swift etc.. have varying degrees of type inference. At this point, types in method signatures, in languages that require it, serve as documentation. And many of these languages are terser than python/javascript.
- waheoo 6y ago
  Thanks for taking the time to respond. 1) I work on a typescript codebase for work. There is a real need for types in this case because the definitions are about 3 layers of abstraction away from their use. It drives me up the wall because I know when you keep definitions close to use, or have some basic conventions this problem melts away. At least to the point of diminishing returns where types are no longer relevant. So, i guess over the years ive been caught out by int + string = 0 all of like, 1-2 times in production, maybe a few more while in dev. Either way its rare enough for me to call FUD on the argument. Stop mixing types and this really doesnt happen. To be fair to your point, at work, i know of a recurring error in production where this is almost certainly the same class of error. Nobody can be bothered fixing it because its too hard to track down and the cost benefit isnt there. 2) Type inference is problematic for me. Doesnt it just open you up to type errors of a different class? 2.5) terse code is not the point, I find rust cryptic and dense to say the least. I prefer something like go wgere readability is a priority over density.
  - tluyben2 6y ago
    > 2) Type inference is problematic for me. Doesnt it just open you up to type errors of a different class? It's at compile time, so not really? It will tell you exactly what it expects vs what you provided at compile time. These kind of languages read like dynamic languages (for the most part) but they are completely static.