<alert comment="newbie zealot">

> What I am excited about is D is becoming the premier language to do unicode in, by a wide margin. And that's thanks to you guys!

This post from The WB back in 04-Aug has stayed with me. I'm not the most imaginative person or "brightest bulb in the box", but sometimes I'm less than clear on what D will eventually be really good for as it matures and hopefully achieves mind-share and market-share critical mass.

I think it might be interesting/valuable to solicit ideas on the kinds of software that D might be especially suitable for.

Another way to think of this question: what kind of projects could we suggest 'D' as the language of choice for the next major release of existing software that has outgrown its original 'sandbox'?

For instance, perhaps reverse-engineering of originally niche apps that were written in interpretative languages (python, php, perl, ruby), but the app has become very popular and would benefit from a "real" compiled language for performance and reliability. phpBB? wiki? SCons?

Another instance; I think D has good-to-great potential to replace certain Java apps that are slower than molasses.

Specifically, the commerical products JTest and C++Test from Parasoft come to mind. They are nice for advanced Lint capabilities, but are practically unusable because they are so sloooooow. It can take overnight to process a medium size set of source files.

I think the XML tools from Altova (Spy, Authenticate, etc.) are written in Java, since they ship with .jar files. My limited experience with them was that they were also slooooooooow.

The Qarbon viewlet application for animated slideshows is written in Java and is sloooooooow. It can 'grind' for almost an hour on elaborate scripts.

Seems like quite a few of the Apache XML tools are written in Java?

For now, a problem with reverse engineering apps like the above is the immaturity of the native D gui's. This might be less of an issue with the apache xml apps that work in a console mode.

Another type of "candidate for being in D's crosshairs" might be small to moderate size C libraries. (reverse-engineering of libsndfile and portaudio come to mind.) D wouldn't necessarily have performance advantages, but could very well have significant reliability advantages. These "inner libraries" used by other tools should be ultra reliable.

Embedded o/s for micro-processors? pda's?

</alert>

"Lynn Allan" <l_d_allan@adelphia.net> wrote in message news:ct3c4s$1nsk$1@digitaldaemon.com...
> I think it might be interesting/valuable to solicit ideas on the kinds of software that D might be especially suitable for.

One useful datapoint is that DMDScript in D is smaller and faster than the same code in C++. I view D as serving the same space as C and C++ do.

> Embedded o/s for micro-processors? pda's?

Now that someone released a GC-free version of phobos, that may be possible. Of course, D assumes a flat, 32-bit memory space, which is probably incompatible with many PDAs (i.e. 68K based Palm-powered handhelds.  the 68K is a 16-bit processor).  Maybe Pocket PCs, and to a limited extend, newer Palms would be more viable candidates.

Or, maybe a smaller version of D (D--? ;) ) could be made for smaller
devices, with support for things like 16- and 8-bit code.  The far and near
pointer mess would probably play havoc with some of the features, however
(arrays, classes (thouch classes on an 8-bit microprocessor are..
overkill?), out/inout params).

In article <ct3c4s$1nsk$1@digitaldaemon.com>, Lynn Allan says...
>
>I think it might be interesting/valuable to solicit ideas on the kinds of software that D might be especially suitable for.
>

Well, for example, a good friend of mine (with my help) is writing a BitTorrent client in D.  Pretty near all clients we've seen have been written either in Java or Python.  (In fact the "bencode" format used by BT's communications is from Python.)  Using D I managed to write the modules 'bittorrent.bencode' and 'bittorrent.metainfo' in literally an hour, and they /worked/ on first compile! (There were a couple of minor issues but they were gone in about ten minutes.)

So yeah... I guess just about anything could be made.  Although, like Walter, I don't think I could recommend it for small, trivial programs, because of GC and Phobos overhead.  Maybe in the future we'll have that solved, though (via the Ares library perhaps?)

-- Chris Sauls

Hi Lynn and others,

I think D has an even bigger potential market as C and C++ have. C and
C++ where designed to be used with a local application. And although there are many network uses (CORBA, SOAP or plain Socket), D is capable to run over networks by its own and use webinterfaces (Mango and DSP). Though these techniques are completely alpha and can't be used right now, the potential of the techniques is high.

