September 04, 2015
On Friday, 4 September 2015 at 14:59:12 UTC, Ola Fosheim Grøstad wrote:
> Actually, browsers are deprecating NPAPI plugins. Flash is so dead…

Could, in principle, Flash be supported through an extension, instead of a media / NPAPI plugin?
September 04, 2015
On Friday, 4 September 2015 at 15:45:35 UTC, Luís Marques wrote:
> On Friday, 4 September 2015 at 14:59:12 UTC, Ola Fosheim Grøstad wrote:
>> Actually, browsers are deprecating NPAPI plugins. Flash is so dead…
>
> Could, in principle, Flash be supported through an extension, instead of a media / NPAPI plugin?

I don't think they will kill Flash outright even after removing plugins. It was more wishful thinking on my part.  Adobe will emulate everything Flash does within HTML5 before it is killed, don't you think?
September 04, 2015
On Friday, 4 September 2015 at 14:26:49 UTC, rsw0x wrote:
>
> All of this could have been avoided by all browser vendors agreeing to implement pNaCl.
> Maybe we'll be lucky and Firefox will fade into obscurity with the way they've been handling things lately.

I thought even the PNaCl people were working on wasm.
September 04, 2015
On 09/02/2015 11:57 PM, 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.
>

The premise here is that Javascript is a lock-in for code that can run in the browser. So to get D code to run in the browser you'd need to generate Javascript. This concern is orthogonal to relative capabilities of languages etc. -- Andrei
September 04, 2015
On 09/03/2015 02:54 AM, Walter Bright wrote:
> 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.

I think it was Gandhi :o). -- Andrei

September 04, 2015
On Friday, 4 September 2015 at 14:43:43 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 4 September 2015 at 14:40:32 UTC, rsw0x wrote:
>> On Friday, 4 September 2015 at 14:34:52 UTC, Ola Fosheim Grøstad wrote:
>>> On Friday, 4 September 2015 at 14:26:49 UTC, rsw0x wrote:
>>>> Maybe we'll be lucky and Firefox will fade into obscurity with the way they've been handling things lately.
>>>
>>> No. TurboFan is in Chrome with asm.js support.
>>
>> I'd rather not advocate the adoption of inferior technology.
>
> It has already been adopted by Microsoft, Google and Mozilla...

Doesn't mean it is not inferior. In fact it is bad enough on its own so there is the whole WebAssembly things going on.
September 04, 2015
On Friday, 4 September 2015 at 14:56:48 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 4 September 2015 at 14:45:39 UTC, rsw0x wrote:
>> Because it has the path of least resistance. It's still a poor technology that is just treating the symptoms.
>
> pnacl/pepper is not good either, they are both poor technologies.
>

Statement do not makes arguements. pNaCl is portable, take only a 20% hit compared to pure native and is compact to send through the wire.

September 04, 2015
On Friday, 4 September 2015 at 14:22:17 UTC, Jonathan M Davis wrote:
> On Thursday, 3 September 2015 at 01:54:45 UTC, Laeeth Isharc wrote:
>> On Tuesday, 1 September 2015 at 17:14:44 UTC, Jonathan M Davis wrote:
>>> 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.
>
> My memory would be pretty sketchy on it at this point. I remember what the project was (it had to do with randomly generating 3D fractals in opengl for a graphics course), but that was back in 2008, I think, and I couldn't really say much interesting about it beyond the fact that I was annoyed enough with C++ at the time to use D for the project. The only thing notable about it is that it was the first thing that I did in D that was actually supposed to do something rather than just messing around with the language.
>
> - Jonathan M Davis

Tku for colour.
September 04, 2015
On Friday, 4 September 2015 at 17:05:41 UTC, deadalnix wrote:
> Statement do not makes arguements. pNaCl is portable, take only a 20% hit compared to pure native and is compact to send through the wire.

You think pnacl is compact and compresses well? That's an unusual position. Both asm.js and pnacl fail to be ideal for various reasons. One is that you loose too much information if you go from a high level language to enable full target optimization. The "p" for portable is questionable.

A BIG advantage with asm.js is that you can generate and compile it from code running in the browser, so you can choose your own transport format, run JITs in the browser etc. You could essentially create a (simple) D development environment in the browser.

Anyway, what we think does not matter. What matters is what is supported by the least common denominator, which for many developers happen to be browsers on weak mobile ARM devices. Apple has no interest in undermining their Apps market, so… who knows where this will go. Let's hope they don't sabotage it.

September 04, 2015
On Thursday, 3 September 2015 at 04:30:04 UTC, Ola Fosheim Grostad wrote:
"I don't have enough time to figure out all the ins-and-outs of the current compiler."

"Unless you sell DMD, how about providing a definition of "customer"?
If you don't pay attention to evaluations, then surely the competition
will steal your thunder and you'll end up as Cobol; on a long tail
in maintenance mode."

Sometimes it's really worth putting energy into ensuring crisp
definitions.  This isn't one of those cases.  Your own language is
exploiting polysemy in an unstraightforward manner - mixing up
different meanings to achieve a rhetorical effect.  Quite clearly
Walter+Andrei listen to what people say, but it doesn't thereby
follow that they should listen to people who think D should go
in a completely different direction based on a very theoretical
view of things and who have no evident experience in writing
a compiler used on a large scale, or in developing a language
community.

