"Walter Bright" <newshound@digitalmars.com> wrote ...
>
> "Kris" <fu@bar.com> wrote ...
>> 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.
>
> 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's cool enough to put the idea in peoples' minds "why am I using a scripting language instead of D?"


OK ~ thanks. Then, if you can, I'd very much appreciate a comment on these related questions:

* So, what happens when you need to debug? D is hardly immune to such things.

* What happens when the source gets "out of date" with the hidden compiler and/or libraries? Couldn't an self-contained executable be considered better in such cases? Like a statically-linked program can sometimes be better than one using DLLs instead?

* This would be the only thing in the compiler front-end that is not platform independent. It that such a good precedent?

* "One file apps" confuses me a bit.  I mean, doesn't the user also have to install GDC, GCC, LIBC, GDB, along with some 'Host' program to compile and cache results? Won't they also have to manage conflicts between GDC and GCC versioning?

* Given that the compiler is so darned fast, why not just compile it immediately anyway? Using "build myscript"?

* Why would someone (who doesn't yet know D) choose to use D for quick, easy, disposable code when they could use Ruby/Python/Perl etc instead?

* Surely the percentage of such disposable code that actually needs to be faster than say, Ruby, is rather small?

Sean Kelly wrote:
> James Dunne wrote:
> 
>> Kris wrote:
>>
>>> "Sean Kelly" <sean@f4.ca> wrote ...
>>>
>>>> Kris wrote:
>>>>
>>>>> So, here's a bit of (somewhat old) speculation:
>>>>>
>>>>> * GCC can apparently generate PocketPC compatable code, for ARM/XScale. David Friedman doesn't feel there'd be huge issues getting GDC to take advantage of that.
>>>>>
>>>>> * Microsoft has both emulators and debuggers for these devices. Very good ones.
>>>>>
>>>>> Do you think it would be cool to get those working together? And then promote the heck out of it? I mean, isn't it potentially a better story than .NET for that market?
>>>>
>>>>
>>>> Definately.  And with Phoenix now available, this may not be terribly difficult, though David would be the one to ask here.
>>>
>>>
>>
>> I hate bursting bubbles but I think Phoenix is a C# API.
> 
> 
> Even if it is, it might not be too difficult to create a managed C++ wrapper for the DMD/GDC front-end.  Also, the Phoenix docs indicate that it accepts MSIL, so code-level integration may not be necessary.
> 
> 
> Sean

For C++ to Managed C++ conversion, insert __gc before every array declaration and new operator, basically...  I've tried to convert the most trivial of C applications over to Managed C++ and it was an absolute nightmare (mostly cuz I didn't get the hang of __gc and __nogc).

"Kris" <fu@bar.com> wrote in message news:ds14ir$16fn$1@digitaldaemon.com...
> "Walter Bright" <newshound@digitalmars.com> wrote ...
>> 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's cool enough to put the idea in peoples' minds "why am I using a scripting language instead of D?"
>
>
> OK ~ thanks. Then, if you can, I'd very much appreciate a comment on these related questions:
>
> * So, what happens when you need to debug? D is hardly immune to such things.

Use the traditional edit/compile/debug cycle on it. This doesn't break that.

> * What happens when the source gets "out of date" with the hidden compiler and/or libraries?

It stops working. (Script engines have exactly the same problem, I know a programmer who had a lot of grief with perl scripts over this.)

> Couldn't an self-contained executable be considered better in such cases?

Absolutely. Interestingly, some script engines have the ability to create 'native' executables by essentially bundling the compiler/interpreter in with the script into one big file.

> Like a statically-linked program can sometimes be better than one using DLLs instead?

Yes.

> * This would be the only thing in the compiler front-end that is not platform independent. It that such a good precedent?

It's a well established precedent in other scripting languages.

> * "One file apps" confuses me a bit.  I mean, doesn't the user also have to install GDC, GCC, LIBC, GDB, along with some 'Host' program to compile and cache results?

