It seems like the C++ committee is speeding up development adding lots of the goodies from D like Ranges, static if, template contraints etc.

Will D still have a case when C++ gets this done?

I wonder if Andrei is part of the C++ Ranges Study Group?

The Future of C++:
http://channel9.msdn.com/Events/Build/2012/2-005

/Jonas

On Mon, 05 Nov 2012 11:00:27 +0100
"jdrewsen" <nospam4321@hotmail.com> wrote:

> It seems like the C++ committee is speeding up development adding lots of the goodies from D like Ranges, static if, template contraints etc.
> 
> Will D still have a case when C++ gets this done?
> 


Yes, even if they go and add all of D's features, D will still be much
cleaner. (IMO)

On Monday, 5 November 2012 at 10:22:02 UTC, Nick Sabalausky wrote:
> On Mon, 05 Nov 2012 11:00:27 +0100
> "jdrewsen" <nospam4321@hotmail.com> wrote:
>
>> It seems like the C++ committee is speeding up development adding lots of the goodies from D like Ranges, static if, template contraints etc.
>> 
>> Will D still have a case when C++ gets this done?
>> 
>
>
> Yes, even if they go and add all of D's features, D will still be much
> cleaner. (IMO)

C++'s "range" is actually a wrapper over an iterator "first-last" pair. While it does bring the convenience of D's ranges to C++, it remains hobbled in terms of efficiency and implementation. C++'s paradigm is pointers and iterators. At best, you can sparkle some ranges over it, but you'll never shift the paradigm.

--------
The thing with C++'s new feature is that it requires developers to be on the bleeding edge of C++ knowledge. It's fine for the enthusiasts that read programming journals on their week-ends (like you and I), but not for the standard developer. Not to mention, even then, the syntax is hard as hell: lambdas in for loops? I have to look up the syntax every time. automatic type inference of the return value of a function? "auto foo() -> declype(...)", what...?

All these functionalities are great, but also out of reach. Most of my colleagues still struggle with "simple" design patters such as strategies, or just plain algorithms with functors. Everytime I say something like "awesome, C++ will allow type inference" or "yay, RValue references!" they look at me like I'm some kind of weird space alien...

--------
D packages the whole thing in an easy to use but complete package. C++ just stacks complicated stuff on top of a hard to use core.

On Monday, 5 November 2012 at 10:00:29 UTC, jdrewsen wrote:
> It seems like the C++ committee is speeding up development adding lots of the goodies from D like Ranges, static if, template contraints etc.
>
> Will D still have a case when C++ gets this done?
>
> I wonder if Andrei is part of the C++ Ranges Study Group?
>
> The Future of C++:
> http://channel9.msdn.com/Events/Build/2012/2-005
>
> /Jonas

http://forum.dlang.org/thread/iokgislnlzsvsosmqbbv@forum.dlang.org

On Monday, 5 November 2012 at 11:06:39 UTC, monarch_dodra wrote:
> On Monday, 5 November 2012 at 10:22:02 UTC, Nick Sabalausky wrote:
>> On Mon, 05 Nov 2012 11:00:27 +0100
>> "jdrewsen" <nospam4321@hotmail.com> wrote:
>>
>>> It seems like the C++ committee is speeding up development adding lots of the goodies from D like Ranges, static if, template contraints etc.
>>> 
>>> Will D still have a case when C++ gets this done?
>>> 
>>
>>
>> Yes, even if they go and add all of D's features, D will still be much
>> cleaner. (IMO)
>
> C++'s "range" is actually a wrapper over an iterator "first-last" pair. While it does bring the convenience of D's ranges to C++, it remains hobbled in terms of efficiency and implementation. C++'s paradigm is pointers and iterators. At best, you can sparkle some ranges over it, but you'll never shift the paradigm.
>
> --------
> The thing with C++'s new feature is that it requires developers to be on the bleeding edge of C++ knowledge. It's fine for the enthusiasts that read programming journals on their week-ends (like you and I), but not for the standard developer. Not to mention, even then, the syntax is hard as hell: lambdas in for loops? I have to look up the syntax every time. automatic type inference of the return value of a function? "auto foo() -> declype(...)", what...?
>
> All these functionalities are great, but also out of reach. Most of my colleagues still struggle with "simple" design patters such as strategies, or just plain algorithms with functors. Everytime I say something like "awesome, C++ will allow type inference" or "yay, RValue references!" they look at me like I'm some kind of weird space alien...
>
> --------
> D packages the whole thing in an easy to use but complete package. C++ just stacks complicated stuff on top of a hard to use core.

I have the same feeling with some of our developers.

Simpler languages tend to be manager friendly. It is always easier to find cheap resources.

In my currently employer I have only done Java and C# projects so far, and I still fear the day I might do a C or C++ project, given the type of knowledge shown by some of our coworkers.


--
Paulo

