www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D vs C++11

reply =?UTF-8?B?IkVyw6hiZSI=?= <erebe erebe.eu> writes:
Hello student here,

I have started to learn D a few months ago with Andrei's book (I 
really liked arguments about design decisions), but as the same 
time I was learning new features of C++11, and now I'm really 
confused. (As learning projects, I've done an IRC Bot in D and an 
IPv6 stack in C++11)

D is a great language and introduce a lot of features I really 
like (range, property, UFCS, great metaprogramming, ...) but 
C++11 and the new standard librairy are well supported now.

I have some solid experience with C++, so I know how cumbersome 
C++ could be (C++11 and universal reference ?), but D has a lot 
of features too and (as C++) a slow learning curve.

I would like to konw the point of view of the community about 
C++11 in regard of D ? Is the gap between D and C++11 is getting 
thinner ? Do you think D will keep attracting people while at the 
same time C++11 has more support (debugger, IDE, Librairies, 
Documentation) ?
Nov 02 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-02 18:03, "Erèbe" wrote:
 Hello student here,

 I have started to learn D a few months ago with Andrei's book (I really
 liked arguments about design decisions), but as the same time I was
 learning new features of C++11, and now I'm really confused. (As
 learning projects, I've done an IRC Bot in D and an IPv6 stack in C++11)

 D is a great language and introduce a lot of features I really like
 (range, property, UFCS, great metaprogramming, ...) but C++11 and the
 new standard librairy are well supported now.

 I have some solid experience with C++, so I know how cumbersome C++
 could be (C++11 and universal reference ?), but D has a lot of features
 too and (as C++) a slow learning curve.

I would say that D is fairly scalable in it's set of features. You can (mostly) program in D as you would in, say, Java. Then you can start bringing in more features of the language as you see fit in your own comfortable speed.
 I would like to konw the point of view of the community about C++11 in
 regard of D ? Is the gap between D and C++11 is getting thinner ? Do you
 think D will keep attracting people while at the same time C++11 has
 more support (debugger, IDE, Librairies, Documentation) ?

I would absolutely say that the gap is getting thinner. I would mostly say that with C++11 C++ has finally started to catch up with D and the rest of the world. -- /Jacob Carlborg
Nov 02 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-02 21:12, so wrote:

 Serious? It doesn't even have a "static if".

I said the gap is getting thinner, not that is gone. It got foreach, some form of CTFE, static assert, lambda to mention a few new features. -- /Jacob Carlborg
Nov 02 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/2/2012 2:33 PM, Jacob Carlborg wrote:
 I said the gap is getting thinner, not that is gone. It got foreach, some form
 of CTFE, static assert, lambda to mention a few new features.

No ranges. No purity. No immutability. No modules. No dynamic closures. No mixins. Little CTFE. No slicing. No delegates. No shared. No template symbolic arguments. No template string arguments. No alias this.
Nov 02 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 11/02/2012 10:53 PM, Walter Bright wrote:
 On 11/2/2012 2:33 PM, Jacob Carlborg wrote:
 I said the gap is getting thinner, not that is gone. It got foreach,
 some form
 of CTFE, static assert, lambda to mention a few new features.

No ranges. No purity. No immutability. No modules. No dynamic closures. No mixins. Little CTFE. No slicing. No delegates. No shared. No template symbolic arguments. No template string arguments. No alias this.

No static if. Limited forward references. No real function local aggregate types. No real nested classes. No local template instantiation. No nested functions. No value range propagation for implicit conversions. No built-in string support. No built-in unicode support. No template guards. No inout. No default-initialization. No return type deduction for non-lambdas. No generic lambdas. No type deduction for lambda parameter types. No super. Less powerful typeof that is called decltype. No is-expressions. No compile-time reflection. No thread-local by default. No UFCS. No tuple/sequence types. No sequence auto-expansion. No sane built-in array types. No tuple slicing. No .init/.min/.max/etc. No kind of static foreach. No new scopes introduced in case statements. No block statements in a for-loop initializer. No optional parentheses on function calls. No implicit reference types. No ^^ operator. No binary ! operator. No built-in complex number types. Less comparison operators. None of eg. bearophile's enhancement requests. ... in no particular order, afaik, and to name a few. :o)
Nov 02 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 11/03/2012 08:19 AM, Paulo Pinto wrote:
 On Friday, 2 November 2012 at 23:08:00 UTC, Timon Gehr wrote:
 On 11/02/2012 10:53 PM, Walter Bright wrote:
 On 11/2/2012 2:33 PM, Jacob Carlborg wrote:
 I said the gap is getting thinner, not that is gone. It got foreach,
 some form
 of CTFE, static assert, lambda to mention a few new features.

No ranges. No purity. No immutability. No modules. No dynamic closures. No mixins. Little CTFE. No slicing. No delegates. No shared. No template symbolic arguments. No template string arguments. No alias this.

No static if. Limited forward references. No real function local aggregate types. No real nested classes. No local template instantiation. No nested functions. No value range propagation for implicit conversions. No built-in string support. No built-in unicode support. No template guards. No inout. No default-initialization. No return type deduction for non-lambdas. No generic lambdas. No type deduction for lambda parameter types. No super. Less powerful typeof that is called decltype. No is-expressions. No compile-time reflection. No thread-local by default. No UFCS. No tuple/sequence types. No sequence auto-expansion. No sane built-in array types. No tuple slicing. No .init/.min/.max/etc. No kind of static foreach. No new scopes introduced in case statements. No block statements in a for-loop initializer. No optional parentheses on function calls. No implicit reference types. No ^^ operator. No binary ! operator. No built-in complex number types. Less comparison operators. None of eg. bearophile's enhancement requests. ... in no particular order, afaik, and to name a few. :o)

What I have learned in all my years of enterprise development is that all those features have zero value for business. Languages get adopted because of business value, not due to the coolness of their feature set, how boring it may sell. If we want to sell D to companies using C++ for years, slowly migrating to JVM, .NET worlds, or just updating their codebases to C++11, then we need to sell D's business value not feature lists.

Maybe you misunderstood. I am not trying to make D look good. The point of the post was to show that C++11 and D are quite different languages. Walter's list was rather short.
Nov 03 2012
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 11/02/2012 11:47 PM, Nick Sabalausky wrote:
 On Fri, 02 Nov 2012 14:53:05 -0700
 Walter Bright <newshound2 digitalmars.com> wrote:

 On 11/2/2012 2:33 PM, Jacob Carlborg wrote:
 I said the gap is getting thinner, not that is gone. It got
 foreach, some form of CTFE, static assert, lambda to mention a few
 new features.

No ranges. No purity. No immutability. No modules. No dynamic closures. No mixins. Little CTFE. No slicing. No delegates. No shared. No template symbolic arguments. No template string arguments. No alias this.

No proper modules. No properties. Slow compilation. No reference semantics for classes. No scope guards. Little default initialization. Goofy ptr and func-ptr declaration syntax. Goofy rules about what is/isn't virtual. Lots of undefined behavior. Forward declarations. Things I'm not entirely certain about: No IFTI?

IFTI is there.
 No polysemous literals?

If I understand the term right, then 0 is polysemous.
 No finally?

Good catch. Also: No scope guards. No exception root type. No exception chaining, ...
Nov 02 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-02 22:53, Walter Bright wrote:

 No ranges. No purity. No immutability. No modules. No dynamic closures.
 No mixins. Little CTFE. No slicing. No delegates. No shared. No template
 symbolic arguments. No template string arguments. No alias this.

Why do you think I'm here, using D instead :) -- /Jacob Carlborg
Nov 03 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-02 23:47, Nick Sabalausky wrote:

 No proper modules. No properties. Slow compilation. No reference
 semantics for classes. No scope guards. Little default initialization.
 Goofy ptr and func-ptr declaration syntax. Goofy rules about what
 is/isn't virtual. Lots of undefined behavior. Forward declarations.

I've read Scott Meyer's Effective C++. On one of the first few pages it says something: "C++ can be hard, but if you think of it as three separate languages it much easier. One for the imperative, C inherited part, one for the object oriented part and one for the template part". With that statement it's no turning back. It can never be a good language it can only become worse, no feature in the world can make up for that. -- /Jacob Carlborg
Nov 03 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-04 00:12, H. S. Teoh wrote:

 My point is, there may are a lot of people with that knowledge in
 the community, and a little impulsion from the root should be
 helpful, because modern support will make D shine even brighter.

