www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is D taking hold in the C++ world?

reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
I've read a couple of things recently that've indicated that D's not 
taken seriously by the C++ world. I am wondering whether this is 
true, since it's certainly not the impression that I've had from the 
people I've spoken with about it, most of whom are not using it now, 
but are definitely interested in doing so in the future; the 
D-curious, if you like?

I'm interested to hear from people what their 
friends/colleagues/etc. think about D, especially in terms of 
whether they would be willing to use it come 1.0.

I'm also interested to hear of any specific must-haves that such 
people have expressed.

Please, everyone, don't turn this thread into what _you_ think about 
D, or what _you_ think should be in 1.0. We have a pretty good feel 
for what D-philes think already.

Cheers

Matthew
Apr 26 2005
next sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <d4mioc$2lgm$1 digitaldaemon.com>, Matthew says...
I'm interested to hear from people what their 
friends/colleagues/etc. think about D, especially in terms of 
whether they would be willing to use it come 1.0.

I've gotten the usual chicken-and-egg problem response: "It's not proven yet." .. and the current status of the language: "It's not done yet." .. are the only significant barriers to adoption I've run across. Everything else seems to take a back seat to those two, no matter how profound. Now personally, I'm happy to swim around in the morass of compiler bugs, not-quite-done-yet language semantics and a library that's "almost there"; but that's because I see D going someplace and want to help make it happen. Each time I bring up D to a new programmer, I'm reminded of how unusual that viewpoint really is. If you ask me, D needs a far more professional web presence if its going to be taken more seriously by the curious and answer-seekers online. Its about instilling confidence in a quality product as well as delivering on that promise. Take a page from Sun's book and look at java.sun.com, then dig through the internet archive for the same pages circa 1997. They've always had a slick (if at times simple) presence, and a well-presented showcase for their technology. The D site has enough *information* about the language, but fails to grab the eye and invite users to spend their coffee break at digitalmars.com. - EricAnderton at yahoo
Apr 26 2005
next sibling parent Kyle Furlong <ky220 umail.ucsb.edu> writes:
pragma wrote:
 In article <d4mioc$2lgm$1 digitaldaemon.com>, Matthew says...
 
I'm interested to hear from people what their 
friends/colleagues/etc. think about D, especially in terms of 
whether they would be willing to use it come 1.0.

I've gotten the usual chicken-and-egg problem response: "It's not proven yet." .. and the current status of the language: "It's not done yet." .. are the only significant barriers to adoption I've run across. Everything else seems to take a back seat to those two, no matter how profound. Now personally, I'm happy to swim around in the morass of compiler bugs, not-quite-done-yet language semantics and a library that's "almost there"; but that's because I see D going someplace and want to help make it happen. Each time I bring up D to a new programmer, I'm reminded of how unusual that viewpoint really is. If you ask me, D needs a far more professional web presence if its going to be taken more seriously by the curious and answer-seekers online. Its about instilling confidence in a quality product as well as delivering on that promise. Take a page from Sun's book and look at java.sun.com, then dig through the internet archive for the same pages circa 1997. They've always had a slick (if at times simple) presence, and a well-presented showcase for their technology. The D site has enough *information* about the language, but fails to grab the eye and invite users to spend their coffee break at digitalmars.com. - EricAnderton at yahoo

Eric has a good point about a web presence, marketing has a huge effect, but I think that something like that would have to grow out of an organized group effort. The issues surrounding the "opening" of the work effort need to be resolved first. (So that there is an organization to manage all efforts, such as a web presence for D)
Apr 26 2005
prev sibling parent reply J C Calvarese <jcc7 cox.net> writes:
pragma wrote:
 In article <d4mioc$2lgm$1 digitaldaemon.com>, Matthew says...

 If you ask me, D needs a far more professional web presence if its going to be
 taken more seriously by the curious and answer-seekers online.  Its about
 instilling confidence in a quality product as well as delivering on that
 promise.  
 
 Take a page from Sun's book and look at java.sun.com, then dig through the
 internet archive for the same pages circa 1997.  They've always had a slick (if
 at times simple) presence, and a well-presented showcase for their technology.
 The D site has enough *information* about the language, but fails to grab the
 eye and invite users to spend their coffee break at digitalmars.com.
 
 - EricAnderton at yahoo

I think you're right. There's nothing necessarily /wrong/ the Digital Mars website, but a little CSS and a few simple graphical elements can go a long way. Obviously jazzy web design isn't Walter's favorite hobby, but there are many D programmers who are skilled at designing flashy web pages. Since Walter doesn't seem to want to do it himself, he can have a contest to to see who can come up with the best design for the D pages at Digital Mars. Everyone who's interested can submit a couple pages showing there proposed design in action. The winner gets a free copy of the Walter's first D book and gets his (or her) name mentioned in the acknowledgements. That might do the trick. -- jcc7 http://jcc_7.tripod.com/d/
Apr 26 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"J C Calvarese" <jcc7 cox.net> wrote in message
news:d4n2nl$1hr$1 digitaldaemon.com...
 I think you're right. There's nothing necessarily /wrong/ the Digital
 Mars website, but a little CSS and a few simple graphical elements can
 go a long way. Obviously jazzy web design isn't Walter's favorite hobby,
 but there are many D programmers who are skilled at designing flashy web
 pages.

Is a flashy web page really an advantage? I see a lot of flashy web pages, and they don't impress me that much. The DM pages are for programmers, who (I assume) want to see a straightforward page that loads fast and is not gimmicky. Maybe I'm all wrong about this. P.S. I also prefer a smaller number of pages with a lot of text to a larger number of small pages. The plethora of small pages means one is constantly clicking and waiting, which interrupts the train of thought. I do agree that I am not going to win any awards for my english composition, and if anyone has any suggestions on rewrites for any part of the text, I'm all ears!
Apr 28 2005
next sibling parent reply Jason Mills <jmills cs.mun.ca> writes:
Walter wrote:
  > Is a flashy web page really an advantage? I see a lot of flashy web 
pages,
 and they don't impress me that much. The DM pages are for programmers, who
 (I assume) want to see a straightforward page that loads fast and is not
 gimmicky. Maybe I'm all wrong about this.

Probably no pragmatic advantage. I would say most hard core programmers are content with the simple/clean web pages as they are. But there are those (a lot in my experience) that like eye candy. For some reason it looks and feels more professional, even if it is a facade. If you want to "sell" a product, wrap it in a nice package.
 P.S. I also prefer a smaller number of pages with a lot of text to a larger
 number of small pages. The plethora of small pages means one is constantly
 clicking and waiting, which interrupts the train of thought.
 
 I do agree that I am not going to win any awards for my english composition,
 and if anyone has any suggestions on rewrites for any part of the text, I'm
 all ears!
 
 

