In article <ds29bf$20rb$1@digitaldaemon.com>, Nick says...
>
>I've just read the slashdot article now (long after the discussion has died out there), and I have to say I didn't think it was anything near "brutal" :) Comparing to comments I've seen about D om /. earlier, I was rather pleasantly surprised by the comments that got modded up.

For what its worth: I got into that thread a little early (before it was even mentioned here), and saw how things were going.  There were a bunch of trolls and knee-jerk reactions to the D-based posts.  It was my gut feeling that things were going to snowball in that direction.  I'm glad to see they didn't. :)

>I think a reader with no prior
>knowledge of D would be left with an overall positive impression.

Simply.  Awesome.  Glad to hear that.

- Eric Anderton at yahoo

Thomas Kuehne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Kris schrieb am 2006-02-03:
> 
>>"pragma" <pragma_member@pathlink.com> ...
>>
>>
>>>You probably already know this, but the '#!' is a token used by the shell
>>>directly:
>>>
>>>http://www.tldp.org/LDP/abs/html/sha-bang.html
>>
>>
>>I guessed so, but was hoping there'd be an alternative?
> 
> 
> Well there is an alternative...
> 
> 1) Begin every D file with a magic sequence like "//-this-is-a-D-script-".
> 
> 2) Add the magic sequence to "/etc/mime-magic".
> 
> 3) Add the magic sequence and the script handler to "/etc/mailcap".
> 
> The problem: 2) and 3) require root access.

Ah; thanks

Oskar Linde wrote:
> Hi,
> 
> Kris wrote:
> 
> [snip]
> 
> 
>>So, while I can clearly see benefits in making the language itself more
>>"approachable" (such as native regex), the notion of a D script appears to
>>be something of a hollow promise? It's still just normal D, after all.
>>Yes?
> 
> 
> Compared to a compiled program, a script is:
> - Transparent. The user has immediate access to the (current) source which
> may or may not be available otherwise.
> - Platform independent. A D script on a nfs share could work on both a Sparc
> Solaris and a x86 Linux machine for example.
> 
> The advantages of a D script would not necessarily be in development time,
> but in distribution and being easily customizable by the user.

Thanks; I appreciate the reply, and agree there's some value in the above. It's just not clear to me how much value is really there (rather little, on the face of it ~ I mean, sharing a D 'script' between Solaris and x86 linux is not exactly a wildly predominant activity, is it?)

On the other hand, I can see using this as an argument for sneaking a D compiler into various standard distributions. Except for one thing: the D community has zero pull or leverage in terms of making that happen for  the multiple distro's that would be required to make this a turn-key script-sharing environment. You'll forgive me if I note that the "out of the box" cross-platform sharing aspect (that Walter pimped earlier) seems riddled with finger-crossing and hollow-promise?


> Regarding development times: small scripts are often coded in different ways
> than regular programs. For example, scripts often contain hardcoded paths
> and values that the user may need to change. A user can probably make such
> changes without needing much (any) knowledge of D and how to invoke a
> compiler.

I'd agree on the simplicity aspect, if Build were not available. But your (valid) argument regarding changes holds perfectly true for Build also. Delaying (hiding) the compile-cycle does not affect that in any way. Wouldn't you agree? I mean, if GDC is going to be magically included in all distro's, then Build can magically be included too.

So why am I troubled by this anyway? Well, it just seems like yet another typically vague and transparant example of the "clutching at straws" approach to D adoption.

In article <ds0qi1$1050$1@digitaldaemon.com>, Walter Bright says...
>
>
>"Kris" <fu@bar.com> wrote in message news:ds0hpf$p5m$1@digitaldaemon.com...
>> How do I resolve that with an association (as described) that tries to execute the file instead? Doesn't it seem that ".d" is being badly overloaded here? And, why would I not just compile such a file/script into an executable in the first place? What is the overriding value in trying to execute a ".d" ? Are you trying to hide the compiler for some reason?
>>
>> It seems like a good idea to make D more 'approachable' at the language level, yet what you describe above appears to cause difficulties instead?
>
>I think this is not going to work on Windows for the reasons you mentioned. It'll work on *nix systems, but that still won't adversely affect Windows.

I think it will instead work. The only precaution being to change the extension
for d script files. Use ".ds" and you win.
Apart from that, I think that having a different extension for D sources
designed to be used as a script is a Good Thing(R).

>The reason to have it, where it can be supported, is simply sugar. One file apps can be distributed as source, and it's not necessary for the user to worry about compiling them, where to store the executable, what if the source gets out of sync with the executable, etc. A good implementation can, as Dave suggested, cache the generated executables so it really is just as good as compiling them manually.

It was my suggestion, not Dave's.

>It's cool enough to put the idea in peoples' minds "why am I using a scripting language instead of D?"

Yes!

Ciao

---
http://www.mariottini.net/roberto/

"Roberto Martiottini" <Roberto_member@pathlink.com> wrote in message news:ds70b2$2ca8$1@digitaldaemon.com...
>>> In article <ds0qi1$1050$1@digitaldaemon.com>, Walter Bright says...
>>The reason to have it, where it can be supported, is simply sugar. One
>>file
>>apps can be distributed as source, and it's not necessary for the user to
>>worry about compiling them, where to store the executable, what if the
>>source gets out of sync with the executable, etc. A good implementation
>>can,
>>as Dave suggested, cache the generated executables so it really is just as
>>good as compiling them manually.
>
> It was my suggestion, not Dave's.

Ah, my mistake. Thank you for the correction.