We *have* had repeated requests for this stuff, and I'm sure whoever has that knowledge in this community have taken heed, but apparently that hasn't been enough. So maybe what we really need is somebody to take the initiative to be the first to make it all happen, I guess?

The biggest problem that I see is the lack of time. I'm working on several tools that I think is useful when developing with D. But I have a full time job where I don't use D, so I don't have much time to work on D related projects at all. -- /Jacob Carlborg
Nov 04 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-03 17:08, H. S. Teoh wrote:
 I find it strange that every so often people clamor for IDE support,
 syntax highlighting, debugger support, etc., yet nobody seems to be
 willing to contribute actual code. Don't like something about the
 current state of D development tools? Well then do something about it.
 The source code is there for a reason, and it's not just to make people
 feel all warm and fuzzy inside because now we can label ourselves "open
 source".

It's not that simple, for me it's mostly the lack of time to work on D related projects. See one of my other replies: http://forum.dlang.org/thread/iokgislnlzsvsosmqbbv forum.dlang.org?page=6#post-k75ijh:241aic:241:40digitalmars.com -- /Jacob Carlborg
Nov 04 2012
prev sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
11/6/2012 4:09 PM, Regan Heath пишет:
 On Sat, 03 Nov 2012 12:46:17 -0000, Erèbe <erebe erebe.eu> wrote:
 .. a Visual studio plugin where you need to buy a liscence in order to
 have the IDE.

I was under the impression that VisualD worked with "express" versions of Visual Studio, which are free.

version of it. Express versions are specifically non-extandable in any way. So If you need both C# and C++ express then you'd have to have 2 independent setups of VS. -- Dmitry Olshansky
Nov 06 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Jacob Carlborg:

 I would say that D is fairly scalable in it's set of features. 
 You can (mostly) program in D as you would in, say, Java

D offers most features present in Java, but the relative efficiency of some operations is not the same. HotSpot de-virtualizes, unroll run-time-bound loops, and most importantly has an efficient generational GC (and other newer GCs like G1) that changes significantly the efficiency of allocations and memory releases. The result is that if you program in D creating lot of short lived garbage as you do in Java, you will see a low(er) performance. So in D it's better to allocate in-place with structs where possible.
 I would absolutely say that the gap is getting thinner. I would 
 mostly say that with C++11 C++ has finally started to catch up 
 with D and the rest of the world.

C++ is a moving target :-) http://root.cern.ch/drupal/content/c14 Bye, bearophile
Nov 02 2012
prev sibling next sibling parent "so" <so so.so> writes:
On Friday, 2 November 2012 at 18:34:13 UTC, Jacob Carlborg wrote:

 I would absolutely say that the gap is getting thinner. I would 
 mostly say that with C++11 C++ has finally started to catch up 
 with D and the rest of the world.

Serious? It doesn't even have a "static if".
Nov 02 2012
prev sibling next sibling parent "Rob T" <rob ucora.com> writes:
On Friday, 2 November 2012 at 20:12:05 UTC, so wrote:
 On Friday, 2 November 2012 at 18:34:13 UTC, Jacob Carlborg 
 wrote:

 I would absolutely say that the gap is getting thinner. I 
 would mostly say that with C++11 C++ has finally started to 
 catch up with D and the rest of the world.

Serious? It doesn't even have a "static if".

.. and not even an array type, or string type, and the template system remains in a semi-useless state in terms of practicality. But it is true that C++11 has added features that attempt to catch up. I recall being very eager to try the new improvements out as soon as they were available, yet soon afterwards I find myself investing my time in D. C++ is permanently bogged down by too much legacy features that are difficult to remove or repair, and I'm convinced that C++ cannot be fixed without a redesign from the ground up. D has effectively "fixed" C++ already, so I agree with the claims that D can be considered as a good C++ replacement. Also I expect that D will continue to evolve and improve, so it may be that C++ can never catch up. --rt
Nov 02 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, November 02, 2012 21:12:02 so wrote:
 On Friday, 2 November 2012 at 18:34:13 UTC, Jacob Carlborg wrote:
 I would absolutely say that the gap is getting thinner. I would
 mostly say that with C++11 C++ has finally started to catch up
 with D and the rest of the world.

Serious? It doesn't even have a "static if".

