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 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

Don't get me wrong, I agree that broken behavior must always be fixed and never left in as a "feature".

Probably the priority bugs should be the ones where the fix ends up breaking existing code. The sooner these are gotten rid of the better.

--rt

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 cost of translating JS source
> code to AST format? (The cost may be negligible to some applications but it's
> there.)

There is a cost, and it is a killer if you've got an 8 bit CPU with a 2K EPROM as a target. This is no longer relevant.


> 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.

Bytecode does not avoid that cost, in fact, bytecode *is* a serialized AST format. (And, btw, the first thing a JIT compiler does is convert bytecode back into an AST.)


> 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.

You're not saving anything.


> That's not answering the question.

Analogies are legitimate answers to questions about motivation.

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 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?

It boils down to the overriding expense in spaceflight is weight. There's the notion of "payload", which is the weight of whatever does something useful in space - the whole point of the mission.

Every bit of weight adds a great deal of more weight in terms of cost to push it all into orbit.

To make the shuttle return and land, you've got wings, rudder, landing gear, flight control system, basically a huge amount of weight devoted to that. That weight subtracts from what you can push up as payload. All of the lifting capability for that also must be insanely reliable.

(And never mind needing things like a custom 747 to transport it around because it's too big to go on the roads, all that money spent trying to make a reusable heat shield, etc.)

Now consider the only thing that actually has to return are the astronauts. And all they actually need to return is a heatshield and a parachute - i.e. an Apollo capsule.

Thinking about it from basic principles, you need:

1. astronauts
2. payload
3. a way to get the astronauts back

So the idea then is to have two launches.

1. an insanely reliable rocket to push the astronauts up, and nothing else
2. a less reliable (and hence cheap) heavy lift rocket to push the payload up

The two launches dock in space, astronauts do their job, astronauts return via their Apollo-style capsule.

Mission accomplished at far, far less cost.

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 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.

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 the shuttle flaws were largely the result of a) the desire to carry large payloads along with astronauts (as Walter mentions) and b) the choice of fuel, which led to several other expensive and dangerous design choices.

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. 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?
>
> It boils down to the overriding expense in spaceflight is weight. There's the notion of "payload", which is the weight of whatever does something useful in space - the whole point of the mission.
>
> Every bit of weight adds a great deal of more weight in terms of cost to push it all into orbit.
>
> To make the shuttle return and land, you've got wings, rudder, landing gear, flight control system, basically a huge amount of weight devoted to that. That weight subtracts from what you can push up as payload. All of the lifting capability for that also must be insanely reliable.
>
> (And never mind needing things like a custom 747 to transport it around because it's too big to go on the roads, all that money spent trying to make a reusable heat shield, etc.)
>
> Now consider the only thing that actually has to return are the astronauts. And all they actually need to return is a heatshield and a parachute - i.e. an Apollo capsule.
>
> Thinking about it from basic principles, you need:
>
> 1. astronauts
> 2. payload
> 3. a way to get the astronauts back
>
> So the idea then is to have two launches.
>
> 1. an insanely reliable rocket to push the astronauts up, and nothing else
> 2. a less reliable (and hence cheap) heavy lift rocket to push the payload up
>
> The two launches dock in space, astronauts do their job, astronauts return via their Apollo-style capsule.
>
> Mission accomplished at far, far less cost.

The shuttle was originally intended to be a lot smaller and sit atop the central booster, avoiding the issues that caused the Columbia disaster. I believe that design may have been intended to operate in the manner you suggest, however the CIA demanded that the shuttle be made much larger to accommodate large military satellites, distorting the design and making it a lot less efficient.

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 the shuttle flaws were largely the result of a) the desire to carry large payloads along with astronauts (as Walter mentions) and b) the choice of fuel, which led to several other expensive and dangerous design choices.

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 orbiting payload. It also carnied along instrumentation such as the Canadarm, a very expensive device that you normally would not want to throw away. The arm was used for deploying the payload and also for performing repair work. It is hard to imagine a throw away rocket booster approach meeting all of these design goals, and I'm leaving out other abilities you cannot get from a simple return capsule approach.

A mistake would be to use the shuttle for purposes that it was not suitable for, such as situations that did not need its unique abilities and could be done more cheaply.

--rt

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 orbiting payload. It also carnied along instrumentation such as
> the Canadarm, a very expensive device that you normally would not want to throw
> away. The arm was used for deploying the payload and also for performing repair
> work. It is hard to imagine a throw away rocket booster approach meeting all of
> these design goals, and I'm leaving out other abilities you cannot get from a
> simple return capsule approach.

I find it hard to believe that the Canadarm cost more than wings, landing gear, a custom 747, etc. (That custom 747 probably cost a cool billion all by itself.) Secondly, the cost of the Canadarm consists of two parts: engineering design, and construction. Once the design is done, the incremental construction cost of making multiple ones is way, way, way cheaper.

As for returning an orbiting payload, has that ever happened? And still, one could launch a shell with a heatshield and parachute on it, put that payload into the shell, and drop it into the atmosphere.

I can see needing to return spy satellites with their film canisters, but film is hopelessly obsolete now, and I can't see any such satellites these days.

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

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 are enough performance gains by first compiling to bytecode, it could be worth the costs over the long term.

If there may be better methods of producing he same or better results that are not strictly bytecode, then that's another story, however one goal is to have a common language that amalgamates everything together under a common roof.

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?

The other question, is are there better alternative techniques? For example, compiling regular source directly to native using a JIT approach. In many ways, this seems like the very best approach, which I suppose is precisely what you've been arguing about all this time. So perhaps I've managed to convince myself that you are indeed correct. I'll take that stance and see if it sticks.

BTW I'm not a fan of interpreted languages, except for situations where you want to transport code in the form of data, or be able to store it for later portable execution. LUA embedded into a game engine is an good use case example (although why not D!).

--rt

Am 20.12.2012, 01:54 Uhr, schrieb Rob T <rob@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 (although why
>  not D!).

Because you need a D-Programmer to program in D. ;)
Scripting languages like Lua reduce the complexity
of programming to fit the needs of its users, which
are often often not programmer. There is a lot more
needed to programm in D then in Lua.

BTW: LuaJIT uses the source code, not Luas byte code.

Peter

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.


> The other question, is are there better alternative techniques? For example,
> compiling regular source directly to native using a JIT approach. In many ways,
> this seems like the very best approach, which I suppose is precisely what you've
> been arguing about all this time. So perhaps I've managed to convince myself
> that you are indeed correct. I'll take that stance and see if it sticks.

Not exactly, I argue that having a bytecode standard is useless. How a compiler works internally is fairly irrelevant.