Scientific computing with D

[Andrei Alexandrescu]

Christopher Wright wrote:
> Walter Bright wrote:
>> Daniel Keep wrote:
>>>
>>> Walter Bright wrote:
>>>> Bill Baxter wrote:
>>>>> Having to recompile and rerun after every one of those changes just
>>>>> isn't quite as direct.
>>>> If it can be done in under half a second, isn't that direct enough? Of
>>>> course, I'm talking about a shell that does it for you.
>>>
>>> $ int a = 42;
>>> $ writefln("a = %s", a);
>>> $ double a = 3.0; // rounded to 1 sf
>>>
>>> How would you write a prompt that does that with D?  Either you store
>>> each successive line in a source file and choke on the third one, or you
>>> compile each line separately and choke on the second.
>>>
>>> Or you could examine each line to look for things like redefining of
>>> symbols... but at that point you're half way to writing an interpreter
>>> anyway.
>>
>> It's the shell's responsibility to decide what semantics to present to 
>> the user, I'm just saying that the process of turning a code snippet 
>> into an executable is fast and should not be a barrier.
> 
> If bash took 0.5 seconds to execute anything, I wouldn't use it.
> 
> If it were something that I used infrequently, I'd tolerate that.

I think it's considerably less than 0.5 seconds for many small programs. 
dmd is surprisingly fast at rummaging through files, in fact so fast 
that I discovered that an intricate caching scheme I'd implemented in 
rdmd yielded no detectable improvement. Note that this is under Linux, 
which creates new processes way faster than Windows, so take this with a 
grain of salt.

I don't have the time to read this but I vaguely recall it might be 
related: 
http://members.shaw.ca/burton-radons/The%20Joy%20and%20Gibbering%20Terror%20of%20Custom-Loading%20Executables.html


Andrei