Apr 28 2005
parent reply "Charlie" <charles jwavro.com> writes:
It doesn't even have to be flashy , CSS and a few images can go a long way
to make it better.  Natural docs ( http://www.naturaldocs.org/ )  produces
very clean interface and can be used for anything really.

Charlie


"Jason Mills" <jmills cs.mun.ca> wrote in message
news:d4rcck$1htf$1 digitaldaemon.com...
 Walter wrote:
   > Is a flashy web page really an advantage? I see a lot of flashy web
 pages,
 and they don't impress me that much. The DM pages are for programmers,


 (I assume) want to see a straightforward page that loads fast and is not
 gimmicky. Maybe I'm all wrong about this.

Probably no pragmatic advantage. I would say most hard core programmers are content with the simple/clean web pages as they are. But there are those (a lot in my experience) that like eye candy. For some reason it looks and feels more professional, even if it is a facade. If you want to "sell" a product, wrap it in a nice package.
 P.S. I also prefer a smaller number of pages with a lot of text to a


 number of small pages. The plethora of small pages means one is


 clicking and waiting, which interrupts the train of thought.

 I do agree that I am not going to win any awards for my english


 and if anyone has any suggestions on rewrites for any part of the text,


 all ears!


Apr 28 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
Does it work with Doxygen tags already in the code?

"Charlie" <charles jwavro.com> wrote in message 
news:d4rda0$1j75$1 digitaldaemon.com...
 It doesn't even have to be flashy , CSS and a few images can go a 
 long way
 to make it better.  Natural docs ( http://www.naturaldocs.org/ ) 
 produces
 very clean interface and can be used for anything really.

 Charlie


 "Jason Mills" <jmills cs.mun.ca> wrote in message
 news:d4rcck$1htf$1 digitaldaemon.com...
 Walter wrote:
   > Is a flashy web page really an advantage? I see a lot of 
 flashy web
 pages,
 and they don't impress me that much. The DM pages are for 
 programmers,


 (I assume) want to see a straightforward page that loads fast 
 and is not
 gimmicky. Maybe I'm all wrong about this.

Probably no pragmatic advantage. I would say most hard core programmers are content with the simple/clean web pages as they are. But there are those (a lot in my experience) that like eye candy. For some reason it looks and feels more professional, even if it is a facade. If you want to "sell" a product, wrap it in a nice package.
 P.S. I also prefer a smaller number of pages with a lot of text 
 to a


 number of small pages. The plethora of small pages means one is


 clicking and waiting, which interrupts the train of thought.

 I do agree that I am not going to win any awards for my english


 and if anyone has any suggestions on rewrites for any part of 
 the text,


 all ears!



Apr 28 2005
parent Jason Mills <jmills cs.mun.ca> writes:
If your looking for doxygen compatibility, but in my opinion, more 
stylish default output HTML, checkout Doxys 
http://www.doxys.dk/doxys_homepage/.

Matthew wrote:
 Does it work with Doxygen tags already in the code?
 
 "Charlie" <charles jwavro.com> wrote in message 
 news:d4rda0$1j75$1 digitaldaemon.com...
 
It doesn't even have to be flashy , CSS and a few images can go a 
long way
to make it better.  Natural docs ( http://www.naturaldocs.org/ ) 
produces
very clean interface and can be used for anything really.


Apr 29 2005
prev sibling next sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <d4r4vt$18hb$1 digitaldaemon.com>, Walter says...
"J C Calvarese" <jcc7 cox.net> wrote in message
news:d4n2nl$1hr$1 digitaldaemon.com...
 I think you're right. There's nothing necessarily /wrong/ the Digital
 Mars website, but a little CSS and a few simple graphical elements can
 go a long way. Obviously jazzy web design isn't Walter's favorite hobby,
 but there are many D programmers who are skilled at designing flashy web
 pages.

Is a flashy web page really an advantage? I see a lot of flashy web pages, and they don't impress me that much. The DM pages are for programmers, who (I assume) want to see a straightforward page that loads fast and is not gimmicky. Maybe I'm all wrong about this.

Walter, technically the D programming language pages are doing everything right. I for one feel that the introduction page should make better use of whitespace to lead the eye down the page to the informative links (comparison, newsgroup, download, etc). The left-hand nav, while being a great index for the manual, is actually a distraction as its available up-front. It should probably be left behind a "reference" or "docs" link from a stripped-down main menu. The menu itself very reference oriented, leaving the higher-traffic links at the bottom (download, tools, community, etc). Also, as you say on the first page "This is the reference document". Perhaps its time for an additional, more simple page? Last, and certainly not least, a site's "look & feel" can say volumes (subconsiously) about how well the site, and the advertised product, are assembled. It makes a statement about quality and commitment that is formulated much earlier (practically eons in terms of mental effort) than when the user even thinks about clicking "download". I'll also add that the current rendition of the site, while improved, isn't much different than it was years ago. In truth, I *left* that site after that first visit, feeling lost, only to revisit months later. D's purpose simply wasn't conveyed to me easily, and the stability of the product was punctuated with a large question-mark. IMO, the DNG has been more helpful in conveying D's promise and mission than the site (however actions *do* speak louder than words, so please take this with a mountain of salt). :(
I do agree that I am not going to win any awards for my english composition,
and if anyone has any suggestions on rewrites for any part of the text, I'm
all ears!

If you don't mind, I'll withold the rest of my critiques, as I'm still formulating them. Plus, I believe that I can probably do the topic more justice by trying a few things offline. If anything comes of this exercise, I'll share my findings here. - EricAnderton at yahoo
Apr 28 2005
parent "Walter" <newshound digitalmars.com> writes:
"pragma" <pragma_member pathlink.com> wrote in message
news:d4s019$24vk$1 digitaldaemon.com...
 If you don't mind, I'll withold the rest of my critiques, as I'm still
 formulating them.  Plus, I believe that I can probably do the topic more

 by trying a few things offline.  If anything comes of this exercise, I'll

 my findings here.

Good. If you like, try mocking up a new front page and let's see how it looks.
Apr 28 2005
prev sibling next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
Walter wrote:
 "J C Calvarese" <jcc7 cox.net> wrote in message
 news:d4n2nl$1hr$1 digitaldaemon.com...
 
I think you're right. There's nothing necessarily /wrong/ the Digital
Mars website, but a little CSS and a few simple graphical elements can
go a long way. Obviously jazzy web design isn't Walter's favorite hobby,
but there are many D programmers who are skilled at designing flashy web
pages.

Is a flashy web page really an advantage? I see a lot of flashy web pages, and they don't impress me that much. The DM pages are for programmers, who (I assume) want to see a straightforward page that loads fast and is not gimmicky. Maybe I'm all wrong about this.

"Flashy" may have not been the best word. I'm certainly not suggesting that the D pages should be some overly fancy Macromedia flash monstrosity. I'm not asking for a bunch of animated .gif or JavaScript marquees either (let's not!). I just think that the pages could be a little more colorful in general. People have certain expectations when they view webpages, and I think most people today expect a different kind of design than they saw five years ago. Anything we can do to improve D's "first impression" would help out. Right now the D pages are mostly black text on white background (a lot of pages do this because it's easy to read), but they could benefit from the addition of some subtle accents. I think it's currently all the same font, but a second font could be used for major headings and other special occasions. The dividers are nice, but a shaded box here or there could add a lot more color to the design. I didn't see a prominant logo for the language (though there is a nice logo for Digital Mars). I don't think that frames are as cool as they used to be. I agree with what Eric wrote in the other branch. It'd be nice if there was some sort of welcome page that a person views before they see the frames. It might be a little bit of TMI. I've compiled some links to some of our competition for inspiration. I like the grassroots ones better than the corporate ones, but they all seems to be more "modern" looking than D's webpage. Grassroots: http://www.php.net/ http://www.python.org/ http://www.ruby-lang.org/en/ http://www.perl.org/ Corporate: http://msdn.microsoft.com/vcsharp/ http://java.sun.com/ http://www.borland.com/delphi/
 P.S. I also prefer a smaller number of pages with a lot of text to a larger
 number of small pages. The plethora of small pages means one is constantly
 clicking and waiting, which interrupts the train of thought.

I don't think that's a problem. That seems like a reasonable view to me.
 I do agree that I am not going to win any awards for my english composition,
 and if anyone has any suggestions on rewrites for any part of the text, I'm
 all ears!

I like your writing style. I'll let you know if I find some mispelled words. -- jcc7 http://jcc_7.tripod.com/d/
Apr 28 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"J C Calvarese" <jcc7 cox.net> wrote in message
news:d4s9m5$2dih$1 digitaldaemon.com...
 I'm not asking for a bunch of animated .gif or JavaScript marquees
 either (let's not!). I just think that the pages could be a little more
 colorful in general. People have certain expectations when they view
 webpages, and I think most people today expect a different kind of
 design than they saw five years ago. Anything we can do to improve D's
 "first impression" would help out.

 Right now the D pages are mostly black text on white background (a lot
 of pages do this because it's easy to read), but they could benefit from
 the addition of some subtle accents. I think it's currently all the same
 font, but a second font could be used for major headings and other
 special occasions. The dividers are nice, but a shaded box here or there
 could add a lot more color to the design. I didn't see a prominant logo
 for the language (though there is a nice logo for Digital Mars).

 I don't think that frames are as cool as they used to be. I agree with
 what Eric wrote in the other branch. It'd be nice if there was some sort
 of welcome page that a person views before they see the frames. It might
 be a little bit of TMI.

 I've compiled some links to some of our competition for inspiration. I
 like the grassroots ones better than the corporate ones, but they all
 seems to be more "modern" looking than D's webpage.

 Grassroots:
 http://www.php.net/
 http://www.python.org/
 http://www.ruby-lang.org/en/
 http://www.perl.org/

 Corporate:
 http://msdn.microsoft.com/vcsharp/
 http://java.sun.com/
 http://www.borland.com/delphi/

I guess nobody likes Times font! Thanks for putting this together.
Apr 29 2005
next sibling parent reply Kyle Furlong <ky220 umail.ucsb.edu> writes:
Walter wrote:
 "J C Calvarese" <jcc7 cox.net> wrote in message
 news:d4s9m5$2dih$1 digitaldaemon.com...
 
I'm not asking for a bunch of animated .gif or JavaScript marquees
either (let's not!). I just think that the pages could be a little more
colorful in general. People have certain expectations when they view
webpages, and I think most people today expect a different kind of
design than they saw five years ago. Anything we can do to improve D's
"first impression" would help out.

Right now the D pages are mostly black text on white background (a lot
of pages do this because it's easy to read), but they could benefit from
the addition of some subtle accents. I think it's currently all the same
font, but a second font could be used for major headings and other
special occasions. The dividers are nice, but a shaded box here or there
could add a lot more color to the design. I didn't see a prominant logo
for the language (though there is a nice logo for Digital Mars).

I don't think that frames are as cool as they used to be. I agree with
what Eric wrote in the other branch. It'd be nice if there was some sort
of welcome page that a person views before they see the frames. It might
be a little bit of TMI.

I've compiled some links to some of our competition for inspiration. I
like the grassroots ones better than the corporate ones, but they all
seems to be more "modern" looking than D's webpage.

Grassroots:
http://www.php.net/
http://www.python.org/
http://www.ruby-lang.org/en/
http://www.perl.org/

Corporate:
http://msdn.microsoft.com/vcsharp/
http://java.sun.com/
http://www.borland.com/delphi/

I guess nobody likes Times font! Thanks for putting this together.

Are you willing to let someone redesign the D website, Walter?
Apr 29 2005
parent "Walter" <newshound digitalmars.com> writes:
"Kyle Furlong" <ky220 umail.ucsb.edu> wrote in message
news:d4sr93$1ik8$2 digitaldaemon.com...
 Are you willing to let someone redesign the D website, Walter?

If someone is willing to do a front page, I'm open minded about adopting it. It needs to have the following characteristics, though: 1) no javascript, no flash, no ActiveX, no Java, no scripts, etc. The page should work for those who have all that stuff turned off for security reasons. 2) be search engine friendly 3) be accessible to those who use text-to-speech programs (this and (2) are flip sides of the same coin) 4) not be fixed size - meaning it should work on small screens as well as large ones 5) not use fixed font sizes. Visually impaired people should be able to make the fonts bigger. 6) load fast. This means no large graphics files. 7) be hand-edittable.
Apr 29 2005
prev sibling next sibling parent zwang <nehzgnaw gmail.com> writes:
Walter wrote:
 I guess nobody likes Times font! Thanks for putting this together.

Why? I like serif font.
Apr 29 2005
prev sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
 I guess nobody likes Times font!

Generally, yes. The Times font is great for printed material, but on screen, fonts without serifs are typically easier to read. Verdana, for example, is a very friendly-on-the-eyes sort of font. Sometimes, a good compromise works well. Georgia, for example, is a serif font that for some people still reads well on screen. In any case, the pages aren't at all bad imho, but they lack... feel. It's all so basic, hardly any colors. Lots of color is very obviously bad, but hardly any can tire your eyes. Sometimes the tiny bit of pizazz is to keep you awake - if it becomes distracting, it's a problem... but that doesn't mean avoid it entirely. PHP's documentation is generally considered to be very good, and when it is asked why the language is popular, the documentation is just about always named as a reason. For one thing, most everything has at least one example - for another, everything has postable comments. D isn't far off at all, in these respects... but do take a look: http://www.php.net/array_keys First, we have color. The headings are in a very dark blue/purple. This isn't distracting and it isn't inaccessable, but it gives the page identity and feel. It's like wearing a good tie - and the current D site is wearing a solid black tie. The example text is also color coded there. One way to achieve this almost transparently is JavaScript (yes, I know it was mentioned as to be avoided) - for example, any <pre> elements with a class set to code could be found and colored in an automated fashion. If JavaScript was disabled, it'd just be black on white. This would mean adding one line to every file, and adding the class... and not worrying about it. Of course, that assumes some sort of color coding (which I hope you'll agree most programmers like) is desirable. And, obviously, with the print media the color could be forced as black - because, again, screen and print are different worlds these days. And... while I think frames are a... very debated concept, you'll see that the PHP documentation I linked to has an index of sorts, but without frames. While there are benefits to frames, one of the major detriments is printing. Some browsers will print each frame separately, others will just bungle it. Some browsers, such as text-only ones (which programmers are decently likely to use!) don't even support frames. Frames also hurt searching. Go to Google, and search for "versionstatement". D is in third place, which is wonderful - but click on the link. No index, no real navigation aside from "[D]". If I didn't know anything about D, I might be confused and I might have trouble finding more information. I'd be more than willing to come up with example pages for some of what I've said. -[Unknown]
Apr 30 2005
next sibling parent "Walter" <newshound digitalmars.com> writes:
"Unknown W. Brackets" <unknown simplemachines.org> wrote in message
news:d50p42$14r0$1 digitaldaemon.com...
 I'd be more than willing to come up with example pages for some of what
 I've said.

I think your comments are on target. Great! Why not pick one of the pages, and mock up an example?
Apr 30 2005
prev sibling parent reply KTC <me here.com> writes:
 
 The example text is also color coded there.  One way to achieve
 this almost transparently is JavaScript (yes, I know it was
 mentioned as to be avoided) - for example, any <pre> elements
 with a class set to code could be found and colored in an
 automated fashion.  If JavaScript was disabled, it'd just be
 black on white.  This would mean adding one line to every file,
 and adding the class... and not worrying about it. 

One can just do it with CSS without having to resort to JS. Works even in most of the GUI browser that has js disabled.
 Of course, that assumes some sort of color coding (which I hope
 you'll agree most programmers like) is desirable.  And,
 obviously, with the print media the color could be forced as
 black - because, again, screen and print are different worlds
 these days. 

Again, CSS is perfectly design for that. "media=print" and set the things you want. KTC -- Experience is a good school but the fees are high. - Heinrich Heine
May 01 2005
parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
 One can just do it with CSS without having to resort to JS. Works 
 even in most of the GUI browser that has js disabled.

Obviously. Of course the JavaScript would use CSS. However, would you rather write regular code, or bother yourself *for every example* to color code all the code? It'd also be a lot easier to make mistakes.
 Again, CSS is perfectly design for that. "media=print" and set the 
 things you want.

I thought that was implied. Unless you thought I meant to use JavaScript to restyle the entire page when you print it... no, a media or separate stylesheet is what I meant. Still, this doesn't make using JavaScript less desirable (or even change how desirable it is) for the above named reasons. The point is, making the color coding manual quite obviously reduces the "hand-editable"-ness of the code. If I were working with (cached) generated content, I would have a function to color code the examples server-side, instead of client side... but it shouldn't matter, because those who have JavaScript off are likely not to want color coding anyway. -[Unknown]
May 01 2005
prev sibling next sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Walter wrote:
 "J C Calvarese" <jcc7 cox.net> wrote in message
 news:d4n2nl$1hr$1 digitaldaemon.com...
 
I think you're right. There's nothing necessarily /wrong/ the Digital
Mars website, but a little CSS and a few simple graphical elements can
go a long way. Obviously jazzy web design isn't Walter's favorite hobby,
but there are many D programmers who are skilled at designing flashy web
pages.

Is a flashy web page really an advantage? I see a lot of flashy web pages, and they don't impress me that much. The DM pages are for programmers, who (I assume) want to see a straightforward page that loads fast and is not gimmicky. Maybe I'm all wrong about this. P.S. I also prefer a smaller number of pages with a lot of text to a larger number of small pages. The plethora of small pages means one is constantly clicking and waiting, which interrupts the train of thought. I do agree that I am not going to win any awards for my english composition, and if anyone has any suggestions on rewrites for any part of the text, I'm all ears!

that would help is a good index, even a QWIC index (though they rapidly get too bulky). When I'm using the documentation, I'm generally trying to find out how to do something specific, and for that an index would be a great assist. Still, I can often go almost right where I need to from the contents index as it is now set up. *DON'T* change that.
Apr 29 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Charles Hixson" <charleshixsn earthlink.net> wrote in message
news:d4udnr$1qvt$1 digitaldaemon.com...
 The current web pages are basically fine as they are.  One thing
 that would help is a good index, even a QWIC index (though they
 rapidly get too bulky).

Shouldn't search work better than an index?
 When I'm using the documentation, I'm
 generally trying to find out how to do something specific, and
 for that an index would be a great assist.  Still, I can often go
 almost right where I need to from the contents index as it is now
 set up. *DON'T* change that.

I, too, really like the use of frames to have a table of contents on the left, and the right is the page. Maybe it could be made to look nicer, but the functionality can't be beat. It's so much better than randomly clicking on a heirarchy of links looking for something. Check out the books on www.generalatomic.com, those pages use the same idea and it works well.
Apr 29 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:d4uhr2$1uhm$2 digitaldaemon.com...
 Shouldn't search work better than an index?

Actually, search and Index tend to complement each other... because the search can help find things not listed in the Index or not listed as expected... and the index can give a quick overview of what's available without having to first know what to search for. TZ
May 17 2005
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <d4r4vt$18hb$1 digitaldaemon.com>, Walter says...
"J C Calvarese" <jcc7 cox.net> wrote in message
news:d4n2nl$1hr$1 digitaldaemon.com...
 I think you're right. There's nothing necessarily /wrong/ the Digital
 Mars website, but a little CSS and a few simple graphical elements can
 go a long way. Obviously jazzy web design isn't Walter's favorite hobby,
 but there are many D programmers who are skilled at designing flashy web
 pages.

Is a flashy web page really an advantage? I see a lot of flashy web pages, and they don't impress me that much. The DM pages are for programmers, who (I assume) want to see a straightforward page that loads fast and is not gimmicky. Maybe I'm all wrong about this.

FWIW, the Comeau website is certainly no flashier than the DigitalMars website and I haven't heard any complaints from the C++ community :) Sean
Apr 30 2005
next sibling parent J C Calvarese <jcc7 cox.net> writes:
Sean Kelly wrote:
 In article <d4r4vt$18hb$1 digitaldaemon.com>, Walter says...
 
"J C Calvarese" <jcc7 cox.net> wrote in message
news:d4n2nl$1hr$1 digitaldaemon.com...

I think you're right. There's nothing necessarily /wrong/ the Digital
Mars website, but a little CSS and a few simple graphical elements can
go a long way. Obviously jazzy web design isn't Walter's favorite hobby,
but there are many D programmers who are skilled at designing flashy web
pages.

Is a flashy web page really an advantage? I see a lot of flashy web pages, and they don't impress me that much. The DM pages are for programmers, who (I assume) want to see a straightforward page that loads fast and is not gimmicky. Maybe I'm all wrong about this.

FWIW, the Comeau website is certainly no flashier than the DigitalMars website and I haven't heard any complaints from the C++ community :) Sean

I'm not familiar with the Comeau website (and I'm too lazy to search for a URL), but since Comeau didn't write the first C++ compiler they never had the same goals for their target audience. It's likely that their target audience is already sold on C++. They just need persuading to try a new compiler. We need to persuade people to try a compiler *and* and language. If we can add a little finese to the first thing that perspective D programmers would see, we can promote D better. -- jcc7 http://jcc_7.tripod.com/d/
Apr 30 2005
prev sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
But Comeau is preaching to the converted. ;)

"Sean Kelly" <sean f4.ca> wrote in message 
news:d50f9n$s9p$1 digitaldaemon.com...
 In article <d4r4vt$18hb$1 digitaldaemon.com>, Walter says...
"J C Calvarese" <jcc7 cox.net> wrote in message
news:d4n2nl$1hr$1 digitaldaemon.com...
 I think you're right. There's nothing necessarily /wrong/ the 
 Digital
 Mars website, but a little CSS and a few simple graphical 
 elements can
 go a long way. Obviously jazzy web design isn't Walter's 
 favorite hobby,
 but there are many D programmers who are skilled at designing 
 flashy web
 pages.

Is a flashy web page really an advantage? I see a lot of flashy web pages, and they don't impress me that much. The DM pages are for programmers, who (I assume) want to see a straightforward page that loads fast and is not gimmicky. Maybe I'm all wrong about this.

FWIW, the Comeau website is certainly no flashier than the DigitalMars website and I haven't heard any complaints from the C++ community :) Sean

Apr 30 2005
prev sibling next sibling parent clayasaurus <clayasaurus gmail.com> writes:
I've told two of my friends about D when i first learned of it... the 
response is something like this

friend #1) i'll use it when it comes installed with linux (gdc)

friend #2) garbage collection, higher level, easier to use? sounds too 
much like java. i think i'll stick with c++.

i recently told my prof. about D and he said, "hmm, I might use this in 
256 next year. :)" , 256 being the programming languages course.


Matthew wrote:
 I've read a couple of things recently that've indicated that D's not 
 taken seriously by the C++ world. I am wondering whether this is 
 true, since it's certainly not the impression that I've had from the 
 people I've spoken with about it, most of whom are not using it now, 
 but are definitely interested in doing so in the future; the 
 D-curious, if you like?
 
 I'm interested to hear from people what their 
 friends/colleagues/etc. think about D, especially in terms of 
 whether they would be willing to use it come 1.0.
 
 I'm also interested to hear of any specific must-haves that such 
 people have expressed.
 
 Please, everyone, don't turn this thread into what _you_ think about 
 D, or what _you_ think should be in 1.0. We have a pretty good feel 
 for what D-philes think already.
 
 Cheers
 
 Matthew
 
 

Apr 26 2005
prev sibling next sibling parent Mike Parker <aldacron71 yahoo.com> writes:
Matthew wrote:
 I've read a couple of things recently that've indicated that D's not 
 taken seriously by the C++ world. I am wondering whether this is 
 true, since it's certainly not the impression that I've had from the 
 people I've spoken with about it, most of whom are not using it now, 
 but are definitely interested in doing so in the future; the 
 D-curious, if you like?
 
 I'm interested to hear from people what their 
 friends/colleagues/etc. think about D, especially in terms of 
 whether they would be willing to use it come 1.0.
 
 I'm also interested to hear of any specific must-haves that such 
 people have expressed.
 
 Please, everyone, don't turn this thread into what _you_ think about 
 D, or what _you_ think should be in 1.0. We have a pretty good feel 
 for what D-philes think already.

What I've heard most often are: * no STL equivalent * lack of tools (IDEs, Debuggers) * not production-ready/stable What I've heard less often are concerns about support and the future direction of the language in light of it being developed by one person rather than a corporation.
Apr 26 2005
prev sibling next sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
 I'm also interested to hear of any specific must-haves that such people 
 have expressed.

 Please, everyone, don't turn this thread into what _you_ think about D, or 
 what _you_ think should be in 1.0. We have a pretty good feel for what 
 D-philes think already.

Each language/technology has its own motivations.... Let's take a look: Java 1) has safe sandbox - practically ideal for commercial programming by big and distributed development teams. 2) cross-platform (widely supported). 3) used to have "compile-once-run-everywhere" motto and still gaining some political benefits from it. 4) IDEs, heavvy, slow but with refactoring and all other bells and wistles. 5) Focused on server side programming these days C++ Multiple motivations on various platforms. Heritage of existing libraries (e.g. MFC,KDE, FLTK) creates critical mass. Multiple compilers of different vendors - this is an abstarct benefit but it is there. Universal. C The most crossplatform and portable language so far. Hard to create something big but for relatively small components and libraries design is just perfect. "Glue languages": Delphi and VB (C# and other .NET languages are here also) These are RAD tools - IDEs unbeatable. Perfect for creating in-house informational systems by their IT departments. And finally about D: There are two big niches for fast GCable language environment: Client side: multiplatform (read: easy portable) GUI application development without Java/NET compromises on effectiveness and weight of runtime. To be an ideal GUI development system D must have a) unified GUI framework(s) and b) IDE comparable by feature set with VB. Server side: Web services - pretty frequently changing and logically "shaggy" systems. D's OOP features: templates, classes will help to build complex systems here. To be an ideal here D must have strong DB interaction layer, transaction and queuing framework (preferrably built-in - written in D and for D). Servlet framework with a ) builtin extendable http server/service and/or b) Apache. D server pages framework. Is all this about Mango? If D would have IDE with builtin debugger working uniformely on supported platforms D will definitely have a chance to get developers from Delphi (up to 15-25% immediately after), VB6 (same number currently), good chunk of .NET developers doing GUI stuff. And yes, GUI candy should be there too. Highly probable that C++ guys doing GUI now will also jump into the boat. C++ is just not good for GUI programming, too many reasons. I think that primary D IDE should be a commercial project. At least initially. D project should have strong motivational fuel to be understandable and respectable by commercial guys - those who make decisions. If anybody will start the project - I am in. What GUI framework(s) needed? ... ummm.. this is another story. All above IMHO of course. But I have a strong feeling that D place is on the client. If D will offer crossplatform GUI solution it will win. Nothing close on the market. Andrew.
Apr 26 2005
prev sibling next sibling parent Kevin Bealer <Kevin_member pathlink.com> writes:
In article <d4mioc$2lgm$1 digitaldaemon.com>, Matthew says...
I've read a couple of things recently that've indicated that D's not 
taken seriously by the C++ world. I am wondering whether this is 
true, since it's certainly not the impression that I've had from the 
people I've spoken with about it, most of whom are not using it now, 
but are definitely interested in doing so in the future; the 
D-curious, if you like?

I'm interested to hear from people what their 
friends/colleagues/etc. think about D, especially in terms of 
whether they would be willing to use it come 1.0.

I'm also interested to hear of any specific must-haves that such 
people have expressed.

Please, everyone, don't turn this thread into what _you_ think about 
D, or what _you_ think should be in 1.0. We have a pretty good feel 
for what D-philes think already.

Cheers

Matthew

There is use, then there is proliferation. To get users, the current status quo is probably good enough once 1.0 hits. Somewhere around there, there will be more folks feeling out D for various single-author projects in fields like mathematics or CompSci experiments at universities. I think proliferation needs something else. The project team needs to be able to flip through the web site or "The D Programming Language" if such a book is written, and be able to answer two question: - What can D provide that Java/C++ can't do as effectively? - Can this language as it stands now, handle every part of the project? The first can be answered, to a degree, with the promotional materials on the web site and by getting individual developers interested. It really needs testimonials that only come once someone gets past the "chicken-egg" issue. The second (less critical) question is really about GUIs, supporting libraries, containers. The D website could endorse (or phobos could assimilate) one or more libraries for a given purpose. Or libraries, independent of endorsement, could find widespread adoption and become semi-standard. If I saw "Recommended graphics library: DUI" in an HTML table near the top of http://www.digitalmars.com/d/index.html, I would know that DUI is not going away because the "D community" or Walter or his heirs, designates or associates has officially adopted it and taken responsibility for keeping it alive. More than one graphics library could be recommended. The key is that there is more than a page of links to people who are "trying to write one". There has to be a kind of mutual buy-in between the library and the language. This is not a criticism of DUI or D; I think this part of the equation just takes time. Kevin
Apr 26 2005
prev sibling next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Matthew wrote:
 I've read a couple of things recently that've indicated that D's not
 taken seriously by the C++ world.

The more senior the developer, the more he's got to lose. Switch to another language, and his entire lead, superiority, seniority, experiencedness, his ivory tower, possibly even job -- are all gone overnight. Since this is based on [non-rational] feelings, it's something he is not used to, or even aware of. And definitely is not used to tackle within himself. This typically results in hits below the belt, grabbing whatever flies by to wield against the perceived enemy. It's about survival, which emotionally gives the right to lie, cheat, derise, exaggerate, and even sabotage. (Hey, it's the scared animal. What can I say.) Look at Microsoft reacting to Linux. The largest company doing what an individual would. FUD. ---- Oh, and you have to _earn_ your reputation with the big guys! A lot of promises is nice, but that only serves _within_ the D community, to keep our own morale up. Look at any physical hero film. The guy is laughed at till he whips the pack leader's ass.
 I'm interested to hear from people what their friends/colleagues/etc.
 think about D, especially in terms of whether they would be willing
 to use it come 1.0.

Friends: - Cool - There's both & and &&, so why f*ck everything up with bit?? - GC is not for systems work - Better docs, howtos, best practices - A complete distro would be cool! (I take this means DMD, dui, mango, db-io, docs, etc.)
 I'm also interested to hear of any specific must-haves that such 
 people have expressed.

Clients: - D bindings for Apache! - HTML creation framework (I guess for the above) - Servlet framework - Serialization! - Robust database connectivity - Full Eclipse integration - "Official" cross platform GUI library - Bit as boolean?????? - No string classes? - Library seems half-done, and haphazard (inconsistent naming, etc.) - Not for serious projects until native on Solaris! - GC with pauses!? (Heavier projects risk even larger pauses!) - No well documented success stories! Is D applied anywhere? - We need reliable and fast support. And pay for it. - No proper generics? - Not until competing suppliers of D. - We don't need a language with home-made docs. - We do business, so if it ain't 1.2 we don't even look at it. - Where's the list of commercial apps already on the market? - Failed casts return null? We need exceptions here! - Who says this language will be around in 2 years? - With new languages coming like a dozen a week, why D? - You say it's so good, why's there nothing big on Sourceforge?
 Please, everyone, don't turn this thread into what _you_ think about
 D, or what _you_ think should be in 1.0. We have a pretty good feel
 for what D-philes think already.

I've felt that the best line I've used is "There's enough work done in Java that should be done in C++, and that's where D really shines." Seems this phrase opens doors better than any of my others.
Apr 27 2005
prev sibling next sibling parent reply Jason Mills <jmills cs.mun.ca> writes:
Matthew wrote:
 I've read a couple of things recently that've indicated that D's not 
 taken seriously by the C++ world. I am wondering whether this is 
 true, since it's certainly not the impression that I've had from the 
 people I've spoken with about it, most of whom are not using it now, 
 but are definitely interested in doing so in the future; the 
 D-curious, if you like?
 
 I'm interested to hear from people what their 
 friends/colleagues/etc. think about D, especially in terms of 
 whether they would be willing to use it come 1.0.

Most of my colleagues think D is great, but it cannot be used for serious development until more "professional" libraries and tools are available. Some also like to see commercially supported libraries and tools. A good GUI library is a must. Currently they are content using Microsoft supported products. It well be hard to make a change until D is seen as a professional programming language. What does this mean? - Good tools. Of course this means a good IDE that can compete with Visual Studio. - Large collection of standard libraries (e.g. Java, .NET), not some hodge-podge of loosely collected libraries, half supported and half not. This *must* include a sexy GUI toolkit. - Wider use and support by the industry. E.g., if Microsoft supported D, it would be used tomorrow. - All above should be professionally documented.
 I'm also interested to hear of any specific must-haves that such 
 people have expressed.

See points above.
 Please, everyone, don't turn this thread into what _you_ think about 
 D, or what _you_ think should be in 1.0. We have a pretty good feel 
 for what D-philes think already.
 
 Cheers
 
 Matthew
 
 

Apr 27 2005
parent "Andreas Schmid" <monkey gmx.info> writes:
I totally agree. It needs a good IDE (a simple one that allows you to define 
projects and step through the source code/compile it is sufficient) to find 
more widespread use.

While everything can be done from the command line, it is an unneccessary 
burden that slows down development time significantly.

-Andreas

"Jason Mills" <jmills cs.mun.ca> wrote in message 
news:d4nvni$vt4$1 digitaldaemon.com...
 Matthew wrote:
 I've read a couple of things recently that've indicated that D's not 
 taken seriously by the C++ world. I am wondering whether this is true, 
 since it's certainly not the impression that I've had from the people 
 I've spoken with about it, most of whom are not using it now, but are 
 definitely interested in doing so in the future; the D-curious, if you 
 like?

 I'm interested to hear from people what their friends/colleagues/etc. 
 think about D, especially in terms of whether they would be willing to 
 use it come 1.0.

Most of my colleagues think D is great, but it cannot be used for serious development until more "professional" libraries and tools are available. Some also like to see commercially supported libraries and tools. A good GUI library is a must. Currently they are content using Microsoft supported products. It well be hard to make a change until D is seen as a professional programming language. What does this mean? - Good tools. Of course this means a good IDE that can compete with Visual Studio. - Large collection of standard libraries (e.g. Java, .NET), not some hodge-podge of loosely collected libraries, half supported and half not. This *must* include a sexy GUI toolkit. - Wider use and support by the industry. E.g., if Microsoft supported D, it would be used tomorrow. - All above should be professionally documented.
 I'm also interested to hear of any specific must-haves that such people 
 have expressed.

See points above.
 Please, everyone, don't turn this thread into what _you_ think about D, 
 or what _you_ think should be in 1.0. We have a pretty good feel for what 
 D-philes think already.

 Cheers

 Matthew
 


Apr 27 2005
prev sibling next sibling parent reply Matthias Becker <Matthias_member pathlink.com> writes:
Bad library, not even the basic collections you find everywhere. So D is
unusable in any kind of project.


A few C++ programmers see things like built in hash-tables and ask why the
languages is bloated with stuff like that, which could be done in the library
and then don't even give it a try.
Apr 27 2005
parent reply Vladimir <kv11111 mail.ru> writes:
Matthias Becker wrote:

 Bad library, not even the basic collections you find everywhere. So D is
 unusable in any kind of project.
 
 
 A few C++ programmers see things like built in hash-tables and ask why the
 languages is bloated with stuff like that, which could be done in the
 library and then don't even give it a try.

described here seems not convincingly for me. -- Vladimir
Apr 28 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Vladimir" <kv11111 mail.ru> wrote in message
news:d4qvmu$114p$2 digitaldaemon.com...
 Matthias Becker wrote:

 Bad library, not even the basic collections you find everywhere. So D is
 unusable in any kind of project.


 A few C++ programmers see things like built in hash-tables and ask why


 languages is bloated with stuff like that, which could be done in the
 library and then don't even give it a try.


 described here seems not convincingly for me.

The text can always be improved. What would be a convincing intro be for you?
Apr 28 2005
parent reply Vladimir <kv11111 mail.ru> writes:
Walter wrote:

 
 "Vladimir" <kv11111 mail.ru> wrote in message
 news:d4qvmu$114p$2 digitaldaemon.com...
 Matthias Becker wrote:

 Bad library, not even the basic collections you find everywhere. So D
 is unusable in any kind of project.


 A few C++ programmers see things like built in hash-tables and ask why


 languages is bloated with stuff like that, which could be done in the
 library and then don't even give it a try.


 described here seems not convincingly for me.

The text can always be improved. What would be a convincing intro be for you?

First informative link from front page is a link to comparation table. First look at this table shows that D has more features than others. But more detailed look shows that many of this features are not missing in other languages but raser implemented as libraries. Reasons for doing it in compiler are not described here. It's not obvious that moving a big part of library into compiler is good. Many people even convinced that this is evil, and have a reasons for it. So, if doing so, *very* *good* description of it's benefits must be written and placed just beside saying thad D has built-in dynamic and assosiative arrays. Without it a lot of C/C++ programmers just stop reading here. The most confusing section is about arrays. Reading page "D Strings vs C++ Strings" which is linked from here one can agree that C++ STL library is far from ideal, and some changes to compiler (such as adding overloadable ~ operator) are also helpful, but there is no reason to built-in library into compiler. As for me, more convincing points is possible optimizations, more standard implementation (no more difference between STL string, QT QString, and many others), reference semantics, but these all are at the bottom of the page. Absence of "How Garbage Collection Works" part is also bad. For many C/C++ programmers GC is associated with java/C# and VMs which are slow. Section "How Garbage Collection Works" is the only chance to be convinces that this really can be not-so-slow (especially for those who does not belive advertisements). May be adding this link: http://www.iecc.com/gclist/GC-faq.html and even this: ftp://ftp.cs.utexas.edu/pub/garbage/gcsurvey.ps would be helpful. -- Vladimir
Apr 29 2005
next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
Vladimir wrote:
 Walter wrote:

The text can always be improved. What would be a convincing intro be for
you?

First informative link from front page is a link to comparation table. First look at this table shows that D has more features than others. But more detailed look shows that many of this features are not missing in other languages but raser implemented as libraries. Reasons for doing it in compiler are not described here.

Listen, he admits in the first paragraph he's counting what's available in each language. Most people expect that the items in such a comparison list are going to be selected to favor the language being endorsed. Also, if someone has to be told that it might be a lot cooler to have a feature built-in as opposed to hacked-in, they may not be a programmer. I believe much of this has already been discussed to death back while Walter first released the comparison chart. ...
 The most confusing section is about arrays. Reading page "D Strings vs C++
 Strings" which is linked from here one can agree
 that C++ STL library is far from ideal, and some changes to compiler (such
 as adding overloadable ~ operator) are also helpful, but there is no reason
 to built-in library into compiler.
 As for me, more convincing points is possible optimizations, more standard
 implementation (no more difference between STL string, QT QString, and many
 others), reference semantics, but these all are at the bottom of the page.
 

 Absence of "How Garbage Collection Works" part is also bad. For many C/C++

Ah, the " To be written..." section on the garbage collection page (http://www.digitalmars.com/d/garbage.html). You're right -- it should either be filled in or dropped. If I had seen that before I forgot about it.
 programmers GC is associated with java/C# and VMs which are slow. Section
 "How Garbage Collection Works" is the only chance to be convinces that this
 really can be not-so-slow (especially for those who does not belive
 advertisements). May be adding this link:
 http://www.iecc.com/gclist/GC-faq.html
 and even this:
 ftp://ftp.cs.utexas.edu/pub/garbage/gcsurvey.ps
 would be helpful.

I think part of the animosity against GC is religious in nature and the only solution for such a problem is prayer by those who are adherents of the "one true religion". At least Microsoft is on our side now with GC. Every time one of their acolytes extols the virtue of "managed code" they're endorsing D. Here's a new slogan for D: "Get the nearly the same memory leak protection without requiring users to download the large .NET framework." ;) -- jcc7 http://jcc_7.tripod.com/d/
Apr 29 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
 First informative link from front page is a link to comparation 
 table. First
 look at this table shows that D has more features than others. 
 But more
 detailed look shows that many of this features are not missing in 
 other
 languages but raser implemented as libraries. Reasons for doing 
 it in
 compiler are not described here.

Listen, he admits in the first paragraph he's counting what's available in each language. Most people expect that the items in such a comparison list are going to be selected to favor the language being endorsed. Also, if someone has to be told that it might be a lot cooler to have a feature built-in as opposed to hacked-in, they may not be a programmer.

Wow! First, huge respect for misrepresenting Vladimir's contrasting of built-in vs libraries with the much more colourful and loaded "built-in as opposed to hacked-in". (I guess that's a useful tactic in debate when the foundation of your argument is built on sand.) Second, if you'll permit me a similar indulgence to re-re-write your response as "if someone has to be told that it might be a lot cooler to have a feature built-in as opposed to [in a library], they may not be a programmer", then I would have to address that by saying that's one of the most stupid things I think anyone's ever said on this newsgroup. Well done! Why don't you email Bjarn Stroustrup or Guido van Rossum, and see if they agree?
Apr 30 2005
parent J C Calvarese <jcc7 cox.net> writes:
Matthew wrote:
First informative link from front page is a link to comparation 
table. First
look at this table shows that D has more features than others. 
But more
detailed look shows that many of this features are not missing in 
other
languages but raser implemented as libraries. Reasons for doing 
it in
compiler are not described here.

Listen, he admits in the first paragraph he's counting what's available in each language. Most people expect that the items in such a comparison list are going to be selected to favor the language being endorsed. Also, if someone has to be told that it might be a lot cooler to have a feature built-in as opposed to hacked-in, they may not be a programmer.

Wow! First, huge respect for misrepresenting Vladimir's contrasting of built-in vs libraries with the much more colourful and loaded "built-in as opposed to hacked-in". (I guess that's a useful tactic in debate when the foundation of your argument is built on sand.) Second, if you'll permit me a similar indulgence to re-re-write your response as "if someone has to be told that it might be a lot cooler to have a feature built-in as opposed to [in a library], they may not be a programmer", then I would have to address that by saying that's one of the most stupid things I think anyone's ever said on this newsgroup. Well done! Why don't you email Bjarn Stroustrup or Guido van Rossum, and see if they agree?

I apologize to Vladimir if I misrepresented anything he wrote. I promise it was accidental. I guess I'm in over my head here. Sorry for wasting everyone's time. -- jcc7 http://jcc_7.tripod.com/d/
Apr 30 2005
prev sibling next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Vladimir" <kv11111 mail.ru> wrote in message 
news:d4tsjv$1ate$1 digitaldaemon.com...
 Walter wrote:

 "Vladimir" <kv11111 mail.ru> wrote in message
 news:d4qvmu$114p$2 digitaldaemon.com...
 Matthias Becker wrote:

 Bad library, not even the basic collections you find everywhere. So D
 is unusable in any kind of project.


 A few C++ programmers see things like built in hash-tables and ask why


 languages is bloated with stuff like that, which could be done in the
 library and then don't even give it a try.


 described here seems not convincingly for me.

The text can always be improved. What would be a convincing intro be for you?

First informative link from front page is a link to comparation table. First look at this table shows that D has more features than others. But more detailed look shows that many of this features are not missing in other languages but raser implemented as libraries. Reasons for doing it in compiler are not described here. It's not obvious that moving a big part of library into compiler is good. Many people even convinced that this is evil, and have a reasons for it. So, if doing so, *very* *good* description of it's benefits must be written and placed just beside saying thad D has built-in dynamic and assosiative arrays. Without it a lot of C/C++ programmers just stop reading here. The most confusing section is about arrays. Reading page "D Strings vs C++ Strings" which is linked from here one can agree that C++ STL library is far from ideal, and some changes to compiler (such as adding overloadable ~ operator) are also helpful, but there is no reason to built-in library into compiler. As for me, more convincing points is possible optimizations, more standard implementation (no more difference between STL string, QT QString, and many others), reference semantics, but these all are at the bottom of the page. Absence of "How Garbage Collection Works" part is also bad. For many C/C++ programmers GC is associated with java/C# and VMs which are slow. Section "How Garbage Collection Works" is the only chance to be convinces that this really can be not-so-slow (especially for those who does not belive advertisements). May be adding this link: http://www.iecc.com/gclist/GC-faq.html and even this: ftp://ftp.cs.utexas.edu/pub/garbage/gcsurvey.ps would be helpful.

I pretty much agree that the D web site could use more description for the pros and cons for certain design decisions. The sections comparing D with other languages could have a FAQ all its own that gives the rationale behind the decisions. We've had thread after thread about certain decisions and if Walter explained himself just once (or sometimes "at all") on the web site it would help stream-line the newsgroup discussion and it would help people coming from other languages understand the factors that led to the current design. Instead of this "rationale" page being aimed at pushing D it would take a balanced view of the issue and explain why the decision in D was what it was. It would help give a less "rah-rah" feel to the comparisons with other languages and make it more informative.
Apr 29 2005
parent J C Calvarese <jcc7 cox.net> writes:
Ben Hinkle wrote:
 "Vladimir" <kv11111 mail.ru> wrote in message 
 news:d4tsjv$1ate$1 digitaldaemon.com...

The text can always be improved. What would be a convincing intro be for
you?

First informative link from front page is a link to comparation table. First look at this table shows that D has more features than others. But more detailed look shows that many of this features are not missing in other languages but raser implemented as libraries. Reasons for doing it in compiler are not described here.


...
Absence of "How Garbage Collection Works" part is also bad. For many C/C++
programmers GC is associated with java/C# and VMs which are slow. Section
"How Garbage Collection Works" is the only chance to be convinces that 
this
really can be not-so-slow (especially for those who does not belive
advertisements). May be adding this link:
http://www.iecc.com/gclist/GC-faq.html
and even this:
ftp://ftp.cs.utexas.edu/pub/garbage/gcsurvey.ps
would be helpful.

I pretty much agree that the D web site could use more description for the pros and cons for certain design decisions. The sections comparing D with other languages could have a FAQ all its own that gives the rationale behind the decisions. We've had thread after thread about certain decisions and if Walter explained himself just once (or sometimes "at all") on the web site it would help stream-line the newsgroup discussion and it would help people coming from other languages understand the factors that led to the current design. Instead of this "rationale" page being aimed at pushing D it would take a balanced view of the issue and explain why the decision in D was what it was. It would help give a less "rah-rah" feel to the comparisons with other languages and make it more informative.

I think "if Walter explained himself just once (or sometimes 'at all') on the web site" vs. having the same argument on the newsgroup over-and-over again is an excellent point. Certainly some of the perpetual hot topics could be more thoroughly described in the web pages. On the other hand, some people seem to start posting complaints after reading only a couple paragraphs (perhaps my perspective is screwed up since I spent so much time as a lurker before I started posting). I think we'll alway have some people who would rather start arguing about how everything about D is wrong before they read the whole spec, but it would be good if the specification could highlight more of the deep thinking that went into the design of D. -- jcc7 http://jcc_7.tripod.com/d/
Apr 29 2005
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"Vladimir" <kv11111 mail.ru> wrote in message
news:d4tsjv$1ate$1 digitaldaemon.com...
 First informative link from front page is a link to comparation table.

 look at this table shows that D has more features than others. But more
 detailed look shows that many of this features are not missing in other
 languages but raser implemented as libraries. Reasons for doing it in
 compiler are not described here.

 It's not obvious that moving a big part of library into compiler is good.
 Many people even convinced that this is evil, and have a reasons for it.
 So, if doing so, *very* *good* description of it's benefits must be

 and placed just beside saying thad D has built-in dynamic and assosiative
 arrays. Without it a lot of C/C++ programmers just stop reading here.

I've added a new page to hopefully address this. Comments welcome. www.digitalmars.com/d/builtin.html
May 01 2005
prev sibling next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
news:d4mioc$2lgm$1 digitaldaemon.com...
 I've read a couple of things recently that've indicated that D's not taken 
 seriously by the C++ world. I am wondering whether this is true, since 
 it's certainly not the impression that I've had from the people I've 
 spoken with about it, most of whom are not using it now, but are 
 definitely interested in doing so in the future; the D-curious, if you 
 like?

 I'm interested to hear from people what their friends/colleagues/etc. 
 think about D, especially in terms of whether they would be willing to use 
 it come 1.0.

 I'm also interested to hear of any specific must-haves that such people 
 have expressed.

 Please, everyone, don't turn this thread into what _you_ think about D, or 
 what _you_ think should be in 1.0. We have a pretty good feel for what 
 D-philes think already.

 Cheers

 Matthew

I haven't met anyone know knows anything about it. When I describe it they don't seem particularly excited to give it a shot - I get the feeling people don't want to invest in an unknown language without some obvious reason. Then again most of the people I talked to either have a large investment in C++ or Java and are comfortable as they are. My own take is that people would be less hesitant to give it a shot if they saw how easy it is to convert Java/C++ code to D and/or if it became possible to mix D with projects that use C++ or Java. The ability to mix C++ with C was one reason why C++ became popular.
Apr 27 2005
parent reply Kevin Bealer <Kevin_member pathlink.com> writes:
In article <d4olba$1mav$1 digitaldaemon.com>, Ben Hinkle says...
<clip>
My own take is that people would be less hesitant to give it a shot if they 
saw how easy it is to convert Java/C++ code to D and/or if it became 
possible to mix D with projects that use C++ or Java. The ability to mix C++ 
with C was one reason why C++ became popular.

Yes, now that I think about it, he ability to call into C++ would be a huge advantage. Not as a put-down, but think about a programmer who thinks C++ is no better than C. What does D offer such a person? Or consider a hypothetical programmer/project who is likely to switch from C to D. If they are willing to switch from C to D, they will already have switched from C to C++, right? I understand why D can't call into C++ now (the many ABIs and manglings of C++), but I think it is not unsurmountable. D adoption could be 20 times faster if I could plug a C++ class into a D class. What should be written (just brainstorming, here..) is a way to "tunnel" D method calls into C++ method calls, possibly via generated C functions in the short term, maybe more directly/transparently at some point in the future. Kevin
Apr 27 2005
next sibling parent reply brad beveridge <brad nowhere.com> writes:
 What should be written (just brainstorming, here..) is a way to "tunnel" D
 method calls into C++ method calls, possibly via generated C functions in the
 short term, maybe more directly/transparently at some point in the future.
 
 Kevin
 

D has been integrated with SWIG ... from D links. "Andy Friesen has taken SWIG and modified it to generate code for D." SWIG is basically a C/C++ parser that generates code that allows many other languages to interface to C/C++. It produces very good proxy classes and function wrappers from what I have seen. Unfortuantly it isn't rolled into the official SWIG website. As with many things in D, the tools are 90% there, but are not official and have no maintainer. Brad
Apr 28 2005
parent reply Brad Beveridge <brad somewhere.net> writes:
John Demme wrote:
 The link on the D links page yields a 404.  Where's Andy's site
 nowadays?
 
 Also, is there a tutorial for this?
 
 John Demme
 
 On Thu, 2005-04-28 at 21:31 +1200, brad beveridge wrote:
 
What should be written (just brainstorming, here..) is a way to "tunnel" D
method calls into C++ method calls, possibly via generated C functions in the
short term, maybe more directly/transparently at some point in the future.

Kevin

D has been integrated with SWIG ... from D links. "Andy Friesen has taken SWIG and modified it to generate code for D." SWIG is basically a C/C++ parser that generates code that allows many other languages to interface to C/C++. It produces very good proxy classes and function wrappers from what I have seen. Unfortuantly it isn't rolled into the official SWIG website. As with many things in D, the tools are 90% there, but are not official and have no maintainer. Brad


think. If you can't find the download I think I may have it on my machine at home. Brad
Apr 28 2005
parent J C Calvarese <jcc7 cox.net> writes:
John Demme wrote:
 Looks like there's a copy from August 1st, 2004 on DSource.
 

Also, John Fletcher wrote up some tips here: http://www.prowiki.org/wiki4d/wiki.cgi?DwithSwig
 On Fri, 2005-04-29 at 09:17 +1200, Brad Beveridge wrote:
 
John Demme wrote:

The link on the D links page yields a 404.  Where's Andy's site
nowadays?

Also, is there a tutorial for this?

John Demme



-- jcc7 http://jcc_7.tripod.com/d/
Apr 29 2005
prev sibling parent reply "Charlie" <charles jwavro.com> writes:
 Or consider a hypothetical programmer/project who is likely to switch from

 D.  If they are willing to switch from C to D, they will already have

 from C to C++, right?

No, I know alot of C programmers that wont touch C++ ( hell most of them ? ) , particularly stuff heavy with calculations. Charlie "Kevin Bealer" <Kevin_member pathlink.com> wrote in message news:d4q10r$306i$1 digitaldaemon.com...
 In article <d4olba$1mav$1 digitaldaemon.com>, Ben Hinkle says...
 <clip>
My own take is that people would be less hesitant to give it a shot if


saw how easy it is to convert Java/C++ code to D and/or if it became
possible to mix D with projects that use C++ or Java. The ability to mix


with C was one reason why C++ became popular.

Yes, now that I think about it, he ability to call into C++ would be a

 advantage.  Not as a put-down, but think about a programmer who thinks C++

 better than C.  What does D offer such a person?

 Or consider a hypothetical programmer/project who is likely to switch from

 D.  If they are willing to switch from C to D, they will already have

 from C to C++, right?

 I understand why D can't call into C++ now (the many ABIs and manglings of

 but I think it is not unsurmountable.  D adoption could be 20 times faster

 could plug a C++ class into a D class.

 What should be written (just brainstorming, here..) is a way to "tunnel" D
 method calls into C++ method calls, possibly via generated C functions in

 short term, maybe more directly/transparently at some point in the future.

 Kevin

Apr 28 2005
parent Kevin Bealer <Kevin_member pathlink.com> writes:
In article <d4r1ki$14g8$1 digitaldaemon.com>, Charlie says...
 Or consider a hypothetical programmer/project who is likely to switch from

 D.  If they are willing to switch from C to D, they will already have

 from C to C++, right?

No, I know alot of C programmers that wont touch C++ ( hell most of them ? ) , particularly stuff heavy with calculations. Charlie

Sure. I know some myself. If it hurts more to read, it must be faster code, aka if it tastes bad, it must be medicine. But if they won't touch C++, they probably won't touch D either. Kevin
Apr 28 2005
prev sibling next sibling parent MicroWizard <MicroWizard_member pathlink.com> writes:
I'm also interested to hear of any specific must-haves that such 
people have expressed.

1.) Graphical IDE 2.) (object) library, almost complete applications, wizards 3.) Graphical debugger 4.) Big company behind it 5.) Lot of shiny things (I've never heard about it...) Tamas Nagy
Apr 27 2005
prev sibling next sibling parent reply Benjamin Herr <ben 0x539.de> writes:
Matthew wrote:
 I'm interested to hear from people what their 
 friends/colleagues/etc. think about D, especially in terms of 
 whether they would be willing to use it come 1.0.

A friend of mine, who mostly codes C++, considers it too close to Java (the casing does not help at all there ;). He would be missing all the "powerful" C++ control that gets taken away from him - manual memory management, class instances on the stack, multiple inheritance. He also thinks it is inconsistent to have (object) reference types and value types with no difference in syntax. I guess he does not like the shift of paradigms - he is also very sceptical of Ruby, and has fun writing things in pointer-mangling C. Another friend of mine (yes, I really have more than one) thinks that D is pointless because it does not solve any real problems. He considers C++ the (currently, I think) best compromise between power and elegance.
Apr 27 2005
next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Benjamin Herr wrote:
 He also thinks it is inconsistent to have (object)
 reference types and value types with no difference in syntax.

Hmm. This has stuck in my eye before. Somehow, though, I haven't been able to formulate any specific complaint about it. It's just a gut feeling: "this is not good".
Apr 27 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:42702E24.90904 nospam.org...
 Benjamin Herr wrote:
 He also thinks it is inconsistent to have (object)
 reference types and value types with no difference in syntax.

Hmm. This has stuck in my eye before. Somehow, though, I haven't been able to formulate any specific complaint about it. It's just a gut feeling: "this is not good".

I have much the same feeling. My gut's usually right - and I believe it is in this case - but it can be somewhat ungenerous with its explanations. ;)
Apr 27 2005
parent reply Vladimir <kv11111 mail.ru> writes:
Matthew wrote:

 
 "Georg Wrede" <georg.wrede nospam.org> wrote in message
 news:42702E24.90904 nospam.org...
 Benjamin Herr wrote:
 He also thinks it is inconsistent to have (object)
 reference types and value types with no difference in syntax.

Hmm. This has stuck in my eye before. Somehow, though, I haven't been able to formulate any specific complaint about it. It's just a gut feeling: "this is not good".

I have much the same feeling. My gut's usually right - and I believe it is in this case - but it can be somewhat ungenerous with its explanations. ;)

-- Vladimir
Apr 28 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Vladimir" <kv11111 mail.ru> wrote in message 
news:d4qvgs$114p$1 digitaldaemon.com...
 Matthew wrote:

 "Georg Wrede" <georg.wrede nospam.org> wrote in message
 news:42702E24.90904 nospam.org...
 Benjamin Herr wrote:
 He also thinks it is inconsistent to have (object)
 reference types and value types with no difference in syntax.

Hmm. This has stuck in my eye before. Somehow, though, I haven't been able to formulate any specific complaint about it. It's just a gut feeling: "this is not good".

I have much the same feeling. My gut's usually right - and I believe it is in this case - but it can be somewhat ungenerous with its explanations. ;)

-- Vladimir

MATLAB uses "." independent of value/reference semantics and it works fine. The difference between value/reference only shows up in assignment behavior (which is the definition of value/reference anyway). But then MATLAB also doesn't have pointers.
Apr 28 2005
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Ben Hinkle wrote:
 "Vladimir" <kv11111 mail.ru> wrote in message 
 news:d4qvgs$114p$1 digitaldaemon.com...
 
Matthew wrote:


"Georg Wrede" <georg.wrede nospam.org> wrote in message
news:42702E24.90904 nospam.org...

Benjamin Herr wrote:

He also thinks it is inconsistent to have (object)
reference types and value types with no difference in syntax.

Hmm. This has stuck in my eye before. Somehow, though, I haven't been able to formulate any specific complaint about it. It's just a gut feeling: "this is not good".

I have much the same feeling. My gut's usually right - and I believe it is in this case - but it can be somewhat ungenerous with its explanations. ;)

I has the same feeling too. -- Vladimir

MATLAB uses "." independent of value/reference semantics and it works fine. The difference between value/reference only shows up in assignment behavior (which is the definition of value/reference anyway). But then MATLAB also doesn't have pointers.

IMHO, getting rid of -> and just using . was a good idea, but that is a different question. I, like the others (it's nice to know I'm not alone) don't like the current syntax. I've stated before my beefs with it: 1) Makes it hard to write a template that handles both struct pointers and object references correctly. 2) Leads to a very common newbie error: segfault because he used an uninitialized class reference. (If we had used C++ syntax, then Java programmers would have had a learning curve...but their error would be caught at build time, not as a runtime error, which, IMHO, is far superior) 3) Made it so that class objects can't be on the stack. Let's be honest, here, the whole reason that we have 'auto' is a kludge to get around the syntax problem. 4) Invited confusion over === and == Don't get me wrong - I still use D all the time. Except for work, I don't even touch C and C++ anymore. But if I ever write D++, this will be one thing that I will change. :)
Apr 28 2005
next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
 MATLAB uses "." independent of value/reference semantics and it works 
 fine. The difference between value/reference only shows up in assignment 
 behavior (which is the definition of value/reference anyway). But then 
 MATLAB also doesn't have pointers.

