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 "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 parent reply "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
next sibling parent reply "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
parent reply 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
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 parent reply =?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
next sibling parent reply "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
parent reply =?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
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Nov 03, 2012 at 11:37:15PM +0100, "Erèbe" 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
next sibling parent reply 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
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 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 reply 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=




g

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




at

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


ow  =


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


ew  =


 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=


h  =


 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=


s  =


 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=


at  =


 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
next sibling parent reply "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, Erèbe <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
next sibling parent reply 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=


'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 peopl=


e

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


n

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


It works with free Visual Studio _Shell_. The so-called integrated 
version of it.

Express versions are specifically non-extandable in any way. So If you 

setups of VS.


-- 
Dmitry Olshansky
Nov 06 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 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 "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 reply 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
next sibling parent reply "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
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 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 "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 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 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 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 reply "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
next sibling parent reply 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
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 reply 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
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 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 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 "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
parent reply "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
parent reply "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
parent reply "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
parent reply "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
parent reply "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
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 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 Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Friday, 2 November 2012 at 21:53:06 UTC, 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.


And tens of more fundamental improvements...
Jun 28 2018
prev sibling parent reply John parker <adamwatson522 gmail.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".


If you use a static variable in your program then you can not 
change the value of that variable. To make fixed a variable 
static you have to use static keyword.you can also take help from 
https://printerchatsupport.co.uk/dell-printer-support/ for your 
query. In a program, if you use static variable then you have to 
declare it as a global variable.
Jun 28 2018
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, June 28, 2018 20:25:15 John parker via Digitalmars-d 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".


 If you use a static variable in your program then you can not
 change the value of that variable. To make fixed a variable
 static you have to use static keyword.you can also take help from
 https://printerchatsupport.co.uk/dell-printer-support/ for your
 query. In a program, if you use static variable then you have to
 declare it as a global variable.


I would point out that you're necro-ing a thread that's nearly 6 years old.

- Jonathan M Davis
Jun 28 2018
prev 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
next sibling parent reply "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
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 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 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) ?


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