On 12/19/2012 1:10 AM, Rob T wrote:
> Using the JS code as an example, you are stating that the JS source code itself
> could just as well be viewed as the "bytecode", and therefore given what I
> previously wrote concerning the "advantages", I could replace "bytecode" with
> "JS source code" and achieve the exact same result. Am I Correct?

Yes.

> I thought that transforming source code into bytecode was an optimization
> technique intended to improve interpretation performance while preserving
> portability across architectures, i.e., the bytecode language was designed
> specifically to improve interpretation performance - but you say that the costs
> of performing the transformations from a high-level language into the optimized
> bytecode language far outweigh the advantages of leaving it as-is, i.e.,
> whatever performance gains you get through the transformation is not significant
> enough to justify the costs of performing the transformation.
>
> Is my understanding of your POV correct?

Mostly. If you use bytecode, you have Yet Another Spec that has to be defined and conformed to. This has a lot of costs.


> What I'm having trouble understanding is this:
>
> If the intention of something like the Java VM was to create a portable
> virtualized machine that could be used to execute any language, then would it
> not make sense to select a common bytecode language that was optimized for
> execution performance, rather than using another common language that was not
> specifically designed for that purpose?

Java as we know it evolved from a language that (as I recall) used bytecode to run on embedded systems of very low power. This use failed, and Java was re-imagined to be a network language that transmitted the bytecode over the internet. The rest was attempts to justify the investment in bytecode, or perhaps it simply never occurred to the Java engineers that the bytecode was redundant.

(Bytecode can make sense on 8 bit machines where the target machine simply has no capacity to run even a simple compiler. Such underpowered machines were obsolete by the time Java was developed, but the old ideas died hard.)


> Do you have a theory or insight that can explain why a situation like the Java
> bytecode VM came to be and why it persists despite your suggestion that it is
> not required or of enough advantage to justify using it (may as well use Java
> source directly)?

Consider the US space shuttle design. It's probably the most wrong-headed engineering design ever, and it persisted because too many billions of dollars and careers were invested into it. Nobody could admit that it was an extremely inefficient and rather crazy design.

A couple NASA engineers have admitted to me privately that they knew this, but to keep their careers they kept their mouths shut.

> Consider the US space shuttle design. It's probably the most wrong-headed engineering design ever, and it persisted because too many billions of dollars and careers were invested into it. Nobody could admit that it was an extremely inefficient and rather crazy design.

Hey, this is really OT, but I'm interested in. Why do you consider it is such a bad design? Because the shuttle is intended to be reentrant and this is costly? Some other issue?

Is about the design or about the entire idea?

Thanks for answering and I promise to not further hijack this thread.

On Wednesday, 19 December 2012 at 08:45:20 UTC, Walter Bright wrote:
> On 12/19/2012 12:19 AM, Max Samukha wrote:
>>> Evidently you've dismissed all of my posts in this thread on that topic :-)
>> As you dismissed all points in favor of bytecode.
>
> And I gave detailed reasons why.
>
>> Such as it being a
>> standardized AST representation for multiple languages. CLI is all about that,
>> which is reflected in its name. LLVM is used almost exclusively for that purpose
>> (clang is great).
>
> My arguments were all based on the idea of distributing "compiled" source code in bytecode format.
>
> The idea of using some common intermediate format to tie together multiple front ends and multiple back ends is something completely different.
>
> And, surprise (!), I've done that, too. The original C compiler I wrote for many years was a multipass affair, that communicated the data from one pass to the next via an intermediate file. I was forced into such a system because DOS just didn't have enough memory to combine the passes.
>
> I dumped it when more memory became available, as it was the source of major slowdowns in the compilation process.
>
> Note that such a system need not be *bytecode* at all, it can just hand the data structure off from one pass to the next. In fact, an actual bytecode requires a serialization of the data structures and then a reconstruction of them - rather pointless.
>

I understand that but can not fully agree. The problem is the components of such a system are distributed and not binary-compatible. The data structures are intended to be transferred over a stream and you *have* to serialize at one end and deserialize at the the other.

