8 ms·

Dynamic typing also makes it possible to type-check things that cannot be statically checked. I worked on a research project (a subproject of the project descr

Dynamic typing also makes it possible to type-check things that cannot be statically checked. I worked on a research project (a subproject of the project described in this NYT article about Peter Neumann: https://www.nytimes.com/2012/10/30/science/rethinking-the-computer-at-80.html https://www.nytimes.com/2012/10/30/science/rethinking-the-co...) that experimented with addressing data security and integrity issues using strong types. For example, writing data to the wrong channel, or reading from the wrong channel, was a type error. Most of the time, most operations could be statically checked, but sometimes they could not. You might, for example, attempt to send a message to a recipient whose privileges change during transmission. Static checking won't help for such cases; the system needed dynamic checking. The project used a novel programming language with both static and dynamic typechecking. It specified a hardware platform with tag support for dynamic types. Mention either static or dynamic typing and a controversy erupts as night follows day between advocates of one and advocates of the other. Why not see the costs and benefits of both? I imagine that the practical answer is that supporting one type discipline costs less in development resources than supporting two, but that doesn't mean that the rejected discipline is therefore wrong and bad. I liked that the project in question's designers didn't engage in a spurious struggle over static versus dynamic types. They understood that both were valuable, that each offered some benefits that the other didn't, and so they used both.

UK-AL 7y ago
I don't think any static type advocate would say that no dynamic checks should be done. Not all can be. You need a mix. Most dynamic types then go on to say why bother at all with static. That's where we disagree. It's dynamic types people that tend to be all or nothing. Where as static type people say use them where it's helps catch the obvious errors, so you don't have to write so many tests.
yogthos 7y ago
Right, I see type checking as a tool, and the developer should be able to decide where this tool provides the most value. I really like the idea of gradual typing, where you can start introducing type definition in places where they make sense. I also find that runtime contracts as seen in Racket and Clojure provide another interesting approach. From my experience contracts make it much easier to specify actual business constraints.

UK-AL 7y ago

I don't think any static type advocate would say that no dynamic checks should be done. Not all can be. You need a mix. Most dynamic types then go on to say why bother at all with static. That's where we disagree. It's dynamic types people that tend to be all or nothing. Where as static type people say use them where it's helps catch the obvious errors, so you don't have to write so many tests.

yogthos 7y ago

Right, I see type checking as a tool, and the developer should be able to decide where this tool provides the most value. I really like the idea of gradual typing, where you can start introducing type definition in places where they make sense. I also find that runtime contracts as seen in Racket and Clojure provide another interesting approach. From my experience contracts make it much easier to specify actual business constraints.