Due to the garbage collector, which with modern programming languages is a good thing (much more stable programs, and not particulary slower, in some ocassions even faster), is given the ease of passing objects quite simply. Which for the techniques mentioned before, among others, is pretty handy (one could use a referential counter or something, but that makes code highly unreadable).

Kind Regards,
Sjoerd van Leent

Lynn Allan wrote:
> <alert comment="newbie zealot">
> 
>>What I am excited about is D is becoming the premier language to do
>>unicode in, by a wide margin. And that's thanks to you guys!
> 
> 
> This post from The WB back in 04-Aug has stayed with me. I'm not the
> most imaginative person or "brightest bulb in the box", but sometimes
> I'm less than clear on what D will eventually be really good for as it
> matures and hopefully achieves mind-share and market-share critical
> mass.
> 
> I think it might be interesting/valuable to solicit ideas on the kinds
> of software that D might be especially suitable for.
> 
> Another way to think of this question: what kind of projects could we
> suggest 'D' as the language of choice for the next major release of
> existing software that has outgrown its original 'sandbox'?
> 
> For instance, perhaps reverse-engineering of originally niche apps
> that were written in interpretative languages (python, php, perl,
> ruby), but the app has become very popular and would benefit from a
> "real" compiled language for performance and reliability. phpBB? wiki?
> SCons?
> 
> Another instance; I think D has good-to-great potential to replace
> certain Java apps that are slower than molasses.
> 
> Specifically, the commerical products JTest and C++Test from Parasoft
> come to mind. They are nice for advanced Lint capabilities, but are
> practically unusable because they are so sloooooow. It can take
> overnight to process a medium size set of source files.
> 
> I think the XML tools from Altova (Spy, Authenticate, etc.) are
> written in Java, since they ship with .jar files. My limited
> experience with them was that they were also slooooooooow.
> 
> The Qarbon viewlet application for animated slideshows is written in
> Java and is sloooooooow. It can 'grind' for almost an hour on
> elaborate scripts.
> 
> Seems like quite a few of the Apache XML tools are written in Java?
> 
> For now, a problem with reverse engineering apps like the above is the
> immaturity of the native D gui's. This might be less of an issue with
> the apache xml apps that work in a console mode.
> 
> Another type of "candidate for being in D's crosshairs" might be small
> to moderate size C libraries. (reverse-engineering of libsndfile and
> portaudio come to mind.) D wouldn't necessarily have performance
> advantages, but could very well have significant reliability
> advantages. These "inner libraries" used by other tools should be
> ultra reliable.
> 
> Embedded o/s for micro-processors? pda's?
> 
> </alert>
> 
> 
> 

On Mon, 24 Jan 2005 13:33:34 -0500, Jarrett Billingsley <kb3ctd2@yahoo.com> wrote:
>> Embedded o/s for micro-processors? pda's?
>
> Now that someone released a GC-free version of phobos, that may be possible.
> Of course, D assumes a flat, 32-bit memory space, which is probably
> incompatible with many PDAs (i.e. 68K based Palm-powered handhelds.  the 68K
> is a 16-bit processor).  Maybe Pocket PCs, and to a limited extend, newer
> Palms would be more viable candidates.
>
> Or, maybe a smaller version of D (D--? ;) )

Lets call it "Dmin".

> could be made for smaller
> devices, with support for things like 16- and 8-bit code.  The far and near
> pointer mess would probably play havoc with some of the features, however
> (arrays, classes (thouch classes on an 8-bit microprocessor are..
> overkill?), out/inout params).

Regan

In article <ct3c4s$1nsk$1@digitaldaemon.com>, Lynn Allan says...
>
>I think it might be interesting/valuable to solicit ideas on the kinds of software that D might be especially suitable for.

Okay, I'll bite. :)

- One thing that hasn't been mentioned yet is using D for real-time media applications.  I think that the low-level control of the GC in D gives it considerable leverage over other GC'd languages in this arena.  One could actually boast that D is a language with all of Java's advantages and can still be used to write a solid video-conferencing app or mp3 player.


- Non-interactive, competition-grade, demonstrations.  I've long since fallen out of doing this stuff, but are there any demo coders here?  I think D could give a coder the edge in making non-interactive, realtime demo programs like those shown at Assembly:

http://www.assembly.org/compos/realtime

