On Thu, Sep 03, 2015 at 02:30:39AM +0000, Laeeth Isharc via Digitalmars-d wrote:
> 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.
[...]

Especially in this forum, where large quantities of discussions, complaints, grandiose ideas, etc., are produced every day, yet disappointingly little of it actually results in anything.  Submitting PRs on Github, or even just submitting bug reports / enhancement requests, OTOH, produces much more tangible value, in spite of frequently not even being mentioned here on the forum. As Walter once said, "Be the change you wish to see."  Somebody else once said, "Talk is cheap; whining is actually free", which seems especially pertinent to this forum.


--T

On Thursday, 3 September 2015 at 03:57:39 UTC, Walter Bright wrote:
> 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.

That is silly. asm.js is a very restricted typed subset with strict rules that allows generation of pure assembly in a contiguous memory sandbox. It is a completely different setup. If you move outside those rules the compiler give up and switch to regular JIT with less restrictions. WebAssembly aims to go beyond what you can do otherwise  (like multithreading).

On Wed, Sep 02, 2015 at 09:09:43PM -0700, Walter Bright via Digitalmars-d wrote:
> 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".

Too true!

	auto featuresRequested = [ x ];
	while (featuresRequested.length > 0) {
		refuse(product, new Reason(featuresRequested));

		auto newFeatures = waitForNextRelease();
		foreach (x; newFeatures) {
			featuresRequested.remove(x);

			auto y = new Excuse();
			featuresRequested ~= y;
		}
	}
	adopt(product);


> 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.

Yes, serve existing customers well, and they will spread the word for you, leading to more customers. Divert your energy to please non-customers in hopes of winning them over, and you may end up driving away what customers you do have.


T

-- 
Век живи - век учись. А дураком помрёшь.

On Wednesday, 2 September 2015 at 21:51:58 UTC, Iain Buclaw wrote:
> This is the best example of double standards that outside reviewers give about the core D maintainers.

Hogwash.

AFAIK, they complained about the backend, not a lack of compilers. When you get fracturing related to code base quality, licensing or language semantics, you have development strategy issues that cause fracturing (you also have private fors like ketmar's).

Besides, different people having different opinions is not double standards.

> 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).

Most C++ compilers are dead. If you scaled up C++ to D based on resources and usage then C++ should have 100s of free compilers. You have 2 free C++14 compilers.

By your argument emacs and xemacs should never have been merged, the fact is that they were better off with uniting efforts.

On Thursday, 3 September 2015 at 02:30:41 UTC, Laeeth Isharc wrote:
> 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.

End user back pressure helps. If it does not help, then the development process is FUBAR. However it does help, Walter is an intelligent man, that enjoys defending his position, but that does not mean that he does not listen to arguments and internalize them over time.

> 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.

Dedicating one cycle to porting, another to refactoring and documentation is a very good start. IFF you focus on that and stick with it and avoid adding more features as code at the same time. (Add them to the plan/spec instead.)

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

Reading is one thing, making it do what you want another. For that you need either documentation or "reverse-engineering the underlying model".

> 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 ?

I don't have enough time to figure out all the ins-and-outs of the current compiler. To do that, in reasonable time, I would need a refactored and documented compiler. (I am also not primarily a low level person, my background is broad, but my major was in systems development).

> 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).

Oh, I would love for D to follow the trajectory of C. C development can follow a near-waterfall development model:

1. specification-ratification-cycle
2. specification based gamma-beta-alpha production implementation
3. release
4. non-semantic improvements

D is nowhere near C's conservative fully spec'ed ISO-standard-based process.

Semantically C does not have many advantages over D, except VLAs (which I find rather useful and think D should adopt).

> 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.

What people can do isn't really all that interesting. What is interesting is what you can do with little effort and better than the alternatives. BASIC ran on machines with just a few K's of RAM, that does not make it a reasonable choice.

> 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.

I think you underestimate the expections people with a major in compsci or a significant amount of development experience have. They care about the actual qualities, not the presentation. Those are the CTOs you need to convince, not the CEOs.

As it stands today both Rust and D falls into the category toy-languages. "toy language" is the term academics use to describe their languages that explore interesting ideas, but does not have the polish, tooling or commercial backing to take a significant market share.

On Thursday, 3 September 2015 at 04:30:04 UTC, Ola Fosheim Grostad wrote:
> On Thursday, 3 September 2015 at 03:57:39 UTC, Walter Bright wrote:
>> 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.
>
> That is silly. asm.js is a very restricted typed subset with strict rules that allows generation of pure assembly in a contiguous memory sandbox. It is a completely different setup. If you move outside those rules the compiler give up and switch to regular JIT with less restrictions. WebAssembly aims to go beyond what you can do otherwise  (like multithreading).

It is twice as slow as native. That's far from allowing generation of pure assembly.

On 3 Sep 2015 8:20 am, "deadalnix via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> On Thursday, 3 September 2015 at 04:30:04 UTC, Ola Fosheim Grostad wrote:
>>
>> On Thursday, 3 September 2015 at 03:57:39 UTC, Walter Bright wrote:
>>>
>>> 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.
>>
>>
>> That is silly. asm.js is a very restricted typed subset with strict
rules that allows generation of pure assembly in a contiguous memory sandbox. It is a completely different setup. If you move outside those rules the compiler give up and switch to regular JIT with less restrictions. WebAssembly aims to go beyond what you can do otherwise (like multithreading).
>
>
> It is twice as slow as native. That's far from allowing generation of
pure assembly.

I have far more faith in gccjit.  But it's more like the orange to a conventional jit's apples.

On 2015-09-03 05:57, Walter Bright wrote:

> 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.

There's a lot of stuff other languages can do that JS can't. For example, classes, which a lot of developers prefer to use in favor of the weird object system in JS.

Although now with ECMAScript 6 classes are supported. But it will still be a long time before enough web browsers support E6. Therefore it can be useful to have an E6 compiler that translates to E5 or E3 compatible JS.

-- 
/Jacob Carlborg

On 9/2/2015 9:09 PM, H. S. Teoh via Digitalmars-d wrote:
> As Walter once said, "Be the change you wish to see."

I think that was Andrei. But I do agree with it.

On 9/2/2015 9:28 PM, H. S. Teoh via Digitalmars-d wrote:
> Yes, serve existing customers well, and they will spread the word for
> you, leading to more customers. Divert your energy to please
> non-customers in hopes of winning them over, and you may end up driving
> away what customers you do have.

That's a good description of the approach I prefer.