IMHO, getting rid of -> and just using . was a good idea, but that is a different question. I, like the others (it's nice to know I'm not alone) don't like the current syntax. I've stated before my beefs with it: 1) Makes it hard to write a template that handles both struct pointers and object references correctly.

I'm not sure what you are referring to. Can you give a pointer to a post or examples?
 2) Leads to a very common newbie error: segfault because he used an 
 uninitialized class reference.  (If we had used C++ syntax, then Java 
 programmers would have had a learning curve...but their error would be 
 caught at build time, not as a runtime error, which, IMHO, is far 
 superior)

IMO better segv than slicing objects passed by value. Any non-trivial class hierarchy is destined to be manipulated by reference.
 3) Made it so that class objects can't be on the stack.  Let's be honest, 
 here, the whole reason that we have 'auto' is a kludge to get around the 
 syntax problem.

I'm with Walter (and Java/C#) that class objects on the stack should be rare. If there are issues with structs that require lots of auto classes then structs need attention. Actually auto classes don't have anything to do with being on the stack - they just force the dtor to be called on scope exit. IMO I haven't seen a D class that should be auto (I've seen good uses auto variables but declaring a class as auto forces all uses to be auto).
 4) Invited confusion over === and ==

Agreed - though the current design isn't unreasonable in the big picture.
Apr 28 2005
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Ben Hinkle wrote:
MATLAB uses "." independent of value/reference semantics and it works 
fine. The difference between value/reference only shows up in assignment 
behavior (which is the definition of value/reference anyway). But then 
MATLAB also doesn't have pointers.

