[jerf]

That strikes me as giving lie to the "Ruby-like syntax" claim; ask a Ruby programmer what that line means and you will not get the correct answer for Zinc.

Actually the connection with Ruby is tenuous anyhow; Ruby and assembler just don't go together. An assembler should produce a very clear one-to-one correspondence of instruction to machine language opcode, pretty much by definition. A high-level language can turn a simple statement into arbitrarily-complicated run-time code, pretty much by definition. Neither of these are criticisms by any means, it's just what they are. There isn't much syntax cross-talk to be had there.

[stcredzero]

A high-level language can turn a simple statement into arbitrarily-complicated run-time code, pretty much by definition.

There are some high level languages where there is a pretty straightforward one-to-one correspondence of statement to bytecode(s).

There isn't much syntax cross-talk to be had there.

Explain the existence of Forth.

[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.

[speleding]

Although I agree that it isn't really possible to have a "Ruby-like" syntax for a low level language since a lot of the syntax depends on Ruby being dynamic, it still seems like valid ambition, as long as you know that limitation.

I would love to have a form of C / C++ with iterators and blocks and without all the curly braces and assorted cruft like 5 different ascii symbols being used in 20 different contexts (actually, Ruby does that too, when will language designers start using a few additional symbols to improve cognitive load?).