This was an interesting paper. Empirically, it is the case that scripting languages became much more predominant for application development in the early 2000s. So the paper predicted well. twitter.com/johnregehr/sta
This Tweet is unavailable.
1
1
9
Conversation
Turning to the "memorable quote," its also empirically the case that successful scripting languages have tended to be written in more modular styles than systems languages - npm, rubygems, cpan, etc
1
The only real countervailing example to the claim that application code and modular code favor dynamic typing is Java, everyone's favorite statically typed language.
1
We've seen in Rust the ecosystem problems that arise from statically defined interfaces: key libraries have difficulty making breaking changes because then we'll have two incompatible traits for the behavior they describe
1
4
The argument that quote comes from is well reasoned: statically defined interfaces lead to issues with modularity because types don't implement all the interfaces they could, often for incidental reasons.
1
1
2
HOWEVER, John Regehr's skepticism is well justified because of the obvious rejoinder: just passing the buck to the program author to make sure their types all implement the unspecified interfaces or else crash is not a great solution
1
5
The challenge then is figuring out how to make statically typed abstract interfaces usable & ergonomic in a distributed, modular ecosystem. We definitely don't have a slam dunk solution here.
1
13
Replying to
This is one of the reasons why I'm growing more and more skeptical of type class systems that require global coherence across an ecosystem. Granted, it doesn't solve all the problems (sometimes implementing an external module would require implementation details of a type).
That's not an issue if you are required to import instances/impls, and can explicitly pass them as parameters if necessary. See modular type classes and modular implicits.
1
1
Show replies