On Thursday, 23 August 2018 at 17:02:12 UTC, Shachar Shemesh wrote:
> On 23/08/18 18:35, Joakim wrote:
> […]
>> How much time or money exactly has Weka spent on getting this issue and other "critical" bugs fixed?
>
> Weka is paying prominent D developers as contractors. We've had David Nadlinger and currently employ Johan Engelen. Both said they are cannot fix this particular bug.

Not to put too fine a point on this, but I don't think I've ever said I couldn't fix the bug; although I probably did mention it would be better to fix in the upstream DMD frontend than in LDC.

I would be happy to have a look at it for Weka at this point, actually.

 — David

On Thursday, 23 August 2018 at 22:12:17 UTC, David Nadlinger wrote:
> Throwing constructors are fundamental for making RAII work in a composable fashion.

Is that actually true, or would handling exceptions within the constructor allow one to initialise the object to an invalid state and thus still follow RAII paradigms correctly?

The amount of bugs and pain I've had to deal with in production code because of throwing constructors makes me lean more towards Walter's viewpoint here. Even one of our most basic datatypes - the IEEE float - initialises to an invalid state. Why can't RAII objects do the same if it performs operations it *knows* throw exceptions?

On Thursday, 23 August 2018 at 03:50:44 UTC, Shachar Shemesh wrote:
> On 22/08/18 21:34, Ali wrote:
>> On Wednesday, 22 August 2018 at 17:42:56 UTC, Joakim wrote:
>>> Pretty positive overall, and the negatives he mentions are fairly obvious to anyone paying attention.
>> 
>> Yea, I agree, the negatives are not really negative
>> 
>> Walter not matter how smart he is, he is one man who can work on the so many things at the same time
>> 
>> Its a chicken and egg situation, D needs more core contributors, and to get more contributors it needs more users, and to get more users it need more core contributors
>> 
>
> No, no and no.
>
> I was holding out on replying to this thread to see how the community would react. The vibe I'm getting, however, is that the people who are seeing D's problems have given up on affecting change.
>
> It is no secret that when I joined Weka, I was a sole D detractor among a company quite enamored with the language. I used to have quite heated water cooler debates about that point of view.
>
> Every single one of the people rushing to defend D at the time has since come around. There is still some debate on whether, points vs. counter points, choosing D was a good idea, but the overwhelming consensus inside Weka today is that D has *fatal* flaws and no path to fixing them.
>
> And by "fatal", I mean literally flaws that are likely to literally kill the language.
>
> And the thing that brought them around is not my power of persuasion. The thing that brought them around was spending a couple of years working with the language on an every-day basis.
>
> And you will notice this in the way Weka employees talk on this forum: except me, they all disappeared. You used to see Idan, Tomer and Eyal post here. Where are they?
>
> This forum is hostile to criticism, and generally tries to keep everyone using D the same way. If you're cutting edge D, the forum is almost no help at all. Consensus among former posters here is that it is generally a waste of time, so almost everyone left, and those who didn't, stopped posting.
>
> And it's not just Weka. I've had a chance to talk in private to some other developers. Quite a lot have serious, fundamental issues with the language. You will notice none of them speaks up on this thread.
>
> They don't see the point.
>
> No technical project is born great. If you want a technical project to be great, the people working on it have to focus on its *flaws*. The D's community just doesn't do that.
>
> To sum it up: fatal flaws + no path to fixing + no push from the community = inevitable eventual death.
>
> With great regrets,
> Shachar


I agree with this. I no longer program in D, except for minor things, because of this type of approach. D, as a language, is the best. D as an actual practical tool is a deadly pit of snakes... anyone of which can bite you, and that won't stop the others. Of course, in the pit is where all the gold is at...

D's ecosystem is the problem, not the language(although, the bugs in the implementation are a problem, they seem to be generally solved and since the source is open it can be fixed when needed).

It is obviously the mentalities of the leaders... it always is, that is why they are called leaders, because they lead and whatever mentalities they have will shape who and what they lead.

It would be amazing to see someone like Microsoft implement a D#! That would be a very impressive language and ecosystem! Specially if it had both .net and native compilation and fixed some of the major language issues D has.

