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
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
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
On 12/21/2012 12: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
On 12/21/2012 2:13 AM, Max Samukha wrote:
What Walter is wrong about is that bytecode is entirely pointless.
I'll bite. What is its advantage over source code?
On Friday, 21 December 2012 at 10:30:21 UTC, Walter Bright wrote:
On 12/21/2012 2:13 AM, Max Samukha wrote:
What Walter is wrong about is that bytecode is entirely
pointless.
I'll bite. What is its advantage over source code?
Interpreting the AST directly: Requires recursion.
Interpreting a
On 12/21/2012 2:37 AM, Araq wrote:
On Friday, 21 December 2012 at 10:30:21 UTC, Walter Bright wrote:
On 12/21/2012 2:13 AM, Max Samukha wrote:
What Walter is wrong about is that bytecode is entirely pointless.
I'll bite. What is its advantage over source code?
Interpreting the AST
On Friday, 21 December 2012 at 10:37:05 UTC, Araq wrote:
On Friday, 21 December 2012 at 10:30:21 UTC, Walter Bright
wrote:
On 12/21/2012 2:13 AM, Max Samukha wrote:
What Walter is wrong about is that bytecode is entirely
pointless.
I'll bite. What is its advantage over source code?
On Friday, 21 December 2012 at 10:30:21 UTC, Walter Bright wrote:
On 12/21/2012 2:13 AM, Max Samukha wrote:
What Walter is wrong about is that bytecode is entirely
pointless.
I'll bite. What is its advantage over source code?
It is not about bytecode vs source code. It is about a common
On Friday, 21 December 2012 at 11:00:01 UTC, Max Samukha wrote:
On Friday, 21 December 2012 at 10:30:21 UTC, Walter Bright
wrote:
On 12/21/2012 2:13 AM, Max Samukha wrote:
What Walter is wrong about is that bytecode is entirely
pointless.
I'll bite. What is its advantage over source code?
On 21.12.2012 10:20, Timon Gehr wrote:
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
On 21.12.2012 11:28, Walter Bright wrote:
On 12/21/2012 12: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
On 2012-00-21 12:12, Max Samukha maxsamu...@gmail.com wrote:
On Friday, 21 December 2012 at 10:30:21 UTC, Walter Bright wrote:
On 12/21/2012 2:13 AM, Max Samukha wrote:
What Walter is wrong about is that bytecode is entirely pointless.
I'll bite. What is its advantage over source code?
It
On Friday, 21 December 2012 at 17:08:28 UTC, Simen Kjaeraas wrote:
On 2012-00-21 12:12, Max Samukha maxsamu...@gmail.com wrote:
On Friday, 21 December 2012 at 10:30:21 UTC, Walter Bright
wrote:
On 12/21/2012 2:13 AM, Max Samukha wrote:
What Walter is wrong about is that bytecode is entirely
On Friday, 21 December 2012 at 07:03:13 UTC, 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
Optimized LLVM bytecode look like a good candidate for the job.
Note that I'm not suggesting this as a spec, but as an example
of possible solution.
It's true that it couldn't be automatically decompiled to
something equivalent to the original D source, but it does
contain type information.
On 12/21/2012 12:07 PM, jerro wrote:
Optimized LLVM bytecode look like a good candidate for the job. Note that I'm
not suggesting this as a spec, but as an example of possible solution.
It's true that it couldn't be automatically decompiled to something equivalent
to the original D source, but
On Friday, 21 December 2012 at 20:08:00 UTC, jerro wrote:
Optimized LLVM bytecode look like a good candidate for the
job. Note that I'm not suggesting this as a spec, but as an
example of possible solution.
It's true that it couldn't be automatically decompiled to
something equivalent to the
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
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
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
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.
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
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
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
On Wednesday, 19 December 2012 at 07:22:45 UTC, Walter Bright
wrote:
On 12/18/2012 11:04 PM, Rob T wrote:
I'm not claiming to be an expert in this area either, however
it seems obvious
that there are significant theoretical and practical
advantages with using the
bytecode concept.
Evidently
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
On Wednesday, 19 December 2012 at 07:22:45 UTC, Walter Bright
wrote:
On 12/18/2012 11:04 PM, Rob T wrote:
I'm not claiming to be an expert in this area either, however
it seems obvious
that there are significant theoretical and practical
advantages with using the
bytecode concept.
Evidently
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
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,
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
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
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
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
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
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
On Wednesday, 19 December 2012 at 13:13:32 UTC, 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
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
On 12/19/2012 7:44 AM, Andrei Alexandrescu wrote:
I thought the claim was about ASTs vs. bytecode, which slowly segued into source
code vs. byte code.
Originally, the claim was how modules should be imported in some binary format
rather than as source code.
Are e in agreement there is a
On 12/19/2012 2:05 AM, eles wrote:
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
On 12/19/12 3:05 AM, eles wrote:
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
On Wednesday, 19 December 2012 at 21:00:20 UTC, Walter Bright
wrote:
On 12/19/2012 2:05 AM, eles wrote:
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.
On Wednesday, 19 December 2012 at 21:24:46 UTC, David Gileadi
wrote:
I had the same question, and Google found me a 2003 article
http://www.spacedaily.com/news/oped-03l.html
which in the wake of Columbia is largely about safety but also
about efficiency. Interestingly the article claims that
On 12/19/2012 4:09 PM, Rob T wrote:
As always the answer is never as simple as it seems (just as it is with bytecode
if I'm to attempt to stay on topic). One of subgoals of the space shuttle was
for it to be able to return not just people back, but also to capture and return
back to earth an
On Wednesday, 19 December 2012 at 09:25:54 UTC, Walter Bright
wrote:
Mostly. If you use bytecode, you have Yet Another Spec that has
to be defined and conformed to. This has a lot of costs.
But those are mostly one-time costs, and for software that has to
run millions of times over, if there
Am 20.12.2012, 01:54 Uhr, schrieb Rob T r...@ucora.com:
I'm not a fan of interpreted languages, except for situationswhere you
want to transport code in the form of data, or beable to store it for
later portable execution. LUA embeddedinto a game engine is an good use
case example
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
An interesting datapoint in regards to bytecode is Javascript. Note that
Javascript is not distributed in bytecode form. There is no Javascript VM. It is
distributed as source code. Sometimes, that source code is compressed and
obfuscated, nevertheless it is still source code.
How the end
On Tuesday, 18 December 2012 at 18:11:37 UTC, Walter Bright wrote:
I suspect there are other languages that do so, too.
Including (a buggy, incomplete subset of) D!
https://github.com/adamdruppe/dmd/tree/dtojs
On Tuesday, 18 December 2012 at 18:11:37 UTC, Walter Bright wrote:
An interesting datapoint in regards to bytecode is Javascript.
Note that Javascript is not distributed in bytecode form. There
is no Javascript VM. It is distributed as source code.
Sometimes, that source code is compressed and
On Tuesday, 18 December 2012 at 18:11:37 UTC, Walter Bright wrote:
Javascript proves that bytecode is not required for write
once, run everywhere, which was one of the pitches for
bytecode.
What is required for w.o.r.e. is a specification for the source
code that precludes undefined and
On Tuesday, 18 December 2012 at 18:22:40 UTC, Max Samukha wrote:
Actually, they call JavaScript an IL for the next ten years.
s/an/the
On 12/18/2012 10:29 AM, Peter Alexander wrote:
On Tuesday, 18 December 2012 at 18:11:37 UTC, Walter Bright wrote:
Javascript proves that bytecode is not required for write once, run
everywhere, which was one of the pitches for bytecode.
What is required for w.o.r.e. is a specification for the
On Tue, Dec 18, 2012 at 10:11:37AM -0800, Walter Bright wrote:
An interesting datapoint in regards to bytecode is Javascript. Note
that Javascript is not distributed in bytecode form. There is no
Javascript VM. It is distributed as source code. Sometimes, that
source code is compressed and
There is Emscripten which compiles LLVM to javascript, so you
could probably get D into JS like that also
https://github.com/kripken/emscripten
On 2012-12-18 19:11, Walter Bright wrote:
Note also that Typescript compiles to Javascript. I suspect there are
other languages that do so, too.
CoffeeScript and Dart to mention two other languages that compile to
JavaScript.
--
/Jacob Carlborg
On Tuesday, 18 December 2012 at 18:11:37 UTC, Walter Bright wrote:
An interesting datapoint in regards to bytecode is Javascript.
Note that Javascript is not distributed in bytecode form. There
is no Javascript VM. It is distributed as source code.
Sometimes, that source code is compressed and
On 12/18/2012 11:41 AM, H. S. Teoh wrote:
What is required for w.o.r.e. is a specification for the source code
that precludes undefined and implementation defined behavior.
[...]
What would you do with system-specific things like filesystem
manipulation, though? That has to be
On Tuesday, 18 December 2012 at 19:25:01 UTC, Walter Bright wrote:
On 12/18/2012 10:29 AM, Peter Alexander wrote:
On Tuesday, 18 December 2012 at 18:11:37 UTC, Walter Bright
wrote:
Javascript proves that bytecode is not required for write
once, run
everywhere, which was one of the pitches for
On 12/18/2012 12:38 PM, Peter Alexander wrote:
On Tuesday, 18 December 2012 at 19:25:01 UTC, Walter Bright wrote:
On 12/18/2012 10:29 AM, Peter Alexander wrote:
On Tuesday, 18 December 2012 at 18:11:37 UTC, Walter Bright wrote:
Javascript proves that bytecode is not required for write once,
On Tuesday, 18 December 2012 at 21:30:04 UTC, Walter Bright wrote:
D is open source. There is little implementation cost to doing
a compiler for it. It's a solved problem.
Let me emit some doubt about that.
First, D is difficult to compile because of the compile time
features. DMD frontend
On 12/18/12 3:35 PM, Walter Bright wrote:
And no, I don't think D can be a systems language *and* eliminate all
undefined and implementation defined behavior.
The SafeD subset takes care of that.
Andrei
On 12/18/2012 1:57 PM, deadalnix wrote:
Yes, it is trivial. The only thing that is lost are local variable names and
comments.
You'll find tools that compact your whole project, loosing in the process all
names.
I believe you're conflating releasing a whole project with what I'm talking
On Tue, Dec 18, 2012 at 07:08:04PM -0500, Andrei Alexandrescu wrote:
On 12/18/12 3:35 PM, Walter Bright wrote:
And no, I don't think D can be a systems language *and* eliminate all
undefined and implementation defined behavior.
The SafeD subset takes care of that.
[...]
Which right now
Without bytecode, the entire compiler becomes a dependency of a
AOT/JIT compiled program.. not only does bytecode allow for
faster on-site compilations, it also means half the compiler can
be stripped away (so i'm told, i'm not claiming to be an expert
here).
I'm actually kinda surprised
On 12/18/12 7:29 PM, H. S. Teoh wrote:
On Tue, Dec 18, 2012 at 07:08:04PM -0500, Andrei Alexandrescu wrote:
On 12/18/12 3:35 PM, Walter Bright wrote:
And no, I don't think D can be a systems language *and* eliminate all
undefined and implementation defined behavior.
The SafeD subset takes
On Tue, 18 Dec 2012, Andrei Alexandrescu wrote:
On 12/18/12 7:29 PM, H. S. Teoh wrote:
Which right now suffers from some silly things like writefln not being
able to be made @safe, just because some obscure formatting parameter is
un@safe. Which is exactly how @safe was designed, of
On Tuesday, December 18, 2012 17:57:50 Brad Roberts wrote:
On Tue, 18 Dec 2012, Andrei Alexandrescu wrote:
On 12/18/12 7:29 PM, H. S. Teoh wrote:
Which right now suffers from some silly things like writefln not being
able to be made @safe, just because some obscure formatting parameter is
On Wednesday, 19 December 2012 at 01:58:54 UTC, Jonathan M Davis
wrote:
Are the remaining issues at the compiler, runtime, or phobos
levels (or
what combination of the three)? Are the bugs filed?
Quite a few are, but it wouldn't surprise me at all if there
are quite a few
which aren't. For
On 12/18/2012 5:58 PM, Jonathan M Davis wrote:
On Tuesday, December 18, 2012 17:57:50 Brad Roberts wrote:
On Tue, 18 Dec 2012, Andrei Alexandrescu wrote:
On 12/18/12 7:29 PM, H. S. Teoh wrote:
Which right now suffers from some silly things like writefln not being
able to be made @safe, just
On Wednesday, 19 December 2012 at 01:09:14 UTC, F i L wrote:
Without bytecode, the entire compiler becomes a dependency of a
AOT/JIT compiled program.. not only does bytecode allow for
faster on-site compilations, it also means half the compiler
can be stripped away (so i'm told, i'm not
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,
On 12/18/2012 11:04 PM, Rob T wrote:
I'm not claiming to be an expert in this area either, however it seems obvious
that there are significant theoretical and practical advantages with using the
bytecode concept.
Evidently you've dismissed all of my posts in this thread on that topic :-)
On Tuesday, 18 December 2012 at 18:11:37 UTC, Walter Bright wrote:
An interesting datapoint in regards to bytecode is Javascript.
Note that Javascript is not distributed in bytecode form. There
is no Javascript VM. It is distributed as source code.
Sometimes, that source code is compressed and
74 matches
Mail list logo