C++11 definitely makes the gap thinner than it was with C++98/03. That doesn't mean that the gap isn't there, and with pretty much anything involving conditional compilation, D is way, way ahead of C++11. C++ templates are virtually unusable in comparison to D templates. There's no reason that C++ couldn't gain those abilities, but even with C++11, it still isn't there yet (though at least they finally have variadic templates). That said, there _are_ some cool things in C++11 that we don't have (e.g. async is pretty cool, and while we have some cool threading stuff, we don't have anything quite like it yet). So, we can still learn from C++ even if we do better than they do in general. - Jonathan M Davis
Nov 02 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 02 Nov 2012 21:25:49 +0100
"Rob T" <rob ucora.com> wrote:

 On Friday, 2 November 2012 at 20:12:05 UTC, so wrote:
 On Friday, 2 November 2012 at 18:34:13 UTC, Jacob Carlborg 
 wrote:

 I would absolutely say that the gap is getting thinner. I 
 would mostly say that with C++11 C++ has finally started to 
 catch up with D and the rest of the world.

Serious? It doesn't even have a "static if".

.. and not even an array type, or string type, and the template system remains in a semi-useless state in terms of practicality. But it is true that C++11 has added features that attempt to catch up. I recall being very eager to try the new improvements out as soon as they were available, yet soon afterwards I find myself investing my time in D. C++ is permanently bogged down by too much legacy features that are difficult to remove or repair, and I'm convinced that C++ cannot be fixed without a redesign from the ground up. D has effectively "fixed" C++ already, so I agree with the claims that D can be considered as a good C++ replacement. Also I expect that D will continue to evolve and improve, so it may be that C++ can never catch up.

///ditto To be fair though, asking "C++ vs D" on a D newsgroup is clearly going to be tilted more towards the D end ;) But yea, personally, I feel that C++11 is merely playing "catch up", and doing so on a broken leg. C++ does have the advantage of being almost universally supported with mature toolchains on pretty much any platform. D's toolchain is very mature on Linux, OSX and (aside from the COFF/OMF stuff) Win32, but still needs work for other platforms and also could use some work for dynamic libs. So whenever D is a viable option, I always go for it because I find it to be vastly superior, even to C++11 (which is merely "slightly less crappy than old C++", IMO). And then when I *have* to use C++, I do so while wishing I was doing it in D. FWIW, I did this little writeup (ok, "rant" ;) ) on my opinion of C++ vs D: https://semitwist.com/articles/article/view/top-d-features-i-miss-in-c
Nov 02 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 2 November 2012 at 21:53:06 UTC, Walter Bright wrote:
 On 11/2/2012 2:33 PM, Jacob Carlborg wrote:
 I said the gap is getting thinner, not that is gone. It got 
 foreach, some form
 of CTFE, static assert, lambda to mention a few new features.

No ranges. No purity. No immutability. No modules. No dynamic closures. No mixins. Little CTFE. No slicing. No delegates. No shared. No template symbolic arguments. No template string arguments. No alias this.

Agree with everything, but D is a hard sell in the enterprise given C++'s maturity.
Nov 02 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Friday, 2 November 2012 at 22:02:04 UTC, Nick Sabalausky wrote:
 So whenever D is a viable option, I always go for it because I 
 find it to be vastly superior, even to C++11 (which is merely 
 "slightly less crappy than old C++", IMO). And then when I 
 *have* to use C++, I do so while wishing I was doing it in D.

I remember trying to read and learn C++ years and years ago. Got a headache just trying to read & understand it (2005ish). It felt like it wasn't consistent with C, it was ugly, friend functions never quite made sense, the default 'streams' library should have been written differently (It was originally an example class correct?) Let's see what else. Headers, document twice, virtual has to be explicitly declared so inheritance is more limited. Constructors had to be the same name as the class, just a bunch of things that didn't quite seem like they fit right. Reading/learning how the STL works they based everything off pointers (which makes some sense) but rather than make a new type and work on that they tried to make that backwards compatible with C, so to use iterators you simulate a pointer. I can understand it's limitations on systems back when memory and drive space was scarce, but we're way past that now. "Polish a turd, it's still a turd!" -- Peanut
Nov 02 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 02 Nov 2012 14:53:05 -0700
Walter Bright <newshound2 digitalmars.com> wrote:

 On 11/2/2012 2:33 PM, Jacob Carlborg wrote:
 I said the gap is getting thinner, not that is gone. It got
 foreach, some form of CTFE, static assert, lambda to mention a few
 new features.

No ranges. No purity. No immutability. No modules. No dynamic closures. No mixins. Little CTFE. No slicing. No delegates. No shared. No template symbolic arguments. No template string arguments. No alias this.

No proper modules. No properties. Slow compilation. No reference semantics for classes. No scope guards. Little default initialization. Goofy ptr and func-ptr declaration syntax. Goofy rules about what is/isn't virtual. Lots of undefined behavior. Forward declarations. Things I'm not entirely certain about: No IFTI? No polysemous literals? No finally?
Nov 02 2012
prev sibling next sibling parent "Rob T" <rob ucora.com> writes:
On Friday, 2 November 2012 at 22:47:20 UTC, Nick Sabalausky wrote:
 No proper modules. No properties. Slow compilation. No reference
 semantics for classes. No scope guards. Little default 
 initialization.
 Goofy ptr and func-ptr declaration syntax. Goofy rules about 
 what
 is/isn't virtual. Lots of undefined behavior. Forward 
 declarations.

 Things I'm not entirely certain about:

 No IFTI? No polysemous literals? No finally?

The number one thing I hate the most about D is that because it is so good, the few things that are not so good (or missing) REALLY stand out and make you 10x more upset about them than you should be. With C++, you learn to accept all the crap and not complain about it so much. --rt
Nov 02 2012
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 11/03/2012 12:05 AM, Rob T wrote:
 With C++, you learn to accept all the crap and not complain about it so much.

Well, it's not so much you learn to accept all the crap as, it's a sufficiently standard tool and so universally adopted, that accepting the crap is often a worthwhile trade for the stuff you get in return (interoperability, range of developers out there who can help you, number of useful libraries ...). But in my case it's definitely a resigned rather than eager compromise. I'm currently working on a simulation involving a bipartite graph, which is proving quite a bit of fun, but in the back of my head right now is a little voice going, "Hey, I bet at some point you're going to need one of the general-purpose graph libraries out there and I bet that's going to make it more convenient to do this in C++." And another voice going "Arrgh no God please don't make me." Now that said, the question that started this thread seems an apt one and is one I'd been wondering about myself. I don't have the expertise to write it personally, but I'd be really happy to see an in-depth article comparing C++11 and D, not a paean to one or the other, but a careful description of the advantages and disadvantages of each (preferably supported by code examples).
Nov 02 2012
prev sibling next sibling parent "so" <so so.so> writes:
On Friday, 2 November 2012 at 22:47:20 UTC, Nick Sabalausky wrote:

 No polysemous literals?

Since when D has polysemous literals? Link please.
Nov 02 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 2 November 2012 at 21:53:06 UTC, Walter Bright wrote:
 On 11/2/2012 2:33 PM, Jacob Carlborg wrote:
 I said the gap is getting thinner, not that is gone. It got 
 foreach, some form
 of CTFE, static assert, lambda to mention a few new features.


 No ranges.

Boost.Range
 No purity.

Yeah :(
 No immutability.

Hmm const objects do it sorta-kinda... ok maybe not lol
 No modules.

Apparently these are being considered for the next version!
 No dynamic closures.

Hmm? std::function works just fine with lambdas
 No mixins.

I don't _quite_ miss these ;)
 Little CTFE.

Yeah. :\
 No slicing.

You can sorta-kinda emulate these with iterators. On the plus side, there's no ambiguity as to value vs. reference semantics in C++.
 No delegates.

std::function?
 No shared.

I don't think many people find themselves using shared in D unfortunately.
 No template symbolic arguments.

I'm not sure I know what this is referring to. Do you mean aliases?
 No template string arguments.

Ah I really miss this in C++...
 No alias this.

While alias this is nice, I don't seem to need it as often in C++ as you'd imagine. It would come in handy sometimes, to be sure, but it's not a deal breaker IMO.
Nov 02 2012
prev sibling next sibling parent "mist" <none none.none> writes:
Regarding delegates - I think deal is that none of this C++ stuff 
can automatically capture local function context with delegate, 
so there are no _real_ delegates.

On Saturday, 3 November 2012 at 02:08:13 UTC, Mehrdad wrote:
 On Friday, 2 November 2012 at 21:53:06 UTC, Walter Bright wrote:
 On 11/2/2012 2:33 PM, Jacob Carlborg wrote:
 I said the gap is getting thinner, not that is gone. It got 
 foreach, some form
 of CTFE, static assert, lambda to mention a few new features.


 No ranges.

Boost.Range
 No purity.

Yeah :(
 No immutability.

Hmm const objects do it sorta-kinda... ok maybe not lol
 No modules.

Apparently these are being considered for the next version!
 No dynamic closures.

Hmm? std::function works just fine with lambdas
 No mixins.

I don't _quite_ miss these ;)
 Little CTFE.

Yeah. :\
 No slicing.

You can sorta-kinda emulate these with iterators. On the plus side, there's no ambiguity as to value vs. reference semantics in C++.
 No delegates.

std::function?
 No shared.

I don't think many people find themselves using shared in D unfortunately.
 No template symbolic arguments.

I'm not sure I know what this is referring to. Do you mean aliases?
 No template string arguments.

Ah I really miss this in C++...
 No alias this.

While alias this is nice, I don't seem to need it as often in C++ as you'd imagine. It would come in handy sometimes, to be sure, but it's not a deal breaker IMO.

Nov 02 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Saturday, 3 November 2012 at 02:27:21 UTC, mist wrote:
 Regarding delegates - I think deal is that none of this C++ 
 stuff can automatically capture local function context with 
 delegate, so there are no _real_ delegates.

I don't understand what you mean... std::function<int(int)> make_adder(int a) { return [=](int b) { return a + b; }; }
Nov 02 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 2 November 2012 at 23:08:00 UTC, Timon Gehr wrote:
 On 11/02/2012 10:53 PM, Walter Bright wrote:
 On 11/2/2012 2:33 PM, Jacob Carlborg wrote:
 I said the gap is getting thinner, not that is gone. It got 
 foreach,
 some form
 of CTFE, static assert, lambda to mention a few new features.

No ranges. No purity. No immutability. No modules. No dynamic closures. No mixins. Little CTFE. No slicing. No delegates. No shared. No template symbolic arguments. No template string arguments. No alias this.

No static if. Limited forward references. No real function local aggregate types. No real nested classes. No local template instantiation. No nested functions. No value range propagation for implicit conversions. No built-in string support. No built-in unicode support. No template guards. No inout. No default-initialization. No return type deduction for non-lambdas. No generic lambdas. No type deduction for lambda parameter types. No super. Less powerful typeof that is called decltype. No is-expressions. No compile-time reflection. No thread-local by default. No UFCS. No tuple/sequence types. No sequence auto-expansion. No sane built-in array types. No tuple slicing. No .init/.min/.max/etc. No kind of static foreach. No new scopes introduced in case statements. No block statements in a for-loop initializer. No optional parentheses on function calls. No implicit reference types. No ^^ operator. No binary ! operator. No built-in complex number types. Less comparison operators. None of eg. bearophile's enhancement requests. ... in no particular order, afaik, and to name a few. :o)

What I have learned in all my years of enterprise development is that all those features have zero value for business. Languages get adopted because of business value, not due to the coolness of their feature set, how boring it may sell. If we want to sell D to companies using C++ for years, slowly migrating to JVM, .NET worlds, or just updating their codebases to C++11, then we need to sell D's business value not feature lists. -- Paulo
Nov 03 2012
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On 11/3/2012 12:19 AM, Paulo Pinto wrote:
 On Friday, 2 November 2012 at 23:08:00 UTC, Timon Gehr wrote:
 
 What I have learned in all my years of enterprise development is that all
those features have zero value for business.
 
 Languages get adopted because of business value, not due to the coolness of
their feature set, how boring it may sell.
 
 If we want to sell D to companies using C++ for years, slowly migrating to
JVM, .NET worlds, or just updating their
 codebases to C++11, then we need to sell D's business value not feature lists.
 
 -- 
 Paulo

In my experience (which admittedly is limited to several companies that are all technology companies, which introduces an specific bias) it's the engineers which ultimately define the languages used. Eventually after enough people want to use <foo>, it gets used. It has little to do with business value or rational logic and more to do with determination and momentum.
Nov 03 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Saturday, 3 November 2012 at 07:35:26 UTC, Brad Roberts wrote:
 On 11/3/2012 12:19 AM, Paulo Pinto wrote:
 On Friday, 2 November 2012 at 23:08:00 UTC, Timon Gehr wrote:
 
 What I have learned in all my years of enterprise development 
 is that all those features have zero value for business.
 
 Languages get adopted because of business value, not due to 
 the coolness of their feature set, how boring it may sell.
 
 If we want to sell D to companies using C++ for years, slowly 
 migrating to JVM, .NET worlds, or just updating their
 codebases to C++11, then we need to sell D's business value 
 not feature lists.
 
 --
 Paulo

In my experience (which admittedly is limited to several companies that are all technology companies, which introduces an specific bias) it's the engineers which ultimately define the languages used. Eventually after enough people want to use <foo>, it gets used. It has little to do with business value or rational logic and more to do with determination and momentum.

Of course each of us works in very different eco-systems. In my case it is enterprise world of Fortune 500 companies, new technologies only get introduced in two forms: - customer requires technology X (e.g. Objective-C for iApps, EC2 for deployments, ...) - company can earn big money if it sells consulting support with technology X -- Paulo
Nov 03 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 03 Nov 2012 08:19:15 +0100
"Paulo Pinto" <pjmlp progtools.org> wrote:
 
 What I have learned in all my years of enterprise development is 
 that all those features have zero value for business.
 
 Languages get adopted because of business value, not due to the 
 coolness of their feature set, how boring it may sell.
 
 If we want to sell D to companies using C++ for years, slowly 
 migrating to JVM, .NET worlds, or just updating their codebases 
 to C++11, then we need to sell D's business value not feature 
 lists.
 

The problem with "business value" is that there's two types of it: First there's "reality" business value which *naturally* includes, among other things, how well it works for the people actually using it. But then there's also "MBA/PHB" business value which *doesn't* factor that in because...well I can't finish that sentence without delving into rather graphic profanity, anatomical references, and general offensiveness to an entire profession ;)
Nov 03 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Saturday, 3 November 2012 at 10:33:54 UTC, Nick Sabalausky 
wrote:
 On Sat, 03 Nov 2012 08:19:15 +0100
 "Paulo Pinto" <pjmlp progtools.org> wrote:
 
 What I have learned in all my years of enterprise development 
 is that all those features have zero value for business.
 
 Languages get adopted because of business value, not due to 
 the coolness of their feature set, how boring it may sell.
 
 If we want to sell D to companies using C++ for years, slowly 
 migrating to JVM, .NET worlds, or just updating their 
 codebases to C++11, then we need to sell D's business value 
 not feature lists.
 

The problem with "business value" is that there's two types of it: First there's "reality" business value which *naturally* includes, among other things, how well it works for the people actually using it. But then there's also "MBA/PHB" business value which *doesn't* factor that in because...well I can't finish that sentence without delving into rather graphic profanity, anatomical references, and general offensiveness to an entire profession ;)

Sadly I meant the MBA type of business value. :(
Nov 03 2012
prev sibling next sibling parent =?UTF-8?B?IkVyw6hiZSI=?= <erebe erebe.eu> writes:
 To be fair though, asking "C++ vs D" on a D newsgroup is 
 clearly going
 to be tilted more towards the D end ;) But yea, personally, I 
 feel that
 C++11 is merely playing "catch up", and doing so on a broken 
 leg.

I didn't expect that much of response to my question, but it was my intent to see the point of view of the community even if I know it is biased. All of you name a lot of missing features in C++11, while I completely agree upon that makes D cool, don't you fear a turtle effect if D only focus on features ? I explain myself, C++ is a well supported language and come with a lot of tools which could help/improve your developpement. In the decision of taking D xor C++, developper could think "Hey I already know C++ and how to work with it (aka tools), let just stick with it and wait for the new C++11 features coming for free". In that situation, C++11's no effort (or little to learn new additions) seem more rewarding than learning D, so why try ? Is there a point in the D roadmap where we will see "Okay, D has enough features, let add some support to the language now" ? Because in my opinion D is for now just a language, a awesome one yes, but not yet a good environnement for developper. C(++) had man (K in vim) and gdb, pascal his own ide, dynamic languages have their interpreters, Java eclipse, what has D ? Nearly no support in vim (my editor of choice), a Plugin for eclipse wich force you to stick with an older version, a Visual studio plugin where you need to buy a liscence in order to have the IDE. The only viable choice for me is the plugin for monodevelop which is really great but no debugger (assert is enough for now). Support should not be a top priority for the D-core now that the language is well featured ? Something coherent with what already exist (dmd) ?
Nov 03 2012
prev sibling next sibling parent "mist" <none none.none> writes:
http://codepad.org/s38L9tUr

Am I misunderstanding something regarding C++ here?

On Saturday, 3 November 2012 at 02:44:49 UTC, Mehrdad wrote:
 On Saturday, 3 November 2012 at 02:27:21 UTC, mist wrote:
 Regarding delegates - I think deal is that none of this C++ 
 stuff can automatically capture local function context with 
 delegate, so there are no _real_ delegates.

I don't understand what you mean... std::function<int(int)> make_adder(int a) { return [=](int b) { return a + b; }; }

Nov 03 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Erèbe:

 Is there a point in the D roadmap where we will see "Okay, D 
 has enough features, let add some support to the language now" 
 ? Because in my opinion D is for now just a language, a awesome 
 one yes, but not yet a good environnement for developper.

You are missing some essential points. First of all features are not just "done": they have corner cases to be fixed, details to be improved, they need to be fully implemented, they need to become efficient, bugs need to be removed, new needs ask for new parts, there are new CPUs to support, new OSes, new vector extensions added to CPUs, and so on. So in the end the work for the core language developers never ends. Putting such developers at work on tools is not a good idea, because then no one does the essential work on the core language and they will often be newbies regarding tools. So it becomes a lose-lose situation. You can't stop the development of the core language to develop tools, it causes a disaster. Usually you have to build a language good enough that it attracts other people, that are willing to work on tools and external modules :-) Bye, bearophile
Nov 03 2012
prev sibling next sibling parent 1100110 <0b1100110 gmail.com> writes:
On Sat, 03 Nov 2012 07:46:17 -0500, Er=C3=A8be <erebe erebe.eu> wrote:

 To be fair though, asking "C++ vs D" on a D newsgroup is clearly goin=


 to be tilted more towards the D end ;) But yea, personally, I feel th=


 C++11 is merely playing "catch up", and doing so on a broken leg.

I didn't expect that much of response to my question, but it was my =

 intent to see the point of view of the community even if I know it is =

 biased.


 All of you name a lot of missing features in C++11, while I completely=

 agree upon that makes D cool, don't you fear a turtle effect if D only=

 focus on features ?
 I explain myself, C++ is a well supported language and come with a lot=

 of tools which could help/improve your developpement. In the decision =

 taking D xor C++, developper could think "Hey I already know C++ and h=

 to work with it (aka tools), let just stick with it and wait for the n=

 C++11 features coming for free". In that situation, C++11's no effort =

 (or little to learn new additions) seem more rewarding than learning D=

 so why try ?

 Is there a point in the D roadmap where we will see "Okay, D has enoug=

 features, let add some support to the language now" ? Because in my  =

 opinion D is for now just a language, a awesome one yes, but not yet a=

 good environnement for developper.

 C(++) had man (K in vim) and gdb, pascal his own ide, dynamic language=

 have their interpreters, Java eclipse, what has D ?

 Nearly no support in vim (my editor of choice), a Plugin for eclipse  =

 wich force you to stick with an older version, a Visual studio plugin =

 where you need to buy a liscence in order to have the IDE. The only  =

 viable choice for me is the plugin for monodevelop which is really gre=

 but no debugger (assert is enough for now).

 Support should not be a top priority for the D-core now that the  =

 language is well featured ? Something coherent with what already exist=

 (dmd) ?

Nearly no support in Vim? Are you joking? What does Vim not support fo= r = D that you want it to? -- = Using Opera's revolutionary email client: http://www.opera.com/mail/
Nov 03 2012
prev sibling next sibling parent "Oleg Kuporosov" <Oleg.Kuporosov gmail.com> writes:
On Saturday, 3 November 2012 at 12:46:18 UTC, Erèbe wrote:

 Nearly no support in vim (my editor of choice), a Plugin for 
 eclipse wich force you to stick with an older version, a Visual 
 studio plugin where you need to buy a liscence in order to have 
 the IDE. The only viable choice for me is the plugin for 
 monodevelop which is really great but no debugger (assert is 
 enough for now).

Hi Erèbe, you can use free Visual Studio Shell with VisualD.. http://www.microsoft.com/en-us/download/details.aspx?id=30670 Thanks, Oleg.
Nov 03 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Saturday, 3 November 2012 at 12:56:36 UTC, mist wrote:
 http://codepad.org/s38L9tUr

 Am I misunderstanding something regarding C++ here?

 On Saturday, 3 November 2012 at 02:44:49 UTC, Mehrdad wrote:
 On Saturday, 3 November 2012 at 02:27:21 UTC, mist wrote:
 Regarding delegates - I think deal is that none of this C++ 
 stuff can automatically capture local function context with 
 delegate, so there are no _real_ delegates.

I don't understand what you mean... std::function<int(int)> make_adder(int a) { return [=](int b) { return a + b; }; }


You could use the following instead auto f = [&](){ return x; }; but then you cannot return the lambda. -- Paulo
Nov 03 2012
prev sibling next sibling parent "mist" <none none.none> writes:
Ye, that is exactly what I meant when said C++ has no real 
context capture and thus no real delegates here.

On Saturday, 3 November 2012 at 15:04:25 UTC, Paulo Pinto wrote:
 On Saturday, 3 November 2012 at 12:56:36 UTC, mist wrote:
 http://codepad.org/s38L9tUr

 Am I misunderstanding something regarding C++ here?

 On Saturday, 3 November 2012 at 02:44:49 UTC, Mehrdad wrote:
 On Saturday, 3 November 2012 at 02:27:21 UTC, mist wrote:
 Regarding delegates - I think deal is that none of this C++ 
 stuff can automatically capture local function context with 
 delegate, so there are no _real_ delegates.

I don't understand what you mean... std::function<int(int)> make_adder(int a) { return [=](int b) { return a + b; }; }


You could use the following instead auto f = [&](){ return x; }; but then you cannot return the lambda. -- Paulo

Nov 03 2012
prev sibling next sibling parent "Kiith-Sa" <kiithsacmp gmail.com> writes:
On Saturday, 3 November 2012 at 12:46:18 UTC, Erèbe wrote:
 To be fair though, asking "C++ vs D" on a D newsgroup is 
 clearly going
 to be tilted more towards the D end ;) But yea, personally, I 
 feel that
 C++11 is merely playing "catch up", and doing so on a broken 
 leg.

I didn't expect that much of response to my question, but it was my intent to see the point of view of the community even if I know it is biased. All of you name a lot of missing features in C++11, while I completely agree upon that makes D cool, don't you fear a turtle effect if D only focus on features ? I explain myself, C++ is a well supported language and come with a lot of tools which could help/improve your developpement. In the decision of taking D xor C++, developper could think "Hey I already know C++ and how to work with it (aka tools), let just stick with it and wait for the new C++11 features coming for free". In that situation, C++11's no effort (or little to learn new additions) seem more rewarding than learning D, so why try ? Is there a point in the D roadmap where we will see "Okay, D has enough features, let add some support to the language now" ? Because in my opinion D is for now just a language, a awesome one yes, but not yet a good environnement for developper. C(++) had man (K in vim) and gdb, pascal his own ide, dynamic languages have their interpreters, Java eclipse, what has D ? Nearly no support in vim (my editor of choice), a Plugin for eclipse wich force you to stick with an older version, a Visual studio plugin where you need to buy a liscence in order to have the IDE. The only viable choice for me is the plugin for monodevelop which is really great but no debugger (assert is enough for now). Support should not be a top priority for the D-core now that the language is well featured ? Something coherent with what already exist (dmd) ?

http://forum.dlang.org/thread/khmerwhgumluolifxtix forum.dlang.org#post-khmerwhgumluolifxtix:40forum.dlang.org
Nov 03 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Nov 03, 2012 at 09:02:58AM -0500, 1100110 wrote:
 On Sat, 03 Nov 2012 07:46:17 -0500, Erbe <erebe erebe.eu> wrote:

Nearly no support in vim (my editor of choice), a Plugin for
eclipse wich force you to stick with an older version, a Visual
studio plugin where you need to buy a liscence in order to have
the IDE. The only viable choice for me is the plugin for
monodevelop which is really great but no debugger (assert is
enough for now).


 Nearly no support in Vim?  Are you joking?  What does Vim not
 support for D that you want it to?

Yeah I use vim too, and I don't see any problem. But then again, maybe he's looking for syntax highlighting or that kind of stuff which I don't use. But still. Oleg has a point -- IDE support and other such things need to be done by other people than the core developers, who need to focus on honing the language. I find it strange that every so often people clamor for IDE support, syntax highlighting, debugger support, etc., yet nobody seems to be willing to contribute actual code. Don't like something about the current state of D development tools? Well then do something about it. The source code is there for a reason, and it's not just to make people feel all warm and fuzzy inside because now we can label ourselves "open source". T -- Klein bottle for rent ... inquire within. -- Stephen Mulraney
Nov 03 2012
prev sibling next sibling parent 1100110 <0b1100110 gmail.com> writes:
On Sat, 03 Nov 2012 11:08:16 -0500, H. S. Teoh <hsteoh quickfur.ath.cx> =
 =

wrote:

 On Sat, Nov 03, 2012 at 09:02:58AM -0500, 1100110 wrote:
 On Sat, 03 Nov 2012 07:46:17 -0500, Er=C3=A8be <erebe erebe.eu> wrote=


 [...]
Nearly no support in vim (my editor of choice), a Plugin for
eclipse wich force you to stick with an older version, a Visual
studio plugin where you need to buy a liscence in order to have
the IDE. The only viable choice for me is the plugin for
monodevelop which is really great but no debugger (assert is
enough for now).


 Nearly no support in Vim?  Are you joking?  What does Vim not
 support for D that you want it to?

Yeah I use vim too, and I don't see any problem. But then again, maybe=

 he's looking for syntax highlighting or that kind of stuff which I don=

 use.

 But still. Oleg has a point -- IDE support and other such things need =

 be done by other people than the core developers, who need to focus on=

 honing the language.

 I find it strange that every so often people clamor for IDE support,
 syntax highlighting, debugger support, etc., yet nobody seems to be
 willing to contribute actual code. Don't like something about the
 current state of D development tools? Well then do something about it.=

 The source code is there for a reason, and it's not just to make peopl=

 feel all warm and fuzzy inside because now we can label ourselves "ope=

 source".


 T

Check out D.Announce. Even *more* support for D in vim. I'm happy enough with my current setup, but I also want to play with thi= s.. -- = Wait. Define 'within'.
Nov 03 2012
prev sibling next sibling parent "Rob T" <rob ucora.com> writes:
Geany on Linux has good D support. It seems more like an editor 
than a true IDE, but it does have some project management 
features and ability to execute builds.

Codeblocks is a complete feature rich C++ cross platform IDE, it 
has some D support but it is incomplete last I checked.

--rt
Nov 03 2012
prev sibling next sibling parent 1100110 <0b1100110 gmail.com> writes:
On Sat, 03 Nov 2012 12:23:17 -0500, Rob T <rob ucora.com> wrote:

 Geany on Linux has good D support. It seems more like an editor than a  
 true IDE, but it does have some project management features and ability  
 to execute builds.

 Codeblocks is a complete feature rich C++ cross platform IDE, it has  
 some D support but it is incomplete last I checked.

 --rt

I LOVE geany. Especially with the built in terminal. I bound ctr-alt to switch to the terminal and ctr-super to switch to the editor. When I need to easily look through multiple files, geany is my goto. I found that the Terminal was easier and far more hackable for builds than any built in execution.. But that's just me. I think Geany's D Syntax highlighting could use a little work(But it does highlight aliases as types, which is awesome), but It's never been enough of an issue for me to actually fix it. (And I might simply be running an older release) Also I think Geany's block insert and block highlighting is easier than Vim's. I never really liked CodeBlocks, It seems like it has soo many things that I wouldn't use simply because the manual method is easier. But it is important to mention, since I assume lots of people don't know about all of the IDE's that support D.
Nov 03 2012
prev sibling next sibling parent "Froglegs" <lugtug yahoo.com> writes:
  I'm not convinced D has caught up to C++ yet from a usability 
standpoint, as the tools are still quite bad(VisualD -not- fun).

  But the other day I tried out MonoD and it shows promise, auto 
completion is solid, and it seems to have at least some of the 
features I've come to expect from using Visual C++ with Visual 
Assist. Its still behind though, perhaps in another year?

  Ideally VisualD would support the completion/reflection stuff 
MonoD has, and that would be a pretty awesome package that I 
think would attract many more developers.
Nov 03 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Nov 03, 2012 at 08:19:15AM +0100, Paulo Pinto wrote:
[...]
 Languages get adopted because of business value, not due to the
 coolness of their feature set, how boring it may sell.
 
 If we want to sell D to companies using C++ for years, slowly
 migrating to JVM, .NET worlds, or just updating their codebases to
 C++11, then we need to sell D's business value not feature lists.

I understand that business types ultimately don't care for feature lists, etc., but the thing about D isn't so much the features themselves, but rather how those features save development costs. For example, I've been working on this particular project in my day job for a while now, and I see almost every day how the lack of a certain feature in C++ or C (or the bad design/implementation of said feature) is costing lots and lots of duplicated or plain wasted development time. Lots of code is copy-n-pasted, or otherwise duplicated, because of the lack of reusable constructs. A certain database subsystem was designed with a particular use in mind, with structs that may contain some nested lists, etc.. Recently they wanted to introduce a JSON-based interface for it. It ended up requiring a lot of duplicated logic, simply because the lack of destructors in C required special-casing a lot of code just to clean things up properly. If this had been done in D, first of all, there wouldn't even need to be an elaborate subsystem for mapping structs to SQL: we'd just write a template-based wrapper that used compile-time introspection to automate most of the code. That, or used AA's and alias this or opDispatch to simulate the structs, which can be done in a day or two's work as opposed to 2 months. Then for the JSON-based interface, the GC would just take care of any garbage that gets generated, so no special casing would be needed. This alone would have saved hundreds of hours of development work, not to mention alleviated many subtle pointer bugs and other problems that we've had to fix over the years, which probably adds up to another hundreds of hours. So much time is wasted in working around C/C++ deficiencies and cleaning up the resulting mess, that I think that alone would have justified using D instead. I mean, we're talking about hundreds of development hours that could've been invested in actual *development* rather than mere maintenance and cleanup. Hundreds of employee hours, which come with the cost of employee benefits, associated costs, etc.. About the only good thing with the current situation is that we'll never be out of a job, because there is no end to the mess that comes from C/C++. T -- If it breaks, you get to keep both pieces. -- Software disclaimer notice
Nov 03 2012
prev sibling next sibling parent reply "Malte Skarupke" <malteskarupke web.de> writes:
On Friday, 2 November 2012 at 17:03:38 UTC, Erèbe wrote:
 Hello student here,

 I have started to learn D a few months ago with Andrei's book 
 (I really liked arguments about design decisions), but as the 
 same time I was learning new features of C++11, and now I'm 
 really confused. (As learning projects, I've done an IRC Bot in 
 D and an IPv6 stack in C++11)

 D is a great language and introduce a lot of features I really 
 like (range, property, UFCS, great metaprogramming, ...) but 
 C++11 and the new standard librairy are well supported now.

 I have some solid experience with C++, so I know how cumbersome 
 C++ could be (C++11 and universal reference ?), but D has a lot 
 of features too and (as C++) a slow learning curve.

 I would like to konw the point of view of the community about 
 C++11 in regard of D ? Is the gap between D and C++11 is 
 getting thinner ? Do you think D will keep attracting people 
 while at the same time C++11 has more support (debugger, IDE, 
 Librairies, Documentation) ?

I've learned C++ in the last two years and learned D in the last couple months, and I slightly prefer C++ over D. When I started using C++11, I took for granted that all the features just work. Using D, I realize that that is actually unusual. In D you still encounter compiler bugs or inconsistent behavior way too often, and I have workarounds all over my code. I also prefer C++ being much more explicit about everything it does. For example I prefer the lambdas with a capture list over D delegates. And in D you've got the core runtime allocating memory without me being aware of it all the time. Sure, it gets garbage collected at some point, but I'd rather that it didn't do it at all. D also makes the const keyword more annoying than it should be. In C++ you typically use it as an indicator for the intent of the interface and to prevent you from making mistakes. There are some programmers who find it very annoying and who never use const. In D I am leaning towards being one of those programmers, even though I belong to the group who uses const more strictly in C++. That being said I do think that I write better code in D, but I wouldn't use it for real projects any time soon. It just isn't ready, and I'm sure that my existing code will break several more times in future compiler versions. At the moment the issue is that C++11 is pretty good, and D is not ready. So people will start using C++11 and they'll see that it's good enough and they'll never migrate. The best features of D don't matter if the language is a bit annoying as soon as you leave the space of clean and nice examples.
Nov 03 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 11/03/2012 11:01 PM, Malte Skarupke wrote:
 ...
 I've learned C++ in the last two years and learned D in the last couple
 months, and I slightly prefer C++ over D. When I started using C++11, I
 took for granted that all the features just work.

I have run into bugs in both g++ and clang, and I do not actually use C++ for anything beyond experimenting.
 Using D, I realize that that is actually unusual.

There are many bugs in the implementation, but stuff often works.
 In D you still encounter compiler bugs or
 inconsistent behavior way too often, and I have workarounds all over my
 code.

Do you not have 'workarounds' all over your C++ code? There are conferences about how to work around C++'s limitations. It is fun, but unproductive.
Nov 03 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 03 Nov 2012 13:46:17 +0100
"Er=E8be" <erebe erebe.eu> wrote:
=20
 All of you name a lot of missing features in C++11, while I=20
 completely agree upon that makes D cool, don't you fear a turtle=20
 effect if D only focus on features ?
 I explain myself, C++ is a well supported language and come with=20
 a lot of tools which could help/improve your developpement. In=20
 the decision of taking D xor C++, developper could think "Hey I=20
 already know C++ and how to work with it (aka tools), let just=20
 stick with it and wait for the new C++11 features coming for=20
 free". In that situation, C++11's no effort (or little to learn=20
 new additions) seem more rewarding than learning D, so why try ?