My feeling is D is and will stay stagnate for the majority of the world. It doesn't seem to have enough momentum to break out and the "leaders" don't seem to know much about actually leading... programming? Yes, but leading? No, not really...(obviously they know something but I'm talking about what is required... a bill gate like character, say, not that we want another one of those!)

D is one of those language where it's always something getting in the way of zoning. Something really little and stupid but constantly trips you up... it becomes a big drag after while. I'd rather program in a language that has it's shit together where I can write large projects in a 10th of the time and with a fourth of the trouble.

Since time is money, you know these types of issues will stop businesses from adopting D. The typical answer from the D community is "Implement it in a library!" or "It has bindings!" as if these are the solutions someone trying to get shit done wants to hear. Usually the libraries are defunct in some way(bit rot, version issues, shitty design, some deal breaker(e.g., uses gc), shitty documentation, etc).

Since D is mainly community driven, this means that the community will cobble shit together and then it becomes part of D. This is good for shear amount of code generation but terrible for unity of design. Everyone does it their way which results in many different approaches to many different things(and this even gets in the libraries and compiler design).

There has to be a sense of balance in anything, and this includes leadership, compiler design, language features, etc... D does not have that balance and people recognize that in whatever way they see it and generally choose not to use it. The people that use it have a defacto need to project D as a balanced language(oh, it has this this and that! It has this and that and that over there too if you jump through hoops A B and C).  Very few people have the intelligence to be able to admit they are going down the wrong path and it's time to turn around. It's human nature to dig and dig and dig and dig and dig and dig...

On 08/23/2018 10:11 PM, Walter Bright wrote:
> On 8/23/2018 5:55 AM, Steven Schveighoffer wrote:
[...]
>> I think he means, if the range ITSELF doesn't allow copying, it won't work with foreach (because foreach makes a copy), but it will work with opApply.
> 
>      foreach (ref v; collection)
> 
> does not make a copy.

It makes a copy of `collection`.

> It's up to the programmer whether copying is done with it. After all, if one is passing a struct instance around by value instead of by ref, there is no escaping copying it. This should not be surprising.

It's not obvious that using `collection` in a `foreach` means passing it around by value.

On 8/23/2018 3:12 PM, David Nadlinger wrote:
> On Thursday, 23 August 2018 at 21:31:41 UTC, Walter Bright wrote:
>> My personal opinion is that constructors that throw are an execrable programming practice, and I've wanted to ban them. (Andrei, while sympathetic to the idea, felt that too many people relied on it.) I won't allow throwing constructors in dmd or any software I have authority over.
> 
> Throwing constructors are fundamental for making RAII work in a composable fashion.

I understand my opinions on this diverge from the conventional wisdom.


> If constructors are not allowed to throw and you want to avoid manually creating a "uninitialized" state – which is error-prone and defeats much of the point of an RAII strategy –, all dependencies need to be injected externally, that is, constructed independently and then passed into the constructor. Sometimes, inversion of control is of course the right call – cf. the hype around DI –, but sometimes you'd rather cleanly abstract the implementation details away.
> 
> Banning them from the language only pushes the complexity of handling semi-constructed objects into ad-hoc user code solutions, which I'd argue is worse in terms of usability and potential for bugs.
> 
> I suppose you view this as advantageous because you place more weight on the language not having to explicitly deal with this scenario in the text of the specification?

It's easy to specify. That's not an issue at all. It's also easy to implement - where my PR for it failed, was it broke existing code that should never have compiled anyway (for example, a nothrow constructor would then call a throwing destructor, or an @safe constructor now would call an unsafe destructor). Dealing with this likely means a compiler switch so an upgrade path is easier.

Let's deal first with the easy case - throwing destructors. The problem is that unwinding the stack to deal with the exception means calling destructors. You then have the infamous "double fault exception", and C++ deals with it by terminating the program, which is hardly useful.

D deals with it via "chained exceptions", which is terrifyingly difficult to understand. If you believe it is understandable, just try to understand the various devious test cases in the test suite. I regard D's chained exceptions as an utter failure.

Back to throwing constructors.

1) They are expensive, adding considerable hidden bloat in the form of finally blocks, one for each constructing field. These unwinding frames defeat optimization. The concept of "zero-cost exception handling" is a bad joke. (Even Chandler Carruth stated that the LLVM basically gives up trying to optimize in the presence of exception handlers.) Herb Sutter has a recent paper out proposing an alternative, completely different, error handling scheme for C++ because of this issue.

2) The presence of constructors that throw makes code hard to reason about. (I concede that maybe that's just me.) I like looking at code and knowing the construction is guaranteed to succeed. Somehow, I've been able to use C++ for decades without needing throwing constructors. Let's take the canonical example, a mutex:

  {
    Mutex a; // acquires a mutex, throws if it fails
    ... locked code ...
  } // mutex is released

My suggestion:

  {
    Mutex a; // creates a mutex
    a.acquire(); // does the obvious thing
    ... locked code ...
  } // mutex is released

It's still RAII, as the destructor checks to see if the Mutex is required, and if so, releases it.

You might argue "my code cannot handle that extra check in the destructor." Fair point, but stack that against the cost of the EH bloat in the constructor, and (for me) the inherently unintuitive nature of a constructor that tries to do far too much.

3) Much of the utility of throwing constructors in C++ comes from "what if the constructor fails to allocate memory". In D, out of memory errors are fatal, no recovery is necessary. That pushes any requirement for throwing constructors to the fringes in the first place.

