D projects list
I think it will be great to have a single place for all D related projects so a developer can easily find what is already done (for an example of "I didn't now about you project" see, e.g. "Modern COM Programming in D" thread), what is *planned* and what great projects have already failed (and, maybe, reveal it). A draft variant of how I see such page is this with a few projects added (note "Planned" tag (yes, empty for now)): http://deoma-cmd.ru/d/d-projects-list/ Usage examples: * lets find a D compiler with release or beta maturity: http://deoma-cmd.ru/d/d-projects-list/?q=Compiler+Beta+Release * lets find not abandoned GUI library for D: http://deoma-cmd.ru/d/d-projects-list/?q=GUI+!Abandoned I'd like to put http://deoma-cmd.ru/d/d-projects-list/projects.js into GitHub so developers can fork and edit it. I'd like to hear (but yes, I can only read, this is NG) any thoughts about this idea. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: D projects list
> Denis V. Shelomovskij > I'd like to hear (but yes, I can only read, this is NG) any thoughts > about this idea. Looks very cool, nice job! On 4/5/12, Denis Shelomovskij wrote: > http://deoma-cmd.ru/d/d-projects-list/?q=GUI+!Abandoned A newer binding of Tk is on github although dated 2008 (not mine): https://github.com/lysevi/dkinter I've got an updated version that can use the newer Tk that has ttk (more native-look widgets). But I didn't bother with Tk much because it basically comes down to having to pass strings to a Tk eval function. For anything complicated you have to allocate a ton of strings.. Tk is probably best left for use with scripting languages imo.
Re: D projects list
"Denis Shelomovskij" wrote in message news:jlkubn$k4f$1...@digitalmars.com... >I think it will be great to have a single place for all D related projects >so a developer can easily find what is already done > (for an example of "I didn't now about you project" see, e.g. "Modern COM > Programming in D" thread), what is *planned* and what great projects have > already failed (and, maybe, reveal it). > > A draft variant of how I see such page is this with a few projects added > (note "Planned" tag (yes, empty for now)): > http://deoma-cmd.ru/d/d-projects-list/ > > Usage examples: > * lets find a D compiler with release or beta maturity: > http://deoma-cmd.ru/d/d-projects-list/?q=Compiler+Beta+Release > * lets find not abandoned GUI library for D: > http://deoma-cmd.ru/d/d-projects-list/?q=GUI+!Abandoned > > > I'd like to put http://deoma-cmd.ru/d/d-projects-list/projects.js into > GitHub so developers can fork and edit it. > > I'd like to hear (but yes, I can only read, this is NG) any thoughts about > this idea. > There are already a "List of D projects" pages on the wiki: See the "Projects" section in the left nav panel here: http://prowiki.org/wiki4d/wiki.cgi I'm sure new categories could be added as needed. However, I do like the idea have having something that's searchable/sortable as you suggest. I would suggest though, that it be separated into two main parts: 1. Some sort of central database with a documented, publically-accessible machine interface, not a human interface. (And for the love of god, not XML.) 2. A human-usable frontend. That way, alternative frontends can be created. We could even create a D module (maybe in phobos?) to access the list. (IMO, that's how most web apps should work. And then backends that deal with the same type of data should use standardized interfaces. Hell, that's how *real* apps already work (standard file formats, network protocols, etc) - that's how computing finally achieved interoperability decades ago, before web apps sunk us back into the "no interoperability" dark ages again...But now I'm ranting, I'll stop.) Captcha and/or user management for write-access would be built into #1, not #2. If captcha, then a frontend would tell the backend "I want to write access to X resource, or everything (whatever)" and the backend would send back a captcha image. The front end would then show it to the user, and relay the answer back to the backend. Actually, better yet, the backend would be user accounts only, but then there'd be a special account for anonymous captcha users. It's be one "anon captcha user" account for *each* frontend that wanted to allow captcha. The frontend would then use whatever the hell captcha system it wanted and, if the user succeeds, the frontend would transparently communicate with the backend via its own "anon captcha user" account. And if the captcha system used by the frontend turns out to suck, or be bypassable, or isn't even being used by the frontend, then the backend could disable or revoke that frontend's "anon captcha user" account. The backend could still, optionally, provide its own "official" captcha system to any frontends that wanted to use it.
Re: D projects list
On Thursday, 5 April 2012 at 21:02:15 UTC, Nick Sabalausky wrote: I would suggest though, that it be separated into two main parts: kill both birds with one web.d.
Re: D projects list
On Apr 5, 2012 5:04 PM, "Nick Sabalausky" wrote > I would suggest though, that it be separated into two main parts: > > 1. Some sort of central database with a documented, publically-accessible > machine interface, not a human interface. (And for the love of god, not > XML.) > > 2. A human-usable frontend. > > That way, alternative frontends can be created. We could even create a D > module (maybe in phobos?) to access the list. > > (IMO, that's how most web apps should work. And then backends that deal with > the same type of data should use standardized interfaces. Hell, that's how > *real* apps already work (standard file formats, network protocols, etc) - > that's how computing finally achieved interoperability decades ago, before > web apps sunk us back into the "no interoperability" dark ages again...But > now I'm ranting, I'll stop.) > > Captcha and/or user management for write-access would be built into #1, not > #2. If captcha, then a frontend would tell the backend "I want to write > access to X resource, or everything (whatever)" and the backend would send > back a captcha image. The front end would then show it to the user, and > relay the answer back to the backend. > > Actually, better yet, the backend would be user accounts only, but then > there'd be a special account for anonymous captcha users. It's be one "anon > captcha user" account for *each* frontend that wanted to allow captcha. The > frontend would then use whatever the hell captcha system it wanted and, if > the user succeeds, the frontend would transparently communicate with the > backend via its own "anon captcha user" account. And if the captcha system > used by the frontend turns out to suck, or be bypassable, or isn't even > being used by the frontend, then the backend could disable or revoke that > frontend's "anon captcha user" account. The backend could still, optionally, > provide its own "official" captcha system to any frontends that wanted to > use it I for one, absolutely love the way you think. This is a great idea and the way it should be done. But, what is wrong with xml when used correctly.
Re: D projects list
"Kevin Cox" wrote in message news:mailman.1385.1333660352.4860.digitalmar...@puremagic.com... > On Apr 5, 2012 5:04 PM, "Nick Sabalausky" wrote >> >> [...] > > I for one, absolutely love the way you think. Really? That's pretty uncommon ;) Most people usually just think I'm nuts! > But, what is wrong with xml when used correctly. > Well, it's technically usable, but it's overrated: It's overly-verbose and over-engineered. It seems simple at a glance, and it really *should* be, and *could* have been, but there's a lot of unnecessary complications if you really dig into *proper* XML. I mean heck, just look at the spec: I know formal standards naturally tend to be big and pedantic, but for something as conceptually simple as XML appears to be, it's waaay out of control. Even as a big super-formal standard, XML *still* shouldn't be *that* complex. JSON is somewhat better, and YAML better still. But protocol buffers are vastly superior IMO.
Re: D projects list
On Thursday, 5 April 2012 at 20:12:39 UTC, Denis Shelomovskij wrote: I think it will be great to have a single place for all D related projects so a developer can easily find what is already done (for an example of "I didn't now about you project" see, e.g. "Modern COM Programming in D" thread), what is *planned* and what great projects have already failed (and, maybe, reveal it). A draft variant of how I see such page is this with a few projects added (note "Planned" tag (yes, empty for now)): http://deoma-cmd.ru/d/d-projects-list/ Well, lists have been attempted (Dsource is a good example), but you are obviously looking at something with good filtering. This is good. There is also work for a package management system Orbit, this likely needs similar functionality. Namely, some one needs to build this stuff, it isn't that they aren't wanted.
Re: D projects list
On Thursday, April 05, 2012 17:48:05 Nick Sabalausky wrote: > "Kevin Cox" wrote in message > news:mailman.1385.1333660352.4860.digitalmar...@puremagic.com... > > > On Apr 5, 2012 5:04 PM, "Nick Sabalausky" wrote > > > >> [...] > > > > I for one, absolutely love the way you think. > > Really? That's pretty uncommon ;) Most people usually just think I'm nuts! Maybe he just really likes nuts? ;) - Jonathan M Davis
Re: D projects list
I think this thread misses the key problem with anything like this.. how to curate the list. How will it be kept current? What's the definition of abandoned? Etc, etc. The presentation and storage formats are almost irrelevant as they're the easiest part of the problem. On Fri, 6 Apr 2012, Denis Shelomovskij wrote: > Date: Fri, 06 Apr 2012 00:13:04 +0400 > From: Denis Shelomovskij > Reply-To: digitalmars.D > To: digitalmars-d@puremagic.com > Newsgroups: digitalmars.D > Subject: D projects list > > I think it will be great to have a single place for all D related projects so > a developer can easily find what is already done > (for an example of "I didn't now about you project" see, e.g. "Modern COM > Programming in D" thread), what is *planned* and what great projects have > already failed (and, maybe, reveal it). > > A draft variant of how I see such page is this with a few projects added (note > "Planned" tag (yes, empty for now)): > http://deoma-cmd.ru/d/d-projects-list/ > > Usage examples: > * lets find a D compiler with release or beta maturity: > http://deoma-cmd.ru/d/d-projects-list/?q=Compiler+Beta+Release > * lets find not abandoned GUI library for D: > http://deoma-cmd.ru/d/d-projects-list/?q=GUI+!Abandoned > > > I'd like to put http://deoma-cmd.ru/d/d-projects-list/projects.js into GitHub > so developers can fork and edit it. > > I'd like to hear (but yes, I can only read, this is NG) any thoughts about > this idea. > > -- > ? ?. ??? > Denis V. Shelomovskij >
Re: D projects list
"Jonathan M Davis" wrote in message news:mailman.1392.1333667746.4860.digitalmar...@puremagic.com... > On Thursday, April 05, 2012 17:48:05 Nick Sabalausky wrote: >> "Kevin Cox" wrote in message >> news:mailman.1385.1333660352.4860.digitalmar...@puremagic.com... >> >> > On Apr 5, 2012 5:04 PM, "Nick Sabalausky" wrote >> > >> >> [...] >> > >> > I for one, absolutely love the way you think. >> >> Really? That's pretty uncommon ;) Most people usually just think I'm >> nuts! > > Maybe he just really likes nuts? ;) > Mmmm, pistachios...
Re: D projects list
"Brad Roberts" wrote in message news:alpine.deb.2.00.1204051616190.5...@slice-2.puremagic.com... >I think this thread misses the key problem with anything like this.. how > to curate the list. How will it be kept current? What's the definition > of abandoned? Etc, etc. The presentation and storage formats are almost > irrelevant as they're the easiest part of the problem. > That would indeed be a key aspect. I've been thinking a combination of: 1. Wiki-like editing and 2. Automatic mining from things like github/bitbucket/dsource and a standard metadata protocol/format (maybe tied into orbit?) that project authors can optionally choose to expose. Actually, having this tied in with orbit somehow would probably be a *very* good idea.
Re: D projects list
06.04.2012 1:04, Nick Sabalausky пишет: "Denis Shelomovskij" wrote in message news:jlkubn$k4f$1...@digitalmars.com... I think it will be great to have a single place for all D related projects so a developer can easily find what is already done (for an example of "I didn't now about you project" see, e.g. "Modern COM Programming in D" thread), what is *planned* and what great projects have already failed (and, maybe, reveal it). A draft variant of how I see such page is this with a few projects added (note "Planned" tag (yes, empty for now)): http://deoma-cmd.ru/d/d-projects-list/ Usage examples: * lets find a D compiler with release or beta maturity: http://deoma-cmd.ru/d/d-projects-list/?q=Compiler+Beta+Release * lets find not abandoned GUI library for D: http://deoma-cmd.ru/d/d-projects-list/?q=GUI+!Abandoned I'd like to put http://deoma-cmd.ru/d/d-projects-list/projects.js into GitHub so developers can fork and edit it. I'd like to hear (but yes, I can only read, this is NG) any thoughts about this idea. There are already a "List of D projects" pages on the wiki: See the "Projects" section in the left nav panel here: http://prowiki.org/wiki4d/wiki.cgi I'm sure new categories could be added as needed. However, I do like the idea have having something that's searchable/sortable as you suggest. I would suggest though, that it be separated into two main parts: 1. Some sort of central database with a documented, publically-accessible machine interface, not a human interface. (And for the love of god, not XML.) 2. A human-usable frontend. That way, alternative frontends can be created. We could even create a D module (maybe in phobos?) to access the list. (IMO, that's how most web apps should work. And then backends that deal with the same type of data should use standardized interfaces. Hell, that's how *real* apps already work (standard file formats, network protocols, etc) - that's how computing finally achieved interoperability decades ago, before web apps sunk us back into the "no interoperability" dark ages again...But now I'm ranting, I'll stop.) Captcha and/or user management for write-access would be built into #1, not #2. If captcha, then a frontend would tell the backend "I want to write access to X resource, or everything (whatever)" and the backend would send back a captcha image. The front end would then show it to the user, and relay the answer back to the backend. Actually, better yet, the backend would be user accounts only, but then there'd be a special account for anonymous captcha users. It's be one "anon captcha user" account for *each* frontend that wanted to allow captcha. The frontend would then use whatever the hell captcha system it wanted and, if the user succeeds, the frontend would transparently communicate with the backend via its own "anon captcha user" account. And if the captcha system used by the frontend turns out to suck, or be bypassable, or isn't even being used by the frontend, then the backend could disable or revoke that frontend's "anon captcha user" account. The backend could still, optionally, provide its own "official" captcha system to any frontends that wanted to use it. Totally agree. You aren't a nut. I'm a nut. Because I believes HTML should die with all present web browsers and JS. And XML because of its frighten overuse. And all slow and buggy web apps. And adobe Flash of course should also die. Damn, they have created slow-by-design thing (e.g. see extremely slow YouTube (and other Flash based video players) video rendering - now you really need a modern PC just to watch a video) and now want to make it faster. With graphical acceleration. It results in BSOD-s (yes, I'm on Windows) using web browsers. Current systems was too stable. Users was too slack. Hello unstable times! Yes, I like ranting more than you... Now on business. I have time now and like you suggestions. So, something like it, I hope, will be done in this year. By the way, I have intentionally added repos to projects list - it is because such catalogue should automatically monitor projects states (the last commit date) when possible. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: D projects list
On Fri, 06 Apr 2012 12:34:09 +0400 Denis Shelomovskij wrote: > Because I believes HTML should die with all present web browsers and > JS. And XML because of its frighten overuse. And all slow and buggy > web apps. > And adobe Flash of course should also die. Interesting...but I just wonder what should remain alive? Back to the desktop only? Sincerely, Gour (not liking XML, JS, Flash...) -- Whenever and wherever there is a decline in religious practice, O descendant of Bharata, and a predominant rise of irreligion — at that time I descend Myself. signature.asc Description: PGP signature
Re: D projects list
06.04.2012 12:49, Gour пишет: On Fri, 06 Apr 2012 12:34:09 +0400 Denis Shelomovskij wrote: Because I believes HTML should die with all present web browsers and JS. And XML because of its frighten overuse. And all slow and buggy web apps. And adobe Flash of course should also die. Interesting...but I just wonder what should remain alive? Back to the desktop only? Why? I didn't say anything about TCP/IP - it can remain for a while :) And desktops now aren't in satisfactory state too. Documents are zipped XML-files, IIRC Microsoft will supply JavaScript as a developing language... -- Денис В. Шеломовский Denis V. Shelomovskij
Re: D projects list
On Fri, 06 Apr 2012 13:24:35 +0400 Denis Shelomovskij wrote: > Why? I didn't say anything about TCP/IP - it can remain for a while :) Ahh, OK. ;) > And desktops now aren't in satisfactory state too. Documents are > zipped XML-files, Really? I use AsciiDoc/LaTeX/LyX for documents and those which are in XML (Gnucash, GNumeric,..) are unzipped: :-) Sincerely, Gour -- But a person free from all attachment and aversion and able to control his senses through regulative principles of freedom can obtain the complete mercy of the Lord. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: D projects list
Denis Shelomovskij wrote: > I think it will be great to have a single place for all D related > projects so a developer can easily find what is already done > (for an example of "I didn't now about you project" see, e.g. "Modern > COM Programming in D" thread), what is *planned* and what great projects > have already failed (and, maybe, reveal it). > > A draft variant of how I see such page is this with a few projects added > (note "Planned" tag (yes, empty for now)): > http://deoma-cmd.ru/d/d-projects-list/ > > Usage examples: > * lets find a D compiler with release or beta maturity: > http://deoma-cmd.ru/d/d-projects-list/?q=Compiler+Beta+Release > * lets find not abandoned GUI library for D: > http://deoma-cmd.ru/d/d-projects-list/?q=GUI+!Abandoned > > > I'd like to put http://deoma-cmd.ru/d/d-projects-list/projects.js into > GitHub so developers can fork and edit it. > > I'd like to hear (but yes, I can only read, this is NG) any thoughts > about this idea. > It's a great idea. I used djangopackages.com a lot when I was doing a django project, something like this would be awesome for D. You might like to check it out, it has some nice features. So, apparently djangopackages.com is built with opencomparison, which is an open source project in itself: http://opencomparison.org/
Re: D projects list
On Fri, Apr 06, 2012 at 12:34:09PM +0400, Denis Shelomovskij wrote: [...] > You aren't a nut. I'm a nut. Because I believes HTML should die with > all present web browsers and JS. And XML because of its frighten > overuse. And all slow and buggy web apps. +1. HTML markup is as ugly as a hag, and XML is just... let me just pull up a quote here: "No, John. I want formats that are actually useful, rather than over-featured megaliths that address all questions by piling on ridiculous internal links in forms which are hideously over-complex." -- Simon St. Laurent on xml-dev > And adobe Flash of course should also die. +1. It should have died a DECADE ago. Except that certain interests kept its decaying worm-infested corpse animating even till today. > Damn, they have created slow-by-design thing (e.g. see extremely slow > YouTube (and other Flash based video players) video rendering - now > you really need a modern PC just to watch a video) and now want to > make it faster. With graphical acceleration. It results in BSOD-s > (yes, I'm on Windows) using web browsers. Current systems was too > stable. Users was too slack. Hello unstable times! [...] Why write stable software when it's much easier to write unstable software and ship on time? After all, marketing is what really matters in the end... T -- Государство делает вид, что платит нам зарплату, а мы делаем вид, что работаем.
Re: D projects list
"H. S. Teoh" wrote in message news:mailman.1417.1333721195.4860.digitalmar...@puremagic.com... > On Fri, Apr 06, 2012 at 12:34:09PM +0400, Denis Shelomovskij wrote: >> And adobe Flash of course should also die. > > +1. It should have died a DECADE ago. Except that certain interests kept > its decaying worm-infested corpse animating even till today. > Funny, that's also how I feel about C++. As I've been saying for awhile, a decade of near-zero interest in anything but VM languages is what kept it on life support. Fortunately, D's quickly becoming the successor that's always been needed so C++ will finally be able to RIP. > >> Damn, they have created slow-by-design thing (e.g. see extremely slow >> YouTube (and other Flash based video players) video rendering - now >> you really need a modern PC just to watch a video) and now want to >> make it faster. With graphical acceleration. It results in BSOD-s >> (yes, I'm on Windows) using web browsers. Current systems was too >> stable. Users was too slack. Hello unstable times! > [...] > > Why write stable software when it's much easier to write unstable > software and ship on time? After all, marketing is what really matters > in the end... > I can personally vouch for the fact that there is *nothing* productive about writing software in Flash. C++ is more productive.
Re: D projects list
On Fri, Apr 06, 2012 at 02:52:38PM -0400, Nick Sabalausky wrote: > "H. S. Teoh" wrote in message > news:mailman.1417.1333721195.4860.digitalmar...@puremagic.com... > > On Fri, Apr 06, 2012 at 12:34:09PM +0400, Denis Shelomovskij wrote: > >> And adobe Flash of course should also die. > > > > +1. It should have died a DECADE ago. Except that certain interests > > kept its decaying worm-infested corpse animating even till today. > > > > Funny, that's also how I feel about C++. As I've been saying for > awhile, a decade of near-zero interest in anything but VM languages is > what kept it on life support. I would've felt the same had I known of a suitable replacement for C++ earlier. But for many years it was the only thing I had (besides pure hardcore C) that was even remotely close to what my "ideal" language would be. > Fortunately, D's quickly becoming the successor that's always been > needed so C++ will finally be able to RIP. You have no idea how many times I swore off C++ because of its inherent stupidities (like hash tables not making the C++ standard before C++11, among many other sillinesses), only to have to crawl back on my knees when other alternatives sucked even more. When I finally discovered D, I was almost blown away by how many things it got right, in my book. (I had a list of things I wanted in an ideal language, and D fits so many items on that list it's quite uncanny.) [...] > I can personally vouch for the fact that there is *nothing* productive > about writing software in Flash. C++ is more productive. [...] >From the very first day I heard about Flash, I've had my doubts. It just *smelled* wrong. That was before I even had any idea of how it's implemented. Time has proven that my gut feeling was correct. Flash is a festering wart that should be blotted from off the face of the internet for the sake of the future of humanity. T -- It is of the new things that men tire --- of fashions and proposals and improvements and change. It is the old things that startle and intoxicate. It is the old things that are young. -- G.K. Chesterton
Re: D projects list
"H. S. Teoh" wrote in message news:mailman.1438.1333780033.4860.digitalmar...@puremagic.com... > On Fri, Apr 06, 2012 at 02:52:38PM -0400, Nick Sabalausky wrote: >> "H. S. Teoh" wrote in message >> news:mailman.1417.1333721195.4860.digitalmar...@puremagic.com... >> > On Fri, Apr 06, 2012 at 12:34:09PM +0400, Denis Shelomovskij wrote: >> >> And adobe Flash of course should also die. >> > >> > +1. It should have died a DECADE ago. Except that certain interests >> > kept its decaying worm-infested corpse animating even till today. >> > >> >> Funny, that's also how I feel about C++. As I've been saying for >> awhile, a decade of near-zero interest in anything but VM languages is >> what kept it on life support. > > I would've felt the same had I known of a suitable replacement for C++ > earlier. But for many years it was the only thing I had (besides pure > hardcore C) that was even remotely close to what my "ideal" language > would be. > Getting fed up with C/C++ many years ago prompted me to seek out alternatives, which happily led me to D back around the 0.8x or 0.9x days. Heh, I remember being mildly disappointed that 0.99 was followed by 0.100 instead of 1.0 ;) > >> Fortunately, D's quickly becoming the successor that's always been >> needed so C++ will finally be able to RIP. > > You have no idea how many times I swore off C++ because of its inherent > stupidities (like hash tables not making the C++ standard before C++11, > among many other sillinesses), only to have to crawl back on my knees > when other alternatives sucked even more. > Yea, the problem IMO is that for at least a full decade eveyone had drunk the Sun Kool-Aid and was obsessed with VMs and "interpreted" and all that silly nonsence. So outside Digital Mars, *real* language development took a ten year hiatus. Only now are there languages like Rust and Issue 9 trying to catch up with D. >> I can personally vouch for the fact that there is *nothing* productive >> about writing software in Flash. C++ is more productive. > [...] > >From the very first day I heard about Flash, I've had my doubts. It just > *smelled* wrong. That was before I even had any idea of how it's > implemented. Time has proven that my gut feeling was correct. Flash is a > festering wart that should be blotted from off the face of the internet > for the sake of the future of humanity. > Heh, you've got better intuition than me then :) Until I actually tried to use it, I don't remember having any problems with Flash beyond terrible, horrible abuses of it like "Flash Sites", "Flash Intros", and what turned out to essentially be the second coming of animated GIFs. The *one* good use of it is stupid/goofy/hilarious shit like "And Whe!" and other such things that make Newgrounds worthwhile. :) But, I had *no hint* of the endless mountains of technical problems with it until I tried it.
Re: D projects list
Am Fri, 6 Apr 2012 14:52:38 -0400 schrieb "Nick Sabalausky" : > "H. S. Teoh" wrote in message > news:mailman.1417.1333721195.4860.digitalmar...@puremagic.com... > > On Fri, Apr 06, 2012 at 12:34:09PM +0400, Denis Shelomovskij wrote: > >> And adobe Flash of course should also die. > > > > +1. It should have died a DECADE ago. Except that certain interests kept > > its decaying worm-infested corpse animating even till today. > > > > Funny, that's also how I feel about C++. As I've been saying for awhile, a > decade of near-zero interest in anything but VM languages is what kept it on > life support. Fortunately, D's quickly becoming the successor that's always > been needed so C++ will finally be able to RIP. Hehe, that might work for your own projects, but realistically look at how many more people are knowledgeable about C++, companies have big projects written in C++, desktop environments are written in C++, many tools (internal, commercial, free) exist for C++, it is a stable target and so on. D is still adding features that make it interesting for certain audiences: SSE intrinsics for the Manus of the world (game devs), annotations for GUI/ORM/RPC bindings, short lambda syntax. Not every feature of D is subjectively better than what is available in C++, but I assume most C++ devs miss _something_ that D offers or will offer (in case of the shared implementation). -- Marco
