On Thu, 23 Aug 2018 04:02:37 -0700, Walter Bright wrote:

> On 8/23/2018 2:09 AM, Shachar Shemesh wrote:
>> * The community
>> 
>> Oh boy.
>> 
>> Someone who carries weight needs to step in when the forum is trying to squash down on criticism. For Mecca, I'm able to do that [2], but for D, this simply doesn't happen.
> 
> If someone is trying to squash criticism, I would like to see what you're referring to. If a post contains unprofessional behavior, like using f--k or harassing people, it will get removed. Simply being critical is not removed (if it was, this this thread would have disappeared).

One problem is that "professional" has a broad range of meanings, and as variety of cultures are represented here. I've had bosses that thought things like "What's the f--- @^Q@#$ is wrong with you?" was professional if the person "deserved" it.

It would be nice to have a published code of conduct; it doesn't need to be large or formal, just a simple definition of professional, respectful behavior. Anybody would be able to point to it, rather than hope you or someone who's around enough to feel comfortable calling someone out is on the NG at the time.

On Thu, 23 Aug 2018 19:34:46 +0000, Abdulhaq wrote:

> There is a class of developers who expect things to Just Work TM, especially if they are told that it Just Works. Each time that they discover some combination of features that doesn't work they have to refactor their code and remember not to try that again. Ultimately the developer painfully learns the things that they should not attempt to use, or they give up before the process is complete and leave. I expect the pain caused by this is much more acute in a commercial environment where the pressure is on.
> 
> Long term D developers have learnt not to bother with certain features or combinations of features and forget all the pain they went through to get that knowledge. They are ones saying, come in the water's lovely.

+1

It's easy to recommend D to someone because it does X, Y, and Z so well, not realizing they need X, Y, and B. And D has a honeymoon period - it's so awesome and will solve all our problems... until you dig deeper, trying to get more and more out of it and struggle to make sense of how to make it fit together.

The pragmatic approach to language design has its downsides.

On Thu, 23 Aug 2018 15:34:34 +0000, Matheus wrote:

> Well, I'm D hobbyist and of course it's not a perfect language and you have some valid points, but on the other hand I think it's very disrespectful to come into a community and say the product that people are working mainly as volunteers and without any payment "is dead".
> 
> Matheus.

Not necessarily. If you see somebody's about to drive off a cliff, warning them is a good thing to do. If someone thinks the direction D is headed will lead to the end of the language as a good/viable choice for programmers, then trying to change that direction is the best thing s/he can do.

On Thu, 23 Aug 2018 15:35:45 +0000, Joakim wrote:

>> * Language complexity
>>
>> Raise your hand if you know how a class with both opApply and the
>> get/next/end functions behaves when you pass it to foreach.
>> How about a struct? Does it matter if it allows copying or not?
>>
>> The language was built because C++ was deemed too complex! Please see the thread about lazy [1] for a case where a question actually has an answer, but nobody seems to know it (and the person who does know it is hard pressed to explain the nuance that triggers this).
> 
> By this rationale, C++ should be dead by now. Why do you think it's fatal to D?

It's worth noting that C++ isn't always chosen for its technical merits. It's a well-known language whose more or less standard status in certain domains means it's the default choice; C++ is sometimes used for projects in which Stroustrup would say it's obviously the wrong language for the job.

D is far more likely to require justification based on technical merit. If D becomes another C++, why bother taking a chance with D when you can just use C++, use a well-supported, commonly-used compiler, and hire from a bigger pool of jobseekers?

On Sat, 01 Sep 2018 11:25:31 +0000, rjframe wrote:

> Should you have to fix the bugs you run into? No. But if they keep you from doing your work, it seems like the economics of fixing D's bugs can make sense. If Weka were to assign its own priorities to D's bugs*, and have one person, once a week, fix the largest-priority bug, how big of an investment would that be, and would the return be worth it? Many bugs will definitely not be worth your time, but others might.

You've answered this already; my apologies for the noise.

--Ryan

On Thu, 23 Aug 2018 14:29:23 +0000, bachmeier wrote:

> Weka is an awesome project, but I don't know that most people considering D should use your experience as the basis of their decision. At least in my areas, I expect considerable growth in the usage of D over the next 10 years. Maybe it won't see much traction as a C++ replacement for large projects like Weka.

As long as D calls itself a systems language (which I believe is still the case), the experience of organizations building large systems is extremely important -- for organizations that want to build large systems.

