www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Comparison chart worries

reply Georg Wrede <georg nospam.org> writes:
Quoting from 
http://www.gamedev.net/community/forums/topic.asp?topic_id=431909



out, wrong. No dynamic arrays? Try System.Collections.Generic.List<T>. No
associative arrays? Try System.Collections.Generic.Dictionary<T>. No aliases?
Try using <class> = Alias;. There are many more on that page, so much so, I am
half tempted to write a page debunking over half your comparisons.
 
 Your comparison sheet is EXTREMELY misleading, as you completely ignore the

Ignoring the presence of many of these facilities in the .NET framework is a
really shady tactic to make D seem like it has several important features that

really not (like multiple inheritance, which is dangerous to begin with).
 
 D is a neat language, but you need to be more honest in your comparisons.


Not directly commenting on this quote (since I'm not that familiar with 


Other languages may have got new versions out, and some of the table 
entries are, ehh, not that obvious to the casual reader.

While some of the more surprising answers (the yes/no stuff) are 
explained in footnotes or on other pages, we must understand that all 
this slashdotting etc. brings readers who don't bother reading "the fine 
print". They may then dismiss the table (and thus D itself) as biased, 
hyped, and regular marketing lies altogether.

I don't think we can afford it.
Jan 13 2007
next sibling parent reply Jeff <jeffrparsons optusnet.com.au> writes:
 (...) Several other 
 features you claim are "important" are really not (like multiple 
 inheritance, which is dangerous to begin with).




Huh? Don't the D docs -support- this stance?

Other than that, I have to agree that the comparison chart seems to me 
to be a bit zealous, and could do more harm than good in its current state.

Maybe instead of just having big shiny green "Yes" and "No" labels 
(supported occasionally by footnotes) the table could be modified to 
note in-line

- which features are provided by the language;
- which are provided by the standard library; and
- which are absent from both (regardless of whether they're implemented 
in other popular libraries because, well, with enough hacks you can 
implement almost anything in some external library, and that doesn't 
necessarily make it useful or usable! :P).

Perhaps a green "Yes (core)", an amber "Yes (std library)" and a red "No"?

Might I suggest #FF77FF, #FFBB77 and #FF7777 to give our eyes a rest? ;)
Jan 13 2007
parent reply James Dennett <jdennett acm.org> writes:
Jeff wrote:

 (...) Several other features you claim are "important" are really not
 (like multiple inheritance, which is dangerous to begin with).




 
 Huh? Don't the D docs -support- this stance?
 
 Other than that, I have to agree that the comparison chart seems to me
 to be a bit zealous, and could do more harm than good in its current state.


Quite possibly (of which more below).


 Maybe instead of just having big shiny green "Yes" and "No" labels
 (supported occasionally by footnotes) the table could be modified to
 note in-line
 
 - which features are provided by the language;
 - which are provided by the standard library; and
 - which are absent from both (regardless of whether they're implemented
 in other popular libraries because, well, with enough hacks you can
 implement almost anything in some external library, and that doesn't
 necessarily make it useful or usable! :P).
 
 Perhaps a green "Yes (core)", an amber "Yes (std library)" and a red "No"?


Or an amber "Yes (core)" and a green "Yes (std library)"
to indicate where the core language facilities didn't
allow a particular feature to be moved to the library?

OK, that's a joke of sorts -- but color-coding for a
particular agenda is the kind of unnecessary bias that
puts people off.  Some languages designers view putting
something in the core language as a weakness (while
obviously knowing that there has to be enough built in
to allow a viable language+library combination).

Walter's position apparently doesn't match that -- but
assuming that something is better because it's in the
core isn't valid in itself; it might be true that being
in the core means that it can avoid weaknesses of some
library approaches though.

I'd certainly say that the D comparison chart was very
offputting to me, and still is.  Much of what is written
there about other languages is arguably misleading, and
I speak particularly of the notes on C++.  It seems to
be a sales pitch rather than an objective comparison --
and fair enough, it may well be a sales pitch, why should
we expect objectivity from Digital Mars in this context?

I'd be inclined to take D more seriously if we could
reduce by an order of magnitude the level of misguided
attacks against other languages and focus more on some
more thorough treatment of the trade-offs involved in
language and library design.  Many of those attacks
show a lack of knowledge of the other languages to
which they refer.  Focus on making D better (which
usually doesn't mean having a bigger core), not on
knocking other languages to make D *seem* better.

-- James
Jan 13 2007
next sibling parent janderson <askme me.com> writes:
James Dennett wrote:

 Jeff wrote:

 (...) Several other features you claim are "important" are really not
 (like multiple inheritance, which is dangerous to begin with).




 Huh? Don't the D docs -support- this stance?

 Other than that, I have to agree that the comparison chart seems to me
 to be a bit zealous, and could do more harm than good in its current state.


 
 Quite possibly (of which more below).
 

 Maybe instead of just having big shiny green "Yes" and "No" labels
 (supported occasionally by footnotes) the table could be modified to
 note in-line

 - which features are provided by the language;
 - which are provided by the standard library; and
 - which are absent from both (regardless of whether they're implemented
 in other popular libraries because, well, with enough hacks you can
 implement almost anything in some external library, and that doesn't
 necessarily make it useful or usable! :P).

 Perhaps a green "Yes (core)", an amber "Yes (std library)" and a red "No"?


 
 Or an amber "Yes (core)" and a green "Yes (std library)"
 to indicate where the core language facilities didn't
 allow a particular feature to be moved to the library?
 
 OK, that's a joke of sorts -- but color-coding for a
 particular agenda is the kind of unnecessary bias that
 puts people off.  Some languages designers view putting
 something in the core language as a weakness (while
 obviously knowing that there has to be enough built in
 to allow a viable language+library combination).
 
 Walter's position apparently doesn't match that -- but
 assuming that something is better because it's in the
 core isn't valid in itself; it might be true that being
 in the core means that it can avoid weaknesses of some
 library approaches though.
 
 I'd certainly say that the D comparison chart was very
 offputting to me, and still is.  Much of what is written
 there about other languages is arguably misleading, and
 I speak particularly of the notes on C++.  It seems to
 be a sales pitch rather than an objective comparison --
 and fair enough, it may well be a sales pitch, why should
 we expect objectivity from Digital Mars in this context?
 
 I'd be inclined to take D more seriously if we could
 reduce by an order of magnitude the level of misguided
 attacks against other languages and focus more on some
 more thorough treatment of the trade-offs involved in
 language and library design.  Many of those attacks
 show a lack of knowledge of the other languages to
 which they refer.  Focus on making D better (which
 usually doesn't mean having a bigger core), not on
 knocking other languages to make D *seem* better.
 
 -- James


This is very true.  I've often thought that the comparison chart does 
more damage then good.  Parhaps it should be removed, we find a third 
party website that does the same thing, or try to compare languages from 
a more practical standpoint rather then a feature standpoint.  ie Here 
how you would do this in C++ and here's how you'd do it in D.

-Joel
Jan 13 2007
prev sibling parent Don Clugston <dac nospam.com.au> writes:
James Dennett wrote:

 Jeff wrote:

 (...) Several other features you claim are "important" are really not
 (like multiple inheritance, which is dangerous to begin with).




 Huh? Don't the D docs -support- this stance?

 Other than that, I have to agree that the comparison chart seems to me
 to be a bit zealous, and could do more harm than good in its current state.


 
 Quite possibly (of which more below).
 

 Maybe instead of just having big shiny green "Yes" and "No" labels
 (supported occasionally by footnotes) the table could be modified to
 note in-line

 - which features are provided by the language;
 - which are provided by the standard library; and
 - which are absent from both (regardless of whether they're implemented
 in other popular libraries because, well, with enough hacks you can
 implement almost anything in some external library, and that doesn't
 necessarily make it useful or usable! :P).

 Perhaps a green "Yes (core)", an amber "Yes (std library)" and a red "No"?


 
 Or an amber "Yes (core)" and a green "Yes (std library)"
 to indicate where the core language facilities didn't
 allow a particular feature to be moved to the library?
 
 OK, that's a joke of sorts -- but color-coding for a
 particular agenda is the kind of unnecessary bias that
 puts people off.  Some languages designers view putting
 something in the core language as a weakness (while
 obviously knowing that there has to be enough built in
 to allow a viable language+library combination).
 
 Walter's position apparently doesn't match that -- but
 assuming that something is better because it's in the
 core isn't valid in itself; it might be true that being
 in the core means that it can avoid weaknesses of some
 library approaches though.
 
 I'd certainly say that the D comparison chart was very
 offputting to me, and still is.  Much of what is written
 there about other languages is arguably misleading, and
 I speak particularly of the notes on C++.




In my view, the chart is useful only for answering the question "I can 
do XXX in my favourite language, can I also do it in D?"
And it would therefore, I think, be better to improve the "D for C++ 
programmers", etc pages and remove the comparison chart to a 3rd party site.

   It seems to

 be a sales pitch rather than an objective comparison --
 and fair enough, it may well be a sales pitch, why should
 we expect objectivity from Digital Mars in this context?


And I think the language itself is strong enough now to not need this 
sort of sales pitch.


 
 I'd be inclined to take D more seriously if we could
 reduce by an order of magnitude the level of misguided
 attacks against other languages and focus more on some
 more thorough treatment of the trade-offs involved in
 language and library design.  Many of those attacks
 show a lack of knowledge of the other languages to
 which they refer.  Focus on making D better (which
 usually doesn't mean having a bigger core), not on
 knocking other languages to make D *seem* better.
 
 -- James
Jan 13 2007
prev sibling next sibling parent janderson <askme me.com> writes:
Georg Wrede wrote:

 Quoting from 
 http://www.gamedev.net/community/forums/topic.asp?topic_id=431909
 


 Period, flat out, wrong. No dynamic arrays? Try 
 System.Collections.Generic.List<T>. No associative arrays? Try 
 System.Collections.Generic.Dictionary<T>. No aliases? Try using 
 <class> = Alias;. There are many more on that page, so much so, I am 
 half tempted to write a page debunking over half your comparisons.

 Your comparison sheet is EXTREMELY misleading, as you completely 

 currently do. Ignoring the presence of many of these facilities in the 
 .NET framework is a really shady tactic to make D seem like it has 

 features you claim are "important" are really not (like multiple 
 inheritance, which is dangerous to begin with).

 D is a neat language, but you need to be more honest in your comparisons.


 
 Not directly commenting on this quote (since I'm not that familiar with 

 
 Other languages may have got new versions out, and some of the table 
 entries are, ehh, not that obvious to the casual reader.
 
 While some of the more surprising answers (the yes/no stuff) are 
 explained in footnotes or on other pages, we must understand that all 
 this slashdotting etc. brings readers who don't bother reading "the fine 
 print". They may then dismiss the table (and thus D itself) as biased, 
 hyped, and regular marketing lies altogether.
 
 I don't think we can afford it.
 



I agree.  Maybe it could be a bit more like this one: 
http://www.prowiki.org/wiki4d/wiki.cgi?LanguagesVersusD

Also would be good it have examples of the different syntax for each case.

-Joel
Jan 13 2007
prev sibling next sibling parent John Reimer <terminal.node gmail.com> writes:
On Sun, 14 Jan 2007 03:58:33 +0200, Georg Wrede wrote:


 Quoting from 
 http://www.gamedev.net/community/forums/topic.asp?topic_id=431909
 


out, wrong. No dynamic arrays? Try System.Collections.Generic.List<T>. No
associative arrays? Try System.Collections.Generic.Dictionary<T>. No aliases?
Try using <class> = Alias;. There are many more on that page, so much so, I am
half tempted to write a page debunking over half your comparisons.
 
 Your comparison sheet is EXTREMELY misleading, as you completely ignore the

Ignoring the presence of many of these facilities in the .NET framework is a
really shady tactic to make D seem like it has several important features that

really not (like multiple inheritance, which is dangerous to begin with).
 
 D is a neat language, but you need to be more honest in your comparisons.


 
 Not directly commenting on this quote (since I'm not that familiar with 

 
 Other languages may have got new versions out, and some of the table 
 entries are, ehh, not that obvious to the casual reader.
 
 While some of the more surprising answers (the yes/no stuff) are 
 explained in footnotes or on other pages, we must understand that all 
 this slashdotting etc. brings readers who don't bother reading "the fine 
 print". They may then dismiss the table (and thus D itself) as biased, 
 hyped, and regular marketing lies altogether.
 
 I don't think we can afford it.



The table seems to be more annoying to outsiders than informative.  People
seem to have there own interpretation for each item in the list and feel
swindled when the language comparison suggests features (or lack of such)
so starkly. Probably the best thing to do is merely state what D offers
with more detailed links to examples; this allows the newcomers decide for
themselves.  

That list awakes far too much fury in the programming community: they
appear to see this as a list of half-truths... something usually seen
in politics and marketing strategies.... not a good thing for D (or
anywhere for that matter).

-JJR
Jan 13 2007
prev sibling next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
It is a good idea to remove the table. So far I have not seen any 
discussion about D where this was not the subject of criticism at the 
least, and it even incites flames. Very distracting.

The table gives the impression of a checklist where D is superior to the 
languages it is compared with. This could only be done by leaving out 
the standard libraries of the 'inferior' languages, which is highly 
misleading because these are an integral part of programming in those 
languages.

And then people even seem to miss that only core language features are 
compared.

Another problem is that the chart suggests that more features is better 
perse. Although Walter Bright is not afraid of making D a rich language, 
I'm quite sure this is not his stance.

The comparison chart serves two purposes: to give a quick overview to 
the D language and to market D against other C family languages. I 
suggest to keep the first purpose and let the marketing be done by what 
is already there in the other comparison pages: programmers are not 
easily wowed by checklists.

For example: keep the table for everything that D has 'yes' (almost 
everything), and leave the other languages out altogether. Then you have 
room to insert a one line summary of the feature, something like that.
Jan 14 2007
parent Johan Granberg <lijat.meREM OVE.gmail.com> writes:
Lutger wrote:

 For example: keep the table for everything that D has 'yes' (almost
 everything), and leave the other languages out altogether. Then you have
 room to insert a one line summary of the feature, something like that.


I agree this is a good idea.
Jan 14 2007
prev sibling next sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
Well, AFAIK dynamic arrays are built-in feature in the D programming language.
System.Collections.Generic.List<T> is a (user-defined) template. I think Mr.
Bright thought about language features when he made "D-vs-others" comparison
table.
Jan 14 2007
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Dejan Lekic wrote:

 Well, AFAIK dynamic arrays are built-in feature in the D programming language.
System.Collections.Generic.List<T> is a (user-defined) template. I think Mr.
Bright thought about language features when he made "D-vs-others" comparison
table.



alias because Alias is too weak to count as a general renaming facility.

But this is not the point. It is not contested that D has these builtin 
features and the others do not, it is not even in question that builtin 
arrays have merit (as opposed to libraries).

The point is that this part of the quote still holds true and from a 
marketing perspective reflects bad on D:

"Your comparison sheet is EXTREMELY misleading, as you completely ignore 

do. Ignoring the presence of many of these facilities in the .NET 
framework is a really shady tactic to make D seem like it has several
Jan 14 2007
parent reply torhu <fake address.dude> writes:
Lutger wrote:
  > The point is that this part of the quote still holds true and from a

 marketing perspective reflects bad on D:
 
 "Your comparison sheet is EXTREMELY misleading, as you completely ignore 

 do. Ignoring the presence of many of these facilities in the .NET 
 framework is a really shady tactic to make D seem like it has several 



 From http://www.digitalmars.com/d/comparison.html:

"While many capabilities are available with standard libraries, this 
table is for features built in to the core language itself."

I guess the problem is that people don't read the introduction to the 
comparison.  But it might be better to put 'library' instead of just 
'no' in that table anyway, like someone suggested.  Than flames like the 
one you are quote might be less common.

I guess you just can't expect the slashdot crowd and many others to 'RTFA'.

And maybe the link to the comparison should be less prominent, and 
labelled 'comparison of built-in features' instead of just 'comparison'?
Jan 14 2007
next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
torhu wrote:

  From http://www.digitalmars.com/d/comparison.html:
 
 "While many capabilities are available with standard libraries, this 
 table is for features built in to the core language itself."
 
 I guess the problem is that people don't read the introduction to the 
 comparison.  But it might be better to put 'library' instead of just 
 'no' in that table anyway, like someone suggested.  Than flames like the 
 one you are quote might be less common.


That is one way to improve the page, might prevent some misunderstandings.


 I guess you just can't expect the slashdot crowd and many others to 'RTFA'.


What I was trying to say, is that the comparison chart is objectionable 
even when you RTFA. As someone in that gamedev thread said in reaction 
to the allegation that the chart is wrong: "Not wrong actually, 
deceptive yes."
Jan 14 2007
prev sibling next sibling parent John Reimer <terminal.node gmail.com> writes:
On Sun, 14 Jan 2007 14:59:29 +0100, torhu wrote:


 Lutger wrote:
   > The point is that this part of the quote still holds true and from a

 marketing perspective reflects bad on D:
 
 "Your comparison sheet is EXTREMELY misleading, as you completely ignore 

 do. Ignoring the presence of many of these facilities in the .NET 
 framework is a really shady tactic to make D seem like it has several 



 
  From http://www.digitalmars.com/d/comparison.html:
 
 "While many capabilities are available with standard libraries, this 
 table is for features built in to the core language itself."
 
 I guess the problem is that people don't read the introduction to the 
 comparison.  But it might be better to put 'library' instead of just 
 'no' in that table anyway, like someone suggested.  Than flames like the 
 one you are quote might be less common.
 
 I guess you just can't expect the slashdot crowd and many others to 'RTFA'.
 
 And maybe the link to the comparison should be less prominent, and 
 labelled 'comparison of built-in features' instead of just 'comparison'?



Most people look at the chart and don't see anything but bright red and
green lights. :)

Walter's disclaimer just doesn't stand out, nor would it appease...

-JJR
Jan 14 2007
prev sibling parent James Dennett <jdennett acm.org> writes:
torhu wrote:

 Lutger wrote:
  > The point is that this part of the quote still holds true and from a

 marketing perspective reflects bad on D:

 "Your comparison sheet is EXTREMELY misleading, as you completely

 currently do. Ignoring the presence of many of these facilities in the
 .NET framework is a really shady tactic to make D seem like it has



 
 From http://www.digitalmars.com/d/comparison.html:
 
 "While many capabilities are available with standard libraries, this
 table is for features built in to the core language itself."
 
 I guess the problem is that people don't read the introduction to the
 comparison. 


I don't think so; the problem I have is that the sentence you
quote above *confirms* that the table is intended to give a
skewed view that has little practical use in assessing the
merit of adding D to your toolchest.


 But it might be better to put 'library' instead of just
 'no' in that table anyway, like someone suggested.  Than flames like the
 one you are quote might be less common.
 
 I guess you just can't expect the slashdot crowd and many others to 'RTFA'.


It's very helpful when building a community not to assume
that all dissent comes from ignorance; the D community in
particular should remember that there are many experts who
know a lot about other languages (and *why* those languages
made the choices they did), and D has a relatively small
community (though hopefully also including smart, educated
people).


 And maybe the link to the comparison should be less prominent, and
 labelled 'comparison of built-in features' instead of just 'comparison'?


It would be even more useful if it came with an introduction
that placed more emphasis on why D chooses to put so much in
the core when other modern languages have largely evolved
towards smaller core languages with better library-building
facilities; some of that information is present elsewhere in
the D documentation (though some of the rationales themselves
could do with more work, as always).

-- James
Jan 14 2007
prev sibling next sibling parent Justin C Calvarese <technocrat7 gmail.com> writes:
Georg Wrede wrote:

 Quoting from 
 http://www.gamedev.net/community/forums/topic.asp?topic_id=431909
 


 Period, flat out, wrong. No dynamic arrays? Try 
 System.Collections.Generic.List<T>. No associative arrays? Try 
 System.Collections.Generic.Dictionary<T>. No aliases? Try using 
 <class> = Alias;. There are many more on that page, so much so, I am 
 half tempted to write a page debunking over half your comparisons.

 Your comparison sheet is EXTREMELY misleading, as you completely 

 currently do. Ignoring the presence of many of these facilities in the 
 .NET framework is a really shady tactic to make D seem like it has 

 features you claim are "important" are really not (like multiple 
 inheritance, which is dangerous to begin with).

 D is a neat language, but you need to be more honest in your comparisons.


 
 Not directly commenting on this quote (since I'm not that familiar with 

 
 Other languages may have got new versions out, and some of the table 
 entries are, ehh, not that obvious to the casual reader.
 
 While some of the more surprising answers (the yes/no stuff) are 
 explained in footnotes or on other pages, we must understand that all 
 this slashdotting etc. brings readers who don't bother reading "the fine 
 print". They may then dismiss the table (and thus D itself) as biased, 
 hyped, and regular marketing lies altogether.
 
 I don't think we can afford it.


I think there are some really good points being made in this thread. The 
comparison chart (http://www.digitalmars.com/d/comparison.html) probably 
stirs up anger in people more often than persuading them to look into D 
more (at least as the table is currently set up).

Maybe rather than being a bunch of colorful yes's and no's, it should be 
  more "professional". Perhaps it should be "Core", "Library", "N/A" 
since much of the disagreement seems to be whether Core or Library is a 
better place to have a feature, we'll just state where it is and let 
people decide for themselves where it should be. And if it's really "not 
available" in that language, we can put "N/A".

Perhaps people won't be so angry then, and they'll continue reading the 
spec long enough to find the pages where Walter justifies why having a 
particular feature built-in is so important.

If we could make the table less controversial, that'd be a good thing. 
There are a growing number of complaints on the DocComments page, too: 
http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Comparison


justified or not, but I think some of the disagreement might come from 
the Core vs. Library issue. (Of course, Language X has that. It's in a 
library.)

-- 
jcc7
Jan 14 2007
prev sibling next sibling parent Charlie <charlie.fats gmail.com> writes:
Georg Wrede wrote:

 Quoting from 
 http://www.gamedev.net/community/forums/topic.asp?topic_id=431909
 


 Period, flat out, wrong. No dynamic arrays? Try 
 System.Collections.Generic.List<T>. No associative arrays? Try 
 System.Collections.Generic.Dictionary<T>. No aliases? Try using 
 <class> = Alias;. There are many more on that page, so much so, I am 
 half tempted to write a page debunking over half your comparisons.

 Your comparison sheet is EXTREMELY misleading, as you completely 

 currently do. Ignoring the presence of many of these facilities in the 
 .NET framework is a really shady tactic to make D seem like it has 

 features you claim are "important" are really not (like multiple 
 inheritance, which is dangerous to begin with).

 D is a neat language, but you need to be more honest in your comparisons.


 
 Not directly commenting on this quote (since I'm not that familiar with 

 
 Other languages may have got new versions out, and some of the table 
 entries are, ehh, not that obvious to the casual reader.
 
 While some of the more surprising answers (the yes/no stuff) are 
 explained in footnotes or on other pages, we must understand that all 
 this slashdotting etc. brings readers who don't bother reading "the fine 
 print". They may then dismiss the table (and thus D itself) as biased, 
 hyped, and regular marketing lies altogether.
 
 I don't think we can afford it.
 


I Agree completely, just throw out the chart.  Let them discover for 
themselves D's power, thats the only way they will believe it anyway.

Charlie
Jan 14 2007
prev sibling next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
I don't agree at all that the table is misleading, deceptive, dishonest, 
etc. It says right up front what it is - a comparison of *core* language 
features. You can do anything in a library in any language.

I agree, though, that it is out of date with respect to the latest 


I also agree that the table is meant to draw attention, with the 
brightly colored boxes, etc. Being a little confrontational helps get 
discussions going. And yes, it throws down the gauntlet and is in your face.

But also, now that 1.0 is here, the time for that may have passed. To 
that end, I've just removed the entries for the non-D languages. People 
coming to D from those languages already know what they can do, and can 
form their own conclusions.
Jan 14 2007
next sibling parent John Reimer <terminal.node gmail.com> writes:
On Sun, 14 Jan 2007 11:42:17 -0800, Walter Bright wrote:


 I don't agree at all that the table is misleading, deceptive, dishonest, 
 etc. It says right up front what it is - a comparison of *core* language 
 features. You can do anything in a library in any language.



We're not saying it is so.  But public perception is a much stronger
argument. Those appearances may be costly to D.
 


 I agree, though, that it is out of date with respect to the latest




Well, I guess that would annoy people too and strengthen they're
argument that the chart isn't accurate? 



 I also agree that the table is meant to draw attention, with the 
 brightly colored boxes, etc. Being a little confrontational helps get 
 discussions going. And yes, it throws down the gauntlet and is in your face.



Is the programming community in any need of help in starting
confrontational discussions? :(

Those aren't the kind of discussions we need. 



 But also, now that 1.0 is here, the time for that may have passed. To 
 that end, I've just removed the entries for the non-D languages. People 
 coming to D from those languages already know what they can do, and can 
 form their own conclusions.



Well, I don't think it matters whether D is at 1.0 or not, but thank you
for being open to changing this.  I think it's the best thing to do.

-JJR
Jan 14 2007
prev sibling next sibling parent Larry Evans <cppljevans cos-internet.com> writes:
On 01/14/2007 01:42 PM, Walter Bright wrote:
[snip]

 
 But also, now that 1.0 is here, the time for that may have passed. To 
 that end, I've just removed the entries for the non-D languages. People 
 coming to D from those languages already know what they can do, and can 
 form their own conclusions.


Walter, it would have helped me (a c++ programmer) to have
the links _Yes_ links for rows names containing "template" in the
row name go directory to the relevant section in template.html.
For example,  the _Yes_ for row name="Template Template Parameters"
would go to "template.html#aliasparameters".  Of course one might
expect the reader to first go to template.html, and then, once he
didn't immediately see anything at the top about "template template 
parameters", do a search for the phrase; however, when someone's
rushed, this would be a big help.

-regards,
Larry
Jan 14 2007
prev sibling next sibling parent just jeff <jeffrparsons optusnet.com.au> writes:
Thank you. It's good to see that not everyone gets overly defensive in 
the face of constructive criticism these days (having just come from a 
long day full of this!). :)
Jan 15 2007
prev sibling next sibling parent John Reimer <terminal.node gmail.com> writes:
Er... sounds like we're pouncing on you pretty hard despite what you did
to fix this: it just sounded very reluctant.

Just wanted to say again: thanks for listening.

-JJR
Jan 15 2007
prev sibling next sibling parent reply =?ISO-8859-1?Q?Lu=EDs_Marques?= <luismarques+spam gmail.com> writes:
Walter Bright wrote:

 But also, now that 1.0 is here, the time for that may have passed. To 
 that end, I've just removed the entries for the non-D languages. People 
 coming to D from those languages already know what they can do, and can 
 form their own conclusions.


I think it's quite nice now. That was a clever choice.
(IMO, in this context, the colors are also fine)

--
Luís Marques
Jan 15 2007
parent reply =?ISO-8859-1?Q?Lu=EDs_Marques?= <luismarques+spam gmail.com> writes:
Luís Marques wrote:

 Walter Bright wrote:

 But also, now that 1.0 is here, the time for that may have passed. To 
 that end, I've just removed the entries for the non-D languages. 
 People coming to D from those languages already know what they can do, 
 and can form their own conclusions.


 
 I think it's quite nice now. That was a clever choice.
 (IMO, in this context, the colors are also fine)
 
 -- 
 Luís Marques


Actually, I'll add that you might want to tweak the comparison comments. 
Because only D is listed now, some remarks about other languages seem to 
appear a bit out of context.

The "Willeam NerdSpeare" remark... well... :)
Jan 15 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Luís Marques wrote:

 Luís Marques wrote:

 Walter Bright wrote:

 But also, now that 1.0 is here, the time for that may have passed. To 
 that end, I've just removed the entries for the non-D languages. 
 People coming to D from those languages already know what they can 
 do, and can form their own conclusions.


 I think it's quite nice now. That was a clever choice.
 (IMO, in this context, the colors are also fine)

 -- 
 Luís Marques


 
 Actually, I'll add that you might want to tweak the comparison comments. 
 Because only D is listed now, some remarks about other languages seem to 
 appear a bit out of context.
 
 The "Willeam NerdSpeare" remark... well... :)


I'll second your "well..." on that.
And I'll raise you one "uh..." for the "Richard Deyman" quote found on 
other pages.  :-)   (Seriously I don't think Richard Feynman's quote 
about quantum mechanics is well-known enough for most people to even 
recognize that its a fake quote, let alone that it's a joke.)

--bb
Jan 15 2007
next sibling parent kenny <funisher gmail.com> writes:

you're on the other pages

it is much better. Speaking for the other language is pretty aggressive. 
I like how it is now.

Bill Baxter wrote:

 Luís Marques wrote:

 Luís Marques wrote:

 Walter Bright wrote:

 But also, now that 1.0 is here, the time for that may have passed. 
 To that end, I've just removed the entries for the non-D languages. 
 People coming to D from those languages already know what they can 
 do, and can form their own conclusions.


 I think it's quite nice now. That was a clever choice.
 (IMO, in this context, the colors are also fine)

 -- 
 Luís Marques


 Actually, I'll add that you might want to tweak the comparison 
 comments. Because only D is listed now, some remarks about other 
 languages seem to appear a bit out of context.

 The "Willeam NerdSpeare" remark... well... :)


 
 I'll second your "well..." on that.
 And I'll raise you one "uh..." for the "Richard Deyman" quote found on 
 other pages.  :-)   (Seriously I don't think Richard Feynman's quote 
 about quantum mechanics is well-known enough for most people to even 
 recognize that its a fake quote, let alone that it's a joke.)
 
 --bb
Jan 15 2007
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
Bill Baxter wrote:

 Luís Marques wrote:

 The "Willeam NerdSpeare" remark... well... :)


 
 I'll second your "well..." on that.
 And I'll raise you one "uh..." for the "Richard Deyman" quote found on 
 other pages.  :-)   (Seriously I don't think Richard Feynman's quote 
 about quantum mechanics is well-known enough for most people to even 
 recognize that its a fake quote, let alone that it's a joke.)


It is a joke just for nerds <g>.

'You will obey my orders!' -- James "D" Quark
Jan 15 2007
prev sibling next sibling parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:

 I don't agree at all that the table is misleading, deceptive, dishonest, 
 etc. It says right up front what it is - a comparison of *core* language 
 features. You can do anything in a library in any language.
 
 I agree, though, that it is out of date with respect to the latest 

 
 I also agree that the table is meant to draw attention, with the 
 brightly colored boxes, etc. Being a little confrontational helps get 
 discussions going. And yes, it throws down the gauntlet and is in your 
 face.
 
 But also, now that 1.0 is here, the time for that may have passed. To 
 that end, I've just removed the entries for the non-D languages. People 
 coming to D from those languages already know what they can do, and can 
 form their own conclusions.


I think that's a wise decision. I've always hated that table.

Andrei
Jan 15 2007
prev sibling parent reply Kevin Bealer <kevinbealer gmail.com> writes:
I'm kind of glad its not going away completely, because I've always found the

when you don't remember the syntax (or keyword!) that makes it tick.

I'm wondering if a larger version like this would be useful:

|String support:
| D                   C                   C++           Java
| UTF8,16,32 types    char*, null         string and    Special class with
| used with D's       terminated          wstring are   language support;
| static + dynamic    arrays with         ASCII and     is an immutable
| arrays.             libc's string.h     UTF16 array   array of UTF16
|                     support functions.  classes.      codepoints.

It could be a mixture of "what exists" plus "how to do it".

But maybe this is beyond the scope of this site for now -- it would take a lot
of
typing and maybe some research to fill in such a table and that might be better
done via wiki.

Kevin
Jan 17 2007
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Kevin Bealer wrote:


 I'm wondering if a larger version like this would be useful:
 
 |String support:
 | D                   C                   C++           Java
 | UTF8,16,32 types    char*, null         string and    Special class with
 | used with D's       terminated          wstring are   language support;
 | static + dynamic    arrays with         ASCII and     is an immutable
 | arrays.             libc's string.h     UTF16 array   array of UTF16
 |                     support functions.  classes.      codepoints.
 
 It could be a mixture of "what exists" plus "how to do it".


For C that should probably be "char* and wchar_t*" instead...
Support is in <wchar.h> (with the usual C portability issues)

--anders
Jan 17 2007
prev sibling next sibling parent reply James Dennett <jdennett acm.org> writes:
Kevin Bealer wrote:

 I'm kind of glad its not going away completely, because I've always found the

 when you don't remember the syntax (or keyword!) that makes it tick.
 
 I'm wondering if a larger version like this would be useful:
 
 |String support:
 | D                   C                   C++           Java
 | UTF8,16,32 types    char*, null         string and    Special class with
 | used with D's       terminated          wstring are   language support;
 | static + dynamic    arrays with         ASCII and     is an immutable
 | arrays.             libc's string.h     UTF16 array   array of UTF16
 |                     support functions.  classes.      codepoints.
 
 It could be a mixture of "what exists" plus "how to do it".


It would be good to get a C++ person to check it over,
so that it doesn't say that wstring is tied to UTF-16,
for example (particularly as C++09 is very likely to
bring support for Unicode strings to C++, and wstring
is intended for fixed-width encodings which excludes
UTF-16, though on many or most platforms it is quite
reasonable to store UCS4 in std::wstrings).

-- James
Jan 17 2007
parent reply Kevin Bealer <kevinbealer gmail.com> writes:
== Quote from James Dennett (jdennett acm.org)'s article

 Kevin Bealer wrote:

 I'm kind of glad its not going away completely, because I've always found the

 when you don't remember the syntax (or keyword!) that makes it tick.

 I'm wondering if a larger version like this would be useful:

 |String support:
 | D                   C                   C++           Java
 | UTF8,16,32 types    char*, null         string and    Special class with
 | used with D's       terminated          wstring are   language support;
 | static + dynamic    arrays with         ASCII and     is an immutable
 | arrays.             libc's string.h     UTF16 array   array of UTF16
 |                     support functions.  classes.      codepoints.

 It could be a mixture of "what exists" plus "how to do it".


 It would be good to get a C++ person to check it over,
 so that it doesn't say that wstring is tied to UTF-16,
 for example (particularly as C++09 is very likely to
 bring support for Unicode strings to C++, and wstring
 is intended for fixed-width encodings which excludes
 UTF-16, though on many or most platforms it is quite
 reasonable to store UCS4 in std::wstrings).
 -- James


I meant this just as an example, but the kind of complexity you are describing
makes me think that an actual description of how or what is supported would be
too problematic after all.

When I wrote the above 'chart line' I was thinking that most of the keyword or
key-phrase items like wstring and "Java String" would be links to more useful
resources.  Maybe it would be better to *just* have a link.

|String support:
| D               C                   C++                 Java
| <char[]>        <link to C howto>   <cppreference link> <class String>

Each could link to an online resource that does a more thorough job of
describing the technique -- this would allow Sun to make the case for
Java's design.  So if D's 'String' link points at a "why use char[]"
page, it wouldn't seem biased, since all the links go to advocates,
owners, or resources specific to the respective languages.

Kevin
Jan 17 2007
parent Walter Bright <newshound digitalmars.com> writes:
Kevin Bealer wrote:

 Each could link to an online resource that does a more thorough job of
 describing the technique -- this would allow Sun to make the case for
 Java's design.  So if D's 'String' link points at a "why use char[]"
 page, it wouldn't seem biased, since all the links go to advocates,
 owners, or resources specific to the respective languages.


I've been accused multiple times of "sabotaging" C++ by referencing what 
I believed was an authoritative source for a C++ technique, and being 
told that technique was ignorant, wrong, obsolete, whatever <g>.

What is the "right" way to do things in C++ depends an awful lot on 
which guru you talk to.
Jan 17 2007
prev sibling parent Don Clugston <dac nospam.com.au> writes:
Kevin Bealer wrote:

 I'm kind of glad its not going away completely, because I've always found the

 when you don't remember the syntax (or keyword!) that makes it tick.
 
 I'm wondering if a larger version like this would be useful:
 
 |String support:
 | D                   C                   C++           Java
 | UTF8,16,32 types    char*, null         string and    Special class with
 | used with D's       terminated          wstring are   language support;
 | static + dynamic    arrays with         ASCII and     is an immutable
 | arrays.             libc's string.h     UTF16 array   array of UTF16
 |                     support functions.  classes.      codepoints.
 
 It could be a mixture of "what exists" plus "how to do it".
 
 But maybe this is beyond the scope of this site for now -- it would take a lot
of
 typing and maybe some research to fill in such a table and that might be better
 done via wiki.
 
 Kevin


Another possibility would be to add a single-line comment beside some of 
the entries, to directly avoid misconceptions.
eg:
Garbage collection --- Optional, Manual memory management also available.
Object oriented --- Optional, free functions also available
Template value parameters --- integral, floating point, or string.

I'm also baffled as to why 'alias' is in the Arrays section.
Jan 18 2007
prev sibling next sibling parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
There's still this text on the front page

"For a quick feature comparison, see [link]this[/link] comparison of D
Jan 19 2007
parent reply kenny <funisher gmail.com> writes:
Jari-Matti Mäkelä wrote:

 There's still this text on the front page
 
 "For a quick feature comparison, see [link]this[/link] comparison of D



also, if you go to

http://digitalmars.com/d/pretod.html

the left hand side incorrectly links to "D Features"

I think I said this before though...
Jan 19 2007
parent Jari-Matti =?ISO-8859-1?Q?M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
kenny wrote:


 Jari-Matti Mäkelä wrote:

 There's still this text on the front page
 
 "For a quick feature comparison, see [link]this[/link] comparison of D



 
 also, if you go to
 
 http://digitalmars.com/d/pretod.html
 
 the left hand side incorrectly links to "D Features"
 
 I think I said this before though...


Oh sorry, didn't notice. Hope it gets fixed soon :)
Jan 20 2007
prev sibling parent reply Vincenzo Romano <vincenzo.romano gmail.com> writes:
Georg Wrede Wrote:


 Quoting from 
 http://www.gamedev.net/community/forums/topic.asp?topic_id=431909
 


out, wrong. No dynamic arrays? Try System.Collections.Generic.List<T>. No
associative arrays? Try System.Collections.Generic.Dictionary<T>. No aliases?
Try using <class> = Alias;. There are many more on that page, so much so, I am
half tempted to write a page debunking over half your comparisons.
 
 Your comparison sheet is EXTREMELY misleading, as you completely ignore the

Ignoring the presence of many of these facilities in the .NET framework is a
really shady tactic to make D seem like it has several important features that

really not (like multiple inheritance, which is dangerous to begin with).
 
 D is a neat language, but you need to be more honest in your comparisons.


 
 Not directly commenting on this quote (since I'm not that familiar with 

 
 Other languages may have got new versions out, and some of the table 
 entries are, ehh, not that obvious to the casual reader.
 
 While some of the more surprising answers (the yes/no stuff) are 
 explained in footnotes or on other pages, we must understand that all 
 this slashdotting etc. brings readers who don't bother reading "the fine 
 print". They may then dismiss the table (and thus D itself) as biased, 
 hyped, and regular marketing lies altogether.
 
 I don't think we can afford it.
 



It's 2009Q2 now.
The comparison is still not a comparison at all by just showing the D features.
If you want to attract more programmers to D you need to show HIGH QUALITY code
(snippets) in, say,
D, C++, Java ... you choose.
You need to show the value.
Apr 23 2009
parent Lutger <lutger.blijdestijn gmail.com> writes:
Vincenzo Romano wrote:
...

 It's 2009Q2 now.
 The comparison is still not a comparison at all by just showing the D 


features.

 If you want to attract more programmers to D you need to show HIGH QUALITY 


code (snippets) in, say,

 D, C++, Java ... you choose.
 You need to show the value.


Did you not find them? Throughout the articles on digitalmars.com/d, in the 
spec and phobos library documentation you find lot's of examples and 
illustrations.
Apr 24 2009