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,




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




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


justice

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


share

 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!
 
 


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




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.


   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.


That was my first feeling after reading intro on digitalmars site. Benefits
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




the

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


 That was my first feeling after reading intro on digitalmars site.


Benefits

 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




 the

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


 That was my first feeling after reading intro on digitalmars site.


 Benefits

 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++

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



 "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




 the

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


 That was my first feeling after reading intro on digitalmars site.


 Benefits

 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++

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

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


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.


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 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
next sibling 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


 
 


The SWIG site has tutorials for other languages, which should apply I 
think.  If you can't find the download I think I may have it on my 
machine at home.

Brad
Apr 28 2005
parent reply 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


 
 


 The SWIG site has tutorials for other languages, which should apply I 
 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 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 parent reply "Charlie" <charles jwavro.com> writes:
 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?


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




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


C to

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


switched

 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. ;)


I has the same feeling too.

-- 
          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. ;)


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



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.


 

 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.



 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.



 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.


Right. But language also must avoid dangerous cases and possibilities to
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.


Absolutely agree.


 

 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.


 Right. But language also must avoid dangerous cases and possibilities to
 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


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.


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.


[snip]

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


[snip]

 (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. ;)




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

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

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

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

 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

 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 


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 

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 

 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

 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

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



;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

 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

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




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

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.



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.



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.



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:

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.



 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.



 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.



 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

 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 

 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

 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 

 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

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


Is that on the web somewhere?  The only thing trusty google could find 
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
 


 Is that on the web somewhere?  The only thing trusty google could find 
 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