A look at the D programming language by Ferdynand Górski

[Rob T]

On Tuesday, 15 January 2013 at 20:02:58 UTC, Walter Bright wrote:
> On 1/14/2013 10:30 PM, Rob T wrote:
>> A really important advantage that scripting languages provides 
>> that D does not
>> currently provide, is direct runtime interpretation of the 
>> language. This is
>> very important for the use cases of script languages such as 
>> Ruby and PHP,
>> because often they are used for coding and testing on the fly, 
>> ie., used in an
>> environment that requires frequent changes with almost instant 
>> feedback.
>
> The way this is currently done is to put the code that would 
> otherwise be in a script into a DLL, and then the dev process 
> becomes:
>
> 1. run program
> 2. dynamically load DLL with "script"
> 3. debug
> 4. change "script" code
> 5. recompile "script" into new DLL
> 6. reload DLL
> 7. rinse, repeat
>
> It turns out that step 5 is nearly instant, on the order of a 
> few seconds.

Doing that is still more difficult in terms of technical skills. 
Also even when you have the skills, you need more access to 
perform code modifications remotely. Often too, you do not want 
to take down the entire application to make a quick fix to some 
bad code.

I think fully scripted languages appeal to the less technically 
inclined who prefer to "just get it done" with the least amount 
of hassle.

I'll suggest that the gap can be filled between scripted and 
compiled in a way that may get some serious attention. The rapid 
development process of a scripted language loses its advantage 
the minute the code stabilizes because at the point of stability, 
the interpretation process becomes a burden on resources without 
any advantages. If the stable scripted code can be compiled and 
linked in, then it gains the advantages of a compiled language.

This is an important point, because companies with large server 
farms are aware that they are paying far more money for 
processing power than they need to because their servers are 
running scripted code most of the time. For example, Twitter 
moved from Ruby to Java to gain performance, so imagine what they 
could get if they moved to something like D instead.

> The hair in the process, however, is DLLs still need better 
> support in D.

Yes, having full DLL support will help, and I cannot wait for 
that support.

When we say "DLL" that usually means Microsoft's implementation 
of dynamic linking, but we need support for Linux too. Also 
please do not overlook the importance of dynamically loaded 
libraries (loaded during runtime) for implementing loadable 
plugins giving you extensibility options like what you see with 
Firefox and other popular applications. Once D has plugin 
support, I'll be very happy.

>> You can also embed a scripting language directly into other 
>> applications, and
>> store "code" as data, which can be transmitted from one 
>> machine to another over
>> the wire. We can store and transmit D code too, but getting it 
>> to automatically
>> run on the other end is not so easy or convenient.
>
> Just so you know, we have a Javascript engine written in D, 
> meaning you can embed Javascript.

I knew about it, but I read somewhere that it was not fully 
compatible with the version of JS that is being used for web 
related work, is this correct? Still, it can be useful to have a 
look at it to see how it does its job.

I wonder if the work on the CTFE can be somehow spun off into an 
embeddable D interpreter?

--rt