> And types: he claims that 'typeless' languages allow for faster
> development because of fewer restrictions. This is, ofc, nonsense.
> The amount of restrictions you have is a function of your problem,
> not your language.
Unless you're implementing something that's already known, you're effectively carving out your problem when you're in the process of writing code. There are more unknowns than there are knowns. A strongly typed language forces you to focus on satisfying the types before you can do anything, at a point where you don't exactly yet know what you want to do. The right time to cast your data rigidly into types is gradually when your data structures settle in their own place one by one; in other words when you're pretty sure things won't change too easily anymore. This allows writing code that works first and then, depending on your needs, gets next correct and then fast, or next fast and then correct. You use the weakly typed or "typeless" style as a prototyping tool that generates snippets of solid code that you can then typefy and write down for good.
Solutions to any given problem are necessarily described with types. You can check those types at runtime or you can check them at compile time, but meaningful programs are typed. If you've got a function that takes a string and your type system lets you run a program where you pass an int to it... did it just allow you to 'quickly iterate'? Sure, you're running a program sooner, but you're going to run into the same type error (function expects string, not int).
Maybe in a larger code base you could argue that the effort involved in satisfying typechecks meaningfully slows down iteration, but even then it's clear that being able to compute the list of type errors you introduced elsewhere (via static typing semantics/analysis) is valuable.
Unless you're implementing something that's already known, you're effectively carving out your problem when you're in the process of writing code. There are more unknowns than there are knowns. A strongly typed language forces you to focus on satisfying the types before you can do anything, at a point where you don't exactly yet know what you want to do. The right time to cast your data rigidly into types is gradually when your data structures settle in their own place one by one; in other words when you're pretty sure things won't change too easily anymore. This allows writing code that works first and then, depending on your needs, gets next correct and then fast, or next fast and then correct. You use the weakly typed or "typeless" style as a prototyping tool that generates snippets of solid code that you can then typefy and write down for good.