Kyle Furlong wrote:
> The question for us is, what "killer app" are we going to produce as a community.

How about the RoR equivalent for the desktop? ;)

http://www.litwindow.com/lwl/doc/html/comparison_10x.html

RapidUI it's an excellent library that wraps the wxWidgets SDK with macros and some template magic to speed up development of GUI apps.

Places were I see D competing with C++ face to face is in the Game and Shareware markets. A really easy game engine and a library like RapidUI wrapping DFL or DWT would sell any of my friends to D any day.

Maybe Doug Clougston (a.k.a Template Ninka) could take this task on it's shoulders?

"Sean Kelly" <sean@f4.ca> wrote
>>> I suppose it's reflective of the mindset here that my first thought was of GDC.  However, is there any barrier to using it for this purpose? And is the GCC tool-chain sufficient/appealing for embedded development? Alternately, are there other customizable options in this arena that could be made into something that doesn't feel like a cobbled together mess?

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?

Some GUI would perhaps help? Maybe a DFL for PocketPC? Or perhaps the WinCE version of DWT that Shawn has (the WinCE code is a version'd subset of the Win32 SWT)?

Thoughts?

"Kris" <fu@bar.com> wrote in message news:druk9p$20qd$1@digitaldaemon.com...
> "Sean Kelly" <sean@f4.ca> wrote
> >>> I suppose it's reflective of the mindset here that my first thought
was
> >>> of GDC.  However, is there any barrier to using it for this purpose?
And
> >>> is the GCC tool-chain sufficient/appealing for embedded development? Alternately, are there other customizable options in this arena that could be made into something that doesn't feel like a cobbled together mess?
>
> 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?
>
> Some GUI would perhaps help? Maybe a DFL for PocketPC? Or perhaps the
WinCE
> version of DWT that Shawn has (the WinCE code is a version'd subset of the
> Win32 SWT)?
>
> Thoughts?

Keep singing, my corpulent little damsel.

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.

> Some GUI would perhaps help? Maybe a DFL for PocketPC? Or perhaps the WinCE version of DWT that Shawn has (the WinCE code is a version'd subset of the Win32 SWT)?

The latter, I think.  I'd like to believe a WinCE port of DWT wouldn't be terribly difficult, and it would be nice to have a consistent API across platforms.


Sean

"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.

So, I suspect the problem be finding volunteers? I'm afraid I don't have the requisite knowledge, time, or skills to take this on; much as I'd dearly love to. It would probably require some debugger support from Walter too, as you noted earlier.


>> Some GUI would perhaps help? Maybe a DFL for PocketPC? Or perhaps the WinCE version of DWT that Shawn has (the WinCE code is a version'd subset of the Win32 SWT)?
>
> The latter, I think.  I'd like to believe a WinCE port of DWT wouldn't be terribly difficult, and it would be nice to have a consistent API across platforms.

Aye. I think we'd find that Shawns work is already 95% there (he's got version(wince) in the codebase, where SWT had if(WinCE) instead).

In article <drtrho$1f1u$1@digitaldaemon.com>, Matthew says...
>
>"Kris" <fu@bar.com> wrote in message news:drtnc5$1ar4$1@digitaldaemon.com...
>> "Walter Bright" <newshound@digitalmars.com> wrote
>>
>> > That's just the problem. If I worked on embedded systems, nothing else would happen.
>>
>> Ah yes; the "all or nothing" syndrome :)
>>
>> This "embedded market" approach is just a notion; take it or leave it.
>Yet,
>> I'm surprised to see you just "pooh pooh" it with a "well, I couldn't do anything else" type of response. That's indicative of a knee-jerk reaction rather than careful thought ~ of course, I could be completely mistaken. Still, you have to wonder why others feel it would be a sound approach.
>
>It's not "a sound approach". It's _the only_ approach I've heard about D that doesn't smack of crossed fingers and pipe-dreams. I think it's time Walter told us what his approach is, cos it sure ain't giving talks to

IMO, a previous post of yours (Matthew) about adding features to the language to entice programmers away from script languages made at least as much sense to me.

The fastest growing languages over recent years have been scripting languages (like you mentioned: Perl, PHP, Python, Ruby, JavaScript) and I think a lot of that is because one can fire up the code editor and knock-out quick utilities, as you mentioned. In particular Perl and Ruby because of built-in regex. PHP started as more-or-less a prototyping tool for smallish sites and now look at it.

If D had a few more script-language like conveniences, then I think many C developers using shell or Perl for utilities would be impressed if they could replace both script and C with D..

The shop I'm currently working in uses many scripts that stay around for years. In typical UNIX fashion, each 'module' is small, standalone and does it's (single) job well, and is then chained together with others to make a 'program'. If it's not in ksh or Perl, it's in C for performance reasons, or to most easily interface with another C library.

For alot of things, D would be the all-around better choice, especially if it could be comfortably used for 'scripting chores'. What's standing in the way are things like Perl's built-in regex and nice 'glue' support routines (e.g.: open(FH,"cut -c1-3 some_data |");while(<FH>){...}). Most of the latter could and should be provided in libraries though, while I'm coming to believe that maybe basic regex support would be served well as part of the language.

One other thing about scripts of course is that you fire them up at the command-line w/o compilation.

I just built a small 'interpreter' that will take a D file prefaced with '#!/usr/bin/rdmd', compile it and run it.

To really make this work nicely, the compiler would have to ignore any first line starting with '#!' and would also (ideally) be able to take input from stdin.

example:

hello_script.d:
---------------
#!/usr/bin/rdmd
import std.stdio;
int main()
{
writefln("Hello (pseudo) scripting world");
}

# chmod u+x hello_script.d
# hello_script.d

(At any time it could be simply compiled and run, of course).

Since the compiler is so fast, it's feasible for even larger 'script' files (one problem is that linking with gcc is a bottleneck for single files).

Please excuse my babbling, but I think this is one area (small utilities initially) where D could catch on with people: "The power of C++, the speed of C and the convenience of Perl". <g>

Kris wrote:

> A changing of direction would pre-suppose an existing one ;-)

