September 04, 2015 Re: dmd codegen improvements | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | 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 Re: dmd codegen improvements | ||||
---|---|---|---|---|
| ||||
Posted in reply to Luís Marques | 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 Re: dmd codegen improvements | ||||
---|---|---|---|---|
| ||||
Posted in reply to rsw0x | 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 Re: dmd codegen improvements | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 Re: dmd codegen improvements | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 Re: dmd codegen improvements | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | 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 Re: dmd codegen improvements | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | 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 Re: dmd codegen improvements | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | 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 Re: dmd codegen improvements | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | 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 Re: dmd codegen improvements | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grostad | 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! |
Copyright © 1999-2021 by the D Language Foundation