IMHO, getting rid of -> and just using . was a good idea, but that is a different question. I, like the others (it's nice to know I'm not alone) don't like the current syntax. I've stated before my beefs with it: 1) Makes it hard to write a template that handles both struct pointers and object references correctly.

I'm not sure what you are referring to. Can you give a pointer to a post or examples?

Say that you want to store a pointer to a type in a template struct. Do you do this? struct RefTo(T) { T reference; } which works for classes, or this struct RefTo(T) { T *pointer; } which works for structs? Sure, you can do specialized templates, but that's a kludge to work around the problem, IMHO.
2) Leads to a very common newbie error: segfault because he used an 
uninitialized class reference.  (If we had used C++ syntax, then Java 
programmers would have had a learning curve...but their error would be 
caught at build time, not as a runtime error, which, IMHO, is far 
superior)

IMO better segv than slicing objects passed by value. Any non-trivial class hierarchy is destined to be manipulated by reference.

I half agree and half disagree. I think that Walter made a very good point when he said that copy constructors are trouble; you are making a similar point by saying that we don't want to pass objects by value. So why not just ban passing classes by value? That is, the following code would be illegal: class Foo {}; int myFunc(Foo pass_by_value) {...} it would give an error: ERROR: Class objects cannot be passed by value. They must be passed by pointer instead. Likewise, any code that required copying a class by value would be illegal. Offhand, I can think of: * Class values as function parameters * Class values as function return values * Direct object assignments
3) Made it so that class objects can't be on the stack.  Let's be honest, 
here, the whole reason that we have 'auto' is a kludge to get around the 
syntax problem.

I'm with Walter (and Java/C#) that class objects on the stack should be rare. If there are issues with structs that require lots of auto classes then structs need attention. Actually auto classes don't have anything to do with being on the stack - they just force the dtor to be called on scope exit. IMO I haven't seen a D class that should be auto (I've seen good uses auto variables but declaring a class as auto forces all uses to be auto).

I agree that the vast majority of class objects should be on the heap. But why require it? BTW, similar to this is the problem that you can't have a global class object without having to initialize it in an init() function.
4) Invited confusion over === and ==

Agreed - though the current design isn't unreasonable in the big picture.

:)
Apr 29 2005
next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message 
news:d4tgj7$usv$1 digitaldaemon.com...
 Ben Hinkle wrote:
MATLAB uses "." independent of value/reference semantics and it works 
fine. The difference between value/reference only shows up in assignment 
behavior (which is the definition of value/reference anyway). But then 
MATLAB also doesn't have pointers.

IMHO, getting rid of -> and just using . was a good idea, but that is a different question. I, like the others (it's nice to know I'm not alone) don't like the current syntax. I've stated before my beefs with it: 1) Makes it hard to write a template that handles both struct pointers and object references correctly.

I'm not sure what you are referring to. Can you give a pointer to a post or examples?

Say that you want to store a pointer to a type in a template struct. Do you do this? struct RefTo(T) { T reference; } which works for classes, or this struct RefTo(T) { T *pointer; } which works for structs? Sure, you can do specialized templates, but that's a kludge to work around the problem, IMHO.

When you said "template that handles struct pointer and objects refs" I thought you meant struct RefTo(T) { T bar; } RefTo!(Object) blah; RefTo!(MyStruct*) blah2; The same template RefTo should be usable by anything with reference semantics (which both struct ptrs and object refs have). I agree sometimes you have to write two templates if you want to use it both with a type with value semantics and with a type with reference semantics. But that's only logical. For the particular case of "RefTo" I'm not sure what the point is but I'd say leave it as one template and make users explicitly take a reference to the structs since that's how structs in D behave - trying to make D structs act like they have reference semantics will result in confusing and clunky code IMO.
2) Leads to a very common newbie error: segfault because he used an 
uninitialized class reference.  (If we had used C++ syntax, then Java 
programmers would have had a learning curve...but their error would be 
caught at build time, not as a runtime error, which, IMHO, is far 
superior)

IMO better segv than slicing objects passed by value. Any non-trivial class hierarchy is destined to be manipulated by reference.

I half agree and half disagree. I think that Walter made a very good point when he said that copy constructors are trouble; you are making a similar point by saying that we don't want to pass objects by value. So why not just ban passing classes by value? That is, the following code would be illegal: class Foo {}; int myFunc(Foo pass_by_value) {...} it would give an error: ERROR: Class objects cannot be passed by value. They must be passed by pointer instead. Likewise, any code that required copying a class by value would be illegal. Offhand, I can think of: * Class values as function parameters * Class values as function return values * Direct object assignments