On Thu, 23 Aug 2018 07:27:56 +0000, JN wrote:

> I think a large part is defining what kind of users D wants to attract.

I've begun wondering whether "pragmatism" is sometimes used as a code word for indecision.

> Is it possible to make a language that both groups would be happy to use? Perhaps, or perhaps the gap is too wide. Is adding features like dip1000 and betterC spreading ourselves too thin? Perhaps. Perhaps there are features that aren't really used, and should be reworked or cut from the language instead

I do think that D can do it. And I think D is the only language I've looked at that can do it. But I think it's going to take Walter and Andrei, in conversation with the core team, putting together a real list of priorities and setting a high-level direction. Look at what the end goal really is and what it will take to get there. The current high level document tends to read as a list of what's already being worked on, but piecemeal improvements probably aren't going to cut it -- this goes back to the leverage conversation Andrei started earlier.

> (has anyone ever used contracts?).

I do. It's a shame D doesn't take them seriously. As it is, I generally use them solely to express intent, which you don't get by placing asserts in the function body. I often read the function signature of functions I'm calling without reading the body, so separating the asserts from the body is helpful.

And they're often useful on interfaces.

On Sat, Sep 01, 2018 at 01:26:01PM +0000, rjframe via Digitalmars-d wrote:
> On Thu, 23 Aug 2018 07:27:56 +0000, JN wrote:
[...]
> > (has anyone ever used contracts?).
> 
> I do.

Me too.  They are very useful to express intent, even if the current implementation leaves some things to be desired.


> It's a shame D doesn't take them seriously.

Not sure what you mean by that.  Care to elaborate?


> As it is, I generally use them solely to express intent, which you don't get by placing asserts in the function body. I often read the function signature of functions I'm calling without reading the body, so separating the asserts from the body is helpful.
[...]

Yes.  The current implementation of contracts leaves some things to be desired, but I'm hopeful after the recent syntax revamp was accepted and merged into git master.

The next milestone to fight for is pushing the checking of contracts to the caller, rather than the callee.  This will be important to solve the currently very annoying (and debilitating) problem with binary shared libraries, in that it will allow the same shared binaries to be used when compiling both with and without contracts.  It should be the end user's build script that decides whether or not contracts are compiled in, but currently this is not the case.

This change may also address the current hackish implementation of subclass contracts (which involves catching Errors, an arguably dangerous thing to do), though I'm not 100% sure.


T

-- 
Старый друг лучше новых двух.

On Saturday, September 1, 2018 8:31:36 AM MDT H. S. Teoh via Digitalmars-d wrote:
> This change may also address the current hackish implementation of subclass contracts (which involves catching Errors, an arguably dangerous thing to do), though I'm not 100% sure.

AFAIK, there's absolutely nothing required to fix that other than just implementing it. As I understand it, the assertions act normally and thus throw AssertErrors, but there should be no technical reason why they couldn't be transformed into something else. e.g.

in
{
    assert(foo < 7);
}

could be lowered to something like

in
{
    if(foo < 7)
        return false;
    return true;
}

The only differences would then be if any functions called in the contract resulted in an AssertError (sinc that would no longer count as a contract failure - which is arguably a bug fix) and that explicitly throwing an AssertError wouldn't work anymore - but I expect that that's rare enough that it wouldn't be all that big a deal.

- Jonathan M Davis

On Saturday, 1 September 2018 at 12:33:49 UTC, rjframe wrote:
> C++ is sometimes used for projects in which Stroustrup would say it's obviously the wrong language for the job.
>
> D is far more likely to require justification based on technical merit. If D becomes another C++, why bother taking a chance with D when you can just use C++, use a well-supported, commonly-used compiler, and hire from a bigger pool of jobseekers?

Stroustrup also said, that "achieving any degree of compatibility [with C/C++] is very hard, as the C/C++ experience shows."

(reference => http://stroustrup.com/hopl-almost-final.pdf  (2007)

(and here refers to D on page 42 btw - that was 11 years ago now).

And yet, D is very intent on doing just that, while also treading its own path.

I personally think this is why D has not taken off, as many would hope. It's hard.

I think it's also why D won't take off, as many hope. It's hard.

Stroustrup was correct (back in the 90's). Yes, it really is hard.

Made even harder now, since C++ has evolved into a 'constantly' moving target...