It's Business 101 that you shouldn't listen to what most people
tell you, because whilst often well-meaning it's based on an
understanding of things different from the practical situation one
faces and that doesn't always understand what one is trying to
achieve.  It's hard to do that whilst not falling into the other
extreme of not attending to the smallest signs from the right
people when you should, but difficulty is in the nature of such
endeavours.

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

Thank the Lord!  I really don't see how anyone can seriously believe
that this is an appropriate model for D for the foreseeable future.
The essential reason for why it is an attractive language is that it
was based on the genius (I mean this in the etymologically-rooted sense)
of one, or a few minds and thereby is greatly superior to anything
designed by a committee.  Maybe at some stage this will be an appropriate
process to establish, but I do note that even some of those involved
in such processes would readily admit that waterfalls are evil, if
necessary at that stage.

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

This is why you come across as a bit academic and not always constructive.
You suggested things weren't developing, and I pointed out that they are,
and gave a few concrete examples of how.  You then said that the first
attempt wasn't perfect.  But you know, as well as I, that it's in the
nature of things that beginnings never are.  It's really tough to be
the first to do something (another reason I think you could be a little
more respectful towards Walter), but every person that follows makes it
some how easier.  There's a slightly mysterious aspect to this, but
nonetheless it's true.  D is running on embedded systems, and it
sounds like it was a pain because of the runtime but not because of
any horrible flaw in the language that means it cannot be considered
a systems language if you want it to be.  I'd be really surprised if
it doesn't become easier from here with time.  I like the old-fashioned
English virtue of being willing in a discussion to give credit where
credit is due.


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

I shared a flat for some time with a pretty smart friend who studied
computer science at Trinity, Cambridge (I didn't study computing).
He wrote this - it wasn't a success businesswise, but that's not
 for technical reasons and timing had a lot to do with it:
https://github.com/pythonanywhere/dirigible-spreadsheet

And I have other friends with similar backgrounds, and I have hired
and worked with developers, and I am not sure that in the enterprise
world a computer science credential has any more incantatory standing
than any other degree - and that's probably as it should be.

My point wasn't that D needs to fool gullible people into adopting
it, but rather the opposite.  I always thought smart people should
just be able to see what's obvious, but one sometimes has to learn
the hard way that ideas and products don't sell themselves of their
own accord.  You have to make it as easy as you can for your
potential customers to appreciate what the value is for them in
adopting what it is you would like them to explore.  Part of that
is that people naturally think differently, and also that what's
obvious from the inside simply isn't from the outside.  CTOs are
not gifted with some magic ability to see through appearances to
the Platonic essences of things.  They are human and have a tough
job.  So one needs to make an effort if they are to easily appreciate
the value.

This is a point John Colvin made with regards to scientists in
his dconf talk.  And, on balance, I rather think that scientists
are a little less concerned about appearances than enterprise people.
And if it's true for them - which it is - it's all the more true for
the enterprise.

"I am not calling D a toy language"
"As it stands today both Rust and D falls into the category toy-languages."

Make up your mind.

Or better, think for a bit about whether a different approach would be
more effective.

Of course you know that you're using a pejorative term (depersonalizing
it as if it is something objective doesn't change that), and asserting
it to apply without any kind of argument for it.  A toy is something
that is suitable for entertaining children, but not something to be
used be a serious craftsman or businessman.  Since serious people
have built their businesses around it (Sociomantic alone being $200mm
EV), you must be fully aware that it can hardly be a toy.  I gather you
think market share is critical - it's reasonable for you to think that,
but not to suggest that it's the only reasonable way of looking at the
world.  Myself, I side with Thiel,who at least must be considered a
serious thinker, and to have some insight regarding the diffusion of technologies and the creation of new enterprises.


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

You're really reaching now.  In a community that draws creative and
curious people something would be wrong if people didn't fork the
compiler and experiment.  Now if there's mass adoption of different
forks and warring tribes, perhaps that's different.  (War is
generative, too, but the costs are too high for this to be sustained
for long).

But this simply isn't the case, and it strikes me that you're
manufacturing words to suit how you feel, rather than basing how
you feel on things as they are.

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

If you scaled up the institutions and mores of Norway to the size of
and conditions applying to the US you would have a very odd country
indeed.  That gedankenexperiment may indeed help stimulate the
imagination to understand what one has before one.  But the conditions
of D are different from those of C++, since the two non-dmd compilers
were written, as you know, to benefit from the code generation
capabilities of other projects.  One may legitimately have the view
that the projects should be consolidated, but one would have to
actually make an argument for it in the Russian style of
 close-reasoning.  As someone said, a statement isn't an argument,
and neither is an analogy to something different.  Also, one's
arguments would need to cohere in this domain, rather than arguing
like a lawyer "1. my client didn't take, let alone steal the vase;
2. it was broken already when he took it; 3. he returned it in
good shape'


"End user back pressure helps. If it does not help, then the
 development process is FUBAR."
My sincere view is that if you adopted a different approach you
would be more effective in your influence.  And there might be
broader beneficial effects too.

" However it does help, Walter is an intelligent man, that enjoys
defending his position"
Patient as he is, I have the impression that the enjoyment is not
saliently on his side of things!