That is an option but I think it would be one of last resort. A type should be usable by itself - if taking pointers to something is required in order to make it useful then that should be built into the type. Also by building reference semantics into object you avoid silly typedefs like typedef Window_t* Window; I dislike C/C++ code that hides pointers behind typedefs. The typedef only becomes usable when it has some obvious naming convention like WindowRef and at that point WindowRef is pretty much the same as Window_t* so why bother.
3) Made it so that class objects can't be on the stack.  Let's be honest, 
here, the whole reason that we have 'auto' is a kludge to get around the 
syntax problem.

I'm with Walter (and Java/C#) that class objects on the stack should be rare. If there are issues with structs that require lots of auto classes then structs need attention. Actually auto classes don't have anything to do with being on the stack - they just force the dtor to be called on scope exit. IMO I haven't seen a D class that should be auto (I've seen good uses auto variables but declaring a class as auto forces all uses to be auto).

I agree that the vast majority of class objects should be on the heap. But why require it?

Make the most common use cases easy and the rest reasonable and you'll have happy users. Conceptual baggage from other languages is a concern but it can be handled through documentation and examples comparing one to the other.
 BTW, similar to this is the problem that you can't have a global class 
 object without having to initialize it in an init() function.

4) Invited confusion over === and ==

Agreed - though the current design isn't unreasonable in the big picture.

:)

Apr 29 2005
next sibling parent reply Vladimir <kv11111 mail.ru> writes:
Ben Hinkle wrote:

 
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:d4tgj7$usv$1 digitaldaemon.com...
 Ben Hinkle wrote:
MATLAB uses "." independent of value/reference semantics and it works
fine. The difference between value/reference only shows up in
assignment behavior (which is the definition of value/reference
anyway). But then MATLAB also doesn't have pointers.

IMHO, getting rid of -> and just using . was a good idea, but that is a different question. I, like the others (it's nice to know I'm not alone) don't like the current syntax. I've stated before my beefs with it: 1) Makes it hard to write a template that handles both struct pointers and object references correctly.

I'm not sure what you are referring to. Can you give a pointer to a post or examples?

Say that you want to store a pointer to a type in a template struct. Do you do this? struct RefTo(T) { T reference; } which works for classes, or this struct RefTo(T) { T *pointer; } which works for structs? Sure, you can do specialized templates, but that's a kludge to work around the problem, IMHO.

When you said "template that handles struct pointer and objects refs" I thought you meant struct RefTo(T) { T bar; } RefTo!(Object) blah; RefTo!(MyStruct*) blah2; The same template RefTo should be usable by anything with reference semantics (which both struct ptrs and object refs have). I agree sometimes you have to write two templates if you want to use it both with a type with value semantics and with a type with reference semantics. But that's only logical. For the particular case of "RefTo" I'm not sure what the point is but I'd say leave it as one template and make users explicitly take a reference to the structs since that's how structs in D behave - trying to make D structs act like they have reference semantics will result in confusing and clunky code IMO.
2) Leads to a very common newbie error: segfault because he used an
uninitialized class reference.  (If we had used C++ syntax, then Java
programmers would have had a learning curve...but their error would be
caught at build time, not as a runtime error, which, IMHO, is far
superior)

IMO better segv than slicing objects passed by value. Any non-trivial class hierarchy is destined to be manipulated by reference.

I half agree and half disagree. I think that Walter made a very good point when he said that copy constructors are trouble; you are making a similar point by saying that we don't want to pass objects by value. So why not just ban passing classes by value? That is, the following code would be illegal: class Foo {}; int myFunc(Foo pass_by_value) {...} it would give an error: ERROR: Class objects cannot be passed by value. They must be passed by pointer instead. Likewise, any code that required copying a class by value would be illegal. Offhand, I can think of: * Class values as function parameters * Class values as function return values * Direct object assignments

That is an option but I think it would be one of last resort. A type should be usable by itself - if taking pointers to something is required in order to make it useful then that should be built into the type. Also by building reference semantics into object you avoid silly typedefs like typedef Window_t* Window; I dislike C/C++ code that hides pointers behind typedefs. The typedef only becomes usable when it has some obvious naming convention like WindowRef and at that point WindowRef is pretty much the same as Window_t* so why bother.
3) Made it so that class objects can't be on the stack.  Let's be
honest, here, the whole reason that we have 'auto' is a kludge to get
around the syntax problem.

I'm with Walter (and Java/C#) that class objects on the stack should be rare. If there are issues with structs that require lots of auto classes then structs need attention. Actually auto classes don't have anything to do with being on the stack - they just force the dtor to be called on scope exit. IMO I haven't seen a D class that should be auto (I've seen good uses auto variables but declaring a class as auto forces all uses to be auto).

I agree that the vast majority of class objects should be on the heap. But why require it?

Make the most common use cases easy and the rest reasonable and you'll have happy users.

make hard-to-find bugs. This is why constructions like if(x=y) does not allowed in D. In my opinion reference/value ambiguous introduces such cases. One can use RefTo!(MyStruct) by mistake - compiler will say nothing. One can try to pass class for template designed for value-types - compiler will say nothing. One can forget about COW technology - compiler will say nothing. (BTW, can one write a transparent COW wrapper for dynamic arrays in D ? In C++ this is easy). Just imagine how many work must be done to convert existing struct into class or vise versa. And compiler will never help here.
 Conceptual baggage from other languages is a concern but 
 it can be handled through documentation and examples comparing one to the
 other.

 
 BTW, similar to this is the problem that you can't have a global class
 object without having to initialize it in an init() function.

4) Invited confusion over === and ==

Agreed - though the current design isn't unreasonable in the big picture.

:)


-- Vladimir
Apr 29 2005
next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
 I agree that the vast majority of class objects should be on the heap.
 But why require it?

Make the most common use cases easy and the rest reasonable and you'll have happy users.

make hard-to-find bugs. This is why constructions like if(x=y) does not allowed in D. In my opinion reference/value ambiguous introduces such cases.

Sure that's legit opinion to have, but one has to weigh the upsides vs the downsides and on Walter's balance the upsides outweigh the downsides. Other people will use different weights and considerations and have different conclusions.
 One can use RefTo!(MyStruct) by mistake - compiler will say nothing.
 One can try to pass class for template designed for value-types - compiler
 will say nothing.

It will say nothing if the template makes sense - it depends on the template. Some would say it's a feature to allow templates to take any type and as long as it compiles it is ok. Restricting template parameters allows more control if the template author wishes.
 One can forget about COW technology - compiler will say nothing.

It's a trade-off, that's true. Sometimes you want COW and sometimes you don't.
 (BTW, can one write a transparent COW wrapper for dynamic arrays in D ? In
 C++ this is easy).

I assume you are referring to the lack of overloadable assignment to keep track of reference counts, corrent? To me that's a slightly different issue than reference/value semantics. Besides with dynamic arrays sometimes one wants to explicitly not use COW (eg filling in a buffer supplied to a function). Will D someday get some sort of overloadable assignment? Who knows - I personally don't have a strong argument against it but then again I don't miss it.
 Just imagine how many work must be done to convert existing struct into
 class or vise versa. And compiler will never help here.

I'm not sure what you mean here. Do you mean convert an existing C++ struct/class to D? Or do you mean a D struct that later becomes a class? I've found it's very easy to replace things like MyStruct* with MyClass or vice versa. Anything that uses MyStruct with value semantics needs attention when converted to using reference semantics but that's to be expected since that's pretty much the whole points of structs vs classes.
Apr 29 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Ben Hinkle" <bhinkle mathworks.com> wrote in message
news:d4trd3$19v9$1 digitaldaemon.com...
 I assume you are referring to the lack of overloadable assignment to keep
 track of reference counts, corrent? To me that's a slightly different

 than reference/value semantics. Besides with dynamic arrays sometimes one
 wants to explicitly not use COW (eg filling in a buffer supplied to a
 function). Will D someday get some sort of overloadable assignment? Who
 knows - I personally don't have a strong argument against it but then

 I don't miss it.

Overloadable assignment, and its cousins the copy constructor and move constructor, are the source of much of the complicated grief in C++ programs. The primary (in fact, only from what I've seen) use for them is to manage memory. This is one major area where automatic memory management really cleans up and simplifies code. All that drudgery and complexity just goes away.
Apr 29 2005
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:
 Overloadable assignment, and its cousins the copy constructor and move
 constructor, are the source of much of the complicated grief in C++
 programs. The primary (in fact, only from what I've seen) use for them is to
 manage memory. This is one major area where automatic memory management
 really cleans up and simplifies code. All that drudgery and complexity just
 goes away.

Agreed. I think it's a forgone conclusion that this decision is not going to change in D; there's too much code that uses reference semantics. And we've found solutions to just about all of the problems that it causes. I'm curious, however, whether (in retrospect) you have changed your mind? Specifically, I'm contrasting my proposal (use value semantics, but put limitations on class objects, to avoid the sorts of pitfalls you describe above) to the current D design. If you were starting over today, which do you think you might choose?
Apr 29 2005
parent "Walter" <newshound digitalmars.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:d4uv7o$28c2$1 digitaldaemon.com...
 I think it's a forgone conclusion that this decision is not going to
 change in D; there's too much code that uses reference semantics.  And
 we've found solutions to just about all of the problems that it causes.
   I'm curious, however, whether (in retrospect) you have changed your
 mind?  Specifically, I'm contrasting my proposal (use value semantics,
 but put limitations on class objects, to avoid the sorts of pitfalls you
 describe above) to the current D design.  If you were starting over
 today, which do you think you might choose?

I think the way it is is pretty good.
Apr 30 2005
prev sibling parent reply Kevin Bealer <Kevin_member pathlink.com> writes:
In article <d4tod4$16rb$1 digitaldaemon.com>, Vladimir says...
..
One can forget about COW technology - compiler will say nothing.
(BTW, can one write a transparent COW wrapper for dynamic arrays in D ? In
C++ this is easy).
Just imagine how many work must be done to convert existing struct into
class or vise versa. And compiler will never help here.

          Vladimir

Would anyone be interested in a COW array class? I've written one. It was part of a discontinued STL like code base. (This is why I wanted opIndexMutable()). I stopped working on after I saw that MinTL does most of the same work plus a lot more, but this class (called "BrittleVector") was not duplicated by MinTL AFAIK. It just keeps a bit and does .dup on non-read-only operations. I think it is safe for many or all combinations of slice sharing. But it is very conservative about copying -- it copies whenever a change may happen. You can do this: BrittleVector array1 = ..; (fill arrays) BrittleVector array2 = new BrittleVector(array2); while(array2[0] == 0) array2.popFront() while(array2[array2.length-1] == 0) array2.popBack() if (array2[0] == 1) { // No duplication unless you get here. array2.pushBack(array2[0]); } Insert, erase, etc are implemented, plus pretty thorough unit testing. (Ben, would you like this for MinTL? Or anyone else writing a collection..) Kevin
May 03 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Kevin Bealer" <Kevin_member pathlink.com> wrote in message 
news:d59q6m$18o1$1 digitaldaemon.com...
 In article <d4tod4$16rb$1 digitaldaemon.com>, Vladimir says...
 ..
One can forget about COW technology - compiler will say nothing.
(BTW, can one write a transparent COW wrapper for dynamic arrays in D ? In
C++ this is easy).
Just imagine how many work must be done to convert existing struct into
class or vise versa. And compiler will never help here.

          Vladimir

Would anyone be interested in a COW array class? I've written one. It was part of a discontinued STL like code base. (This is why I wanted opIndexMutable()). I stopped working on after I saw that MinTL does most of the same work plus a lot more, but this class (called "BrittleVector") was not duplicated by MinTL AFAIK. It just keeps a bit and does .dup on non-read-only operations. I think it is safe for many or all combinations of slice sharing. But it is very conservative about copying -- it copies whenever a change may happen.

 (Ben, would you like this for MinTL?  Or anyone else writing a 
 collection..)

I think it's too inefficient to dup on every modification so for now MinTL will assume users manage their own COW if needed. I'll keep it in mind, though.
May 04 2005
parent Kevin Bealer <Kevin_member pathlink.com> writes:
In article <d5apen$273n$1 digitaldaemon.com>, Ben Hinkle says...
"Kevin Bealer" <Kevin_member pathlink.com> wrote in message 
news:d59q6m$18o1$1 digitaldaemon.com...
 In article <d4tod4$16rb$1 digitaldaemon.com>, Vladimir says...
 ..
One can forget about COW technology - compiler will say nothing.
(BTW, can one write a transparent COW wrapper for dynamic arrays in D ? In
C++ this is easy).
Just imagine how many work must be done to convert existing struct into
class or vise versa. And compiler will never help here.

          Vladimir

Would anyone be interested in a COW array class? I've written one. It was part of a discontinued STL like code base. (This is why I wanted opIndexMutable()). I stopped working on after I saw that MinTL does most of the same work plus a lot more, but this class (called "BrittleVector") was not duplicated by MinTL AFAIK. It just keeps a bit and does .dup on non-read-only operations. I think it is safe for many or all combinations of slice sharing. But it is very conservative about copying -- it copies whenever a change may happen.

 (Ben, would you like this for MinTL?  Or anyone else writing a 
 collection..)

I think it's too inefficient to dup on every modification so for now MinTL will assume users manage their own COW if needed. I'll keep it in mind, though.

Sharing sets a "brittle" bit in both objects. It only does a dup if the shared bit is set, and duping clear the bit. If you then modify each object ten times, you get two .dup() operations, not twenty. A true COW implementation would probably keep a refcount and do only one dup, though. In my scheme the original array becomes garbage if you modify both objects. You could probably implement this from this description more easily than reading all my code. My design was by analogy with the "std.string" functions (ie toupper) that return the original if the data is already uppercase. You can "copy" a brittle vector almost for free, then pass it into a function, and it only dups it if the data actually changes. This would be good for "delete_if" type operation. (Unfortunately, "foreach()" is a mutable operation in D.) Kevin
May 04 2005
prev sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Ben Hinkle wrote:
I half agree and half disagree.  I think that Walter made a very good 
point when he said that copy constructors are trouble; you are making a 
similar point by saying that we don't want to pass objects by value.

So why not just ban passing classes by value?  That is, the following code 
would be illegal:
class Foo {};
int myFunc(Foo pass_by_value) {...}
it would give an error:
ERROR: Class objects cannot be passed by value.
They must be passed by pointer instead.

Likewise, any code that required copying a class by value would be 
illegal.  Offhand, I can think of:
* Class values as function parameters
* Class values as function return values
* Direct object assignments

That is an option but I think it would be one of last resort. A type should be usable by itself - if taking pointers to something is required in order to make it useful then that should be built into the type. Also by building reference semantics into object you avoid silly typedefs like typedef Window_t* Window; I dislike C/C++ code that hides pointers behind typedefs. The typedef only becomes usable when it has some obvious naming convention like WindowRef and at that point WindowRef is pretty much the same as Window_t* so why bother.

I agree, I hate those types of typedefs. But aren't you advocating exactly that by advocating reference semantics? What is the difference, from a practical point of view, between (In a value-semantics language) class Window_t {}; typedef Window_t* Window; and (In a reference-semantics language) class Window {}; Aren't we doing the same thing in both cases?
Apr 29 2005
parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message 
news:d4u49n$1ioj$1 digitaldaemon.com...
 Ben Hinkle wrote:
I half agree and half disagree.  I think that Walter made a very good 
point when he said that copy constructors are trouble; you are making a 
similar point by saying that we don't want to pass objects by value.

So why not just ban passing classes by value?  That is, the following 
code would be illegal:
class Foo {};
int myFunc(Foo pass_by_value) {...}
it would give an error:
ERROR: Class objects cannot be passed by value.
They must be passed by pointer instead.

Likewise, any code that required copying a class by value would be 
illegal.  Offhand, I can think of:
* Class values as function parameters
* Class values as function return values
* Direct object assignments

That is an option but I think it would be one of last resort. A type should be usable by itself - if taking pointers to something is required in order to make it useful then that should be built into the type. Also by building reference semantics into object you avoid silly typedefs like typedef Window_t* Window; I dislike C/C++ code that hides pointers behind typedefs. The typedef only becomes usable when it has some obvious naming convention like WindowRef and at that point WindowRef is pretty much the same as Window_t* so why bother.

I agree, I hate those types of typedefs. But aren't you advocating exactly that by advocating reference semantics? What is the difference, from a practical point of view, between (In a value-semantics language) class Window_t {}; typedef Window_t* Window; and (In a reference-semantics language) class Window {}; Aren't we doing the same thing in both cases?

To me the expectations are different. Since C/C++ doesn't have any reference-semantics classes hiding the reference behind a typedef is not expected. But in languages where references are implicit it becomes expected and so it is less of a problem (unless someone avoids classes and uses a struct where they should use a class or vice-versa). But I agree that it is true an identifier without any context doesn't give any more information about value/reference semantics in D than a typedef does in C++. So in C when I see a type without a ptr I assume it is value based and get annoyed when the typedef hides it but in D one can't assume the type is value based so I have to rely on a guess based on the name or look up the definition. Usually that's enough.
Apr 29 2005
prev sibling parent reply "Uwe Salomon" <post uwesalomon.de> writes:
 Say that you want to store a pointer to a type in a template struct.  Do  
 you do this?
 	struct RefTo(T) {
 	  T reference;
 	}
 which works for classes, or this
 	struct RefTo(T) {
 	  T *pointer;
 	}
 which works for structs?  Sure, you can do specialized templates, but  
 that's a kludge to work around the problem, IMHO.

You declare this: /// brief Struct with reference. /// /// Dear user. Please use only reference types /// (objects or pointers) for T. Thank you. /// struct RefTo(T) { T reference; } And then this: class Klasse { ... } struct Struktur { ... } RefTo!(Klasse) klasseRef; RefTo!(Struktur*) strukturRef; Does even have the same semantics: klasseRef.store(new Klasse); strukturRef.store(new Struktur); Ciao uwe
Apr 29 2005
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Uwe Salomon" <post uwesalomon.de> wrote in message
news:op.spz368oi6yjbe6 sandmann.maerchenwald.net...
 You declare this:

 ///  brief Struct with reference.
 ///
 /// Dear user. Please use only reference types
 /// (objects or pointers) for T. Thank you.
 ///
 struct RefTo(T)
 {
    T reference;
 }

You can build that restriction into the template! struct RefTo(T:Object) { T reference; } struct RefTo(T: T*) { T* reference; } RefTo!(int *) X; // works RefTo!(int) Y; // fails
Apr 29 2005
parent "Uwe Salomon" <post uwesalomon.de> writes:
 ///  brief Struct with reference.
 ///
 /// Dear user. Please use only reference types
 /// (objects or pointers) for T. Thank you.
 ///
 struct RefTo(T)
 {
    T reference;
 }

You can build that restriction into the template! struct RefTo(T:Object) { T reference; } struct RefTo(T: T*) { T* reference; } RefTo!(int *) X; // works RefTo!(int) Y; // fails

Yes, but it is annoying for larger templates to define it twice if most of the functions are the same. But one could use a "restricting sub-template": template UseOnlyPointersForRefTo(T : Object) {} template UseOnlyPointersForRefTo(T : T*) {} struct RefTo(T) { private: T m_data; // Dear user: If this fails, then you did not use an Object or // a pointer as type T. mixin UseOnlyPointersForRefTo!(T); public: // Lots of lengthy functions... } By the way, mixins are great! Ciao uwe
Apr 29 2005
prev sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Uwe Salomon wrote:
 Say that you want to store a pointer to a type in a template struct.  
 Do  you do this?
     struct RefTo(T) {
       T reference;
     }
 which works for classes, or this
     struct RefTo(T) {
       T *pointer;
     }
 which works for structs?  Sure, you can do specialized templates, but  
 that's a kludge to work around the problem, IMHO.

You declare this: /// brief Struct with reference. /// /// Dear user. Please use only reference types /// (objects or pointers) for T. Thank you. /// struct RefTo(T) { T reference; } And then this: class Klasse { ... } struct Struktur { ... } RefTo!(Klasse) klasseRef; RefTo!(Struktur*) strukturRef; Does even have the same semantics: klasseRef.store(new Klasse); strukturRef.store(new Struktur);

Sure. I didn't mean to imply that you could not. But your solution then forces this complexity throughout all other types which use the template. Say that you had some other templates: struct Foo(T) { RefTo!(T) ref; } struct Bar(T) { Foo!(T) foo; } struct Baz(T) { Bar!(T) bar; } Now, you have to percolate the restriction all the way up to the Baz template.
Apr 29 2005
prev sibling parent reply J C Calvarese <jcc7 cox.net> writes:
Russ Lewis wrote:
 Don't get me wrong - I still use D all the time.  Except for work, I 
 don't even touch C and C++ anymore.  But if I ever write D++, this will 
 be one thing that I will change. :)

Sorry to break it to you, but someone has already written D++. In fact, it's already at version 4.1. ;) Perhaps D# is still available as a name. D++: http://www.pagemac.com/dpp/index.php What is D++? D++ is a scripting language programmed in Microsoft Visual Basic 6... you know what? I think I've already written this. Perhaps you should all the info on the about page, as it's far more detailed than this is going to get. (From the D++ FAQ) (By the way, I just found out about D++ today due to its link at http://www.kochandreas.com/home/language/matrix.htm. I wonder how many more people might stumble upon D if it were listed.) -- jcc7 http://jcc_7.tripod.com/d/
Apr 29 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"J C Calvarese" <jcc7 cox.net> wrote in message
news:d4u50k$1jcg$1 digitaldaemon.com...
 (By the way, I just found out about D++ today due to its link at
 http://www.kochandreas.com/home/language/matrix.htm. I wonder how many
 more people might stumble upon D if it were listed.)

Amusingly, that page says it was last updated in October of 2005.
Apr 29 2005
next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
Walter wrote:
 "J C Calvarese" <jcc7 cox.net> wrote in message
 news:d4u50k$1jcg$1 digitaldaemon.com...
 
(By the way, I just found out about D++ today due to its link at
http://www.kochandreas.com/home/language/matrix.htm. I wonder how many
more people might stumble upon D if it were listed.)

Amusingly, that page says it was last updated in October of 2005.

LOL At first, I thought the same thing until I remembered that in some places in the world "10.04.2005" means April 10, 2005. But you're just kidding, right? -- jcc7 http://jcc_7.tripod.com/d/
Apr 29 2005
parent reply a lurker <a_member pathlink.com> writes:
In article <d4ulbu$21gh$1 digitaldaemon.com>, J C Calvarese says...
Walter wrote:
 "J C Calvarese" <jcc7 cox.net> wrote in message
 news:d4u50k$1jcg$1 digitaldaemon.com...
 
(By the way, I just found out about D++ today due to its link at
http://www.kochandreas.com/home/language/matrix.htm. I wonder how many
more people might stumble upon D if it were listed.)

Amusingly, that page says it was last updated in October of 2005.

LOL At first, I thought the same thing until I remembered that in some places in the world "10.04.2005" means April 10, 2005.

"some places"? Just "some"? To me, month/day/year is the weird thing! Who invented this messy order? Ah, those who measure things with inches! ;-)
But you're just kidding, right?

