> I should have said "you shouldn't use reflection.emit for a new language."
You should've said a lot of things. Especially considering how interested in useless pendanticy you are.
> That method has a lot of pitfalls and the conclusion at the end of the article is, use the DLR.
The DLR includes a code generating interface that happens to use Reflection.Emit. It makes it easy to implement languages with direct dispatch, but it makes it very difficult to implement threaded interpreters or dynamic dispatch operations.
For an example: Look at what would be necessary to implement CLOS or Forth using the DLR and you'll see using Reflection.emit is much easier.
> Jython is not Python running on the JVM. It's Python syntax executing as Java would. It is not first class because it has restrictions. An Object (as in base object type too) in Jython is not the same as a Java Oject. It's all wrapped an marshalled and imposes restrictions.
That's an implementation detail to work around some Java library implementation decisions, and isn't a reflection of the JVM. Clojure (for example) doesn't have these restrictions either.
> Java's strange half assed backwards compatibility means it is not open to significant optimizations of new features it implements. Java runs about as well now as it ever will.
That's a feature. DotNet's strange half assed backwards compatibility means sometimes your code breaks because Microsoft changes things.
> No. The binary that makes up the text file is different than the binary that makes up the assembelled program. An x86 CPU can't assemble programs on its own.
Nobody said it did.
> IL bytecode does not exist. There is the CIL object oriented assembly language for the CLI, and there is bytecode which represents the assembled instructions of CIL for CLI. We have gone over this a dozen times.
Minor semantics. There is a 1:1 relationship between the bytecode the DotNet runtime executes and the assembly mnemonics it choses to represent with output dumps.
It's sounding more and more like your whole point is that the DotNet programmers have a text-based representation of their bytecodes.
> As Sun stated, there is no standard way to represent bytecode in a low level language. One person might have use mov, the other might use mvr for the same fucking thing. Anyone can use whatever they want. So others would need to learn each mnemonic for each implementation for the same fucking thing. That prospect is unreasonable at best.
It's meaningless. This doesn't cause any problems because people interact with the operations directly, instead of the textual mnemonics. Just like on DotNet, nobody uses the textual mnemonics, or the offline assembler. It's just stupid.
> And as I have pointed out, implementing the syntax does not mean the language works like its native implementation. It can only approximate in on the JVM.
You have failed to demonstrate any meaningful difference. I'll stick to the JVM: It's faster, and my code that I wrote over ten years ago will still run in another ten years, and I will be laughing, knowing, that you will never be able to say the same.