sadly, matters are not this simple.
admittedly, C is my main-used language, although C++ and ASM are also in
my top 3, probably with my own custom language (BGBScript, presently
most similar to ActionScript) in 4th place, and Java in 5th place.
"It looks as if the war between C++ and C# is over
and C++ has won."
possibly, both C++ and C# have merits do, and each can be used for
things which are problematic in the other.
ultimately, although more work may be needed to do some things in C or
C++, there is a little less of a problem with running into a "glass
ceiling" as in C# or Java.
"If I was asked to write an advertising poster for C++
it would go something like:
"Do you want to write applications that run directly on
the CPU without interpreters or VMs getting in the way?"
VMs in turn have good and bad points.
I wouldn't want to be stuck in a world where I *had* to use a VM as the
primary/sole development environment, however, VMs still have merits
which make their use worthwhile in addition to native code.
a recent idea of mine (revived from an older idea of mine from 2009) is
to use a modified/fudged version of x86 machine code in a VM (the design
was altered slightly to make it better suited to a VM interpreter/JIT
and to variable address-word sizes).
a proof-of-concept would be to use it on an ARM-based target.
I already have a plain x86 interpreter (from 2009 or so) which I have
successfully tested on ARM, however, what I was imagining above would be
technically different (it would operate much closer to the metal,
operating in the same address space and with likely sharing data
structures/... with the native code, whereas the existing interpreter
uses virtual address spaces and a partially synthesized "OS").
sadly, I have many more important things to do, so may not have time to
do much with this idea...
note that most of my other stuff is built on other, more specialized,
bytecode formats (high-level bytecodes, whereas a modified x86 variant
would be more of a lower-level byte code).
"Do you want make use of the operating system interfaces
as if you owned them?"
any VM with a competent FFI should allow this, although sadly many HLL
VMs (including the JVM) have been relatively incompetent at doing this
"well" (for example, Java tends to require much evil boilerplate, as do
the majority of existing HLL VMs AFAICT).
..NET does a little better.
in my case, I have managed to largely gloss over this issue (typically,
relatively little boilerplate is needed). I have wondered though why
others have not done so, as the problems are not *that* hard, and it is
not like I have corporate levels of developer resources at-hand.
say, we devide FFIs into levels:
level 1: no real FFI, stuff is hard-coded into or registered with the VM
or similar and may have to deal with VM internals and/or complex
interfacing rules;
level 2: one writes boilerplate in C or C++, but the VM can locate the
functions on its own (for example, JVM with JNI);
level 3: one writes boilerplate or signatures in the HLL, but the VM
manages the native calls (Java JNA, .NET P/Invoke, ...);
level 4: one uses a tool which reads C or C++ headers and similar and
spews out the boilerplate (for example, Swig);
level 5: one references the headers, with any needed glue-code being
generated on-the-fly and behind-the-scenes.
level 6: there is no noticeable seam (code running inside and outside
the VM is indistinguishable, and cross-language interfaces are entirely
transparent).
my own VM is presently mostly at around 4.5, where a tool is needed to
process the C headers, but this was mostly for performance reasons
(processing the C headers during program startup was relatively
expensive, and would require keeping them around). however, most
interface code is dynamically generated (calls to C are automatic, but
direct calls from C or C++ may require generated stubs).
"Do you want to use a language that isn't going to be
crippled by an evil proprietor?"
"Then you need C++"
fair enough.
C# is, theoretically standardized, but MS currently holds the only
really "good" implementation.
Mono is not nearly as good, and is IMO written on some of the most nasty
code I have probably ever seen (it could use some level of code-cleanup
and fixing up its overall architecture).
most other implementations are far less feature-complete.
Java is a little better on this front in that it tends to have more
mature open-source implementations, at the cost of Java itself being a
"not very impressive" language.
ultimately, I much rather write code mostly in C and C++, and develop my
own technology for what doesn't work as well in C or C++.
granted, it is probably not like my own VM technology would be winning
any awards any time soon anyways.
or such...