-- 
jcc7
http://jcc_7.tripod.com/d/

Apr 29 2005
parent reply J C Calvarese <jcc7 cox.net> writes:
a lurker wrote:
 In article <d4ulbu$21gh$1 digitaldaemon.com>, J C Calvarese says...

(I think if you were truly "a lurker", I wouldn't be reading your posts, but that's another issue entirely.)
 
Walter wrote:

"J C Calvarese" <jcc7 cox.net> wrote in message
news:d4u50k$1jcg$1 digitaldaemon.com...


(By the way, I just found out about D++ today due to its link at
http://www.kochandreas.com/home/language/matrix.htm. I wonder how many
more people might stumble upon D if it were listed.)

Amusingly, that page says it was last updated in October of 2005.

LOL At first, I thought the same thing until I remembered that in some places in the world "10.04.2005" means April 10, 2005.

"some places"? Just "some"? To me, month/day/year is the weird thing! Who invented this messy order? Ah, those who measure things with inches! ;-)

Do you still have 3600 seconds in your hours or have converted to metric time? Let's not get into some waste of time argument about how "my meter is longer than your yard". Generally, people like that to which they're accustomed. If I see 04-05, I think April 5 before I consider it might be May 4. If I see 04-05-02, I guess it's April 5, 2002, but it could be May 2, 2004. On the other hand, when I embed the date in a filename, I usually use YYYY_MM_DD because I like how it sorts. Go ISO! -- jcc7 http://jcc_7.tripod.com/d/
Apr 29 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 29 Apr 2005 23:20:15 -0500, J C Calvarese wrote:


 On the other hand, when I embed the date in a filename, I usually use 
 YYYY_MM_DD because I like how it sorts. 

Me too, but I try to use dates as dd/Month/yyyy when they are intended for humans to read, just to avoid this ambiguity. -- Derek Parnell Melbourne, Australia 30/April/2005 2:22:30 PM
Apr 29 2005
parent jicman <jicman_member pathlink.com> writes:
Derek Parnell says...
On Fri, 29 Apr 2005 23:20:15 -0500, J C Calvarese wrote:


 On the other hand, when I embed the date in a filename, I usually use 
 YYYY_MM_DD because I like how it sorts. 

Me too, but I try to use dates as dd/Month/yyyy when they are intended for humans to read, just to avoid this ambiguity.

Me too. I almost said, "great minds think alike," and then I remember that I was part of this, so I had to take it out. ;-) josé
Apr 30 2005
prev sibling parent "Carlos Santander B." <csantander619 gmail.com> writes:
J C Calvarese wrote:
 Do you still have 3600 seconds in your hours or have converted to metric 
 time? Let's not get into some waste of time argument about how "my meter 
 is longer than your yard". Generally, people like that to which they're 
 accustomed. If I see 04-05, I think April 5 before I consider it might 
 be May 4. If I see 04-05-02, I guess it's April 5, 2002, but it could be 
 May 2, 2004.
 
 On the other hand, when I embed the date in a filename, I usually use 
 YYYY_MM_DD because I like how it sorts. Go ISO!
 

I also use that format, all the time (except with dashes, instead of underscores). Honestly, baring some obvious exceptions, I never know a date in a short format. -- Carlos Santander Bernal
Apr 30 2005
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Fri, 29 Apr 2005 17:11:49 -0700, Walter wrote:

 "J C Calvarese" <jcc7 cox.net> wrote in message
 news:d4u50k$1jcg$1 digitaldaemon.com...
 (By the way, I just found out about D++ today due to its link at
 http://www.kochandreas.com/home/language/matrix.htm. I wonder how many
 more people might stumble upon D if it were listed.)

Amusingly, that page says it was last updated in October of 2005.

No it doesn't. I says it was last updated on the 10th of April, 2005. -- Derek Parnell Melbourne, Australia 30/04/2005 11:13:47 AM
Apr 29 2005
prev sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"manual memory management, class instances on the stack, multiple 
inheritance."

"manual memory management"...  'new' and 'delete' class methods are there.
"class instances on the stack"... this is about RAII I guess. 'auto' works 
fine.
"multiple inheritance"... Last 10 years Java proves that single inheritance 
plus
interfaces are working.  In my opinion they are working better (more clean
and much more reliable) than multiple inheritance in C++.

Andrew.


"Benjamin Herr" <ben 0x539.de> wrote in message 
news:d4oq91$1sek$1 digitaldaemon.com...
 Matthew wrote:
 I'm interested to hear from people what their
 friends/colleagues/etc. think about D, especially in terms of
 whether they would be willing to use it come 1.0.

A friend of mine, who mostly codes C++, considers it too close to Java (the casing does not help at all there ;). He would be missing all the "powerful" C++ control that gets taken away from him - manual memory management, class instances on the stack, multiple inheritance. He also thinks it is inconsistent to have (object) reference types and value types with no difference in syntax. I guess he does not like the shift of paradigms - he is also very sceptical of Ruby, and has fun writing things in pointer-mangling C. Another friend of mine (yes, I really have more than one) thinks that D is pointless because it does not solve any real problems. He considers C++ the (currently, I think) best compromise between power and elegance.

Apr 27 2005
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 27 Apr 2005 09:26:18 +1000, Matthew wrote:

 I've read a couple of things recently that've indicated that D's not 
 taken seriously by the C++ world.

I'm not in the C++ plus world, nor are my professional colleagues, but I'm wondering if D's target audience is not the current C/C++/C#/Java crowd. Instead, might it be found in the Perl, Python, Ruby, Euphoria, and total-newbie groups that have not been exposed to the foibles of the 'C' legacy, and are looking for speed, power, and simplicity? Would attempting to "sell" to this set of people be a useful exercise? -- Derek Melbourne, Australia 28/04/2005 5:40:45 PM
Apr 28 2005
next sibling parent reply Matthias Becker <Matthias_member pathlink.com> writes:
 I've read a couple of things recently that've indicated that D's not 
 taken seriously by the C++ world.

I'm not in the C++ plus world, nor are my professional colleagues, but I'm wondering if D's target audience is not the current C/C++/C#/Java crowd. Instead, might it be found in the Perl, Python, Ruby, Euphoria, and total-newbie groups that have not been exposed to the foibles of the 'C' legacy, and are looking for speed, power, and simplicity?

A Python programmer looking for simplicity should switch to D? Have you ever looked at Python?
Apr 29 2005
parent jicman <jicman_member pathlink.com> writes:
Matthias Becker says...
 I've read a couple of things recently that've indicated that D's not 
 taken seriously by the C++ world.

I'm not in the C++ plus world, nor are my professional colleagues, but I'm wondering if D's target audience is not the current C/C++/C#/Java crowd. Instead, might it be found in the Perl, Python, Ruby, Euphoria, and total-newbie groups that have not been exposed to the foibles of the 'C' legacy, and are looking for speed, power, and simplicity?

A Python programmer looking for simplicity should switch to D? Have you ever looked at Python?

I have used python and written many server/client applications based on python and, though python is pretty simple, D is not far away from it. josé
Apr 30 2005
prev sibling next sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:2ddk2n5oayb6$.1lycbdczpdp9w$.dlg 40tude.net...
 On Wed, 27 Apr 2005 09:26:18 +1000, Matthew wrote:

 I've read a couple of things recently that've indicated that D's 
 not
 taken seriously by the C++ world.

I'm not in the C++ plus world, nor are my professional colleagues, but I'm wondering if D's target audience is not the current C/C++/C#/Java crowd. Instead, might it be found in the Perl, Python, Ruby, Euphoria, and total-newbie groups that have not been exposed to the foibles of the 'C' legacy, and are looking for speed, power, and simplicity? Would attempting to "sell" to this set of people be a useful exercise? -- Derek Melbourne, Australia 28/04/2005 5:40:45 PM

Apr 29 2005
prev sibling next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:2ddk2n5oayb6$.1lycbdczpdp9w$.dlg 40tude.net...
 On Wed, 27 Apr 2005 09:26:18 +1000, Matthew wrote:

 I've read a couple of things recently that've indicated that D's 
 not
 taken seriously by the C++ world.

I'm not in the C++ plus world, nor are my professional colleagues, but I'm wondering if D's target audience is not the current C/C++/C#/Java crowd. Instead, might it be found in the Perl, Python, Ruby, Euphoria, and total-newbie groups that have not been exposed to the foibles of the 'C' legacy, and are looking for speed, power, and simplicity? Would attempting to "sell" to this set of people be a useful exercise?

