E
Ed
An unGooglable.
Reading recent Eclipse posts, and hearing the contention between those
using Java 1.4 and 1.5, let alone between Java and C++, I'd have
thought that we'd have, by now, another layer of source code, beneath
that which we construct in our editors, yet above any
machine-executable.
It shouldn't be impossible define an object-oriented language entirely
in XML (for example). Thus, when your favourite editor opens a source
code file, it could ask how you want this XML language
human-interpretted (as opposed to machine-interpretted). You could, for
example, have the editor display the code as Java. You'd then edit and
update the code as Java, and compile it, and run the byte-code.
Then later, a C++-fanatic colleague, could open the same XML file, but
chose to view it as C++. The editor would take care of the translation
(actually, "Translation," is a better word that, "Interpretted"), and
present the code to him as pure C++, which he can then edit and update
as C++, and he could think he's running and executing the native code,
though the editor (having previously been configured so) would actually
compile to byte code and run in a JVM (or vice-versa, a Javaer could
update Java code which is then compiled to native from the ensuing
XML). But that's not important to our C++er, he just wants to edit the
code and run the results, and that's what he sees.
Yes, there'd be library issues. Of course, java.util doesn't exist in
C++; but there's no reason why an intelligent translation-editor
couldn't be told the C++ library equivalents, so that they appear as
normal to a Javaer. An specifically, there's no translation that
couldn't be fully specified in XML.
Essentially: your choice of source-code need not limit that of others
working on the same code.
Does anyone know if such an experiment/undertaking/instanity has been
investigated?
..ed (listening to Coldplay's, "Yellow")
Reading recent Eclipse posts, and hearing the contention between those
using Java 1.4 and 1.5, let alone between Java and C++, I'd have
thought that we'd have, by now, another layer of source code, beneath
that which we construct in our editors, yet above any
machine-executable.
It shouldn't be impossible define an object-oriented language entirely
in XML (for example). Thus, when your favourite editor opens a source
code file, it could ask how you want this XML language
human-interpretted (as opposed to machine-interpretted). You could, for
example, have the editor display the code as Java. You'd then edit and
update the code as Java, and compile it, and run the byte-code.
Then later, a C++-fanatic colleague, could open the same XML file, but
chose to view it as C++. The editor would take care of the translation
(actually, "Translation," is a better word that, "Interpretted"), and
present the code to him as pure C++, which he can then edit and update
as C++, and he could think he's running and executing the native code,
though the editor (having previously been configured so) would actually
compile to byte code and run in a JVM (or vice-versa, a Javaer could
update Java code which is then compiled to native from the ensuing
XML). But that's not important to our C++er, he just wants to edit the
code and run the results, and that's what he sees.
Yes, there'd be library issues. Of course, java.util doesn't exist in
C++; but there's no reason why an intelligent translation-editor
couldn't be told the C++ library equivalents, so that they appear as
normal to a Javaer. An specifically, there's no translation that
couldn't be fully specified in XML.
Essentially: your choice of source-code need not limit that of others
working on the same code.
Does anyone know if such an experiment/undertaking/instanity has been
investigated?
..ed (listening to Coldplay's, "Yellow")