Compilation strategy

[H. S. Teoh]

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