Without built-in regex, it's not going to sell as an alternative to Perl or Ruby. And I can't see how it's ever going to be a credible alternative to Python, which takes simplicity and usability to the extreme and, perhaps more importantly, a wealth of libraries. I just don't see D as an alternative to scripting languages. DMDScript might, but I've not (yet) used it, and don't really know anything about it. I've always felt that D will be a credible alternative to 1. C - more OO and built-in GC 2. C++ - better templates, address some of its imperfections (http://imperfectcplusplus.com <g>) 3. Java - more expressive, better syntax, templates, doesn't need a VM 4. .NET - not vendor locked (or won't be), templates, doesn't need a VM I would think that at the moment it could credibly be said to have achieved 1, but is woefully failing on 2 because of significant fundamental defects in the language, and failing on 3 and 4 because of lack of libraries and IDEs/tools. Since there's much resistance from Walter to acknowledge/fix the defects, and much apathy/nonchalence from most of the community about them, I think the likelihood of 2 ever being achieved is negligable. It's going to take a real shift in attitude which just isn't going to happen. I think Walter's ambitions would be better served But I think that the only impediments to 3 and 4 are time, and getting to grips with the gripes - some of which are significant - with Phobos. As long as Phobos gets a proper redesign / reimplementation, such that it neatly, and orthogonally supports 1 programming (procedural, non-OO) and 3/4 programming (class-based, OO), then I see no reason why D cannot compete strongly on 3 / 4. So, in summary: Will D beat (i.e. be a credible, practicable alternative to): Perl - no, because that's not its intent Python - no, because that's not its intent Ruby - no, because that's not its intent C - yes, apart from things that have to be minimally coupled and maximally portable to any/all platforms. Big potential here C++ - no, because there's no effective desire/purpose to address the many reasons why C++ programmers are better off sticking where they are. Huge potential here, but would require huge effort. Not going to happen this lifetime Java - yes, once comprehensive tools and libraries are implemented. Big potential. Just a matter of time .NET - yes, once comprehensive tools and libraries are implemented. Big potential. Just a matter of time. And if D.NET is a commercial reality, it can be a takeover, and not a fight For me, I can certainly live with the prospect of needing to know two compiled languages - C++ and D - and two scripting languages - Python and Ruby. (Speaking from a programming-as-fun perspective, that's almost ideal!) :-) Thoughts?
Apr 29 2005
next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
[Curse OE!!]

 Since there's much resistance from Walter to acknowledge/fix the 
 defects, and much apathy/nonchalence from most of the community 
 about them, I think the likelihood of 2 ever being achieved is 
 negligable. It's going to take a real shift in attitude which just 
 isn't going to happen. I think Walter's ambitions would be better 
 served

by loosing *all* the material on the website about being an evolution from / alternative to C++, because it just doesn't wash, and really gunning for Java/.NET. e.g. " Why is D as good as Java/.NET? Because it takes all their good features and makes them better? Why is D better than Java/.NET? Because it adds in simplicity from C with many powerful features from C++! " That's true - or will be when the libs are here - and I think it's a really powerful statement. Let's forget competing with C++, and go for the genuine and credible targets: those big fat VM languages beloved by large dev organisations. Maybe such a shift in focus might mean we'd start to accelerate towards 1.0, by working together on Phobos/libs. Whadayafink?
Apr 29 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
news:d4udiq$1quc$1 digitaldaemon.com...
 [Curse OE!!]

 Since there's much resistance from Walter to acknowledge/fix the defects, 
 and much apathy/nonchalence from most of the community about them, I 
 think the likelihood of 2 ever being achieved is negligable. It's going 
 to take a real shift in attitude which just isn't going to happen. I 
 think Walter's ambitions would be better served

by loosing *all* the material on the website about being an evolution from / alternative to C++, because it just doesn't wash, and really gunning for Java/.NET. e.g. " Why is D as good as Java/.NET? Because it takes all their good features and makes them better? Why is D better than Java/.NET? Because it adds in simplicity from C with many powerful features from C++! " That's true - or will be when the libs are here - and I think it's a really powerful statement. Let's forget competing with C++, and go for the genuine and credible targets: those big fat VM languages beloved by large dev organisations. Maybe such a shift in focus might mean we'd start to accelerate towards 1.0, by working together on Phobos/libs. Whadayafink?

Noone will be surprised but I consider D to be a perfectly fine alternative to C++. It compete with C++ just as much as it competes with Java/C# (and just as much as Java/C# competes with C++). Obviously some people will prefer C++ just as some people prefer Java etc. But to say it "doesn't compete with C++" is somewhat irrelevant since the marketplace will obviously consider anything that calls itself a successor to C and competing with Java/C# as competing with C++ as well. We might as well be honest and say *how* it competes with C++ and where one might want to choose one over the other. To me the downside of the current web pages is that it tends to be very rah-rah for D and ignores any counter-argument. I wouldn't be surprised if C++ programmers responded better if their specific concerns were addressed (or at least acknowledged) on the site.
Apr 29 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
 to say it "doesn't compete with C++" is somewhat irrelevant since 
 the marketplace will obviously consider anything that calls itself 
 a successor to C and competing with Java/C# as competing with C++ 
 as well.

My point was that D is not now, and is unlikely to become, any more credible/relevant an alternative to C++ than it is Perl/Python/Ruby. Furthermore, by fostering, or at least not rejecting, the notion that it _is_ a credible/relevant alternative to C++ is detrimental to its chances of success, since people can reasonably criticise its _fundamentals_ wrt C++, which I don't believe is the case with Java/.NET. Of course, I may be wrong, as I'm not exactly an expert in Java / .NET. But I'm not aware of any great negative relativism from Java/.NET aficionados, other than that the libraries and tools are deficient. Thus, my proposition that D is it stands as a language, has no great impediment to being a competitor for C and Java/.NET given appropriate libraries/documentation/tools, which cannot be said for C++.
 We might as well be honest and say *how* it competes with C++ and 
 where one might want to choose one over the other. To me the 
 downside of the current web pages is that it tends to be very 
 rah-rah for D and ignores any counter-argument. I wouldn't be 
 surprised if C++ programmers responded better if their specific 
 concerns were addressed (or at least acknowledged) on the site.

This is very true, but I think that's not going to bring in more C++ people into the inner circle. It might serve to get them past the front door, but they're still as likely to wander off in a huff of disdain, perhaps just a little more informed in their criticism. My point about perspective is that discussion of D as an alternative to C++ should either stop, or be markedly downplayed, since this seems to be given very little credit in the wider C++ community (and maybe not all that much within the D community). Rather we should focus on genuine areas of specific competitiveness - i.e. given D with excellent libraries/docs/tools, why would one use .NET? - and on promoting D in its own right, which is at once both more optimistic and less fallacious.
Apr 29 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d4v7ib$2gbk$1 digitaldaemon.com...
 to say it "doesn't compete with C++" is somewhat irrelevant since
 the marketplace will obviously consider anything that calls itself
 a successor to C and competing with Java/C# as competing with C++
 as well.

My point was that D is not now, and is unlikely to become, any more credible/relevant an alternative to C++ than it is Perl/Python/Ruby. Furthermore, by fostering, or at least not rejecting, the notion that it _is_ a credible/relevant alternative to C++ is detrimental to its chances of success, since people can reasonably criticise its _fundamentals_ wrt C++, which I don't believe is the case with Java/.NET. Of course, I may be wrong, as I'm not exactly an expert in Java / .NET. But I'm not aware of any great negative relativism from Java/.NET aficionados, other than that the libraries and tools are deficient. Thus, my proposition that D is it stands as a language, has no great impediment to being a competitor for C and Java/.NET given appropriate libraries/documentation/tools, which cannot be said for C++.
 We might as well be honest and say *how* it competes with C++ and
 where one might want to choose one over the other. To me the
 downside of the current web pages is that it tends to be very
 rah-rah for D and ignores any counter-argument. I wouldn't be
 surprised if C++ programmers responded better if their specific
 concerns were addressed (or at least acknowledged) on the site.

This is very true, but I think that's not going to bring in more C++ people into the inner circle. It might serve to get them past the front door, but they're still as likely to wander off in a huff of disdain, perhaps just a little more informed in their criticism. My point about perspective is that discussion of D as an alternative to C++ should either stop, or be markedly downplayed, since this seems to be given very little credit in the wider C++ community (and maybe not all that much within the D community). Rather we should focus on genuine areas of specific competitiveness - i.e. given D with excellent libraries/docs/tools, why would one use .NET? - and on promoting D in its own right, which is at once both more optimistic and less fallacious.

I agree that there should be less focus on (and reliance on) D's relation to C and C++, and more focus on D as a language in and of itself, viable as an alternative to any programming language currently in existance. I also feel that D needs to have more focus on it's not only being being flexible enough work well with other languages, but also being powerful enough to stand on it's own. (are we there yet?) TZ
May 25 2005
parent reply Sam <Sam_member pathlink.com> writes:
I'm not sure if this is relevant here, but I am an expert .NET developer and I
have used C++ (through Microsoft's managed extensions with the Visual C++
compiler) with the .NET framework.  Can the same be done with D or the D
compiler?  If so, it would actually make D the language of choice for .NET
development, at least in my book.  Or at least until the second version of C#
comes out...

By the way, I think it can be done and wouldn't be that difficult to do.  It's
just a matter of who has the time to do it.  But I think a lot of people would
be interested in .NET development with the D language................

Or dare I say......................

The D# language!!!!!!!!!!!!

;D

PS-
If anyone wants to attempt this, look into .NET's 'System.CodeDOM' namespace.

In article <d72so5$hch$1 digitaldaemon.com>, TechnoZeus says...
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d4v7ib$2gbk$1 digitaldaemon.com...
 to say it "doesn't compete with C++" is somewhat irrelevant since
 the marketplace will obviously consider anything that calls itself
 a successor to C and competing with Java/C# as competing with C++
 as well.

My point was that D is not now, and is unlikely to become, any more credible/relevant an alternative to C++ than it is Perl/Python/Ruby. Furthermore, by fostering, or at least not rejecting, the notion that it _is_ a credible/relevant alternative to C++ is detrimental to its chances of success, since people can reasonably criticise its _fundamentals_ wrt C++, which I don't believe is the case with Java/.NET. Of course, I may be wrong, as I'm not exactly an expert in Java / .NET. But I'm not aware of any great negative relativism from Java/.NET aficionados, other than that the libraries and tools are deficient. Thus, my proposition that D is it stands as a language, has no great impediment to being a competitor for C and Java/.NET given appropriate libraries/documentation/tools, which cannot be said for C++.
 We might as well be honest and say *how* it competes with C++ and
 where one might want to choose one over the other. To me the
 downside of the current web pages is that it tends to be very
 rah-rah for D and ignores any counter-argument. I wouldn't be
 surprised if C++ programmers responded better if their specific
 concerns were addressed (or at least acknowledged) on the site.

This is very true, but I think that's not going to bring in more C++ people into the inner circle. It might serve to get them past the front door, but they're still as likely to wander off in a huff of disdain, perhaps just a little more informed in their criticism. My point about perspective is that discussion of D as an alternative to C++ should either stop, or be markedly downplayed, since this seems to be given very little credit in the wider C++ community (and maybe not all that much within the D community). Rather we should focus on genuine areas of specific competitiveness - i.e. given D with excellent libraries/docs/tools, why would one use .NET? - and on promoting D in its own right, which is at once both more optimistic and less fallacious.

I agree that there should be less focus on (and reliance on) D's relation to C and C++, and more focus on D as a language in and of itself, viable as an alternative to any programming language currently in existance. I also feel that D needs to have more focus on it's not only being being flexible enough work well with other languages, but also being powerful enough to stand on it's own. (are we there yet?) TZ

-Sam sam987883
May 25 2005
parent J C Calvarese <technocrat7 gmail.com> writes:
In article <d72tl7$i0j$1 digitaldaemon.com>, Sam says...
I'm not sure if this is relevant here, but I am an expert .NET developer and I
have used C++ (through Microsoft's managed extensions with the Visual C++
compiler) with the .NET framework.  Can the same be done with D or the D
compiler?  If so, it would actually make D the language of choice for .NET
development, at least in my book.  Or at least until the second version of C#
comes out...

By the way, I think it can be done and wouldn't be that difficult to do.  It's
just a matter of who has the time to do it.  But I think a lot of people would
be interested in .NET development with the D language................

Or dare I say......................

The D# language!!!!!!!!!!!!

Someone already started a similar project (called D.net), but it stalled (I think due to lack of time). Here's some information about it: http://www.prowiki.org/wiki4d/wiki.cgi?DDotNet I think he made use of D's open source frontend and combined it with his own backend in VSC++. jcc7
May 26 2005
prev sibling next sibling parent John Reimer <brk_6502 yahoo.com> writes:
Matthew wrote:
 "Derek Parnell" <derek psych.ward> wrote in message 
 news:2ddk2n5oayb6$.1lycbdczpdp9w$.dlg 40tude.net...
 
On Wed, 27 Apr 2005 09:26:18 +1000, Matthew wrote:


I've read a couple of things recently that've indicated that D's 
not
taken seriously by the C++ world.

I'm not in the C++ plus world, nor are my professional colleagues, but I'm wondering if D's target audience is not the current C/C++/C#/Java crowd. Instead, might it be found in the Perl, Python, Ruby, Euphoria, and total-newbie groups that have not been exposed to the foibles of the 'C' legacy, and are looking for speed, power, and simplicity? Would attempting to "sell" to this set of people be a useful exercise?

Without built-in regex, it's not going to sell as an alternative to Perl or Ruby. And I can't see how it's ever going to be a credible alternative to Python, which takes simplicity and usability to the extreme and, perhaps more importantly, a wealth of libraries. I just don't see D as an alternative to scripting languages. DMDScript might, but I've not (yet) used it, and don't really know anything about it. I've always felt that D will be a credible alternative to 1. C - more OO and built-in GC 2. C++ - better templates, address some of its imperfections (http://imperfectcplusplus.com <g>) 3. Java - more expressive, better syntax, templates, doesn't need a VM 4. .NET - not vendor locked (or won't be), templates, doesn't need a VM I would think that at the moment it could credibly be said to have achieved 1, but is woefully failing on 2 because of significant fundamental defects in the language, and failing on 3 and 4 because of lack of libraries and IDEs/tools. Since there's much resistance from Walter to acknowledge/fix the defects, and much apathy/nonchalence from most of the community about them, I think the likelihood of 2 ever being achieved is negligable. It's going to take a real shift in attitude which just isn't going to happen. I think Walter's ambitions would be better served But I think that the only impediments to 3 and 4 are time, and getting to grips with the gripes - some of which are significant - with Phobos. As long as Phobos gets a proper redesign / reimplementation, such that it neatly, and orthogonally supports 1 programming (procedural, non-OO) and 3/4 programming (class-based, OO), then I see no reason why D cannot compete strongly on 3 / 4. So, in summary: Will D beat (i.e. be a credible, practicable alternative to): Perl - no, because that's not its intent Python - no, because that's not its intent Ruby - no, because that's not its intent C - yes, apart from things that have to be minimally coupled and maximally portable to any/all platforms. Big potential here C++ - no, because there's no effective desire/purpose to address the many reasons why C++ programmers are better off sticking where they are. Huge potential here, but would require huge effort. Not going to happen this lifetime Java - yes, once comprehensive tools and libraries are implemented. Big potential. Just a matter of time .NET - yes, once comprehensive tools and libraries are implemented. Big potential. Just a matter of time. And if D.NET is a commercial reality, it can be a takeover, and not a fight For me, I can certainly live with the prospect of needing to know two compiled languages - C++ and D - and two scripting languages - Python and Ruby. (Speaking from a programming-as-fun perspective, that's almost ideal!) :-) Thoughts?

I liked that summary very much. I think your analysis of D here was very accurate, specifically pertaining to C++.
Apr 29 2005
prev sibling next sibling parent reply Benji Smith <dlanguage xxagg.com> writes:
Matthew wrote:
         Java - yes, once comprehensive tools and libraries are 
 implemented. Big potential. Just a matter of time

There are a few different things that D would need to accomplish before making any headway into the Java world. #1 -- Standard Library As you've mentioned, Java has a huge standard library, with (mostly) well-thought-out implementations of tons and tons of usefull classes. Just to give you an idea of the scope of the library, the Java 1.5 JRE includes 2485 classes and 794 interfaces, organized into 166 packages. Admittedly, D can dispense with some fraction of these classes because it has more intrinsic language features than Java. But it's likely that a suitable D standard library is still nowhere even remotely close to having the kind of fully fleshed-out library that Java has. When D has several thousand classes in its standard library, then Java people might start taking interest. #2 -- Ease of Use with 3rd Party Libraries Although the standard library is an issue, I think this one is more important, and more consistently overlooked. In Java, it's trivial to use classes from a third-party library. Here are the steps: 1. Download a JAR file containing the classes I'll be using. 2. Include the path to that JAR file in my classpath. 3. Now I'm able to use all of those classes as if I wrote them and had the source code available to me. With Java, I don't need to use any special semantics to call external code. The semantics are completely identical when methods in my own classes, methods from compiled classes, methods from classes in a JAR archive, or methods executed on classes constucted through reflection. The only thing I need to worry about, as a developer, is putting an import statement at the top of my source file pointing to the appropriate package/class. And then the runtime does everything else for me. What's more, I don't need to use any special linking semantics, and my classes will execute identically on windows or unix. D is light years away from offering anything that approaches this level of convenience and simplicity when it comes to executing third-party code. And until D provides those same niceties, I believe Java programmers will not be interested. #3 -- Documentation Deneration It's nice that there is some grassroots support starting to develop around Doxygen for producing API documentation from D files. But since Java implicitly supports the javadoc specification, I think Java developers would expect the same level of doc-generation support from any vendor of a D compiler. Either D needs a doc-generation tool of its own (produced by Digital Mars) or it needs a specification and a feature-complete Doxygen implementation (also produced by Digital Mars). This is the least important of my 3 points, but I think it's still an expectation of Java developers, and you won't be able to lure Java programmers to D without an official document-generation workflow. --BenjiSmith
Apr 29 2005
next sibling parent Benji Smith <dlanguage xxagg.com> writes:
Benji Smith wrote:
 blah blah blah Java Java Java blah blah blah

Wow, I've never written one message with so many typos in my life. <<blushes>> --BenjiSmith
Apr 29 2005
prev sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
Benji, #2 and #3 are excellent additions to my post (and their 
overlooking quite telling about my particular perspectives and 
preferences).

Thanks. :-)


"Benji Smith" <dlanguage xxagg.com> wrote in message 
news:d4ug5k$1t33$1 digitaldaemon.com...
 Matthew wrote:
         Java - yes, once comprehensive tools and libraries are 
 implemented. Big potential. Just a matter of time

There are a few different things that D would need to accomplish before making any headway into the Java world. #1 -- Standard Library As you've mentioned, Java has a huge standard library, with (mostly) well-thought-out implementations of tons and tons of usefull classes. Just to give you an idea of the scope of the library, the Java 1.5 JRE includes 2485 classes and 794 interfaces, organized into 166 packages. Admittedly, D can dispense with some fraction of these classes because it has more intrinsic language features than Java. But it's likely that a suitable D standard library is still nowhere even remotely close to having the kind of fully fleshed-out library that Java has. When D has several thousand classes in its standard library, then Java people might start taking interest. #2 -- Ease of Use with 3rd Party Libraries Although the standard library is an issue, I think this one is more important, and more consistently overlooked. In Java, it's trivial to use classes from a third-party library. Here are the steps: 1. Download a JAR file containing the classes I'll be using. 2. Include the path to that JAR file in my classpath. 3. Now I'm able to use all of those classes as if I wrote them and had the source code available to me. With Java, I don't need to use any special semantics to call external code. The semantics are completely identical when methods in my own classes, methods from compiled classes, methods from classes in a JAR archive, or methods executed on classes constucted through reflection. The only thing I need to worry about, as a developer, is putting an import statement at the top of my source file pointing to the appropriate package/class. And then the runtime does everything else for me. What's more, I don't need to use any special linking semantics, and my classes will execute identically on windows or unix. D is light years away from offering anything that approaches this level of convenience and simplicity when it comes to executing third-party code. And until D provides those same niceties, I believe Java programmers will not be interested. #3 -- Documentation Deneration It's nice that there is some grassroots support starting to develop around Doxygen for producing API documentation from D files. But since Java implicitly supports the javadoc specification, I think Java developers would expect the same level of doc-generation support from any vendor of a D compiler. Either D needs a doc-generation tool of its own (produced by Digital Mars) or it needs a specification and a feature-complete Doxygen implementation (also produced by Digital Mars). This is the least important of my 3 points, but I think it's still an expectation of Java developers, and you won't be able to lure Java programmers to D without an official document-generation workflow. --BenjiSmith

Apr 29 2005
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Sat, 30 Apr 2005 08:42:40 +1000, Matthew wrote:

 "Derek Parnell" <derek psych.ward> wrote in message 
I'm
 wondering if D's target audience is not the current C/C++/C#/Java 
 crowd.
 Instead, might it be found in the Perl, Python, Ruby, Euphoria, 
 and
 total-newbie groups that have not been exposed to the foibles of 
 the 'C'
 legacy, and are looking for speed, power, and simplicity?

 Would attempting to "sell" to this set of people be a useful 
 exercise?

Without built-in regex, it's not going to sell as an alternative to Perl or Ruby. And I can't see how it's ever going to be a credible alternative to Python, which takes simplicity and usability to the extreme and, perhaps more importantly, a wealth of libraries. I just don't see D as an alternative to scripting languages.

I'm sorry, but I didn't make myself as clear as I thought I had. I was not suggesting D as an alternative to those scripting languages, but as an additional tool to be used in places that are outside of the scripting language problem domain. In other words, when people who have only been using such scripting languages, eventually need to use a programming language to do something that is better achieved though using a non-scripting language, then might not D be a useful tool for them? And if so, should the current D community and DigitalMars be actively promoting D to that group of potential users? -- Derek Parnell Melbourne, Australia http://www.dsource.org/projects/build 30/04/2005 10:31:44 AM
Apr 29 2005
parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:120x3hvv15xxp$.d1p5yypli8xj$.dlg 40tude.net...
 On Sat, 30 Apr 2005 08:42:40 +1000, Matthew wrote:

 "Derek Parnell" <derek psych.ward> wrote in message
I'm
 wondering if D's target audience is not the current 
 C/C++/C#/Java
 crowd.
 Instead, might it be found in the Perl, Python, Ruby, Euphoria,
 and
 total-newbie groups that have not been exposed to the foibles of
 the 'C'
 legacy, and are looking for speed, power, and simplicity?

 Would attempting to "sell" to this set of people be a useful
 exercise?

Without built-in regex, it's not going to sell as an alternative to Perl or Ruby. And I can't see how it's ever going to be a credible alternative to Python, which takes simplicity and usability to the extreme and, perhaps more importantly, a wealth of libraries. I just don't see D as an alternative to scripting languages.

I'm sorry, but I didn't make myself as clear as I thought I had. I was not suggesting D as an alternative to those scripting languages, but as an additional tool to be used in places that are outside of the scripting language problem domain.

Ok. Makes a lot more sense in that light.
 In other words, when people who have only been using such 
 scripting
 languages, eventually need to use a programming language to do 
 something
 that is better achieved though using a non-scripting language, 
 then might
 not D be a useful tool for them?

Yes indeed.
 And if so, should the current D community
 and DigitalMars be actively promoting D to that group of potential 
 users?

Not now, unless it wants to look very silly. People who are migrating from scripting languages will want (i) ease of use of the language, which is nothing like the same as ease of understanding of the language. Given the current state of the available tool set, it'd be hard to imagine someone coming to D as their first compiled language and not being strongly put off (ii) documentation (iii) libraries. But, once these issues are sorted, then I think it'd be a very good first compiled-language for such people.
Apr 29 2005
prev sibling next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d4ud9f$1qrc$1 digitaldaemon.com...
 Without built-in regex, it's not going to sell as an alternative to
 Perl or Ruby.

A couple months back, I added numerous functions to std.string and std.regexp which mostly close the gap with Ruby.
Apr 30 2005
parent jicman <jicman_member pathlink.com> writes:
In Walter's (really D's) defense, I have to say that I have translated a perl
script which extensively used Regular expression, and also a few JScript scripts
that also used regexp, and they have worked perfectly.  So, I would say that
Walter's correct.

josé

Walter says...
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d4ud9f$1qrc$1 digitaldaemon.com...
 Without built-in regex, it's not going to sell as an alternative to
 Perl or Ruby.

A couple months back, I added numerous functions to std.string and std.regexp which mostly close the gap with Ruby.

Apr 30 2005
prev sibling next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d4ud9f$1qrc$1 digitaldaemon.com...
 I just don't see D as an alternative to scripting languages.
 DMDScript might, but I've not (yet) used it, and don't really know
 anything about it.

DMDScript is an implementation of ECMA262 (i.e. javascript). It has nothing to do with D, other than being implemented in D.
Apr 30 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d4vlsg$4l7$2 digitaldaemon.com...
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:d4ud9f$1qrc$1 digitaldaemon.com...
 I just don't see D as an alternative to scripting languages.
 DMDScript might, but I've not (yet) used it, and don't really 
 know
 anything about it.

DMDScript is an implementation of ECMA262 (i.e. javascript). It has nothing to do with D, other than being implemented in D.

nothing? I thought it shared a lot of the syntax, char[] and whatnot? Oh well, I stand corrected.
Apr 30 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d51c57$1kir$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:d4vlsg$4l7$2 digitaldaemon.com...
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:d4ud9f$1qrc$1 digitaldaemon.com...
 I just don't see D as an alternative to scripting languages.
 DMDScript might, but I've not (yet) used it, and don't really
 know
 anything about it.

DMDScript is an implementation of ECMA262 (i.e. javascript). It has nothing to do with D, other than being implemented in D.

nothing? I thought it shared a lot of the syntax, char[] and whatnot? Oh well, I stand corrected.

The syntax has superficial similarities, both being curly brace languages, but the D language has as much in common with the DMDScript language as C++ does to Ruby.
Apr 30 2005
parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d51efr$1mj1$1 digitaldaemon.com...
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:d51c57$1kir$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:d4vlsg$4l7$2 digitaldaemon.com...
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:d4ud9f$1qrc$1 digitaldaemon.com...
 I just don't see D as an alternative to scripting languages.
 DMDScript might, but I've not (yet) used it, and don't really
 know
 anything about it.

DMDScript is an implementation of ECMA262 (i.e. javascript). It has nothing to do with D, other than being implemented in D.

nothing? I thought it shared a lot of the syntax, char[] and whatnot? Oh well, I stand corrected.

The syntax has superficial similarities, both being curly brace languages, but the D language has as much in common with the DMDScript language as C++ does to Ruby.

What, they're both brilliant?? :-)
May 02 2005
prev sibling parent reply jicman <jicman_member pathlink.com> writes:
Matthew says...
"Derek Parnell" <derek psych.ward> wrote in message 
news:2ddk2n5oayb6$.1lycbdczpdp9w$.dlg 40tude.net...
 On Wed, 27 Apr 2005 09:26:18 +1000, Matthew wrote:

 I've read a couple of things recently that've indicated that D's 
 not
 taken seriously by the C++ world.

I'm not in the C++ plus world, nor are my professional colleagues, but I'm wondering if D's target audience is not the current C/C++/C#/Java crowd. Instead, might it be found in the Perl, Python, Ruby, Euphoria, and total-newbie groups that have not been exposed to the foibles of the 'C' legacy, and are looking for speed, power, and simplicity? Would attempting to "sell" to this set of people be a useful exercise?

Without built-in regex, it's not going to sell as an alternative to Perl or Ruby.

With all due respect, what is so hard about, import std.regexp; That's all one needs. Of course, the syntax is different, but it's a few minutes of learning it and it won't be that hard.
And I can't see how it's ever going to be a credible alternative to 
Python, which takes simplicity and usability to the extreme and, 
perhaps more importantly, a wealth of libraries.

Well, hmmmm, let's see: speed, stand-along executable, did I mentioned speed?
Apr 30 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"jicman" <jicman_member pathlink.com> wrote in message 
news:d51e6c$1mcf$1 digitaldaemon.com...
 Matthew says...
"Derek Parnell" <derek psych.ward> wrote in message
news:2ddk2n5oayb6$.1lycbdczpdp9w$.dlg 40tude.net...
 On Wed, 27 Apr 2005 09:26:18 +1000, Matthew wrote:

 I've read a couple of things recently that've indicated that 
 D's
 not
 taken seriously by the C++ world.

I'm not in the C++ plus world, nor are my professional colleagues, but I'm wondering if D's target audience is not the current C/C++/C#/Java crowd. Instead, might it be found in the Perl, Python, Ruby, Euphoria, and total-newbie groups that have not been exposed to the foibles of the 'C' legacy, and are looking for speed, power, and simplicity? Would attempting to "sell" to this set of people be a useful exercise?

Without built-in regex, it's not going to sell as an alternative to Perl or Ruby.

With all due respect, what is so hard about, import std.regexp; That's all one needs. Of course, the syntax is different, but it's a few minutes of learning it and it won't be that hard.
And I can't see how it's ever going to be a credible alternative 
to
Python, which takes simplicity and usability to the extreme and,
perhaps more importantly, a wealth of libraries.

Well, hmmmm, let's see: speed, stand-along executable, did I mentioned speed?

Speed is very important, when it's important. But often it's not, in which case usability, ease-of-use, libraries, etc. is more important. A lot of scripting involves such cases, so unless D can compete on ease of use and libs, such programming is not going to attract D use.
May 02 2005
parent Derek Parnell <derek psych.ward> writes:
On Mon, 2 May 2005 18:33:54 +1000, Matthew wrote:


[snip]

 Well, hmmmm, let's see: speed, stand-along executable, did I 
 mentioned speed?

Speed is very important, when it's important. But often it's not, in which case usability, ease-of-use, libraries, etc. is more important. A lot of scripting involves such cases, so unless D can compete on ease of use and libs, such programming is not going to attract D use.

Agreed. And that is the same as saying that when the situation arises that a scripting language is not (or no longer) suitable, then D ought to be an attractive alternative. It seems that you are both in agreement, but with different emphasis. -- Derek Parnell Melbourne, Australia http://www.dsource.org/projects/build v2.05 is now available. 02/May/2005 3/05/2005 7:21:22 AM
May 02 2005
prev sibling parent jicman <jicman_member pathlink.com> writes:
Derek Parnell says...
On Wed, 27 Apr 2005 09:26:18 +1000, Matthew wrote:

 I've read a couple of things recently that've indicated that D's not 
 taken seriously by the C++ world.

I'm not in the C++ plus world, nor are my professional colleagues, but I'm wondering if D's target audience is not the current C/C++/C#/Java crowd. Instead, might it be found in the Perl, Python, Ruby, Euphoria, and total-newbie groups that have not been exposed to the foibles of the 'C' legacy, and are looking for speed, power, and simplicity? Would attempting to "sell" to this set of people be a useful exercise?

That is a great idea. However, we need to get COM to work with D. Most of us, python, perl, JScript folks use lots of COM programming, which these work. But, you're right, this will grow D's popularity. I find that D is as easy as python, which is very easy. So, the scripting folks will love to have an executable instead of an script powered by a some interpreter. Just a thought... josé
Apr 30 2005
prev sibling next sibling parent reply John Demme <me teqdruid.com> writes:
The link on the D links page yields a 404.  Where's Andy's site
nowadays?

Also, is there a tutorial for this?

John Demme

On Thu, 2005-04-28 at 21:31 +1200, brad beveridge wrote:
 What should be written (just brainstorming, here..) is a way to "tunnel" D
 method calls into C++ method calls, possibly via generated C functions in the
 short term, maybe more directly/transparently at some point in the future.
 
 Kevin
 

D has been integrated with SWIG ... from D links. "Andy Friesen has taken SWIG and modified it to generate code for D." SWIG is basically a C/C++ parser that generates code that allows many other languages to interface to C/C++. It produces very good proxy classes and function wrappers from what I have seen. Unfortuantly it isn't rolled into the official SWIG website. As with many things in D, the tools are 90% there, but are not official and have no maintainer. Brad

Apr 28 2005
parent David L. Davis <SpottedTiger yahoo.com> writes:
In article <1114718207.20340.4.camel localhost.localdomain>, John Demme says...
...

   Where's Andy's site nowadays?

Andy's site is now here: http://aegisknight.org/~andy/d/ *** caution!!...it's slow to load up *** David L. ------------------------------------------------------------------- "Dare to reach for the Stars...Dare to Dream, Build, and Achieve!" ------------------------------------------------------------------- MKoD: http://spottedtiger.tripod.com/D_Language/D_Main_XP.html
Apr 28 2005
prev sibling next sibling parent John Demme <me teqdruid.com> writes:
Looks like there's a copy from August 1st, 2004 on DSource.

On Fri, 2005-04-29 at 09:17 +1200, Brad Beveridge wrote:
 John Demme wrote:
 The link on the D links page yields a 404.  Where's Andy's site
 nowadays?
 
 Also, is there a tutorial for this?
 
 John Demme
 
 On Thu, 2005-04-28 at 21:31 +1200, brad beveridge wrote:
 
What should be written (just brainstorming, here..) is a way to "tunnel" D
method calls into C++ method calls, possibly via generated C functions in the
short term, maybe more directly/transparently at some point in the future.

Kevin

D has been integrated with SWIG ... from D links. "Andy Friesen has taken SWIG and modified it to generate code for D." SWIG is basically a C/C++ parser that generates code that allows many other languages to interface to C/C++. It produces very good proxy classes and function wrappers from what I have seen. Unfortuantly it isn't rolled into the official SWIG website. As with many things in D, the tools are 90% there, but are not official and have no maintainer. Brad


think. If you can't find the download I think I may have it on my machine at home. Brad

Apr 28 2005
prev sibling next sibling parent reply Michael Hainze <Michael_member pathlink.com> writes:
Simple solution to get D adopted--get Linus Torvalds to convert Linux to D.  Or
perhaps some brave soul can fork it and convert the basic Linux toolchain and
kernel to D.  I was recently thinking of how to automatedly convert C to a
better language, and D looks as good as anything I was coming up with (although,
I would like a syntax to expose member objects as if they were superclasses for
a pretense of multiple inheritance).  Some kind of quick-and-dirty converter
that just works, followed by a code cleanup at leisure.  Perhaps some linty tool
that marks up the trouble spots for manual patching prior to compilation would
help, too.

Maybe somebody can fix up a D environment in the Eclipse IDE without too much
hassle?  C/C++ in Eclipse isn't here yet, but D would be much easier, probably
not much harder than Java.  My $0.02...
Apr 28 2005
parent reply Brad Beveridge <brad somewhere.net> writes:
Michael Hainze wrote:
 Simple solution to get D adopted--get Linus Torvalds to convert Linux to D.  Or
 perhaps some brave soul can fork it and convert the basic Linux toolchain and
 kernel to D.

Though I think you are jesting, it would be nice if D had a high-profile "killer app" that would make people sit up and take D seriously as a language. As an aside - how hard would it be to make a toy OS kernel in D. Or, if not a toy OS an embedded environment? Brad
Apr 28 2005
next sibling parent pragma <pragma_member pathlink.com> writes:
In article <d4rptj$1vuc$1 digitaldaemon.com>, Brad Beveridge says...
Michael Hainze wrote:
 Simple solution to get D adopted--get Linus Torvalds to convert Linux to D.  Or
 perhaps some brave soul can fork it and convert the basic Linux toolchain and
 kernel to D.

Though I think you are jesting, it would be nice if D had a high-profile "killer app" that would make people sit up and take D seriously as a language. As an aside - how hard would it be to make a toy OS kernel in D. Or, if not a toy OS an embedded environment?

Didn't Sun already try this for Java? Seems to me that maybe they were onto something with pushing their language/platform in such a manner. :) Outside that, the "Killer app" territory is likely to be covered by a mature project built on top of what we already have. Right now, we're still building the toolchain (build and the like) and compatibility/platform libs. Personally, I'm doing my damndest to get some good stuff out there. I doubt I'm in "killer app" territory with DSP and it's XML stack, but those will pay dividends later. FYI, I have a modified version of the DMDFE that spits out XML instead of .obj files. This was actually pretty easy to do, thanks to Ben's pioneering. I plan to use it as part of a documentation toolchain, which will likely be XSLT driven. IMO, what's needed is something that makes people go "wow" first, and "made with what?" second. ;) - EricAnderton at yahoo
Apr 28 2005
prev sibling parent reply Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brad Beveridge schrieb am Fri, 29 Apr 2005 11:00:38 +1200:
 Michael Hainze wrote:
 Simple solution to get D adopted--get Linus Torvalds to convert Linux to D.  Or
 perhaps some brave soul can fork it and convert the basic Linux toolchain and
 kernel to D.

Though I think you are jesting, it would be nice if D had a high-profile "killer app" that would make people sit up and take D seriously as a language. As an aside - how hard would it be to make a toy OS kernel in D. Or, if not a toy OS an embedded environment?

It's not that difficult. (I'm currently updateing the dkernel source to the current DMD.) Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFCcbCp3w+/yD4P9tIRAqUWAJwLIJvDtYY2Yjit/54HXiYNSXUoXACfTgsf 3y+DIKygtvCdDNOZrHQWo84= =dqXN -----END PGP SIGNATURE-----
Apr 28 2005
parent reply Brad Beveridge <brad somewhere.net> writes:
 
 It's not that difficult.
 (I'm currently updateing the dkernel source to the current DMD.)
 
 Thomas
 

was http://www.geocities.com/one_mad_alien/dkernel.html, which looks a little old. Brad
Apr 28 2005
parent Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brad Beveridge schrieb am Fri, 29 Apr 2005 16:06:34 +1200:
 
 It's not that difficult.
 (I'm currently updateing the dkernel source to the current DMD.)
 
 Thomas
 

was http://www.geocities.com/one_mad_alien/dkernel.html, which looks a little old.

I'll try to setup a public Monotone server in the coming days. Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFCcbdd3w+/yD4P9tIRAnrUAKCF3h92ZAn+MKfPtsv3LMt/eHTZIwCgzvHn lSXP7Pfy+hl7UFGgXlo4fdg= =Q8J9 -----END PGP SIGNATURE-----
Apr 28 2005
prev sibling parent JimH <JimH_member pathlink.com> writes:
I recently discovered the D web site and the language looks really nice,
although I haven’t tried it yet. There are a couple of reasons why I’d be
hesitant to use it at my job.

1. I’d be expecting the programmers around me as well as those who come after me
and maintain my code to learn a new language (although it is similar). Everyone
knows C/C++. If someone needs to maintain my C/C++ code, they can jump right in.
But before they maintain my D code they’d have to learn it, as well as install a
new set of tools on their computer. And they’d probably be griping the whole
time, “Why couldn’t he just use C++. Grrr.” Granted, there’s nothing D can do
about this. It’s just the way it is.

2. “Nobody ever got fired for buying IBM”. I may choose to use D in my company.
But if anything goes wrong and there’s some problem or limitation that would not
have occurred if I had used C++ in the first place, it won’t go down well. But
the same is not true in the reverse case. If I use C++ and there is a problem or
limitation, no one will blame me for choosing C++. In fact, this seems like the
same issue all over again as it was with C and C++. Way back when most people
were using straight C, it was hard to get C++ accepted. If you finished your C++
program and it ran at all slower than a C version, you’d risk getting chided for
“those virtual functions that just slow things down”, or some such stuff.

I think both of these issues are about the critical mass effect. D would be more
attractive if lots of people were already using it. If you can get to that
critical mass, then it snowballs.

If D had a decent IDE it would be nice. I have to say I do like some things
about the Visual Studio IDE. I like how it can take me to the definition of a
variable, or how it can show me the type when I hover my mouse over it. But even
if D had a nice IDE, that would still be a side issue.

I don’t care if the D web page is slick or not.


Jim


In article <d4mioc$2lgm$1 digitaldaemon.com>, Matthew says...
I've read a couple of things recently that've indicated that D's not 
taken seriously by the C++ world. I am wondering whether this is 
true, since it's certainly not the impression that I've had from the 
people I've spoken with about it, most of whom are not using it now, 
but are definitely interested in doing so in the future; the 
D-curious, if you like?

I'm interested to hear from people what their 
friends/colleagues/etc. think about D, especially in terms of 
whether they would be willing to use it come 1.0.

I'm also interested to hear of any specific must-haves that such 
people have expressed.

Please, everyone, don't turn this thread into what _you_ think about 
D, or what _you_ think should be in 1.0. We have a pretty good feel 
for what D-philes think already.

Cheers

Matthew

May 09 2005