September 03, 2015
On Thursday, 3 September 2015 at 21:01:10 UTC, Ola Fosheim Grostad wrote:
> On Thursday, 3 September 2015 at 13:12:07 UTC, Adam D. Ruppe wrote:
>> On Thursday, 3 September 2015 at 06:45:16 UTC, Jacob Carlborg wrote:
>>> 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.
>
> If you don't change the prototype object, then it is mostly similar, but more flexible. Functions are constructors and prototype objects are class definitions. You could also use typescript, typescript playground is quite fun. It allows you to explore the JS output in realtime.
>
>> You can kinda do classes in JS, it just isn't pretty syntax. In the D to JS toy I did, I just did an array of function pointers to handle the virtual functions, similar to how D is compiled to machine code.
>>
>> It'd be fairly ugly to write by hand but when converting languages, it works well enough.
>
> Huh? Dynamic languages have dynamic lookup, how is that different from virtual functions?

Maybe because you need 2 map lookups + 1 indirection instead of an array lookup in addition of the indirect call.

But who know, with a vectorized SSA, it surely will be faster than light.
September 03, 2015
On Thursday, 3 September 2015 at 21:08:51 UTC, Ola Fosheim Grostad wrote:
> On Thursday, 3 September 2015 at 10:04:58 UTC, deadalnix wrote:
>> On Thursday, 3 September 2015 at 09:56:55 UTC, Ola Fosheim Grøstad wrote:
>>> On Thursday, 3 September 2015 at 06:18:54 UTC, deadalnix wrote:
>>>> It is twice as slow as native. That's far from allowing generation of pure assembly.
>>>
>>> It is translatable to pure assembly, addressing is modulo heap size. Performance is a different issue since it does not provide SIMD yet.
>>
>> SIMD is not even remotely close to explaining the perf difference.
>
> What browser? Only FF supports it. Chrome just JIT it IIRC.

asm.js typically runs half the speed of natively compiled code. pNaCl run about 20% slower typically.

The gap is way to big for vectorization to be a reasonable explanation. In fact a large body of code just do not vectorize at all.

You seems to be fixated on that vectorization thing, when it is not even remotely close to the problem at hand.

September 04, 2015
On Thursday, 3 September 2015 at 22:48:47 UTC, deadalnix wrote:
> On Thursday, 3 September 2015 at 21:01:10 UTC, Ola Fosheim Grostad wrote:
>> Huh? Dynamic languages have dynamic lookup, how is that different from virtual functions?
>
> Maybe because you need 2 map lookups + 1 indirection instead of an array lookup in addition of the indirect call.
>
> But who know, with a vectorized SSA, it surely will be faster than light.

obj.f is not slower than obj.v[5]

on the contrary, it is faster
September 04, 2015
On Thursday, 3 September 2015 at 22:53:01 UTC, deadalnix wrote:
> asm.js typically runs half the speed of natively compiled code. pNaCl run about 20% slower typically.

Browser version, benchmark, reference?

Without informationloss there is no inherent overhead outside sandboxing if you avoid the sandbox boundaries.

Other people report 1-1.5x.
September 04, 2015
On Thursday, 3 September 2015 at 21:58:18 UTC, Walter Bright wrote:
> Yeah, I'd have to read through the source code. But it's still copyrighted, and I prefer not to be subject to taint. For years, many people did not believe I could have created a C++ compiler on my own, and they were quick to believe any possibility that I didn't. Refusing to look at other compilers helped a lot with this.

Yeah, sure, that's your choice. It would have been been interesting to hear your take on it, though.

 — David
September 04, 2015
On 2015-09-03 23:01, Ola Fosheim Grostad wrote:

> If you don't change the prototype object, then it is mostly similar, but
> more flexible. Functions are constructors and prototype objects are
> class definitions.

Looking how many languages compile to JS and how many JS libraries there are out there that try to invent some kind of new syntax for declaring classes and now E6, I would say a lot of people are not satisfied with the current state of JS.

> You could also use typescript, typescript playground
> is quite fun. It allows you to explore the JS output in realtime.

Yeah, that's one those languages I was thinking about ;)

-- 
/Jacob Carlborg
September 04, 2015
On Friday, 4 September 2015 at 07:44:23 UTC, Jacob Carlborg wrote:
> Looking how many languages compile to JS and how many JS libraries there are out there that try to invent some kind of new syntax for declaring classes and now E6, I would say a lot of people are not satisfied with the current state of JS.

Yes, JS gets painful once you get above 1000 lines of code. Fortunately we can now use typed ES6 also on older platforms. There are also polyfills for things like Promises (async), and Fetch (dead easy ajax http request).


>> You could also use typescript, typescript playground
>> is quite fun. It allows you to explore the JS output in realtime.
>
> Yeah, that's one those languages I was thinking about ;)

I have no problem recommending TypeScript with WebStorm (or some other editor) for business like applications. For more demanding apps I think we need a more traditional language that generates high quality asm.js like code as well as regular ES6 and some clean bridging. So either a new language or a modified language (like a D++ or something).
September 04, 2015
On Friday, 4 September 2015 at 07:52:30 UTC, Ola Fosheim Grøstad wrote:
> I have no problem recommending TypeScript with WebStorm (or some other editor) for business like applications.

Err... avoid WebStorm. Just noticed JetBrains have decided to rip off their customers with a subscription model and increase their pricing 100%. Damn, I'm going back to OpenSource IDEs…

September 04, 2015
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:
>> 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.

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
September 04, 2015
On Friday, 4 September 2015 at 13:39:45 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 4 September 2015 at 07:52:30 UTC, Ola Fosheim Grøstad wrote:
>> I have no problem recommending TypeScript with WebStorm (or some other editor) for business like applications.
>
> Err... avoid WebStorm. Just noticed JetBrains have decided to rip off their customers with a subscription model and increase their pricing 100%. Damn, I'm going back to OpenSource IDEs…

I believe the FOSS version of Intellij can install the Javascript plugin which also adds support for Typescript.
May be wrong.