[jerf]

I said "run-time code", not bytecodes. I'm talking about what actually executes. I've seen "bytecodes" that qualify as high-level languages by this standard, like CPython bytecode. Is that even so surprising? Single bytecodes for OO languages can translate to a lot of work to resolve.

And, what about Forth? It's a fairly low-level language by this standard. It has convenient ways to link together a lot of little functions, but one word does not dispatch on types and expand operator overloading and do the other things that can result in one line of C++ producing half a kilobyte of code, to say nothing of the functions that half-a-kilobyte may be invoking. Nor do I see why you think that's related to the syntax point.

I really have no idea what points you or your upmodders think you've won.

[stcredzero]

Actually, bytecodes for langs like Smalltalk can get you down to controlling all of your runtime state down to the level of bits. (Squeak actually runs bit-identical on something like 50 environments!)

As for precisely what runtime instructions are executed, most of the time, we can consider this to be an implementation detail. In the case of superscalar processors, you can't necessarily tell me what order your assembly language instructions are executed.

And, what about Forth? It's a fairly low-level language by this standard.

It bridges the gap between high-level and low level. It's a clear piece of evidence that there isn't such a huge gulf as you claim.

but one word does not dispatch on types and expand operator overloading and do the other things that can result in one line of C++ producing half a kilobyte of code

There are high level languages that don't do this either. Actually, I know of a specialized declarative Smalltalk that has gotten the entire image down to 45k. A Smalltalk VM is basically little more than a 256 branch switch statement, plus message dispatch, plus GC.

The gulf isn't nearly as large as you imagine. Rather, there are a number of "high level" languages that are actually pretty minimal.

[jerf]

You've really missed my point. I pretty much defined high level and low level by how they expanded out from simple instructions. You can't cite examples to prove this is wrong, by definition you've classified your definitions wrong. That this is not a universal definition doesn't bother me one little bit, because there is not universal definition of any non-trivial software engineering term.

[stcredzero]

Your definition classifies some widely recognized "high level" languages as low level.

[Retric]

If you want to redefine a commonly used term your doing something wrong. What you need to do is define a new term. Replace "High Level Languages" with "Abstract Languages" and nobody would have a problem with what you said. It might not mean anything, but at least it's clear. However, when you, redefine an existing term and you can be wrong and people will call you on it.