Even if it's never shown at a given party, coding to the constraints listed for these competitions is a great way to show off D's speed and capabilities; not to mention those of the programmer!


- Games, games, games.  We've seen some inital offerings from the far east in the form of Warning Forever and Torus Trooper; both of which are great games. Its amazing what SDL bindings and a nose for fast code can accomplish (both of the above play nicely on my 400Mhz P2).


- (Future) Sandboxed code.  One of the things that could easily come of the Ares
project is a reduced library that would be perfect for restricted (secure)
programming environments (like DSP for example).  Even a reduced capability
phobos module would go a long way to this end.


- Misc.  I've developed a healthy respect for D's ability to fight platform bloat (*coughjavacoughdotnetcough*) and bind to practically any library in existance that's worth using.  To that end, I've put off replacing my existing machine (the "400Mhz Franken-vunder-box") as the code-compile-test loop is lightning fast compared to the competition; Its *very* usable at this speed.

- EricAnderton at yahoo

> Now that someone released a GC-free version of phobos, that may be
possible.
> Of course, D assumes a flat, 32-bit memory space, which is probably incompatible with many PDAs (i.e. 68K based Palm-powered handhelds.
the 68K
> is a 16-bit processor).

FWIW: if memory serves (from the mid-80's), the 68000 was 32-bit internally, and had 24 address lines, resulting in 16meg usable memory.

pragma wrote:
> In article <ct3c4s$1nsk$1@digitaldaemon.com>, Lynn Allan says...
> 
>>I think it might be interesting/valuable to solicit ideas on the kinds
>>of software that D might be especially suitable for.
> 
> 
> Okay, I'll bite. :)
> 
> - One thing that hasn't been mentioned yet is using D for real-time media
> applications.  I think that the low-level control of the GC in D gives it
> considerable leverage over other GC'd languages in this arena.  One could
> actually boast that D is a language with all of Java's advantages and can still
> be used to write a solid video-conferencing app or mp3 player.
> 
> 
> - Non-interactive, competition-grade, demonstrations.  I've long since fallen
> out of doing this stuff, but are there any demo coders here?  I think D could
> give a coder the edge in making non-interactive, realtime demo programs like
> those shown at Assembly:
> 
> http://www.assembly.org/compos/realtime
> 
> Even if it's never shown at a given party, coding to the constraints listed for
> these competitions is a great way to show off D's speed and capabilities; not to
> mention those of the programmer!
> 

I used to write a few 64k intros in C++, but I found it hard to meet the code size constraint with D because of its statically linked library.
D might help "mega demo" productivity, though.


> 
> - Games, games, games.  We've seen some inital offerings from the far east in
> the form of Warning Forever and Torus Trooper; both of which are great games.
> Its amazing what SDL bindings and a nose for fast code can accomplish (both of
> the above play nicely on my 400Mhz P2).
> 
> 
> - (Future) Sandboxed code.  One of the things that could easily come of the Ares
> project is a reduced library that would be perfect for restricted (secure)
> programming environments (like DSP for example).  Even a reduced capability
> phobos module would go a long way to this end.
> 
> 
> - Misc.  I've developed a healthy respect for D's ability to fight platform
> bloat (*coughjavacoughdotnetcough*) and bind to practically any library in
> existance that's worth using.  To that end, I've put off replacing my existing
> machine (the "400Mhz Franken-vunder-box") as the code-compile-test loop is
> lightning fast compared to the competition; Its *very* usable at this speed.
> 
> - EricAnderton at yahoo

Regan Heath wrote:
> On Mon, 24 Jan 2005 13:33:34 -0500, Jarrett Billingsley  <kb3ctd2@yahoo.com> wrote:
> 
>>> Embedded o/s for micro-processors? pda's?
>>
>>
>> Now that someone released a GC-free version of phobos, that may be  possible.
>> Of course, D assumes a flat, 32-bit memory space, which is probably
>> incompatible with many PDAs (i.e. 68K based Palm-powered handhelds.  the  68K
>> is a 16-bit processor).  Maybe Pocket PCs, and to a limited extend, newer
>> Palms would be more viable candidates.
>>
>> Or, maybe a smaller version of D (D--? ;) )
> 
> Lets call it "Dmin".

If we really want to be clever, we could call it "d".

 -- andy