=20

That is a problem we face, but it's true of any up-and-coming language, and it's not really specific to "focus on features". I'd say the biggest selling points to C++ users would be much better productivity, and much better safety without sacrificing efficiency. In other words, C++'s two biggest known weak points.
 Is there a point in the D roadmap where we will see "Okay, D has=20
 enough features, let add some support to the language now" ?=20

We've *already* been at that point there for some time. Language features are no longer added without strong justification. And the primary focuses are on toolchain and fleshing out the std lib.
 C(++) had man (K in vim) and gdb, pascal his own ide, dynamic=20
 languages have their interpreters, Java eclipse, what has D ?
=20

Such things are typically cross-language these days (well, except for interpreters). What what D has is "All that cross-language stuff". As examples: a lot of people use gdb with D, D syntax highlighting is in damn near every editor on the planet (and definitely all scintilla-based ones), and there are D plugins for all the major IDEs: Eclipse, VisualD and Mono-Develop. That said, D does have DustMite which isn't an editor anything like that, but it is damn awesome: https://github.com/CyberShadow/DustMite/wiki
 Nearly no support in vim (my editor of choice), a Plugin for=20
 eclipse wich force you to stick with an older version,

Hmm, I guess I wouldn't have known. I can't use vi, and I don't use Eclipse (too bloated).
 a Visual studio plugin where you need to buy a liscence in order to
 have the IDE.

