On Mon, Dec 17, 2012 at 04:42:13PM -0800, Walter Bright wrote: > On 12/17/2012 3:03 PM, deadalnix wrote: [...] > >And what prevent us from using a bytecode that loose information ? > > I'd turn that around and ask why have a bytecode? > > > >As long as it is CTFEable, most people will be happy. > > CTFE needs the type information and AST trees and symbol table. > Everything needed for decompilation. > > I know that bytecode has been around since 1995 in its current > incarnation, and there's an ingrained assumption that since there's > such an extensive ecosystem around it, that there is some advantage > to it. > > But there isn't.
Now this, I have to agree with. The only advantage to bytecode is that if you have two interpreters on two different platforms, then bytecode on one can run verbatim on the other. But: 1) Bytecode is slower than native code, and always will be. 2) Unless, of course, you're running a machine that runs the bytecode directly. But that just means your code is native to that machine, and the interpreters on other machines are emulators. So you're already using native code anyway. And since you're already at it, might as well just use native code on the other machines, too. 3) Performance can be improved to (near) native speeds with a JIT compiler. But then you might as well as go native to begin with. Why wait till runtime to do compilation, when it can be done beforehand? 4) Bytecode cannot be (easily) linked with native libraries. Various wrappers and other workarounds are necessary. The bytecode/native boundary is often inefficient, because generally there's need of translation between bytecode interpreter data types and native data types. 5) There are other issues, but I can't be bothered to think of them right now. But anyway, this is getting a bit off-topic. The original issue was separate compilation, and .di files. Just for the record, I'd like to state that I am *not* convinced about the need to obfuscate library code (either by using .di or by other means), primarily because it's futile, but also because I believe in open source code. However, I know a LOT of employers and enterprises are NOT comfortable with the idea, and would not so much as consider a particular language/toolchain if they can't at least have the illusion of security. You may say it's silly, and I'd agree, but that does nothing to help adoption. Using PIMPL only helps if you're trying to hide implementation details of a struct or class. Anything that requires CTFE is out of the question. Templates are out of the question (this was also true with C++). This reduces the incentive to adopt D, since they might as well just stick with C++. We lose. If we implement a way of "hiding" implementation details that *allows* CTFE and templates (and thus one up the C++ situation), this will create a stronger incentive for D adoption. It doesn't matter if it's not hard to "unhide" the implementation; we don't lose anything (having no way to hide implementation is what we already have), plus it increases our chances of adoption -- esp. by enterprises, who are generally the kind of people who even care about this issue in the first place, and who are the people we *want* to attract. Sounds like a win to me. But then again, even if we never do this, it makes no difference to *me* -- the current situation is good enough for *me*. The question is whether or not we want to D to be better received by enterprises. T -- I am a consultant. My job is to make your job redundant. -- Mr Tom