November 03, 2012
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.
November 03, 2012
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
November 03, 2012
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.
November 03, 2012
On Sat, 03 Nov 2012 13:46:17 +0100
"Erèbe" <erebe@erebe.eu> wrote:
> 
> 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 ?
> 

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 enough features, let add some support to the language now" ?

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 languages have their interpreters, Java eclipse, what has D ?
> 

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 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 monodevelop which is really great but no debugger (assert is enough for now).
> 

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 language is well featured ? Something coherent with what already 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.

November 03, 2012
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?
November 03, 2012
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.
November 03, 2012
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?
November 03, 2012
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è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.
[...]
> 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++.
> 

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 benefits. But YMMV, of course.

November 03, 2012
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.)

November 03, 2012
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