4 ms·
> Most developers I’ve encountered who seek to add types to dynamic languages will never truly understand dynamic languages, closures, concurrency passing or fu
by Tehnix 8y ago
> Most developers I’ve encountered who seek to add types to dynamic languages will never truly understand dynamic languages, closures, concurrency passing or functional programming for that matter.
I don't see how seeking to add types precludes also understanding "closures, concurrency passing or functional programming", especially since these are in no way foreign concepts in statically typed languages.
> If you want a statically typed language, use one. Use one that was designed for deterministic behavior and static correctness.
I definitely see what you're trying to say, but as I understand it, these projects to "add types" often come on later, when the project is so big, that it is simply less time consuming to just develop a type checker, than it is to rewrite your entire codebase in a new language.
- iamleppert 8y agoMy argument is that you can always implement your own breed of type checking either via convention (with appropriate enforcement via static analysis or linting tools if so desired without having to run the code), or you can do type checking at run time -- most dynamic languages have a facility to interrogate a variable to determine its contents and you can implement any number of tests on it as you see fit to validate it.
- hderms 8y agoIn practice the difference in guarantees between a static type checking system and a runtime one are so vast that I think they're mostly incomparable. Runtime checking is like doing most of the work of modelling a program with static types but achieving a fraction of the benefit.