Hey everyone, I am write an 8 page paper on D for my Organization of Programming Languages class.  I thought it would be cool to ask the D community what you love about D, and what you don't so much love.  It would make an interesting few lines or paragraph in my paper to see what people more experienced with the language think of it.  If you'd rather just e-mail your answer to me, feel free: mh1252 AT messiah.edu.  Thanks!

>Hey everyone, I am write an 8 page paper on D for my Organization of Programming Languages class.  I thought it would be cool to ask the D community what you love about D, and what you don't so much love.  It would make an interesting few lines or paragraph in my paper to see what people more experienced with the language think of it.  If you'd rather just e-mail your answer to me, feel free: mh1252 AT messiah.edu.  Thanks!

What I like:
DbC

What I don't like:
missing type-inference

For me it's the ability to express myself easily and clearily.  For example , hashes are a construct I use alot.

C++
===

std::map<string,HTREEITEM> projectMap;
/* populate */
std::map<string,HTREEITEM>::iterator it;
it = projectMap.find("DFL");
if ( it != projectMap.end () ) item = it->second;

D
===

HTREEITEM [ char [] ] projectMap;
/* populate */
if ( ! (projectMap["DFL"] is null)  ) item = projectMap["DFL"];

Java
====

TreeMap projectMap = new TreeMap();
/* populate */
if ( projectMap.containsKey("DFL") ) item = projectMap.get("DFL");



And unless you use STL all the time you'll probably have to break out your STL refrence to check on the syntax for all of that.  Java's way is easier on the eyes , but performance of java for me has always been unaccceptable, that and Object Oriented only mind-set is limiting for me.

It may sound like something small , and really there's nothing revolutionary about D ( except it does what it does better than the rest :) ) , but when your talking about large scale projects I think it will make a huge difference.  I think that's where D will shine most.

And D makes an awesome prototype language, the compiler is blazing fast , faster than any compiler Ive ever used ( javac, dmc, gcc, cl , borlands C++ and pascal which is super fast too ) , but more than that, the pseudocode you jot down when working on a new project almost directly translates to D code!

Every programmer has their own method -- I personally like to stack layer on layer of abstraction till the end code can be used as a one liner ( a one liner with clear intentions , one could write a one liner in PERL that would solve world hunger but no-one would be able to understand it, including the author ), and D being higher level than all of the compiled languages I've used makes it simple to do.


Cons
====

It's very slow to develop , its been pre 1.0 for going on 6 years.  Walter's awesome and we all appreciate what he's done , but he seems kind of an old schooler.  I'd prefer paying for D, so he can higher a team of developers and get this thing in to production.  Or seek investors ... anything to speed up development so we can get a _commercial_ quality compiler ( I've actually been using D at work for 6 months, and it works beautifully the compiler is great, but something must be done about phobos ... its embarasing).


I think the easiest way to convert programmers is to show them good D code, compare them against their favorite language.  Miguel's d-neural , kris's Mango ( Im sure there are many others , going to check out DUI now that its finnaly got an installer for windows , im a lazy bastard and require an installer! ) are examples of really good code, that compared to other languages make D look awesome.

Just rambling,
Charlie


In article <cno86k$1imr$1@digitaldaemon.com>, mh1252 AT messiah.edu says...
>
>Hey everyone, I am write an 8 page paper on D for my Organization of Programming Languages class.  I thought it would be cool to ask the D community what you love about D, and what you don't so much love.  It would make an interesting few lines or paragraph in my paper to see what people more experienced with the language think of it.  If you'd rather just e-mail your answer to me, feel free: mh1252 AT messiah.edu.  Thanks!
>
>

Near and dear:
    I find the syntax of D very expressive and easy to learn.
    I like templates and operator overloading.
    I'm looking forward to using delegates.

Less than ideal:
    I'd like to have Java-style inner (adaptor) classes.

In article <cnqqun$2981$1@digitaldaemon.com>, Charlie says...
>
[snip]
>Cons
>====
>
>It's very slow to develop , its been pre 1.0 for going on 6 years.  Walter's awesome and we all appreciate what he's done , but he seems kind of an old schooler.  I'd prefer paying for D, so he can higher a team of developers and get this thing in to production.  Or seek investors ... anything to speed up development so we can get a _commercial_ quality compiler ( I've actually been using D at work for 6 months, and it works beautifully the compiler is great, but something must be done about phobos ... its embarasing).
>

[I don't want this to come across as 'confrontational' because it's not - it is a request for specific criticism so we can fix phobos or come up with an alternative].

What do you find embarrassing about phobos?

Specifics please.. Programming style, design, bugs (if so, of what specifically), lack of functionality, performance? Again, specifics please.

I'm thinking (and someone who knows of a replacement that is 80% finished please correct me if I'm wrong, but) it may be a bit late in the game to rewrite the core library for v1.

FWIW, I've had little problem with any Phobos library routines myself but there are certainly parts of it that I haven't used. The basic I/O, string, conversion, stream, buffered stream, regex, zip and math parts I've used certainly seem to work well in general. I'm thinking the D community may be best served by improving phobos unless there is something else better nearing completion out there..

- Dave

>[I don't want this to come across as 'confrontational' because it's not - it is a request for specific criticism so we can fix phobos or come up with an alternative].

No problem at all! :)

