On 8/29/2015 9:16 PM, Ola Fosheim Grostad wrote:
> Here is a good list:
> [...]
> 5. Performance.

Ironically, you guys complained in this thread when that gets worked on.

On Wednesday, 2 September 2015 at 19:05:32 UTC, Walter Bright wrote:
> On 8/29/2015 9:16 PM, Ola Fosheim Grostad wrote:
>> Here is a good list:
>> [...]
>> 5. Performance.
>
> Ironically, you guys complained in this thread when that gets worked on.

I agree that having a native D backend is a good thing. In fact, I'd very much like to see WebAssembly/asm.js codegen built around a backend that create compact builds since download size is an issue. Which is a different kind of "performance".

I just don't see how I could use the current backend to achieve it. Maybe with your experience you could at some point in the future lay the foundation for a new a free backend, that is more minimalistic than LLVM, but that also could be used for the web?

On 2 Sep 2015 9:05 pm, "Walter Bright via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> On 8/29/2015 1:13 PM, Ola Fosheim Grostad wrote:
>>
>> But the net effect of maintaining 3 different backends is sending
signals that
>> the project lacks direction and priorities.
>
>
> Back when there was only 1 compiler, people complained about that, saying
it signaled lack of reliable support.
>

Is this argument still being used?

This is the best example of double standards that outside reviewers give about the core D maintainers.

In any other language, you'd call it freedom of choice (devil's advocate: the fact that there are dozens of C++ compilers has a negative impact on usage and adoption).

Iain.

On Tuesday, 1 September 2015 at 17:14:44 UTC, Jonathan M Davis wrote:
> It's been mentioned before that there really isn't much point in using C when you can use D. Even if you completely avoid the GC and the standard library, you're _still_ ahead of where you'd be with C, and you can call C functions trivially. So, you can definitely use D as a better C; you just lose out on a lot of cool stuff that D has to offer beyond that. But D has a lot to offer over C even without using any of that stuff.
>
> One of the first projects I used D for was back in college a number of years ago where I got sick of some of the issues I was having with C++ and went with D because it gave me stuff like array bounds checking. I was using very few of D's features (heck, D2 was quite young at that point, and I don't think that ranges had been introduced to Phobos yet at that point, so the standard library was seriously lacking anyway), but it was still easier to use D.
>
> - Jonathan M Davis


worthy of a quick blogpost sometime?  Laeeth.

On Wednesday, 2 September 2015 at 20:50:03 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 2 September 2015 at 19:05:32 UTC, Walter Bright wrote:
>> On 8/29/2015 9:16 PM, Ola Fosheim Grostad wrote:
>>> Here is a good list:
>>> [...]
>>> 5. Performance.
>>
>> Ironically, you guys complained in this thread when that gets worked on.
>
> I agree that having a native D backend is a good thing. In fact, I'd very much like to see WebAssembly/asm.js codegen built around a backend that create compact builds since download size is an issue. Which is a different kind of "performance".
>
> I just don't see how I could use the current backend to achieve it. Maybe with your experience you could at some point in the future lay the foundation for a new a free backend, that is more minimalistic than LLVM, but that also could be used for the web?

Adam Ruppe already wrote a javascript backend - it's not maintained as I guess not so much interest.  Maybe not the fastest, but it's already been done.  Again, JS not asm.js but I don't see why a man of your evident ability should find this an infeasible project were you to be serious about completing it.

On Wednesday, 2 September 2015 at 21:51:58 UTC, Iain Buclaw wrote:
> On 2 Sep 2015 9:05 pm, "Walter Bright via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>>
>> On 8/29/2015 1:13 PM, Ola Fosheim Grostad wrote:
>>>
>>> But the net effect of maintaining 3 different backends is sending
> signals that
>>> the project lacks direction and priorities.
>>
>>
>> Back when there was only 1 compiler, people complained about that, saying
> it signaled lack of reliable support.
>>
>
> Is this argument still being used?
>
> This is the best example of double standards that outside reviewers give about the core D maintainers.
>
> In any other language, you'd call it freedom of choice (devil's advocate: the fact that there are dozens of C++ compilers has a negative impact on usage and adoption).
>
> Iain.

A very interesting phenomenon, and one tends to refine one's understanding of it when thinking about developments in financial markets, because then it's serious and one has one's career at stake in learning to understand this phenomenon better.

There's a great deal of insight in Dr Iain Mcgilchrist's The Master and His Emissary.

What I think is happening is the gestalt perception system in the brain has an emotional reaction to some entity (in this case D) and the part specialised in articulation of ideas (that is also prone to confabulation) comes up with a reason to explain why.  But the feeling is primary, and the words just justify the feeling (since cognitive dissonance is uncomfortable).

The best recent example of this phenomenon was the hysteria over how the dollar was going to collapse, and anyone with any brain simply had to own precious metals and real assets + emerging market currencies.

It didn't quite play out that way, and it wasn't hard to figure that out at the time.  (Timing was the hard part):

http://www.slideshare.net/Laeeth/is-the-us-dollar-bottoming

Anyway, once you start to understand this phenomenon you see it everywhere.  I do believe that's in play with regards to D.  And that's why it really doesn't matter what the naysayers believe - the ones you want to focus on pleasing are those who are favourably disposed towards D anyway and just need to understand the case for it better, or have one or two missing things completed.


Laeeth.

On Sunday, 30 August 2015 at 16:17:49 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 30 August 2015 at 06:07:25 UTC, Laeeth Isharc wrote:
>> Morale is important in long term projects that don't pay off very quickly, and constant nagging and grumbling doesn't tend to help, even in the case when it is entirely well founded.
>
> Actually, it does help.