For example, we serialize a D host app and a C library into portable pnacl bitcode and transfer it to Chrome for compilation and execution. There is no point in having C, D (or whatever other languages people are going to invent) front-ends on the receiving side. The same applies to JS - people "serialize" ASTs generated from, say, a CoffeeScript source into JS, transfer that to the browser, which "deserializes" JS into an internal AST representation.

Note that I am not arguing that bytecode is the best kind of standard AST representation. I am arguing that there *is* a point in such serialized representation. Hence, your claim that ILs are *completely* useless is not quite convincing.

When we have a single God language (I wouldn't object if it were D but it is not yet ;)), then there would be no need in complications like ILs.

>
>> Not advocating bytecode here but you claiming it is completely useless is so
>> D-ish :).
>
> I'm not without experience doing everything bytecode is allegedly good at.

I am not doubting your experience but that might be an authoritative argument.

>
> As for CLI, it is great for implementing C#. For other languages, not so much. There turned out to be no way to efficiently represent D slices in it, for example.

That is the limitation of CLI, not the concept. LLVM does not have that problem.

On Wednesday, 19 December 2012 at 08:45:20 UTC, Walter Bright wrote:
> On 12/19/2012 12:19 AM, Max Samukha wrote:
>>> Evidently you've dismissed all of my posts in this thread on that topic :-)
>> As you dismissed all points in favor of bytecode.
>
> And I gave detailed reasons why.
>
>> Such as it being a
>> standardized AST representation for multiple languages. CLI is all about that,
>> which is reflected in its name. LLVM is used almost exclusively for that purpose
>> (clang is great).
>
> My arguments were all based on the idea of distributing "compiled" source code in bytecode format.
>
> The idea of using some common intermediate format to tie together multiple front ends and multiple back ends is something completely different.
>
> And, surprise (!), I've done that, too. The original C compiler I wrote for many years was a multipass affair, that communicated the data from one pass to the next via an intermediate file. I was forced into such a system because DOS just didn't have enough memory to combine the passes.
>
> I dumped it when more memory became available, as it was the source of major slowdowns in the compilation process.
>
> Note that such a system need not be *bytecode* at all, it can just hand the data structure off from one pass to the next. In fact, an actual bytecode requires a serialization of the data structures and then a reconstruction of them - rather pointless.
>
>
>> Not advocating bytecode here but you claiming it is completely useless is so
>> D-ish :).
>
> I'm not without experience doing everything bytecode is allegedly good at.
>
> As for CLI, it is great for implementing C#. For other languages, not so much. There turned out to be no way to efficiently represent D slices in it, for example.

There other part of an intermediate representation which you ignored is attaching *multiple backends* which is important for portability and the web.
Applications could be written in safeD (a subset that is supposed to have no implementation defined or undefined behaviors) and compiled to such an intermediate representation (let's call it common-IR since you don't like "bytecode"). Now, each client platform has its own backend for our common-IR. We can have install-time compilation like in .NET or JIT as in Java or both, or maybe some other such method.
Having such format allows to add distribution to the system. The serialization and de-serialization is only pointless when done on the same machine.

Another usecase could be a compilation server - we can put only the front-end on client machines and do the optimizations and native code generation on the server. This can be used for example in a browser to allow D scripting. Think for instant about smart-phone browsers.

the dreaded "bytecode" helps to solve all those use cases.

On Wednesday, 19 December 2012 at 07:14:30 UTC, Rob T wrote:
> On Wednesday, 19 December 2012 at 01:58:54 UTC, Jonathan M Davis wrote:
>> Such operations should be @system but are currently considered @safe. Who
>> knows how many others we've missed beyond what's currently in bugzilla.
>>
>> - Jonathan M Davis
>
> Unfortunately fixing these will break existing code, or can the behavior be depreciated?

We *must* take the liberty to fix them; if SafeD is not sound, it's hardly worth its salt.

David

On 12/19/12 4:10 AM, Rob T wrote:
> Do you have a theory or insight that can explain why a situation like
> the Java bytecode VM came to be and why it persists despite your
> suggestion that it is not required or of enough advantage to justify
> using it (may as well use Java source directly)?

I think the important claim here is that an AST and a bytecode have the same "power". Clearly to parse source code into AST form has a cost, which is clearly understood by everyone in this discussion.

Andrei

