On Monday, 27 July 2015 at 20:49:54 UTC, Andrei Alexandrescu wrote:
> I'll do my best to limit my participation in emotional debates, and suggest other D luminaries to do the same.

LOL. That's why I was originally planning to not say anything in this thread...

- Jonathan M Davis

On Monday, 27 July 2015 at 21:54:23 UTC, Jonathan M Davis wrote:
> On Monday, 27 July 2015 at 20:49:54 UTC, Andrei Alexandrescu wrote:
>> I'll do my best to limit my participation in emotional debates, and suggest other D luminaries to do the same.
>
> LOL. That's why I was originally planning to not say anything in this thread...
>
> - Jonathan M Davis

Your comments were very clear and much appreciated, but I see the point.

On Monday, 27 July 2015 at 22:47:05 UTC, jmh530 wrote:
> On Monday, 27 July 2015 at 21:54:23 UTC, Jonathan M Davis wrote:
>> On Monday, 27 July 2015 at 20:49:54 UTC, Andrei Alexandrescu wrote:
>>> I'll do my best to limit my participation in emotional debates, and suggest other D luminaries to do the same.
>>
>> LOL. That's why I was originally planning to not say anything in this thread...
>>
>> - Jonathan M Davis
>
> Your comments were very clear and much appreciated, but I see the point.

Well, I ended up commenting, because there were some very import points relevant to what we do with D that needed clarifying. What I wanted to avoid (and mostly did) was arguing over Rust vs D. For instance, I'd hate to lose the ternary operator in favor of the expression if-else blocks that were being suggested, but there's no point in arguing over it, because we're not going to lose the the ternary operator, and we're not going to make it so that if-else blocks can be used as expressions. Arguing about it at this point just creates contention. And it's far too easy to come at that sort of discussion from an emotional point of view that D is better because I really like it and am invested in it, and what's being suggested is alien to me or doesn't fit with my aesthetics or whatever. Sometimes what another language has _is_ better, but often, it's a trade-off or even completely subjective, and regardless, it generally isn't going to have any effect on D at this point. Rather, it's just going to make emotions flare. So, at this point, I'd prefer to generally avoid discussions of D vs any other language. I got into a really nasty argument about ranges vs iterators the other day on reddit, and I just don't want to be doing that sort of thing anymore.

However, what we _do_ stand to learn from is what's work welling for other languages (like Rust) in terms of process and the things that they do that don't necessarily have to do with the language itself which help them succeed, particularly, since even though we're generally pretty strong on the language front (not perfect, but we definitely have a very strong offering), we tend to have problems with marketing, getting folks to contribute, getting those contributions merged in in a timely manner, getting releases out, etc. We've definitely improved on that front, but it's probably our weakest point, whereas the language itself is pretty fantastic.

But I would like to avoid arguments over which language is better or which feature in which language is better or anything like that, particularly since we're unlikely to add anything to D at this point because of such discussions. Rather, we need to finish what we have and make it solid.

- Jonathan M Davis

On Tuesday, 28 July 2015 at 05:49:40 UTC, Jonathan M Davis wrote:
> On Monday, 27 July 2015 at 22:47:05 UTC, jmh530 wrote:
>> On Monday, 27 July 2015 at 21:54:23 UTC, Jonathan M Davis wrote:
>>> On Monday, 27 July 2015 at 20:49:54 UTC, Andrei Alexandrescu wrote:
>>>> I'll do my best to limit my participation in emotional debates, and suggest other D luminaries to do the same.
>>>
>>> LOL. That's why I was originally planning to not say anything in this thread...
>>>
>>> - Jonathan M Davis
>>
>> Your comments were very clear and much appreciated, but I see the point.
>
> Well, I ended up commenting, because there were some very import points relevant to what we do with D that needed clarifying. What I wanted to avoid (and mostly did) was arguing over Rust vs D. For instance, I'd hate to lose the ternary operator in favor of the expression if-else blocks that were being suggested, but there's no point in arguing over it, because we're not going to lose the the ternary operator, and we're not going to make it so that if-else blocks can be used as expressions. Arguing about it at this point just creates contention. And it's far too easy to come at that sort of discussion from an emotional point of view that D is better because I really like it and am invested in it, and what's being suggested is alien to me or doesn't fit with my aesthetics or whatever. Sometimes what another language has _is_ better, but often, it's a trade-off or even completely subjective, and regardless, it generally isn't going to have any effect on D at this point. Rather, it's just going to make emotions flare. So, at this point, I'd prefer to generally avoid discussions of D vs any other language. I got into a really nasty argument about ranges vs iterators the other day on reddit, and I just don't want to be doing that sort of thing anymore.
>
> However, what we _do_ stand to learn from is what's work welling for other languages (like Rust) in terms of process and the things that they do that don't necessarily have to do with the language itself which help them succeed, particularly, since even though we're generally pretty strong on the language front (not perfect, but we definitely have a very strong offering), we tend to have problems with marketing, getting folks to contribute, getting those contributions merged in in a timely manner, getting releases out, etc. We've definitely improved on that front, but it's probably our weakest point, whereas the language itself is pretty fantastic.
>
> But I would like to avoid arguments over which language is better or which feature in which language is better or anything like that, particularly since we're unlikely to add anything to D at this point because of such discussions. Rather, we need to finish what we have and make it solid.
>
> - Jonathan M Davis

