The article is mainly focused on static typing. I guess it makes sense since the title is "Types". Although reading this, you might just think that dynamic typing is good for nothing.
The more practical part of the article is great. However, the theoretical part could use some works. Especially the terminology isn't actually clear.
Takes some example, what is "memory-safe" ? The only example makes it sounds like bound checking. And what does "no way to escape the language's type rules" mean? There are some usages of "valid program" and "invalid program" that makes my spider sense tingling as well.
> However, no dynamic language can match the speed of carefully written static code in a language like Rust.
> Any blanket statement of the form "static languages are better at x than dynamic languages" is almost certainly nonsense.
Those two quoted statements come from the article.
The section "Arguments for static and dynamic types" didn't mention a single reason why dynamic typing could be preferable over static-typing. It could at least have mentioned macro, or hand-waving claim that dynamic typing makes for prettier code at time (I think the author of python's requests library made that argument in one of the blog post).
I think the last part should be removed (ranking the language by their typed system power).
> There's a clear trend toward more powerful systems over time, especially when judging by language popularity rather than languages simply existing.
Well, it looks true since we didn't consider any dynamic language at all...
Focusing more on the "Concrete examples of type system power differences" would have been better for the article, I think. Something along the line of an example of Non-nullable type with something simple in TS, to optional/maybe monad, then dependent type that you can implement matrix multiplication (m * n) with (n * p) and got the type (m * p) back.
> The author is highly probably on the static typing camp.
First and foremost, i don't think dividing people into these clear-cut "camps" is good for this discussion (and probably for most discussions too...).
Second, i very much doubt that the author is a purist of static typing, or even a strong proponent of it. He has a series of programming screencasts called Destroy All Software, and in most the episodes i've seen he uses Ruby, Bash or Python. So, unless he has dramatically changed his style since then, i don't think he has any problems using dynamically typed languages.
> And what does "no way to escape the language's type rules" mean?
I can give you an example, from bitter experience.
In the original Pascal, the size of an array was part of the type of an array. There was no possible type for a variable-sized array. And you couldn't cast from an array of one fixed size to an array of another fixed size.
Well, we were trying to do a 2D numerical simulation on a grid, with the size of the grid being user-specified. The original version of the program used a linked list to simulate the array, since you could have an arbitrarily-long linked list. But this meant that, if the simulation was 60x60, to reference the cell directly below the current one, you had to follow 60 links to get there!
I replaced it with a 2D array of a fixed size, with the size being the largest amount we could fit into available memory (it was on an embedded system, so the amount of memory available was predictable). Of that, we used only the user-specified subset to do the simulation.
TL;DR: If you need to do something that's outside what's allowed by your type system, and there's no way to escape the language's type system, you're trapped.
>> However, no dynamic language can match the speed of carefully written static code in a language like Rust.
>> Any blanket statement of the form "static languages are better at x than dynamic languages" is almost certainly nonsense.
> Those two quoted statements come from the article.
I think author had in mind "ALL static languages are better at x than ALL dynamic languages" as a nonsense. He probably didn't have in mind that "A static language_ IS better at x than A dynamic language_" is a nonsense.
The more practical part of the article is great. However, the theoretical part could use some works. Especially the terminology isn't actually clear.
Takes some example, what is "memory-safe" ? The only example makes it sounds like bound checking. And what does "no way to escape the language's type rules" mean? There are some usages of "valid program" and "invalid program" that makes my spider sense tingling as well.
> However, no dynamic language can match the speed of carefully written static code in a language like Rust.
> Any blanket statement of the form "static languages are better at x than dynamic languages" is almost certainly nonsense.
Those two quoted statements come from the article.
The section "Arguments for static and dynamic types" didn't mention a single reason why dynamic typing could be preferable over static-typing. It could at least have mentioned macro, or hand-waving claim that dynamic typing makes for prettier code at time (I think the author of python's requests library made that argument in one of the blog post).
I think the last part should be removed (ranking the language by their typed system power).
> There's a clear trend toward more powerful systems over time, especially when judging by language popularity rather than languages simply existing.
Well, it looks true since we didn't consider any dynamic language at all...
Focusing more on the "Concrete examples of type system power differences" would have been better for the article, I think. Something along the line of an example of Non-nullable type with something simple in TS, to optional/maybe monad, then dependent type that you can implement matrix multiplication (m * n) with (n * p) and got the type (m * p) back.