I don't know where you got that, but that's that remotely true. It works fine with the free VS shell, even says so on the VisualD homepage, and I've done it that way myself.
 The only viable choice for me is the plugin for=20
 monodevelop which is really great but no debugger (assert is=20
 enough for now).
=20

Lots of people here use vim and swear by it. And again, gdb for debugging. (But I'm a printf-debugging fan myself. Or writeln in D's case ;) )
 Support should not be a top priority for the D-core now that the=20
 language is well featured ? Something coherent with what already=20
 exist (dmd) ?

Ideally, yes, but they have other big things to work on too, and there's only so much manpower to go around. Especially since very few of the people who really want or expect big IDE features have been willing to join up and lend a hand.
Nov 03 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Saturday, 3 November 2012 at 15:06:36 UTC, mist wrote:
 Ye, that is exactly what I meant when said C++ has no real 
 context capture and thus no real delegates here.

The std::function is just as "real" as any delegate. And the variable capture [&] is just as real as in any other language. The only difference is that you have to manage the lifetimes of variables instead of having a GC randomly pause your app. So if you want to _return_ an object, you have to make sure it's valid. That makes it no less "real" than any other type of delegate; it's just forcing you to think about the lifetime of the context. Welcome to C++ I guess?
Nov 03 2012
prev sibling next sibling parent =?UTF-8?B?IkVyw6hiZSI=?= <erebe erebe.eu> writes:
On Saturday, 3 November 2012 at 13:17:46 UTC, bearophile wrote:
 Erèbe:

 Is there a point in the D roadmap where we will see "Okay, D 
 has enough features, let add some support to the language now" 
 ? Because in my opinion D is for now just a language, a 
 awesome one yes, but not yet a good environnement for 
 developper.