>Specifics please..

Well right now its a mixture of OO and procedural, which I think is inconsistent.  I would prefer phobos all procedural, and an optional OO lib built atop ( though I think im alone on this one ), or just OO , anything that is consistent.

Theirs been lots of bugs but they usually get fixed as they go.  It just seems to me everytime I do some hardcore D I find something in phobos.  Last weekend was trying to use std.math2 and found toString(real) in both std.string and std.math2.  And I'd like to see math import math2 as math2 is not in the docs.

And I've really grown to like the import system , but I think its a sign of bad
design when i cant import std.c.stdlib and std.random w/o conflicts ( function
rand() conflicts ).  Maybe phobos's rand() should be renamed to random() , or
the std.c.stdlib needs to be renamed.  I think all of phobos should be conflict
free.

These conflicts seem to appear all the time for me, probably im just unlucky.

>I'm thinking (and someone who knows of a replacement that is 80% finished please correct me if I'm wrong

There is a group at http://www.dsource.org/forums/viewforum.php?f=31& that is making Ares , a new phobos.  I think they are waiting on DLL's ( so phobos can be a shared lib ).

And maybe embarasing was a strong word , but D is such an amazing language , to have phobos anything less than 100% is ... unacceptable ( can't seem to stay away from these words).

>I'm thinking the D community may be best
>served by improving phobos unless there is something else better nearing
>completion out there..

It would suck to have all the existing code required to be re-written , but we _are_ still pre 1.0 , and maybe still fair game :) ?

( I dont mean it to sound so negative but D must succeed! )

Charlie

In article <cntqpp$15qr$1@digitaldaemon.com>, Dave says...
>
>In article <cnqqun$2981$1@digitaldaemon.com>, Charlie says...
>>
>[snip]
>>Cons
>>====
>>
>>It's very slow to develop , its been pre 1.0 for going on 6 years.  Walter's awesome and we all appreciate what he's done , but he seems kind of an old schooler.  I'd prefer paying for D, so he can higher a team of developers and get this thing in to production.  Or seek investors ... anything to speed up development so we can get a _commercial_ quality compiler ( I've actually been using D at work for 6 months, and it works beautifully the compiler is great, but something must be done about phobos ... its embarasing).
>>
>
>[I don't want this to come across as 'confrontational' because it's not - it is a request for specific criticism so we can fix phobos or come up with an alternative].
>
>What do you find embarrassing about phobos?
>
>Specifics please.. Programming style, design, bugs (if so, of what specifically), lack of functionality, performance? Again, specifics please.
>
>I'm thinking (and someone who knows of a replacement that is 80% finished please correct me if I'm wrong, but) it may be a bit late in the game to rewrite the core library for v1.
>
>FWIW, I've had little problem with any Phobos library routines myself but there are certainly parts of it that I haven't used. The basic I/O, string, conversion, stream, buffered stream, regex, zip and math parts I've used certainly seem to work well in general. I'm thinking the D community may be best served by improving phobos unless there is something else better nearing completion out there..
>
>- Dave
>
>

"Charlie" <Charlie_member@pathlink.com> wrote in message news:cnua47$1u8f$1@digitaldaemon.com...
> And I've really grown to like the import system , but I think its a sign
of bad
> design when i cant import std.c.stdlib and std.random w/o conflicts (
function
> rand() conflicts ).  Maybe phobos's rand() should be renamed to random() ,
or
> the std.c.stdlib needs to be renamed.  I think all of phobos should be
conflict
> free.

If they are accessed as std.c.stdlib.rand() and std.random.rand(), there isn't a conflict. That's the beauty of using modules instead of #include, you don't have to give everything a unique name across the board.

In article <cnr6bt$2r85$1@digitaldaemon.com>, Garett Bass says...
>
>Near and dear:
>    I find the syntax of D very expressive and easy to learn.
Only if you are familiar with C-like languages.

>    I like templates and operator overloading.
If you like templates you should look at languages which are more powerfull in this aspect, e.g. C++'s templates, O'Caml's/SML's functors, ...

>Less than ideal:
>    I'd like to have Java-style inner (adaptor) classes.
Right, we have function-literals, why don't we have class literals?

Matthias Becker wrote:

>>   I find the syntax of D very expressive and easy to learn.
> 
> Only if you are familiar with C-like languages.

That is one of the design goals of D:

> Major Goals of D:
>  Have a short learning curve for programmers
>  comfortable with programming in C or C++.

This should also make it familiar
for programmers used to Java or C# ?


> Who D is Not For
>  As a first programming language - Basic or Java is more
>  suitable for beginners. D makes an excellent second
>  language for intermediate to advanced programmers.

(from http://www.digitalmars.com/d/overview.html)

--anders

On Sat, 27 Nov 2004 12:03:15 +0000, Matthias Becker wrote:

> In article <cnr6bt$2r85$1@digitaldaemon.com>, Garett Bass says...
> 
>>Less than ideal:
>>    I'd like to have Java-style inner (adaptor) classes.
> Right, we have function-literals, why don't we have class literals?

I'd like to know that.
Nobody knows, nobody sais why.
We should have inner classes
even if not the anonyumous classes java has.

Ant