Very wise. More often than not it is useless and irrelevant to discuss features other languages have. This does not mean that we shouldn't get inspiration from other languages. However, D's reality is different from Rust's or Go's and features don't necessarily translate directly into D (or even make sense in D). Another thing is, as I pointed out earlier, that a lot of "new" features other languages have are not yet tested well enough to be able to say whether or not they are really that good[1]. After all we are still experimenting with features and fixing things here and there after using them in the real world.

There is a tendency to think that any feature we don't have absolutely soooo has to be incorporated, else D will never take off. I beg to differ. The question should not be "Why doesn't D have this feature?", but "How do I get the same effect in D?". Often we don't have to introduce a new feature, we merely have to use the tools we have to get the same effect. And we do have a lot of tools.

[1] I wonder what kind of bugs will be introduced, when if-else is used as an expression.

On 2015-07-25 09:08, Jonathan M Davis wrote:

> I do think that our built-in unit testing facilities are a huge win for
> us though. It actually seems kind of silly at this point that most other
> languages don't have something similar given how critical they are to
> high quality, maintainable code.

Most modern languages are capable to implement something similar or better purely in library code.

-- 
/Jacob Carlborg

"Jonathan M Davis" <jmdavisProg@gmx.com> wrote:
>> trait C : A,B { }
> 
> How is that any different from interfaces? You can do exactly the same thing with them.
> 
>> impl<T: A+B> C for T { }

^^^
That's the important line.
You can define *and implement* the trait C for *all types that already
implement A and B*.
That's definitely not possible with interfaces. The difference between
traits and interfaces is, that trait implementation is separate from the
type definition.

>> fn myFunction(c: C) {...}
> [...]
> But as soon as you have to create a new one that combines two or more
> interfaces/traits/concepts, then that doesn't scale. interfaces force
> that. I wouldn't expect traits or concepts to, because they're
> compile-time constructs, but that would depend on how the language defines them.
> 
> It might make sense to create combined traits/concepts for the cases where the operations in question are often going to be required together, but in general, it's going to scale far better to require them separately rather than require a combined trait/concept. Otherwise, you get a combinatorial explosion of traits/concepts as you combine them to create new traits/concepts - either that, or you code doesn't end up being very generic, because it's frequently using traits/concepts that require more operations than it actually uses, meaning that it will work with fewer types than it would otherwise.

Because you can implement the combined trait directly for all separate subtraits, you can define that new trait just for the use of one function.

Tobi

On Wednesday, 22 July 2015 at 20:50:53 UTC, simendsjo wrote:
> If I'm not mistaken, people of the D community have tried to
> market the language quite heavily. I don't know why more people
> haven't joined, and it's even more baffeling to see the comments
> on Reddit calling D related posts spam and speaking negatively of
> the marketing on a site where upvotes dictates the ranking on the
> front page.


I wish all the D related posts go under the sub-reddit
https://www.reddit.com/r/dlang

dlang is a familiar name due to the dlang.org itself. Also, the pattern is easy to guess, like the golang.

You may be having tens of sub-reddits for D but they all look non-standard and confusing at best.

On Tuesday, 28 July 2015 at 15:39:13 UTC, John wrote:
> I wish all the D related posts go under the sub-reddit
> https://www.reddit.com/r/dlang
>
> dlang is a familiar name due to the dlang.org itself. Also, the pattern is easy to guess, like the golang.
>
> You may be having tens of sub-reddits for D but they all look non-standard and confusing at best.


To make my point more clear, the other language groups post their announcements to their respective sub-reddits like r/rust, r/golang etc, while D group tries to post *everything* directly to the r/programming. This is what makes them call it a spam.

On Tuesday, 28 July 2015 at 09:29:28 UTC, Chris wrote:
> [1] I wonder what kind of bugs will be introduced, when if-else is used as an expression.

I believe most Algol-like languages outside the C-family have it...

On Thursday, 30 July 2015 at 02:30:45 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 28 July 2015 at 09:29:28 UTC, Chris wrote:
>> [1] I wonder what kind of bugs will be introduced, when if-else is used as an expression.
>
> I believe most Algol-like languages outside the C-family have it...

So can you tell me what pitfalls there are? Sure people must have come across some nasty bugs related to this.