This is when people design their type system which decrease performance by a factor of 6. Such as with python or typed racket. Of course people are getting angry at types, when
* it's getting slower,
* there are no run-time guarantees,
* there are no compile-time errors.
With normal type designs you expect a performance win of about factor 6. With compile-time checks in place you can get rid of previous run-time checks. Also with const values.
A type is a *guarantee*, not some hint. Compilers are always better to produce type hints than users, if someone types his variables and functions these must be guarantees of course.
They need to improve safety, documentation and run-time performance.
Even with dynamic languages where the compile-time cost is added to the run-time cost, it should still run faster, not slower. Even with added compile-time type checks.
When I added types to perl5 before all the others started with their attempts, it became faster and safer. Then my eyes started watering when ruby, racket and python did it wrong, whilst perl6 and php did it right.
2 comments
[ 4.5 ms ] story [ 17.3 ms ] thread* it's getting slower,
* there are no run-time guarantees,
* there are no compile-time errors.
With normal type designs you expect a performance win of about factor 6. With compile-time checks in place you can get rid of previous run-time checks. Also with const values.
A type is a *guarantee*, not some hint. Compilers are always better to produce type hints than users, if someone types his variables and functions these must be guarantees of course.
They need to improve safety, documentation and run-time performance. Even with dynamic languages where the compile-time cost is added to the run-time cost, it should still run faster, not slower. Even with added compile-time type checks.
When I added types to perl5 before all the others started with their attempts, it became faster and safer. Then my eyes started watering when ruby, racket and python did it wrong, whilst perl6 and php did it right.