> The shuttle concept was so expensive that it severely stunted what we could do in space, and finally sank the whole manned space program.

Thank you to all of you that expressed viewpoints on this issue.
I found the discussion valuable and reasonable arguments were
made (both sides). Anyway, it is too off-topic, so I consider
this hijack ended.

On Thursday, 20 December 2012 at 01:41:38 UTC, Walter Bright wrote:
> On 12/19/2012 4:54 PM, Rob T wrote:
>> One question I have for you, is what percentage performance gain can you expect
>> to get by using a well chosen bytecode-like language verses interpreting
>> directly from source code?
>
> I know of zero claims that making a bytecode standard for javascript will improve performance.
One data point along this line, the most popular javascript implementation these days is v8, which is implemented as a javascript compiler, not with bytecode:

http://wingolog.org/archives/2011/08/02/a-closer-look-at-crankshaft-v8s-optimizing-compiler

More interesting posts about v8 on that blog:

http://wingolog.org/tags/v8

On Thursday, 20 December 2012 at 01:41:38 UTC, Walter Bright wrote:
> Not exactly, I argue that having a bytecode standard is useless. How a compiler works internally is fairly irrelevant.

Note that in the first place, bytecode discussion has started with the need of provide a CTFEable module that do not contains more information that what is in a DI file, as it is a concern for some companies.

Bytecode can solve that problem nicely IMO. You mentioned that DI is superior here, but I don't really understand how.

On 12/20/2012 1:30 PM, deadalnix wrote:
> Note that in the first place, bytecode discussion has started with the need of
> provide a CTFEable module that do not contains more information that what is in
> a DI file, as it is a concern for some companies.
>
> Bytecode can solve that problem nicely IMO. You mentioned that DI is superior
> here, but I don't really understand how.

No, it doesn't solve that problem at all. I explained why repeatedly.

On Friday, 21 December 2012 at 05:43:18 UTC, Walter Bright wrote:
> On 12/20/2012 1:30 PM, deadalnix wrote:
>> Note that in the first place, bytecode discussion has started with the need of
>> provide a CTFEable module that do not contains more information that what is in
>> a DI file, as it is a concern for some companies.
>>
>> Bytecode can solve that problem nicely IMO. You mentioned that DI is superior
>> here, but I don't really understand how.
>
> No, it doesn't solve that problem at all. I explained why repeatedly.

No you explained that java's bytecode doesn't solve that problem. Which is quite different.

On 12/20/2012 10:05 PM, deadalnix wrote:
> On Friday, 21 December 2012 at 05:43:18 UTC, Walter Bright wrote:
>> On 12/20/2012 1:30 PM, deadalnix wrote:
>>> Note that in the first place, bytecode discussion has started with the need of
>>> provide a CTFEable module that do not contains more information that what is in
>>> a DI file, as it is a concern for some companies.
>>>
>>> Bytecode can solve that problem nicely IMO. You mentioned that DI is superior
>>> here, but I don't really understand how.
>>
>> No, it doesn't solve that problem at all. I explained why repeatedly.
>
> No you explained that java's bytecode doesn't solve that problem. Which is quite
> different.

Please reread all of my messages in the thread. I addressed this.

On 12/20/2012 10:05 PM, deadalnix wrote:
> No you explained that java's bytecode doesn't solve that problem. Which is quite
> different.

I did, but obviously you did not find that satisfactory. Let me put it this way:

Design a bytecode format, and present it here, that is CTFEable and is not able to be automatically decompiled.

On 21.12.2012 08:02, Walter Bright wrote:
> On 12/20/2012 10:05 PM, deadalnix wrote:
>> No you explained that java's bytecode doesn't solve that problem.
>> Which is quite
>> different.
>
> I did, but obviously you did not find that satisfactory. Let me put it
> this way:
>
> Design a bytecode format, and present it here, that is CTFEable and is
> not able to be automatically decompiled.

Sorry, can't resist: How about feeding the x86 machine byte code (including some fixup information) into an interpreter? Maybe not realistic, but a data point in the field of possible "byte codes". The interpreter might even enjoy hardware support ;-)

That might not cover all possible architectures, but if the distributed library is compiled for one platform only, CTFEing against another won't make much sense anyway.

On 12/21/2012 09:37 AM, Rainer Schuetze wrote:
>
>
> On 21.12.2012 08:02, Walter Bright wrote:
>> On 12/20/2012 10:05 PM, deadalnix wrote:
>>> No you explained that java's bytecode doesn't solve that problem.
>>> Which is quite
>>> different.
>>
>> I did, but obviously you did not find that satisfactory. Let me put it
>> this way:
>>
>> Design a bytecode format, and present it here, that is CTFEable and is
>> not able to be automatically decompiled.
>
> Sorry, can't resist: How about feeding the x86 machine byte code
> (including some fixup information) into an interpreter? Maybe not
> realistic,

http://bellard.org/jslinux/

> but a data point in the field of possible "byte codes". The
> interpreter might even enjoy hardware support ;-)
>

Direct hardware support is not achievable because CTFE needs to be pure and safe.

> That might not cover all possible architectures, but if the distributed
> library is compiled for one platform only, CTFEing against another won't
> make much sense anyway.
>

On Thursday, 20 December 2012 at 21:30:44 UTC, deadalnix wrote:
> On Thursday, 20 December 2012 at 01:41:38 UTC, Walter Bright wrote:
>> Not exactly, I argue that having a bytecode standard is useless. How a compiler works internally is fairly irrelevant.
>
> Note that in the first place, bytecode discussion has started with the need of provide a CTFEable module that do not contains more information that what is in a DI file, as it is a concern for some companies.
>
> Bytecode can solve that problem nicely IMO. You mentioned that DI is superior here, but I don't really understand how.

Walter is right that bytecode doesn't solve that problem at all. High level bytecodes like Microsoft IL are trivially decompiled into very readable source code. I did that frequently at one of my jobs when I needed to debug third-party .NET libraries that we didn't have source code for.

The advantage of bytecode is not in obfuscation. What Walter is wrong about is that bytecode is entirely pointless.