4 ms·

Right, both approaches have their respective costs. That's why I think it comes down to the pain points you're willing to live with. And as you note, you're goi

Right, both approaches have their respective costs. That's why I think it comes down to the pain points you're willing to live with. And as you note, you're going to have to write spedification tests for any serious software regardless of the type discipline. And it's also worth noting that there are other tools available, such a runtime contracts as seen in Racket and Clojure. If you have a specification for what the code is supposed to be doing, and you do specification testing then you will have a high level of confidence regardless of the type discipline. The kinds of errors that will slip through in a dynamic language would necessarily be edge cases and undefined behaviors. These are typically the kinds of bugs that static typing can help you catch. On the other hand, dynamic typing facilitates features such as hot loading. Just last week my team had a production issue where the service we were using changed the API, and the team managing it didn't notify us. We were able to update the code that talks to the service via the REPL with zero downtime. This is something that would've been a much bigger issue if we had to take the whole system down.

mikelevins 7y ago
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.

mikelevins 7y ago

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.