There's a big difference between saying "dmd generates code that's slow by the standards of modern C++ compilers.  it's an impressive accomplishment for a small group, but we ought to do better.  I know C++ and asm, and only have a little time, but I would like to help.  what would be most useful to look at ?"

and something else.

In my experience grumbling without action doesn't tend to lead to the change you want in the world.  In theory maybe it should, and someone will listen.  But human beings are funny creatures.

> There has been changes over time. Right now the most sensible thing to do is
> to focus on stability, refactor the codebase, document the codebase and track regressions. If you actually want others to contribute you need to leading by example... E.g. you need to get the boring stuff done first.

Well how would a dictator of D accomplish that?  Probably porting the compiler to D would be a pretty good start, for a variety of reasons.  That will help with stability, refactoring, and documentation I should have thought.  Not everyone knows C++, and of those who do, not everyone wants to write in it.

By the way, the dmd source code doesn't seem horribly obscure to read at first glance.

> If you actually want others to contribute you need to leading by example

alors ?  as you point out, an asm.js backend would be rather nice to have, and you are by all accounts a low-level guy, so it shouldn't be hard to do, no ?

> There is absolutely no point in helping out with a project that add features/optimizations faster than they are finished. Such projects are never finished. Even if you got 10 more people to work on it, the outcome would not be that it would be finished, you would end up getting more features, not more polish.

Given that C compilers are still developing, I doubt D will ever be finished in my useful career.  So what ?  The facts speak against your claim, since D is clearly becoming more polished with every release - just look at the improvements to the GC within the past year.  (Runtime/compiler, whatever).

> For a project that is in perpetual beta leaders need to show their priorities.

Andrei talked about documentation and presentation a little while back, and we're now in a much better state.  Allocators soon here.  People have got D to run on embedded systems with low resources.  GC is getting better - maybe not yet good enough for some, but I don't know that it's an easy problem and realistic to expect things to change in the space of a year.  etcimon has written something interesting - maybe a niche application or not yet ready for prime time - I haven't had time to see.

Walter talked about the need to get across that D is being used for serious business by serious people.  He made the Andy Smith talk happen, and that certainly increases the language credibility amongst a group that spends a lot of money on technology.  Maybe D will have another decent-sized hedge fund user soon.  I tried with a bank, but they had bigger problems.

> 1. Complete the language specification (define semantics).
> 2. Implement and polish semantics.
> 3. Clean up syntax.
> 4. Tooling.
> 5. Performance.

As some wit once said, what is true is not original, and what is original is not necessarily true.  Ie syntax/tooling/performance is already a focus here.  Semantics, I don't know.  I'd bet on good taste over excessive formalisation, but I am no computer science expert.  It's good enough for my modest needs.  I'd honestly bet that a little more effort to communicate the practical commercial benefits of D would make much more of a difference than this abstract stuff.  But who am I to say.



Laeeth.

On Thursday, 3 September 2015 at 02:02:06 UTC, Laeeth Isharc wrote:
> Adam Ruppe already wrote a javascript backend - it's not maintained as I guess not so much interest.

It is several years old now, the compiler has been completely refactored since then so it wouldn't work anyway. Besides, I wasn't particularly happy with my approach and found it pretty useless in actual practice. (In fact, I think ALL JS converters are useless in practice right now, not adding enough benefit over plain javascript to warrant the extra pains the converter brings. But maybe browsers will change that by supporting better debugging features, etc., to bridge the gap.)

I think ldc can output javascript if you compile it yourself using a llvm thing too.


BTW those refactorings in the compiler should make it quite a bit easier to do than it was then; if we were to start over, we could probably have it more-or-less working in like a full-time work week. But getting all the semantics right and then any runtime library etc would be tricky. (One thing I wanted with mine was to generate compact code, so I tried to match JS semantics fairly closely rather than D, and offered bindings to native JS functions to prefer over using phobos (though a decent chunk of Phobos actually did work, notably most of std.algorithm). Array.sort is like a few dozen bytes. std.algorithm.sort is hundreds of kilobytes of generated JS code.)

but still i'm meh on the practical usefulness of such things. I guess if you target a canvas and run your code in it that makes more sense but my preferred style is a progressive enhancement webpage where you want to know the browser platform and work with it rather than around it.

On 9/2/2015 7:48 PM, Adam D. Ruppe wrote:
> but still i'm meh on the practical usefulness of such things. I guess if you
> target a canvas and run your code in it that makes more sense but my preferred
> style is a progressive enhancement webpage where you want to know the browser
> platform and work with it rather than around it.

I don't see a whole lot of point to generating JS from another language. You can't do anything more than JS can do, and you're likely to be doing less.

On 9/2/2015 7:08 PM, Laeeth Isharc wrote:
> And that's why it really doesn't
> matter what the naysayers believe - the ones you want to focus on pleasing are
> those who are favourably disposed towards D anyway and just need to understand
> the case for it better, or have one or two missing things completed.

That's right.

I've heard "I'd use your product if only you added Feature X" for 35 years. Every time I come back with "Here's X, now you can use it!" they just come back with "That's great, but I actually need Feature Y".

The truth is, those people will never use it. They just come up with endless reasonable sounding excuses. They'll wear you out chasing rainbows.

Those kinds of feature requests should be responded to politely, but with a healthy amount of skepticism.

Of much more realistic interest are those who are already heavily using the product, but are blocked by this or that.