Yes. But gcc, libc, and gdb will already be there. And this will give an incentive to put gdc into the default distribution so it is always there, too. It isn't a different problem than script engines already have.

> Won't they also have to manage conflicts between GDC and GCC versioning?

Yes, but similar issues exist for Perl and that doesn't seem to have impeded it.

> * Given that the compiler is so darned fast, why not just compile it immediately anyway? Using "build myscript"?

The fast compiler is what makes this practical. You don't have to manage .obj and .exe files, nor store them. You're replacing 100Kb files with 1Kb files.

> * Why would someone (who doesn't yet know D) choose to use D for quick, easy, disposable code when they could use Ruby/Python/Perl etc instead?

Because they don't have to throw away their code and start over in another language when it exceeds a certain level of complexity or starts having performance limitations. Lots of sophisticated projects started out as quick hacks, and just grew. D provides a growth path.

> * Surely the percentage of such disposable code that actually needs to be faster than say, Ruby, is rather small?

The attraction is scalability - you can use one language for small throwaway scripts and the same language for huge projects. Less learning. (A lot of people are attracted to Ruby, only to find out that it just doesn't work for large projects.)

"Walter Bright" <newshound@digitalmars.com> wrote
>> * So, what happens when you need to debug? D is hardly immune to such things.
>
> Use the traditional edit/compile/debug cycle on it. This doesn't break that.
>
>> * What happens when the source gets "out of date" with the hidden compiler and/or libraries?
>
> It stops working. (Script engines have exactly the same problem, I know a programmer who had a lot of grief with perl scripts over this.)
>
>> Couldn't an self-contained executable be considered better in such cases?
>
> Absolutely. Interestingly, some script engines have the ability to create 'native' executables by essentially bundling the compiler/interpreter in with the script into one big file.
>
>> Like a statically-linked program can sometimes be better than one using DLLs instead?
>
> Yes.
>
>> * This would be the only thing in the compiler front-end that is not platform independent. It that such a good precedent?
>
> It's a well established precedent in other scripting languages.
>
>> * "One file apps" confuses me a bit.  I mean, doesn't the user also have to install GDC, GCC, LIBC, GDB, along with some 'Host' program to compile and cache results?
>
> Yes. But gcc, libc, and gdb will already be there. And this will give an incentive to put gdc into the default distribution so it is always there, too. It isn't a different problem than script engines already have.
>
>> Won't they also have to manage conflicts between GDC and GCC versioning?
>
> Yes, but similar issues exist for Perl and that doesn't seem to have impeded it.
>
>> * Given that the compiler is so darned fast, why not just compile it immediately anyway? Using "build myscript"?
>
> The fast compiler is what makes this practical. You don't have to manage .obj and .exe files, nor store them. You're replacing 100Kb files with 1Kb files.
>
>> * Why would someone (who doesn't yet know D) choose to use D for quick, easy, disposable code when they could use Ruby/Python/Perl etc instead?
>
> Because they don't have to throw away their code and start over in another language when it exceeds a certain level of complexity or starts having performance limitations. Lots of sophisticated projects started out as quick hacks, and just grew. D provides a growth path.
>
>> * Surely the percentage of such disposable code that actually needs to be faster than say, Ruby, is rather small?
>
> The attraction is scalability - you can use one language for small throwaway scripts and the same language for huge projects. Less learning. (A lot of people are attracted to Ruby, only to find out that it just doesn't work for large projects.)

~~~~~~~~~~~~~~~

Since you have an answer for everything, how about this one: <g>

What is the strategic plan for getting D adopted in the commercial market-place? Can you perhaps talk about 1 year, 3 year, and 5 year intervals please? If there isn't one, then that's fine too.

James Dunne wrote:
> 
> For C++ to Managed C++ conversion, insert __gc before every array declaration and new operator, basically...  I've tried to convert the most trivial of C applications over to Managed C++ and it was an absolute nightmare (mostly cuz I didn't get the hang of __gc and __nogc).

This is no longer true in VC 2005--the syntax has been changed completely, and the new syntax is a lot more palatable.  However, I wasn't thinking of converting all of GDC so much as writing a marshalling layer of sorts.  That aside, the MSIL option still holds.


Sean

Kris wrote:
> "Walter Bright" <newshound@digitalmars.com> wrote
>>> * So, what happens when you need to debug? D is hardly immune to such things.
>> Use the traditional edit/compile/debug cycle on it. This doesn't break that.
>>
>>> * What happens when the source gets "out of date" with the hidden compiler and/or libraries?
>> It stops working. (Script engines have exactly the same problem, I know a programmer who had a lot of grief with perl scripts over this.)
>>
>>> Couldn't an self-contained executable be considered better in such cases?
>> Absolutely. Interestingly, some script engines have the ability to create 'native' executables by essentially bundling the compiler/interpreter in with the script into one big file.
>>
>>> Like a statically-linked program can sometimes be better than one using DLLs instead?
>> Yes.
>>
>>> * This would be the only thing in the compiler front-end that is not platform independent. It that such a good precedent?
>> It's a well established precedent in other scripting languages.
>>
>>> * "One file apps" confuses me a bit.  I mean, doesn't the user also have to install GDC, GCC, LIBC, GDB, along with some 'Host' program to compile and cache results?
>> Yes. But gcc, libc, and gdb will already be there. And this will give an incentive to put gdc into the default distribution so it is always there, too. It isn't a different problem than script engines already have.
>>
>>> Won't they also have to manage conflicts between GDC and GCC versioning?
>> Yes, but similar issues exist for Perl and that doesn't seem to have impeded it.
>>
>>> * Given that the compiler is so darned fast, why not just compile it immediately anyway? Using "build myscript"?
>> The fast compiler is what makes this practical. You don't have to manage .obj and .exe files, nor store them. You're replacing 100Kb files with 1Kb files.
>>
>>> * Why would someone (who doesn't yet know D) choose to use D for quick, easy, disposable code when they could use Ruby/Python/Perl etc instead?
>> Because they don't have to throw away their code and start over in another language when it exceeds a certain level of complexity or starts having performance limitations. Lots of sophisticated projects started out as quick hacks, and just grew. D provides a growth path.
>>
>>> * Surely the percentage of such disposable code that actually needs to be faster than say, Ruby, is rather small?
>> The attraction is scalability - you can use one language for small throwaway scripts and the same language for huge projects. Less learning. (A lot of people are attracted to Ruby, only to find out that it just doesn't work for large projects.)
> 
> ~~~~~~~~~~~~~~~
> 
> Since you have an answer for everything, how about this one: <g>
> 
> What is the strategic plan for getting D adopted in the commercial market-place? Can you perhaps talk about 1 year, 3 year, and 5 year intervals please? If there isn't one, then that's fine too.
> 
> 
> 

I'm also very interested in a response to this query.

"Kris" <fu@bar.com> wrote in message news:ds183t$18j6$1@digitaldaemon.com...
> What is the strategic plan for getting D adopted in the commercial market-place? Can you perhaps talk about 1 year, 3 year, and 5 year intervals please? If there isn't one, then that's fine too.

The plan is to continue to expand its appeal by expanding its capabilities, and to continue to flog it at every opportunity.

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.

Thomas

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.

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.

/Oskar

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. I think a reader with no prior knowledge of D would be left with an overall positive impression.

And while I don't necessarily believe that "all PR is good PR", I think that every time D gets mentioned on /. some readers will click the link and check out the docs, and a few will download and try the compiler. And once they're HOOKED, there's no turning back ;-)

Nick

In article <drr58d$21j0$1@digitaldaemon.com>, pragma says...
>
>In article <pan.2006.02.01.20.06.12.251531@sneakemail.com>, =?iso-8859-1?q?Knud_S=F8rensen?= says...
>>
>>Slashdot have just posted a story called beyond Java
>>
>>http://books.slashdot.org/article.pl?sid=06/02/01/1455213
>
>Wow.  The feedback to those D posts is.. erm.. brutal.
>
>Gotta love Slashdot.