> This sounds good on paper, but good luck passing your custom types to third party libraries. Or even doing something as simple as calculating average age.
Ada solved this in the 80s, it isn't some unresolved field of comp sci. (Java already does this for array bounds!)
> You do realize the more powerful the type system is, the more closely it is going to resemble programming language, which means that structures you build on top of it will contain bugs? You're not really solving bugs, you're just pushing them to another layer.
Unit Tests are no different, except with worse syntax than built in language support.
At least with support in the type system you can turn off range checks for production builds. Meanwhile unit tests only run when invoked, giving less confidence than type checks that undergoing simulated usage as part of daily test builds.
There is of course a gradient, JavaScript exists on one side of that gradient (unit tests are needed for everything, starting with what type of object is even being returned), Java exists in the middle, and you have actual type safe languages farther along.
The point I was originally aiming to make is that Java is statically typed, but its type system is not so powerful as to negate the need for unit tests.
> Ada solved this in the 80s, it isn't some unresolved field of comp sci
Every solution comes at a cost. Where is Ada now?
> Unit Tests are no different, except with worse syntax than built in language support.
And I'm not advocating for unit tests, nor do I treat them as replacement for types. The fact that they occasionally overlap doesn't mean they serve same purposes.
> At least with support in the type system you can turn off range checks for production builds
> And I'm not advocating for unit tests, nor do I treat them as replacement for types. The fact that they occasionally overlap doesn't mean they serve same purposes.
So you don't advocate for unit tests, you don't want a powerful type system, what do you want?
> Every solution comes at a cost. Where is Ada now?
A source of features for newer languages, thus is the circle of programming language life.
> Sounds like dynamic typing with extra steps.
Static assertions based on build flags have been around for a very long time, in all sorts of languages. They are a performance/safety trade off.
> So you don't advocate for unit tests, you don't want a powerful type system, what do you want?
"Write tests. Not too many. Mostly integration."
Leave static typing for performance-critical sections.
> They are a performance/safety trade off.
So is dynamic typing. Only performance in this case means developer performance. Turns out most of our software is not landing airplanes, and developer performance is way more important than occasional non-critical bug that affects 5 users and gets fixed within a day.
Ada solved this in the 80s, it isn't some unresolved field of comp sci. (Java already does this for array bounds!)
> You do realize the more powerful the type system is, the more closely it is going to resemble programming language, which means that structures you build on top of it will contain bugs? You're not really solving bugs, you're just pushing them to another layer.
Unit Tests are no different, except with worse syntax than built in language support.
At least with support in the type system you can turn off range checks for production builds. Meanwhile unit tests only run when invoked, giving less confidence than type checks that undergoing simulated usage as part of daily test builds.
There is of course a gradient, JavaScript exists on one side of that gradient (unit tests are needed for everything, starting with what type of object is even being returned), Java exists in the middle, and you have actual type safe languages farther along.
The point I was originally aiming to make is that Java is statically typed, but its type system is not so powerful as to negate the need for unit tests.