You are missing some essential points. First of all features are not just "done": they have corner cases to be fixed, details to be improved, they need to be fully implemented, they need to become efficient, bugs need to be removed, new needs ask for new parts, there are new CPUs to support, new OSes, new vector extensions added to CPUs, and so on. So in the end the work for the core language developers never ends. Putting such developers at work on tools is not a good idea, because then no one does the essential work on the core language and they will often be newbies regarding tools. So it becomes a lose-lose situation. You can't stop the development of the core language to develop tools, it causes a disaster. Usually you have to build a language good enough that it attracts other people, that are willing to work on tools and external modules :-) Bye, bearophile

Duly noted
On Saturday, 3 November 2012 at 15:25:07 UTC, Kiith-Sa wrote:

 http://forum.dlang.org/thread/khmerwhgumluolifxtix forum.dlang.org#post-khmerwhgumluolifxtix:40forum.dlang.org

Thanks I will try ! On Saturday, 3 November 2012 at 16:06:11 UTC, H. S. Teoh wrote:
 Yeah I use vim too, and I don't see any problem. But then 
 again, maybe
 he's looking for syntax highlighting or that kind of stuff 
 which I don't
 use.

I only use IDE at the beginning (for a new language or librairy) because I found autocompletion helpful, after that I switch back to vim.
 But still. Oleg has a point -- IDE support and other such 
 things need to
 be done by other people than the core developers, who need to 
 focus on
 honing the language.

 I find it strange that every so often people clamor for IDE 
 support,
 syntax highlighting, debugger support, etc., yet nobody seems 
 to be
 willing to contribute actual code. Don't like something about 
 the
 current state of D development tools? Well then do something 
 about it.
 The source code is there for a reason, and it's not just to 
 make people
 feel all warm and fuzzy inside because now we can label 
 ourselves "open
 source".


 T

