![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
tangaroaImagine a highly-abstract, highly-verbose, machine-readable superlanguage that supports a superset of the features available in the common general-purpose object-oriented languages like C++, Java, Python, Perl, Javascript, and PHP.
Instead of programming code being interpreted or compiled down to a base machine language, it is instead decompiled upward to the more abstract language. This more abstract language is later compiled down to JVM or machine code, and can also be compiled downward to any of the supported input languages.
At the higher level, "Optimize Later" is taken to an extreme. Everything is de-optimized and tagged with hints as to how it should be optimized in a future step. Everything is an Object; data types are simply sets of constraints on what the data is allowed to be at this point in time. Every operation is a method call. Global functions are methods of the global object.
The decompiler could read C's for(*p=arr; *p; p++){...} and recognize this as an iterator pattern. The abstract language could record an iterator looping across a set of objects, with enough added details that the compiler could reduce the abstract language down to the same code produced by a C compiler. A programmer could also extend the abstracted method to operate on a different set of data types that match the interface contract, like a skiplist of Objects instead of a serialized array of bytes.
A compiler converts the high-level language to machine-readable code. Late binding is used if there are not enough hints to compile down any further. A simple compiler could theoretically ignore all the hints and use late binding and message passing for everything, and the program should still work.
Any programming code which cannot yet be decompiled to the higher-level language can be saved as-is and run through the equivalent of eval() until future versions of the decompiler can be made to recognize it.
It would not surprise me if half of the work for this has already been done by IDE developers. Perhaps the team behind Eclipse or IDEA has already built something like this.
Advantage:
Code from different languages could be merged. You could now use any CPAN library in C++, pass the perl subroutine a plain int or any custom class of yours that meets the interface contract, and it would just work. The userspace libraries in a future operating system could be saved in this high-level language to spur future development.
Advantage:
Given enough hints and knowledge of what values and interfaces are allowed to be at any time, high-level OO code can be compiled down into low-level machine code.
Disadvantage:
The process of compiling software is significantly slowed.
Big disadvantage:
The barrier to public acceptance of new languages is raised. Language creators will be expected to add support for their new language to the new abstract superlanguage, and there will be resistance to any new features that the superlanguage does not support.
Instead of programming code being interpreted or compiled down to a base machine language, it is instead decompiled upward to the more abstract language. This more abstract language is later compiled down to JVM or machine code, and can also be compiled downward to any of the supported input languages.
At the higher level, "Optimize Later" is taken to an extreme. Everything is de-optimized and tagged with hints as to how it should be optimized in a future step. Everything is an Object; data types are simply sets of constraints on what the data is allowed to be at this point in time. Every operation is a method call. Global functions are methods of the global object.
The decompiler could read C's for(*p=arr; *p; p++){...} and recognize this as an iterator pattern. The abstract language could record an iterator looping across a set of objects, with enough added details that the compiler could reduce the abstract language down to the same code produced by a C compiler. A programmer could also extend the abstracted method to operate on a different set of data types that match the interface contract, like a skiplist of Objects instead of a serialized array of bytes.
A compiler converts the high-level language to machine-readable code. Late binding is used if there are not enough hints to compile down any further. A simple compiler could theoretically ignore all the hints and use late binding and message passing for everything, and the program should still work.
Any programming code which cannot yet be decompiled to the higher-level language can be saved as-is and run through the equivalent of eval() until future versions of the decompiler can be made to recognize it.
It would not surprise me if half of the work for this has already been done by IDE developers. Perhaps the team behind Eclipse or IDEA has already built something like this.
Advantage:
Code from different languages could be merged. You could now use any CPAN library in C++, pass the perl subroutine a plain int or any custom class of yours that meets the interface contract, and it would just work. The userspace libraries in a future operating system could be saved in this high-level language to spur future development.
Advantage:
Given enough hints and knowledge of what values and interfaces are allowed to be at any time, high-level OO code can be compiled down into low-level machine code.
Disadvantage:
The process of compiling software is significantly slowed.
Big disadvantage:
The barrier to public acceptance of new languages is raised. Language creators will be expected to add support for their new language to the new abstract superlanguage, and there will be resistance to any new features that the superlanguage does not support.
