> Programs without TypeScript also require programmers to keep types in mind
Not types, as such, but usually generics.
JS is hard to talk about in this context because of it's weak typing and desire to type cast just about anything. So the comment may well be true for JS, but I wouldn't be certain of it, it certainly wasn't the case when I was working with CoffeeScript to avoid the common pitfalls of JS.
But, for most dynamic languages, if you'll allow to stretch things a bit, I don't need to understand precisely what I'm feeding into the function.
Instead of asking "is it a string?" or "is it a vector?" or anything else along those lines, usually I just need to ask "is it iterable?", if so, good enough for me.
This can ease refactoring, when you need to change to a new type, because if the interface provides the same mechanism, you don't need to change anything. If it doesn't, then it may be possible to provide the interface, rather than modifying the function.
---
Things can get more complex than this, however.
Most people think of dynamic and weakly typed languages as the same.
However, there are several strongly typed, dynamic languages. Often times they would not allow you to pass the wrong type to standard functions.
Some dynamic languages have guards and contracts to ensure types - and some of those guards and contracts are... "compile time"... for lack of a better term.
That gives you optional typing, that you can add as you feel the need to tighten up your code, whilst still allowing you to be as dynamic as you feel appropriate.
Not types, as such, but usually generics.
JS is hard to talk about in this context because of it's weak typing and desire to type cast just about anything. So the comment may well be true for JS, but I wouldn't be certain of it, it certainly wasn't the case when I was working with CoffeeScript to avoid the common pitfalls of JS.
But, for most dynamic languages, if you'll allow to stretch things a bit, I don't need to understand precisely what I'm feeding into the function.
Instead of asking "is it a string?" or "is it a vector?" or anything else along those lines, usually I just need to ask "is it iterable?", if so, good enough for me.
This can ease refactoring, when you need to change to a new type, because if the interface provides the same mechanism, you don't need to change anything. If it doesn't, then it may be possible to provide the interface, rather than modifying the function.
---
Things can get more complex than this, however.
Most people think of dynamic and weakly typed languages as the same.
However, there are several strongly typed, dynamic languages. Often times they would not allow you to pass the wrong type to standard functions.
Some dynamic languages have guards and contracts to ensure types - and some of those guards and contracts are... "compile time"... for lack of a better term.
That gives you optional typing, that you can add as you feel the need to tighten up your code, whilst still allowing you to be as dynamic as you feel appropriate.