The problem with these massive ecosystems of dynamic code extensions is that when you layer leaky abstraction on top of leaky abstraction, each layer being broken in its own subtle ways, the end result is a ticking time bomb waiting to cost its users thousands or millions of dollars in lost productivity. Your example of JavaScript in web browsers is a perfect demonstration of this.
We are the only engineering discipline where there are a significant number of people who actually think extensibility is more important than stability or robustness. Imagine a civil engineer pooh-poohing the stability of the bridge he's building, pointing instead to how easy it is to add additional lanes. Imagine a mechanical engineer decrying running a formal analysis of a new design for a car, saying "forget about that, look at how easily customers can plug in custom dashboard attachments!" This is lunacy, plain and simple.
This reeks of what I have seen as a common attitude among software developers where we make sweeping statements about other professions with little to back it up.
I will not claim that extensibility is the be all end all attribute. I will claim that it is a valuable attribute. More so for some applications than others.
Similarly, I will make the same claim for formal checked programs. In some fields/industries, why wouldn't this be the norm?
So, if the claim is that static typing can make for a more completely specified application and that we should demand that for some fields. I agree.
If the claim is that static programming is superior to dynamic, I take issue.
"If the claim is that static programming is superior to dynamic, I take issue."
I think this would benefit from a little more clarity about what you mean when you say "static programming" versus "dynamic programming" - I'm sure you don't mean "Dynamic Programming".
If you mean static types, then I think that they are a tremendous win wherever they apply, and I think that sufficiently sophisticated type systems exist that they can apply most places. Trying to express meaningful constraints in a brain dead type system is awkward and you wind up moving between over- and under-constraining yourself - though I've been surprised at what I can express in C (with zero runtime overhead) with a little creativity.
If "static programming" is taken to mean "compiled, with runtime compilation of additional code made difficult to impossible", which often correlates with "statically typed" in existing languages but is technologically orthogonal, then I agree that this kind of "static programming" is not uniformly superior.
Yeah, apologies. I did not mean "dynamic programming." I thought the context made what I meant fairly clear, though.
If you have any examples that show how this is technically orthogonal, I'm all ears. Hence my request for examples of things that are as extensible as emacs.
And to be clear, my understanding is that ghc is actually fairly extensible. I would love if there were more examples. Preferably in more approachable domains than compilers.
'Yeah, apologies. I did not mean "dynamic programming." I thought the context made what I meant fairly clear, though.'
No worries - as I said, I'd understood that didn't mean "dynamic programming".
"If you have any examples that show how this is technically orthogonal, I'm all ears. Hence my request for examples of things that are as extensible as emacs."
Well, Typed Racket would presumably be one example. More generally, as a theoretical proof, one could bundle the entire compiler into the runtime and link in arbitrary new code.
"And to be clear, my understanding is that ghc is actually fairly extensible. I would love if there were more examples. Preferably in more approachable domains than compilers."
I'm not aware of it being exceptionally easy to write plugins for GHC compared to other compilers - it has incorporated a lot of extensions to the Haskell language but that's not the same as a plugin ecosystem (which might itself exist - just "I'm not aware"). It certainly has a plugin interface, but so does GCC. As GHC it itself implemented in Haskell, a lot of pieces of it are also available as libraries.
There are no non-leaky abstractions outside of toy applications. Extensibility is the unique strength of software. Otherwise you might as well do it with hardware. Other disciplines are (more) limited by their physical constraints. If air-tight abstractions could solve everything machines could do the programming and there wouldn't be much need for human programmers.
Well it is pretty self-evident that non-leaky abstractions don't exist -- or I haven't really seen one in all these years. Take functions in functional programming: if tail recursion matters that is one leak; if strict or lazy evaluation matters that is another leak; if you want to share intermediate results well that springs a big leak; etc. Engineering is about trade-offs. We are there to judge what matters to us and therefore "leaks" and abstract away details that may not matter to us (at the level we are working on). Yes fundamentally I do see this as the barrier to complete automation.
We are the only engineering discipline where there are a significant number of people who actually think extensibility is more important than stability or robustness. Imagine a civil engineer pooh-poohing the stability of the bridge he's building, pointing instead to how easy it is to add additional lanes. Imagine a mechanical engineer decrying running a formal analysis of a new design for a car, saying "forget about that, look at how easily customers can plug in custom dashboard attachments!" This is lunacy, plain and simple.