On 12/19/12 4:25 AM, Walter Bright wrote:
> On 12/19/2012 1:10 AM, Rob T wrote:
>> Using the JS code as an example, you are stating that the JS source
>> code itself
>> could just as well be viewed as the "bytecode", and therefore given
>> what I
>> previously wrote concerning the "advantages", I could replace
>> "bytecode" with
>> "JS source code" and achieve the exact same result. Am I Correct?
>
> Yes.

I thought the claim was about ASTs vs. bytecode, which slowly segued into source code vs. byte code. Are e in agreement there is a cost of translating JS source code to AST format? (The cost may be negligible to some applications but it's there.)

There's also the serialization aspect. Serializing and deserializing an AST takes extra effort because pointers must be fixed. Bytecode can be designed to avoid most of that cost.

On these two accounts alone, one may as well choose bytecode if it ever needs to be read and written. Defining a strategy for pointer serialization is comparable work.

>> Do you have a theory or insight that can explain why a situation like
>> the Java
>> bytecode VM came to be and why it persists despite your suggestion
>> that it is
>> not required or of enough advantage to justify using it (may as well
>> use Java
>> source directly)?
>
> Consider the US space shuttle design. It's probably the most
> wrong-headed engineering design ever, and it persisted because too many
> billions of dollars and careers were invested into it. Nobody could
> admit that it was an extremely inefficient and rather crazy design.
>
> A couple NASA engineers have admitted to me privately that they knew
> this, but to keep their careers they kept their mouths shut.

That's not answering the question.


Andrei

On 12/19/12 8:13 AM, David Nadlinger wrote:
> On Wednesday, 19 December 2012 at 07:14:30 UTC, Rob T wrote:
>> On Wednesday, 19 December 2012 at 01:58:54 UTC, Jonathan M Davis wrote:
>>> Such operations should be @system but are currently considered @safe.
>>> Who
>>> knows how many others we've missed beyond what's currently in bugzilla.
>>>
>>> - Jonathan M Davis
>>
>> Unfortunately fixing these will break existing code, or can the
>> behavior be depreciated?
>
> We *must* take the liberty to fix them; if SafeD is not sound, it's
> hardly worth its salt.
>
> David

Yes.

Andrei

On Wednesday, 19 December 2012 at 10:55:43 UTC, foobar wrote:
> There other part of an intermediate representation which you ignored is attaching *multiple backends* which is important for portability and the web.
> Applications could be written in safeD (a subset that is supposed to have no implementation defined or undefined behaviors) and compiled to such an intermediate representation (let's call it common-IR since you don't like "bytecode"). Now, each client platform has its own backend for our common-IR. We can have install-time compilation like in .NET or JIT as in Java or both, or maybe some other such method.
> Having such format allows to add distribution to the system. The serialization and de-serialization is only pointless when done on the same machine.
>
> Another usecase could be a compilation server - we can put only the front-end on client machines and do the optimizations and native code generation on the server. This can be used for example in a browser to allow D scripting. Think for instant about smart-phone browsers.
>
> the dreaded "bytecode" helps to solve all those use cases.

Imagine if the compiler were built in a user extensible way, such that one could write a plugin module that outputs the compiled code in the form of JVM bytecode which could run directly on the JVM.

It doesn't really matter if Walter is correct or not concerning his views, what matters is that people want X, Y and Z, and no matter how silly it may seem to some people, the silliness is never going to change. Why fight it, why not do ourselves a favor and embrace it. We don't have to do anything silly, just provide the means to allow people to do what they want to do. Most of it will be bad, which is the case right now and always will be, but every so often someone will do something brilliant.

Why not make D the platform of choice, meaning you really do have a choice?

--rt

On Wednesday, 19 December 2012 at 07:14:30 UTC, Rob T wrote:
> On Wednesday, 19 December 2012 at 01:58:54 UTC, Jonathan M Davis wrote:
>> Such operations should be @system but are currently considered @safe. Who
>> knows how many others we've missed beyond what's currently in bugzilla.
>>
>> - Jonathan M Davis
>
> Unfortunately fixing these will break existing code, or can the behavior be depreciated?
>

The code is already broken. The compiler detecting more faulty code is a plus.