3 ms·

I think many of these points are valid for a type system like Java's but they hold less ground for other languages a. Yes tests are still needed but you need f

by aszen 6y ago

I think many of these points are valid for a type system like Java's but they hold less ground for other languages a. Yes tests are still needed but you need far less of them thanks to type you can focus testing on the critical logic instead of validating input and output types. b. Solved issue in modern pl, even php considers null a value of separate type. c. This is a good point, but with values coming from outside the system, I'm forced to do run time checking because of types which makes the whole program more less error prone. d. This is a very valid point for most mainstream typed programming languages, row polymorphism is one technique which helps here. Every function only specifies the key's it needs to work so it can receive arbitrary records. I believe this is also possible in python by typing out dict keys and values.

closeparen 6y ago
Yes, I am looking forward to better type systems (and community habits/norms around those type systems) solving most of these problems. In particular, I would like to see the community gain enough faith in the safety guarantees of more advance type systems to back off of blind line coverage mandates. But today we have Go and Java's type systems, and the same coverage mandates as Python and Node. In particular I would like to see the compiler enforce that you either return a legitimate value or raise an exception, and that the caller does not go down a path that calls for a value if an exception was raised. I hate that a reference can get 10 miles away before you discover there's no data there, and it being wrapped in Option or ? or a technically-not-null zero value doesn't mitigate that.
- aszen 6y ago
  On your point about compiler enforcing legitimate values, the way I see it is that if u don't get the right values from the outside world you should immediately exit the program with a nice error message. As the data moves further down into your core functions it should become more well defined and highly structured. Basically you should parse messy data into the types you need and then you don't need to validate the data in each of your functions. How to enforce this is a tricky problem for the compiler, maybe it's architectural pattern that can be enforced by libraries and frameworks.

by aszen 6y ago

closeparen 6y ago

Yes, I am looking forward to better type systems (and community habits/norms around those type systems) solving most of these problems. In particular, I would like to see the community gain enough faith in the safety guarantees of more advance type systems to back off of blind line coverage mandates. But today we have Go and Java's type systems, and the same coverage mandates as Python and Node. In particular I would like to see the compiler enforce that you either return a legitimate value or raise an exception, and that the caller does not go down a path that calls for a value if an exception was raised. I hate that a reference can get 10 miles away before you discover there's no data there, and it being wrapped in Option or ? or a technically-not-null zero value doesn't mitigate that.

aszen 6y ago
On your point about compiler enforcing legitimate values, the way I see it is that if u don't get the right values from the outside world you should immediately exit the program with a nice error message. As the data moves further down into your core functions it should become more well defined and highly structured. Basically you should parse messy data into the types you need and then you don't need to validate the data in each of your functions. How to enforce this is a tricky problem for the compiler, maybe it's architectural pattern that can be enforced by libraries and frameworks.