I was expecting the argument of "Not happy ? Do it yourself !". I shall be glad to do it by myself, but I don't have the knowledge (of the language, of the codebase) yet, and in regards with my studies and the time I can dedicate to my side-projects, I will not be started before 6 months or more. My point is, there may are a lot of people with that knowledge in the community, and a little impulsion from the root should be helpful, because modern support will make D shine even brighter. I will work toward this direction but it will take me time.
Nov 03 2012
prev sibling next sibling parent "Tommi" <tommitissari hotmail.com> writes:
On Saturday, 3 November 2012 at 22:01:21 UTC, Malte Skarupke
wrote:
 D also makes the const keyword more annoying than it should be.

What kind of annoyances regarding const have you encountered in D?
Nov 03 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 03 Nov 2012 23:01:19 +0100
"Malte Skarupke" <malteskarupke web.de> wrote:

 On Friday, 2 November 2012 at 17:03:38 UTC, Er=E8be wrote:
 Hello student here,

 I have started to learn D a few months ago with Andrei's book=20
 (I really liked arguments about design decisions), but as the=20
 same time I was learning new features of C++11, and now I'm=20
 really confused. (As learning projects, I've done an IRC Bot in=20
 D and an IPv6 stack in C++11)

 D is a great language and introduce a lot of features I really=20
 like (range, property, UFCS, great metaprogramming, ...) but=20
 C++11 and the new standard librairy are well supported now.

 I have some solid experience with C++, so I know how cumbersome=20
 C++ could be (C++11 and universal reference ?), but D has a lot=20
 of features too and (as C++) a slow learning curve.

 I would like to konw the point of view of the community about=20
 C++11 in regard of D ? Is the gap between D and C++11 is=20
 getting thinner ? Do you think D will keep attracting people=20
 while at the same time C++11 has more support (debugger, IDE,=20
 Librairies, Documentation) ?

I've learned C++ in the last two years and learned D in the last=20 couple months, and I slightly prefer C++ over D. When I started=20 using C++11, I took for granted that all the features just work.=20 Using D, I realize that that is actually unusual. In D you still=20 encounter compiler bugs or inconsistent behavior way too often,=20 and I have workarounds all over my code.

 D also makes the const keyword more annoying than it should be.=20
 In C++ you typically use it as an indicator for the intent of the=20
 interface and to prevent you from making mistakes. There are some=20
 programmers who find it very annoying and who never use const. In=20
 D I am leaning towards being one of those programmers, even=20
 though I belong to the group who uses const more strictly in C++.
=20

Bringing things back to another branch of this thread: What you say here is a big part of the reason our core devs aren't focused on IDE sorts of things right now. Because this core stuff needs to come first. That said, my experience with the current state of D seems to be better than yours, unfortunately. But maybe that's because I was using D five or so years ago (and mostly gave up on C++ close to 10 years ago) and so the thing I see most is the improvement since then (plus, of course, I've become more accustomed to dealing with the issues when they do pop up). You do raise some fair points. *Personally* I find dealing with D's occasional hiccups to be much more than totally compensated for by D's bene= fits. But YMMV, of course.
Nov 03 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 03 Nov 2012 23:45:58 +0100
"Tommi" <tommitissari hotmail.com> wrote:

 On Saturday, 3 November 2012 at 22:01:21 UTC, Malte Skarupke
 wrote:
 D also makes the const keyword more annoying than it should be.

What kind of annoyances regarding const have you encountered in D?

My understanding is that Phobos, and even Object, aren't totally const-correct yet, so that's given people some trouble. ('Course, my info on that might be outdated, I don't know.)
Nov 03 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Nov 03, 2012 at 11:37:15PM +0100, "Erbe" wrote:
[...]
 On Saturday, 3 November 2012 at 16:06:11 UTC, H. S. Teoh wrote:
Yeah I use vim too, and I don't see any problem. But then again,
maybe he's looking for syntax highlighting or that kind of stuff
which I don't
use.

I only use IDE at the beginning (for a new language or librairy) because I found autocompletion helpful, after that I switch back to vim.

So what's missing about D support in vim?
But still. Oleg has a point -- IDE support and other such things need
to be done by other people than the core developers, who need to
focus on honing the language.

I find it strange that every so often people clamor for IDE support,
syntax highlighting, debugger support, etc., yet nobody seems to be
willing to contribute actual code. Don't like something about the
current state of D development tools? Well then do something about
it.  The source code is there for a reason, and it's not just to make
people feel all warm and fuzzy inside because now we can label
ourselves "open source".


 I was expecting the argument of "Not happy ? Do it yourself !". I
 shall be glad to do it by myself, but I don't have the knowledge (of
 the language, of the codebase) yet, and in regards with my studies
 and the time I can dedicate to my side-projects, I will not be
 started before 6 months or more.

What I said wasn't directed at you specifically. I was just saying that the state of IDE support, etc., are the way they are, because so far few have stepped up to do something about it. We've had a lot of people complain about lack of IDE support, debugger, etc., but we haven't had many volunteers to actually do the work, so there's really not much that can be done about it. For one thing, I only use vim with gdb and command-line tools, so I wouldn't even know where to begin in terms of adding/improving IDE support for D. I don't even use syntax highlighting or any of that stuff.
 My point is, there may are a lot of people with that knowledge in
 the community, and a little impulsion from the root should be
 helpful, because modern support will make D shine even brighter.

