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
