3 ms·

The other benefit is refactoring. That saying which goes along the lines of: "you're going to be reading a lot more code than writing it" is very true. After yo

The other benefit is refactoring. That saying which goes along the lines of: "you're going to be reading a lot more code than writing it" is very true. After your project gets to a certain size, and it need not be large, you start making smaller changes and moving code around -- having some guard rails there is a huge productivity boost. Being able to read code and know that it does what it says because you know the types also improves your productivity. The critique of typed languages being slow to write was somewhat true in the past. However, more modern typed languages (e.g. Swift or Typescript) do a lot of inference and have some flexibility built in. Because of that I think you get many of the same benefits of loose typing while maintaining type safety. One worry I had with starting Typescript was a fear it was going to make engineers over-engineer things, which is a behavior that Java seems to promote -- that turned out to not be true. You can go off the deep-end on generics, but in practice I haven't seen this. Also with Typescript, you're not so far from Javascript where it's an entirely new language. So if you love Javascript, you don't lose anything.

Barrin92 6y ago
I don't really buy this argument about readability because the sort of information stored in types very quickly becomes pretty meaningless for humans. I remember working on a Haskell codebase and getting into an argument about this with a developer who was very much in the typed language camp. Then I saw a function that had like 8 parameters, some were just String, or Int, some where synonyms, and I asked him what it does based on the type signature. He didn't know. I didn't know either. Int -> Int -> Foo -> String -> Foo very quickly starts to mean nothing. Types don't enhance the meaning of the code. if you want to understand your code better, what you're looking for is better names, not better types. As far as understanding code is concerned, in the best case types have the exact function as names, in the worst case they entice people to write 'int x' rather than giving something a proper name.
- j-krieger 6y ago
  The magic is in the combination of types and proper names. What use is a variable that‘s nicely named when you don‘t know what it holds?
- deleted 6y ago
  [deleted]
- resonantjacket5 6y ago
  If you don't have types you still might not know what to pass in. I mean if it says function( id, filePath, newStudent) is id a number or a string. Or say filePath perhaps you have a defined class for that instead of passing in a string. Sure you could write it as function( idNumber, filePathString, newStudentClass) but you're just reimplemting types as a naming scheme that isn't able to be checked compile time.
- tome 6y ago
  Huh? Just because there was once a function whose argument types didn't help you understand it doesn't imply that types aren't an aid to readability in general!

Barrin92 6y ago

I don't really buy this argument about readability because the sort of information stored in types very quickly becomes pretty meaningless for humans. I remember working on a Haskell codebase and getting into an argument about this with a developer who was very much in the typed language camp. Then I saw a function that had like 8 parameters, some were just String, or Int, some where synonyms, and I asked him what it does based on the type signature. He didn't know. I didn't know either. Int -> Int -> Foo -> String -> Foo very quickly starts to mean nothing. Types don't enhance the meaning of the code. if you want to understand your code better, what you're looking for is better names, not better types. As far as understanding code is concerned, in the best case types have the exact function as names, in the worst case they entice people to write 'int x' rather than giving something a proper name.

j-krieger 6y ago
The magic is in the combination of types and proper names. What use is a variable that‘s nicely named when you don‘t know what it holds?
deleted 6y ago
[deleted]
resonantjacket5 6y ago
If you don't have types you still might not know what to pass in. I mean if it says function( id, filePath, newStudent) is id a number or a string. Or say filePath perhaps you have a defined class for that instead of passing in a string. Sure you could write it as function( idNumber, filePathString, newStudentClass) but you're just reimplemting types as a naming scheme that isn't able to be checked compile time.
tome 6y ago
Huh? Just because there was once a function whose argument types didn't help you understand it doesn't imply that types aren't an aid to readability in general!