>> @When things are truly late-bound, it makes as little sense to split computational instructions into these "language" silos.
> I can't understand you. Can you rephrase?
Oops, think-o, that should have said "it makes as little sense to split computational abstractions into these language silos".
To clarify: there are "languages" like Haskell/Ruby/Python/Java/C that make an enormous number of decisions about the kinds of abstractions we use to describe what it is a computer is to do. A "language" is a set of decisions about syntax, type systems, functional or object-oriented abstractions, memory allocation and garbage collection, call stack traversal. If one decides to compile to a VM instead of machine code, that introduces another set of variables - from JIT compilation techniques to the kind of VM specifications you publish (do you publish a reference VM like Squeak, or a bunch of papers and tests like the JVM). "The Java language" is a set of hundreds of those kinds of decisions. So is "the Python language". Comparing the two is really difficult, because for almost any problem, some subset of Java's decisions will be better, while another subset of Python's decisions will be better. But these sets of decisions aren't atomic (they can be split!).
Every time you late-bind a decisions to the user, it removes a dimension from the decision space that the "language" lives in. It expands the power of the language to span that entire dimension. Hence, the most powerful language is one that makes the most irreversible decisions.
talking [...] in broad strokes undermines attention to good engineering and striving to be great engineers
That sounds right, and I should avoid it if it's needless. However, it's also important to always try to unify concepts to simplify our models of things. The important thing is to make sure the simpler model is just as accurate.
> I can't understand you. Can you rephrase?
Oops, think-o, that should have said "it makes as little sense to split computational abstractions into these language silos".
To clarify: there are "languages" like Haskell/Ruby/Python/Java/C that make an enormous number of decisions about the kinds of abstractions we use to describe what it is a computer is to do. A "language" is a set of decisions about syntax, type systems, functional or object-oriented abstractions, memory allocation and garbage collection, call stack traversal. If one decides to compile to a VM instead of machine code, that introduces another set of variables - from JIT compilation techniques to the kind of VM specifications you publish (do you publish a reference VM like Squeak, or a bunch of papers and tests like the JVM). "The Java language" is a set of hundreds of those kinds of decisions. So is "the Python language". Comparing the two is really difficult, because for almost any problem, some subset of Java's decisions will be better, while another subset of Python's decisions will be better. But these sets of decisions aren't atomic (they can be split!).
Every time you late-bind a decisions to the user, it removes a dimension from the decision space that the "language" lives in. It expands the power of the language to span that entire dimension. Hence, the most powerful language is one that makes the most irreversible decisions.
talking [...] in broad strokes undermines attention to good engineering and striving to be great engineers
That sounds right, and I should avoid it if it's needless. However, it's also important to always try to unify concepts to simplify our models of things. The important thing is to make sure the simpler model is just as accurate.