On Monday, 5 November 2012 at 11:39:54 UTC, Erèbe wrote:
> On Monday, 5 November 2012 at 10:00:29 UTC, jdrewsen wrote:
>> It seems like the C++ committee is speeding up development adding lots of the goodies from D like Ranges, static if, template contraints etc.
>>
>> Will D still have a case when C++ gets this done?
>>
>> I wonder if Andrei is part of the C++ Ranges Study Group?
>>
>> The Future of C++:
>> http://channel9.msdn.com/Events/Build/2012/2-005
>>
>> /Jonas
>
> http://forum.dlang.org/thread/iokgislnlzsvsosmqbbv@forum.dlang.org

I didn't read all of that thread because of the title "D vs C++11" - but it does list some very good arguments in favour of D.

I'll stop the emergency port of my D project to C++ then :P

/Jonas

On Monday, 5 November 2012 at 10:00:29 UTC, jdrewsen wrote:
> Will D still have a case when C++ gets this done?

C++ does a pretty good job on a lot of things, but there's a bunch of little things that just make it a little more frustrating day to day than D.

There's still a bunch of big differences too, but it is little conveniences and cleaner syntax, etc., that I don't think C++ will catch up on.

Le 05/11/2012 11:22, Nick Sabalausky a écrit :
> On Mon, 05 Nov 2012 11:00:27 +0100
> "jdrewsen"<nospam4321@hotmail.com>  wrote:
>
>> It seems like the C++ committee is speeding up development adding
>> lots of the goodies from D like Ranges, static if, template
>> contraints etc.
>>
>> Will D still have a case when C++ gets this done?
>>
>
>
> Yes, even if they go and add all of D's features, D will still be much
> cleaner. (IMO)
>

You never heard about @property ?

On 11/05/2012 11:22 AM, Nick Sabalausky wrote:
> On Mon, 05 Nov 2012 11:00:27 +0100
> "jdrewsen" <nospam4321@hotmail.com> wrote:
>
>> It seems like the C++ committee is speeding up development adding
>> lots of the goodies from D like Ranges, static if, template
>> contraints etc.
>>
>> Will D still have a case when C++ gets this done?
>>
>
>
> Yes, even if they go and add all of D's features, D will still be much
> cleaner. (IMO)
>

Compile times!

On Mon, Nov 05, 2012 at 01:19:04PM +0100, jdrewsen wrote:
> On Monday, 5 November 2012 at 11:39:54 UTC, Erèbe wrote:
> >On Monday, 5 November 2012 at 10:00:29 UTC, jdrewsen wrote:
> >>It seems like the C++ committee is speeding up development adding lots of the goodies from D like Ranges, static if, template contraints etc.
> >>
> >>Will D still have a case when C++ gets this done?
> >>
> >>I wonder if Andrei is part of the C++ Ranges Study Group?
> >>
> >>The Future of C++: http://channel9.msdn.com/Events/Build/2012/2-005
> >>
> >>/Jonas
> >
> >http://forum.dlang.org/thread/iokgislnlzsvsosmqbbv@forum.dlang.org
> 
> I didn't read all of that thread because of the title "D vs C++11" - but it does list some very good arguments in favour of D.
> 
> I'll stop the emergency port of my D project to C++ then :P
[...]

The thing you've to understand about C++ is that it is an old, widely-adopted language, and therefore it needs to maintain backward compatibility with the very large existing codebase. This prevents it from truly cleaning up some of the earliest design flaws, because that will break just about every C++ program ever written, which is something the C++ committee pretty much will never do.

We're already seeing a little bit of this effect in D; introducing breaking changes OT1H lets us clean up the language and make it much better, but it also alienates a lot of existing users. That's why Walter has stated that there must be no more breaking changes, even if it is to fix what is in retrospect a poor language design decision. This limits how much we can do to fix existing design issues.

D had the advantage that it could learn from C++'s mistakes and do things better. C++ doesn't have that benefit; it can introduce new features, but the old flaws that still plague the language must live on. The horribly ambiguous template syntax, for example, will continue to live on. C++ will continue being the language that must be parsed before it can be lexed. The ctor, copy ctor, etc., mess, must still live on. Operator overloading will never have the convenience of D's compile-time string-based approach, which allows very nice ways of reducing boilerplate code. Etc., etc..

And new features must work around existing syntax in order to not break existing code, which means nice syntax like D's templates, aliases, etc., will never be as nice as they are in D.

I used to be big on C/C++ before I found D. From my admittedly biased POV, though, C++11 (and beyond) is "too little, too late". I remember being really excited when I first found out about C++11 (back when it was still called C++0x -- it didn't make it before the turn of the decade). Finally, I thought, here was the long-needed language update that everyone's been waiting for. Well, I have to say that I felt quite deflated after reading the spec summary. Yes it introduced some new innovations which I liked, and some fixes to the most glaring language flaws. But it was too little, too late. It took way too many years to finalize, which meant many more years before wide adoption and availability of conforming implementations. And it *still* didn't fix all of the fundamental flaws in the language.

Not long afterwards, I found D, and that was the end of C++ for me. Yes D does have its warts, but in spite of it all it's still superior to C++ in many fundamental ways.


T

-- 
Guns don't kill people. Bullets do.