> For the programming that I do, I am often creating new architectures. Therefore I need dynamic typing.
He seems to consider static typing equivalent to "locking down" an architecture, that when you use static typing you're locked in to a certain way of doing it, and you're stuck with it. In my experience of working with large codebases with both dynamically and statically typed languages, the opposite is true.
Static typing frees you up to make changes to interfaces in a way that dynamic typing does not. For instance, if i want to add or remove a parameter to a function in a statically typed language, it's trivial. I just do it, and the compiler goes "ok, this function is called from these 4 places, so just fix those" and you now are assured that everything will work.
That doesn't work in dynamically typed languages. There's no reliable way to change an interface and be confident that you haven't broken anything (+/- extremely good linters, but those aren't perfect in the way a compiler is). This leads to a "never change this function, you can break all sorts of things" attitude that simply doesn't exist with static typing, where the compiler can just tell you what you need to fix.
There are perfectly valid arguments in favor of dynamic typing (it's arguably easier, often faster to work with etc.) but this particular one is extremely silly. The exact opposite is true.
Good test coverage and test-first philosophy can make this problem go away, but it always requires that you didn’t make an error in your tests. I always found this argument bizarre: I write tons of tests but I know that I’m fallible, and writing such tests is time-consuming. Why not let a static type checker do the work for me, with less chance of error?
Also a good reason for defining and using the most specific subtypes possible. In some domains, "this arg is a string" is useless for validation or documentation because everything is a string. Is it really a URL? a UUID? a serialized timestamp? a property name?
That's called something being stringly typed, and it's a code smell. You make URL classes, UUID classes, timestamp classes, enums, etc to replace the strings.
Keep in mind that pattern matching can be dangerous. Change something and suddenly your code could be flowing in new unexpected ways without notifying you with a runtime error. I like pattern matching too but it has bitten me
> [change is] trivial. I just do it, and the compiler goes
You are talking about the ability to refactor. In my experience with major refactors, you need a test suite, not the type checker. Why so specific? Very simple, when I did this in the past, the compiler tended to be happy way, waaaaayyyy before the test suite. Had I relied on just the compiler, I would have been in a very bad place.
> "locking down" an architecture
Simple refactors are not "changing the architecture". Static type systems tend to be fairly specific about the kinds of architectures that are expressible, and they tend to be "you can have any architecture you like, as long is it's black, er, call-and-return". Now we tend not to notice this, because we are so used to everything being call-and-return that we don't even notice it.
"We Don’t Know Who Discovered Water, But We Know It Wasn’t a Fish" -- Marshall McLuhan
Once you do notice, and you do want to build alternative architectures, the straight-jacked becomes very constricting.
He seems to consider static typing equivalent to "locking down" an architecture, that when you use static typing you're locked in to a certain way of doing it, and you're stuck with it. In my experience of working with large codebases with both dynamically and statically typed languages, the opposite is true.
Static typing frees you up to make changes to interfaces in a way that dynamic typing does not. For instance, if i want to add or remove a parameter to a function in a statically typed language, it's trivial. I just do it, and the compiler goes "ok, this function is called from these 4 places, so just fix those" and you now are assured that everything will work.
That doesn't work in dynamically typed languages. There's no reliable way to change an interface and be confident that you haven't broken anything (+/- extremely good linters, but those aren't perfect in the way a compiler is). This leads to a "never change this function, you can break all sorts of things" attitude that simply doesn't exist with static typing, where the compiler can just tell you what you need to fix.
There are perfectly valid arguments in favor of dynamic typing (it's arguably easier, often faster to work with etc.) but this particular one is extremely silly. The exact opposite is true.