ell, as I expected, TS wasn't up to defending
all these claims he has made about HLLs vs. C/C++.
Nevertheless, it's not a bad idea to go over each of these
points and present *my* take on them.
BTW, TS, you "punted" so don't expect any replies (from
me) for any comments you have. You had your chance,
I would have helped you even, but this is for everyone
First, let's begin by discussing how important this attribute is to someone
who wants to use a language.
The problem with "hardware-independence" is that you always wind
up with a "lowest-common-denominator" result. *Every* language
I've bothered to learn exhibits *some* hardware dependencies. For example,
most programming languages I've come across (not all, but most) assume an
imperative execution model (e.g., Von Neumann or Harvard Architecture).
There are clearly some that don't immediately fit this mold (e.g., Prolog),
but even those languages that aren't directly imperative are written with
an imperative execution model in mind. For example, very few common
languages would run well on a dataflow machine (and, conversely, languages
invented for dataflow machines rarely do well on imperative machines).
Likewise, few languages do well on SIMD machines or even MIMD
machines (though some languages are okay at *coarse* MIMD).
How many languages work well on decimal machines?
How many would work well on a ternary machine?
Today, most popular programming languages *assume* that their
code executes on a binary machine. Many algorithms depend upon
execution on a binary machine (e.g., ever used the "<<" operator in
C/C++?). Yeah, the language could be tweaked to produce
portable results on a ternary architecture, but the performance hit
would be unacceptable to most people (even Knuth was unable
to get away with machine independence in his "MIX" VM; he
had to break down and use a binary shift operator in a couple
Now to the specific question. Are assembly and C/C++
Well, what does hardware independent mean?
As best I can tell from the original paper on which TS based
his post, this means "CPU independence".
Clearly, C/C++ is *fairly* CPU-independent. The proof of
that is the wide variety of C/C++ compilers running on
different CPUs. While C/C++ does contain some hardware
specific features, there is no question that C/C++ is fairly
hardware independent. Indeed, on the basis of real-world
implementations, it's probably not too outrageous to claim
that C/C++ is the most hardware independent language
available today (yes, other languages like Ada have been
*designed* to be less hardware dependent, but C/C++
has been ported to more CPUs than just about any other
language, so arguing that other languages are more hardware
independent that C/C++ is a non-starter).
Is assembly language hardware independent?
Well, the obvious answer is "no."
However, what is "assembly language"?
Based on comments I've read in TS' posts,
"assembly language" is not a specific language (e.g.,
MASM, HLA, RosASM, whatever), but a generic
term applying to *all* assembly languages. In this sense,
"assembly language" is probably the one language that *is*
ported to every CPU out there. After all, *every* CPU has
a machine instruction set (and almost every manufacturer
provides an assembler of some sort for their CPUs), therefore,
much as one can argue that C/C++ is hardw