5 ms·

Perhaps this went completely over my head somehow? I'm not seeing why this is needed, other than people who find comfort in static typing think Ruby is broken

Perhaps this went completely over my head somehow? I'm not seeing why this is needed, other than people who find comfort in static typing think Ruby is broken without it. I've been programming with Ruby every day for 5+ years, and it performs and debugs just fine without static typing. My summary opinion is if static typing makes you happy go for it. Please don't try to force it into Ruby as a feature of the language, however, as it's current model of dynamic typing is one of it's best features.

dragonwriter 9y ago
Optional static verification is becoming the norm in dynamic languages, Ruby has several libraries for it already. (This one seems different from other ruby ones I've seen in that it type checks vanilla Ruby rather than requiring annotations for type checking.) This is a good thing for dynamic language adoption, because it means that organizations that evolve to where static typing is more important (larger teams and code bases, basically) don't have to either do a ground up rewrite or forgo it's benefits.
kazinator 9y ago
If, without sacrificing any dynamic aspects of a language, we can be better informed about programs and expressions before they are executed, it's almost a pure win, and therefore a no-brainer. ("Almost" because we pay for it with some machine cycles and memory required to execute the checks.) If you call a three-arg function with only two-args, it is more helpful to see a diagnostic than not to see a diagnostic, all else being equal.
stereobooster 9y ago
The reason is to fight with bugs, which are caused by type errors. Current approaches are: 1) use guards 2) add tests which check types 3) use error reporting software, like Sentry, and cath errors in production Is there any reason you do not want not catch type errors without additional code and useless tests before you deployed it to production? https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-quantifying-detectable-bugs-in-javascript/ https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-q...

dragonwriter 9y ago

Optional static verification is becoming the norm in dynamic languages, Ruby has several libraries for it already. (This one seems different from other ruby ones I've seen in that it type checks vanilla Ruby rather than requiring annotations for type checking.) This is a good thing for dynamic language adoption, because it means that organizations that evolve to where static typing is more important (larger teams and code bases, basically) don't have to either do a ground up rewrite or forgo it's benefits.

kazinator 9y ago

If, without sacrificing any dynamic aspects of a language, we can be better informed about programs and expressions before they are executed, it's almost a pure win, and therefore a no-brainer. ("Almost" because we pay for it with some machine cycles and memory required to execute the checks.) If you call a three-arg function with only two-args, it is more helpful to see a diagnostic than not to see a diagnostic, all else being equal.

stereobooster 9y ago

The reason is to fight with bugs, which are caused by type errors. Current approaches are: 1) use guards 2) add tests which check types 3) use error reporting software, like Sentry, and cath errors in production Is there any reason you do not want not catch type errors without additional code and useless tests before you deployed it to production? https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-quantifying-detectable-bugs-in-javascript/ https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-q...