We *have* had repeated requests for this stuff, and I'm sure whoever has that knowledge in this community have taken heed, but apparently that hasn't been enough. So maybe what we really need is somebody to take the initiative to be the first to make it all happen, I guess?
 I will work toward this direction but it will take me time.

Best of luck to you, then! Maybe you can be the first one to make it happen. T -- A bend in the road is not the end of the road unless you fail to make the turn. -- Brian White
Nov 03 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 3 Nov 2012 16:12:44 -0700
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:

 I don't even use syntax highlighting

Now that's hard-core!
Nov 03 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Nov 03, 2012 at 07:14:18PM -0400, Nick Sabalausky wrote:
 On Sat, 3 Nov 2012 16:12:44 -0700
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:
 
 I don't even use syntax highlighting

Now that's hard-core!

I've *tried* using it before, mind you. I just found the colors more distracting than helpful. But then, I'm just a crazy command-line-only relic from the 70's. My window manager is something that turns X11 into a glorified text console. I don't do desktops at all. (Sometimes I chmod -w $HOME in order to prevent Firefox from creating a Desktop subdir in my home.) So I don't expect many to share my views on these things. :-P T -- Let's call it an accidental feature. -- Larry Wall
Nov 03 2012
prev sibling next sibling parent "Malte Skarupke" <malteskarupke web.de> writes:
On Saturday, 3 November 2012 at 22:45:59 UTC, Tommi wrote:
 On Saturday, 3 November 2012 at 22:01:21 UTC, Malte Skarupke
 wrote:
 D also makes the const keyword more annoying than it should be.

What kind of annoyances regarding const have you encountered in D?

To start off it's simple things like this: void main() { struct A { this(int x) { this.x = x; } int x; } const(A) a = A(5); A b = a; } This doesn't compile. And it will probably never compile. The issue is that struct A has a context pointer and because of transitive const, you are not allowed to copy that pointer. And you can not specify your own copy constructor because all copy constructors happens post-blit, at which point you'd already have a non-const pointer. So that will probably never change. But that's not a big problem. It's more been stuff like me implementing an equivalent of std::function from C++. (as I said I like to be more explicit about things than delegates) I uploaded the code for it here: http://dpaste.dzfl.pl/60a46049 As you can see there isn't a single mention of const in there. All I wanted was a const and an immutable version of opCall and better const correctness for opAssign, but I just couldn't get it to compile. It'd be great if you could have a look at it. If you succeed in getting that code to be const correct, please tell me how you did it. (Also worth mentioning: I ran into at least two more issues in just this one file: 1. I couldn't specify the templated opAssign that C++'s std::function has because of a compiler bug (which will be fixed in DMD 2.061) and I had to define opAssign twice because there is no way to specify a function which accepts both an rvalue and an lvalue) That being said the code still is much cleaner than it would be in C++. Another issue I've had was trying to implement my own hashtable which has more deterministic memory behavior. In that I found it very difficult to get the ranges for byKey and byValue to be const correct. I think I had issues with the "inout" keyword when I was passing pointers marked as inout to the range object. I think I'll revisit that one tomorrow and maybe I'll then post code here.
Nov 03 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, November 03, 2012 09:08:16 H. S. Teoh wrote:
 Yeah I use vim too, and I don't see any problem. But then again, maybe
 he's looking for syntax highlighting or that kind of stuff which I don't
 use.

D does syntax highlighting just fine. It's distributed with vim, and if you want the latest version, you can grab it from here ( https://github.com/JesseKPhillips/d.vim ), though for some reason, more recent versions are missing from the page at vim.org ( http://www.vim.org/scripts/script.php?script_id=379 ). Jesse Phillips maintains vim's D syntax file, and he's still an active member of the community. I don't know of anything that vim doesn't support with D that it supports with C or C++. It may be that there are further plugins that you can get which work with C/C++ but not D (e.g. I have no idea whether cscope would work or not; I expect that plugins like that would choke on templated stuff though). It doesn't have IDE-level features in general, but vim doesn't have those normally. It's a power user level text editor, not an IDE. - Jonathan M Davis
Nov 03 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, November 03, 2012 13:46:17 Er=C3=A8be wrote:
 Nearly no support in vim (my editor of choice)

What does vim do for D that it doesn't do for C/C++? Some plugins that = you can=20 use for C/C++ probably won't work for D, but vim itself should support = D just=20 as well as C/C++. vim is a power user level editor, not an IDE, so most= of the=20 types of features that really require understanding the language wouldn= 't be=20 in vim anyway.
 Support should not be a top priority for the D-core now that the
 language is well featured ? Something coherent with what already
 exist (dmd) ?

The folks who work on the compiler and libraries are unlikely to be the= same=20 folks working on tools for D. Stuff that requires compiler support does= get=20 done by the compiler folks (e.g. providing debug symbols that gdb can u= se),=20 but IDE stuff? That's not going to be done by the people working on the= core=20 language. It's generally a completely different set of people who end u= p=20 working on that sort of stuff, and even without adding lots of new feat= ures to=20 the language, there's still a lot for the core developers to be working= on in=20 terms of bug fixing or fleshing out the standard library. And D isn't a= dding=20 features left and right. In fact, it's mostly feature frozen. So, that = long=20 list of features says nothing about the focus of the D community at thi= s point=20 as far as work goes. That just means that lots of work was done in the = past. The main focuses of the compiler folks at this point are compiler featu= res=20 which will help make D more fully usable (e.g. adding 64-bit support to= =20 Windows) and bug fixes. We're not adding much in the way of features to= the=20 language at all at this point. So, their focus is likely where it shoul= d be,=20 aside perhaps from which bug in particular gets fixed first. If you want better tools beyond the compiler, then other people need to= write=20 them. And other people _do_ write them. We have VisualD, Mono-D, etc. M= aybe=20 there aren't enough people working on that sort of thing, but work is=20= definitely being done there. But if you're looking for something like a fully-fledged IDE for D writ= ten=20 completely in D, then you're going to have a very long time to wait, be= cause=20 that's the sort of thing that takes years and lots of people to write. = And=20 given that all there is that needs to be done for D, that's arguably a = very=20 poor use of time anyway, because solid plugins for IDEs like Ecilpse an= d=20 Monodevelop will do the job just fine for the most part and require far= less=20 effort. Maybe we'll get it someday, but no time soon. And other people are putting time and effort into other types of tools = to=20 improve D from the standpoint of tools (e.g. some work has been done on= =20 getting a package management tool for D similar to what some other lang= uages=20 have). So, work _is_ being done. It just takes time, and we arguably do= n't=20 have enough people much of anywhere in the various areas of D developme= nt. So,=20 pretty much everything is slower than we might like it to be. But it _i= s_=20 improving, and work is still getting done. - Jonathan M Davis
Nov 03 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 2 Nov 2012 18:47:22 -0400
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:

 On Fri, 02 Nov 2012 14:53:05 -0700
 Walter Bright <newshound2 digitalmars.com> wrote:
 
 On 11/2/2012 2:33 PM, Jacob Carlborg wrote:
 I said the gap is getting thinner, not that is gone. It got
 foreach, some form of CTFE, static assert, lambda to mention a few
 new features.

No ranges. No purity. No immutability. No modules. No dynamic closures. No mixins. Little CTFE. No slicing. No delegates. No shared. No template symbolic arguments. No template string arguments. No alias this.

No proper modules. No properties. Slow compilation. No reference semantics for classes. No scope guards. Little default initialization. Goofy ptr and func-ptr declaration syntax. Goofy rules about what is/isn't virtual. Lots of undefined behavior. Forward declarations. Things I'm not entirely certain about: No IFTI? No polysemous literals? No finally?

And no underscores in numeric literals. It's a minor little thing, but it's so very nice to have: No more carefully counting digits to make sure you got it right. :)
Nov 03 2012
prev sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Sat, 03 Nov 2012 12:46:17 -0000, Er=E8be <erebe erebe.eu> wrote:
 .. a Visual studio plugin where you need to buy a liscence in order to=

 have the IDE.

I was under the impression that VisualD worked with "express" versions o= f = Visual Studio, which are free. R -- = Using Opera's revolutionary email client: http://www.opera.com/mail/
Nov 06 2012