> ... “dynamic types” are, at their core, there to make unit testing less tedious, and are a tool for finding bugs.
I don't think this is a good description of dynamic typing. I'd probably go with something more like, dynamic typing is a way to defer until runtime typing aspects of the program's implementation. I suppose dynamic typing does make unit testing easier, among other things, but it feels wrong to say it's "for" that. A car is for getting one or more people from point A to B. It also has a radio, but a car is not "for" listening to the radio.
> I suppose dynamic typing does make unit testing easier, among other things, but it feels wrong to say it's "for" that.
The summary is trying to say that that's dynamic typing's primary advantage. Any other advantage you'd care to ascribe to dynamic typing is not intrinsic to dynamic typing itself.
The whole article seems concerned with the testability and bug-finding nature of types. But the main strength of dynamic types is the ability to defer decisions until runtime.
JS isn't dynamically typed to make testing easier. JS uses dynamic types because you couldn't build the web any other way.
> But the main strength of dynamic types is the ability to defer decisions until runtime.
That's not a strength. Deferring until runtime only that which must be deferred is a strength, but that's not one exhibited by dynamically typed languages. It is one that's available to statically typed languages though, like C# and now even Haskell has a deferred typing mode.
> JS uses dynamic types because you couldn't build the web any other way.
That's patently false. The whole engine running every browser is statically typed. There are libraries for working with the full DOM in HTML documents for Java, C# and other typed languages.
Obviously the ability to defer decisions to runtime is a strength - how could you possibly dispute that?
And yes statically typed languages have this strength if they use dynamic types. The article's point is that static and dynamic types are fundamentally unrelated to each other. Many languages can and do use both.
When you make a web page you have no idea what "only must" be deferred. There's no way to enforce that the JS you write today will be statically compatible with the libraries and browsers that it touches tomorrow. That's why JS uses dynamic types.
> That's patently false. The whole engine running every browser is statically typed
My point is not about building web browsers, it is about building the web. The web has JS which must coexist with arbitrary other JS, running on many different browsers with many more versions. How could you possibly build this without dynamic typing?
> The article's point is that static and dynamic types are fundamentally unrelated to each other
Not unrelated. You can embed dynamic types into a statically typed language, but not vice versa. Formerly dynamically typed languages that pull in static types, like Racket or TypeScript, become statically typed languages with embedded dynamic types.
> There's no way to enforce that the JS you write today will be statically compatible with the libraries and browsers that it touches tomorrow
This has nothing to do with dynamic types but with standardisation. C# is a language that is considerably different from its first release, and yet v1.0 C# still compiles on the latest compiler. The converse is not true, for either JS or C#. Dynamic types don't help with this problem.
> The web has JS which must coexist with arbitrary other JS, running on many different browsers with many more versions. How could you possibly build this without dynamic typing?
How do all the arbitrary programs on your computer coexist? The programs that interact do so via protocols or standard interfaces, and the ones that don't interact are isolated. This is no different than any other software.
> Formerly dynamically typed languages that pull in static types, like Racket or TypeScript, become statically typed languages with embedded dynamic types.
These languages are not "formerly dynamically typed." These languages are fully dynamically typed. Dynamic typing does not mean the absence of static types! That's the main point of the article.
I use and love statically typed languages. Dynamic types are a "yes and", enabling new things. ObjC and TypeScript are examples of languages with static and dynamic types.
> C# is a language that is considerably different from its first release, and yet v1.0 C# still compiles on the latest compiler. The converse is not true, for either JS or C#. Dynamic types don't help with this problem.
Actually dynamic types help enormously with this problem. They enable testing for the presence of features at runtime, and conditionally invoking code that otherwise could not type check.
Consider for example preventing event propagation in JS. This varies by browser so you might write:
if (event.preventDefault) event.preventDefault();
dynamically checking for the presence of a field, and then invoking it as a function. This is where dynamic types shine.
You can write this in C# or Java using reflection, because these languages have dynamic types. You can't write this in languages without dynamic types.
> How do all the arbitrary programs on your computer coexist? The programs that interact do so via protocols or standard interfaces
Every program on my computer is a conversation between the application code, the system libraries, and plugins. The browser I am using to type this dynamically interrogates the classes that it uses to discover their features, and conditionally invoke code. Example [1] - notice how this statically typed code is making a dynamic type query, illustrating that these concepts are completely compatible.
My computer's programs rely on dynamic types. That's how they retain compatibility across different versions, and it's how the OS vendor keeps the programs working across system updates.
> These languages are not "formerly dynamically typed." These languages are fully dynamically typed. Dynamic typing does not mean the absence of static types!
No, dynamically typed means the program has only one type: the universal value.
> They enable testing for the presence of features at runtime, and conditionally invoking code that otherwise could not type check. [...] You can't write this in languages without dynamic types.
That's incorrect. Extensible idioms don't look the same as they do in dynamically typed languages, but looking the same is immaterial. The same sort of behavioral extensibility is achievable with static typing without reflection, for instance, as found in the Yi editor [1]. Once again, it's about protocols and interfaces.
> Example [1] - notice how this statically typed code is making a dynamic type query, illustrating that these concepts are completely compatible.
That is merely one way to do it
> My computer's programs rely on dynamic types. That's how they retain compatibility across different versions, and it's how the OS vendor keeps the programs working across system updates.
That's not dynamic typing, compatibility is the advantage of standardized protocols and interfaces.
I don't think this is a good description of dynamic typing. I'd probably go with something more like, dynamic typing is a way to defer until runtime typing aspects of the program's implementation. I suppose dynamic typing does make unit testing easier, among other things, but it feels wrong to say it's "for" that. A car is for getting one or more people from point A to B. It also has a radio, but a car is not "for" listening to the radio.