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

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.

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

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

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

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

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

> 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://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; };
> }

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