Yeah,
but direction happens anyway without pointing. Like through actions ?
But it's a lot harder to read between the lines than from the lines...

> Seriously, what interests me is setting a strategic gameplan for D gaining real-world traction. As Matthew noted, there's been little more than some vague finger-crossing and fluffly-wishing thus far. My interest is purely selfish ~ I want D to become a legitimate option in the commercial sector because it's simply a more advanced tool for the kind of work I'm involved in.

I'm using it for myself and as an alternative in a free software world. Currently I do not offer any commercial D packages, they're all gratis.

--anders

Dave wrote:
> If D had a few more script-language like conveniences, then I think many C
> developers using shell or Perl for utilities would be impressed if they could
> replace both script and C with D..

On the face of it, trying to mix languages from the opposite ends of the spectrum sounds like dangerous ground :)

[snip]
> To really make this work nicely, the compiler would have to ignore any first
> line starting with '#!' and would also (ideally) be able to take input from
> stdin.
> 
> example:
> 
> hello_script.d:
> ---------------
> #!/usr/bin/rdmd

Egad! :)

Is is possible hide that within a comment?

[snip]

> Please excuse my babbling, but I think this is one area (small utilities
> initially) where D could catch on with people: "The power of C++, the speed of C
> and the convenience of Perl". <g>

And the eyes of a snake :)

It sounds interesting; like a modern-day Rexx perhaps? Yet, though 'auto' is really nice, is it a match for the lax types and late-binding in a typical scripting environment? Isn't there perhaps some risk of creating a FrankenD? Or are you thinking of a much more restricted style of scripting?

Native regular-expressions in D have been visited a number of times, but I don't think anyone has come up with a really solid approach for it yet. There's the distinct possiblity of doing so via templates, but that perhaps wouldn't have the charm or simplicity of a scripting language?

Then there's long unanswered questions about how to handle things like regex text-folding in unicode ~ toupper() et. al. just don't cut it anymore, and the rules can become really quite complex. Perhaps building all that into the language itself (rather than via a configurable library) ought to raise an eyebrow or two? I mention this because of a familiarity with ICU.

After that, wouldn't one want to start building, say, the IO system directly into the language? Or is that stretching the concept?

2 cents;

Anders F Björklund wrote:
> Kris wrote:
>> Seriously, what interests me is setting a strategic gameplan for D gaining real-world traction. As Matthew noted, there's been little more than some vague finger-crossing and fluffly-wishing thus far. My interest is purely selfish ~ I want D to become a legitimate option in the commercial sector because it's simply a more advanced tool for the kind of work I'm involved in.
> 
> 
> I'm using it for myself and as an alternative in a free software world. Currently I do not offer any commercial D packages, they're all gratis.

I hope you misunderstood me on that one ~ I didn't mean any commercial stuff that I might have personally (all my code is gratis too). Instead I meant using D as a recognized and valid alternative for C++/ObjectiveC/Java within the place where I work. I don't care much for those, so it would be nice to legitimally use D in the workplace instead.

kris wrote:

> I hope you misunderstood me on that one ~ I didn't mean any commercial stuff that I might have personally (all my code is gratis too). Instead I meant using D as a recognized and valid alternative for C++/ObjectiveC/Java within the place where I work. I don't care much for those, so it would be nice to legitimally use D in the workplace instead.

No, I don't think I did... Just that I'm using Perl/PHP "commercially"
at the moment and don't have any non-hobby projects going, D-suitable.

I've always found that companies make their decisions on non-technical
grounds, so maybe D just needs some better marketing. Or a new name :-)


Anyway, my vague point was that right now I am doing this for myself.

Whether or not it (D) will become a legitimate option in the commercial sector is not something that I worry about. Seems to be all .NET anyway.

But I would of course also *like* seeing D become a valid alternative !

--anders