D popularity

Nick Sabalausky SeeWebsiteToContactMe at semitwist.com
Mon Jan 21 15:17:56 PST 2013


On Mon, 21 Jan 2013 21:02:49 +0100
"Rob T" <alanb at ucora.com> wrote:

> On Monday, 21 January 2013 at 08:09:45 UTC, Jonathan M Davis 
> wrote:
> > On Monday, January 21, 2013 08:52:23 Rob T wrote:
> >> If the goal is to increase the popularity of D, and if people
> >> prefer scripted languages over compiled, then a good place to
> >> start is to create an interpreter for D, thus allowing it to be
> >> used as a scripted language, and also retain the ability to be
> >> compiled for optimal performance.
> >
> > You can already do that. Assuming that dmd is installed in the 
> > right place,
> > you can make your source file executable, put #!/bin/dmd at the 
> > top of it, and
> > then run it. It'll be compiled and run. It's not interpreted, 
> > strictly
> > speaking, but given how fast D compiles and how fast D code 
> > runs once it's
> > been compiled, it'll be plenty fast.
> >
> > - Jonathan M Davis
> 
> Yes that kind of thing works well in some situations, but there's 
> more required than that. For example, there are situations where 
> you want to make a change to a component of a large application 
> without stopping the entire application. Also there are 
> situations where an embedded interpreter is critical to the 
> success of the application.
> 

That's what will be great about having good dynamic lib support - once
we get good dynamic lib support:

void reloadScriptD()
{
    if(system("rdmd -make-dll myScript.d") == Success!)
    {
        auto persistentState = myScriptModule.getPersistentState();
        myScriptModule.unload();
        myScriptModule = load("myScript.(dll|s)");
        myScriptModule.init(persistentState);
    }
}

Fucking awesome :)

I look forward to being able to do that (without worrying about
whatever shared lib issues I know exist but don't really understand).

In fact, didn't Quake 2 do something like that, just without actually
invoking the compiler? (Or using a language that compiles fast.)

Having a service-based D compiler would be even more awesome: Ie, Kinda
like how the fancier IDE's do incremental compilation, but generalized
out for more than just IDEs to use.

> I think that D almost gets it right, it's close and it does many 
> things very well, but it still falls short in terms of meeting 
> all of the major advantages of a scripted language.
> 

I, reluctantly, have to agree.

For shell-scripting sorts of things, I think D's already a very nice
alternative to bash/batch/etc despite some rough edges (Knowing that a D
compiler, of the right version, is properly set up in a standard way
on the target machine, and actually getting the new
std.process...eventually), but for individual programs that include
scriptability features I wouldn't feel comfortable trying it until D
dynamic libs are considered much more mature.

But note that these are all basically toolchain issues, and not actual
language issues. They're *certainly* not issues with D being
static-typed or native-compiled.



More information about the Digitalmars-d mailing list