One takeaway from this is despite my loathing of throwing constructors, they are a part of D and I need to make them work properly.

I.e. I am not dictating everything in D based on my personal opinions. I try to pick my battles.

On 8/23/2018 3:20 PM, David Nadlinger wrote:
> Not to put too fine a point on this, but I don't think I've ever said I couldn't fix the bug; although I probably did mention it would be better to fix in the upstream DMD frontend than in LDC.
> 
> I would be happy to have a look at it for Weka at this point, actually.

I don't believe it's unfixable, either.

On Thursday, 23 August 2018 at 17:02:12 UTC, Shachar Shemesh wrote:
>> How much time or money exactly has Weka spent on getting this issue and other "critical" bugs fixed?
>
> Weka is paying prominent D developers as contractors. We've had David Nadlinger and currently employ Johan Engelen. Both said they are cannot fix this particular bug.
>
> If you can, feel free to contact me off-list, and I'm fairly sure we can get the budget for you to work on it. The same goes for anyone else on this list.

I'll be taking a good stab at it. I am currently wading through the swamps of Semantic Analysis and am currently up against a ~thousand headed hydra~ thousand line function .

On Thursday, 23 August 2018 at 04:46:25 UTC, Eugene Wissner wrote:
> But this kind of development doesn't work anymore that well for commercial customers that aren't (only) interested in research. From this perspective D becomes over-complicated, half-finished language. And nobody can tell what will be "in" tomorrow.

My point of view (as a tiny commercial user) is that D has everything you need:

- a way to convert money into bugfixes with the new Foundation deals

- it's pretty boring and predictable with upgrades, few surprise. Each releases bring improvements, you get CI and docs for free etc.

- future-proof. It's not a weaponized language, people love it etc. It cannot be wiped out by a giant because it doesn't fit a corporate agenda.


Of the real problems I think I see - and everyone sees those differently:

A - D needs to keep generating drama (like this thread) to storify its development and keep people active. It creates engagement. A lot of the D marketing is very reasonable and that doesn't cut it that much. Where is superdan?

B - sometimes bizzarre allocation of effort, that's probably part of some unexplainable evil plan, but can at times feel like counterproductive wrt marketing.

  For example: why implement AVX in DMD backend? Who are the users that will be delighted by that? Those interested in performance already use some other back-end, it's imo a completely useless development since _no one_ use D_SIMD seriously apart from compiler tests (https://github.com/search?l=D&p=4&q=D_SIMD&type=Code)

C - _absurd_ focus on the language, and in lesser part Phobos instead of _community_ and DUB things (ie: libraries, making sure they exist and make some sense while not putting more work on core developers). What if the language was "good enough" while the ecosystem wasn't?

Example:
  A best example of this is std.experimental:
     * "to develop something for std.experimental, put it on DUB it will be able to be used and upgraded!"
     * "to update something in std.experimental, put it back on DUB it will be able to be upgraded while keeping backward-compatibility!"

Example:

The solution is (still subjectively) obviously to offload as much as possible to the community, simply because there are more people making libraries than core developers so why core developers should take ownership of an ever growing amount of "big Phobos"?
Phobos shouldn't even be a thing, we always read "hopefully this will be moved into Phobos" which is entirely wrong. People should be pushed to use the community to their advantage. SemVer is where it's at.

On Friday, 24 August 2018 at 00:32:59 UTC, Guillaume Piolat wrote:

>   For example: why implement AVX in DMD backend? Who are the users that will be delighted by that? Those interested in performance already use some other back-end, it's imo a completely useless development since _no one_ use D_SIMD seriously apart from compiler tests (https://github.com/search?l=D&p=4&q=D_SIMD&type=Code)

But I need it to implement `memcpy` and `memcmp` in D, so we can remove the dependency on the D standard library :-)

https://github.com/JinShil/memcpyD

I know.  I'm weird.

> Phobos shouldn't even be a thing, we always read "hopefully this will be moved into Phobos" which is entirely wrong. People should be pushed to use the community to their advantage. SemVer is where it's at.

Totally agree.  It seems, from someone without much historical perspective, that Phobos was intended to be something like the .Net Framework for D.  Perhaps there are a few fundamentals (std.algorithm, std.allocator, etc.) to keep, but for the others... move 'em to Dub and let the "free market" sort it out.

Mike