www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Experiments with emscripten and D

reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
This is SDL and std.algorithm code translated to JavaScript with 
emscripten. I've used the latest git versions of LDC and emscripten (the 
latter needed some modifications).

https://gist.github.com/pszturmaj/6244260
https://gist.github.com/pszturmaj/6244266

I couldn't manage to post it as single gist, and it seems there's a bug 
in the sdl.html gist (it looks empty). Just click Download Gist or '< >' 
icon (view raw) and save it as sdl.html.

Then open sdl.html in the web browser. It should print sorted and mapped 
array contents and run simple graphics demo.

I'm starting to work on this to fix the rest of the druntime so it can 
work under JS VM. Any help with this will be appreciated :-)
Aug 15 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Piotr Szturmaj:


 Then open sdl.html in the web browser. It should print sorted 
 and mapped array contents and run simple graphics demo.


Very nice. D is meant to run efficiently, but the Web is very 
important. There are many situations where it could be useful to 
run D code in a browser, so your work is important.

Integration with asm.js too is useful. (Expecially when asm.js 
gets a garbage collection, as Mozilla says). Currently only C and 
C++ are perhaps the only two languages usable to write 
asm.js+WebGL games for the browser. This could become one of the 
few niches open for D. There is also WebCL 
(http://www.khronos.org/webcl/ ) for heavy computations in the 
browser.

I have found some related activity from Rust people:
https://github.com/mozilla/rust/issues/2235
https://github.com/Yoric/Mozilla-Student-Projects/issues/33
https://mail.mozilla.org/pipermail/rust-dev/2012-April/001607.html

Once your work is more more completed, the dlang site could show 
(in a sub-page) the compiler that compiles the online examples of 
the docs that's able to produce html+JS on the fly from the D 
code written in the browser.

Bye,
bearophile
Aug 15 2013
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 15 August 2013 at 21:36:07 UTC, bearophile wrote:

 Integration with asm.js too is useful.


Doesn't the llvm backend do that automatically now? So ldc should 
get that too. I thought I read that llvm did in a blog somewhere, 
but I'm not sure.
Aug 15 2013
parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
W dniu 15.08.2013 23:45, Adam D. Ruppe pisze:

 On Thursday, 15 August 2013 at 21:36:07 UTC, bearophile wrote:

 Integration with asm.js too is useful.


 Doesn't the llvm backend do that automatically now? So ldc should get
 that too. I thought I read that llvm did in a blog somewhere, but I'm
 not sure.


Emscripten can output asm.js. Just add -s ASM_JS=1 to emcc arguments.
Aug 15 2013
prev sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
bearophile:

 Piotr Szturmaj:


 Then open sdl.html in the web browser. It should print sorted and
 mapped array contents and run simple graphics demo.


 Very nice. D is meant to run efficiently, but the Web is very important.
 There are many situations where it could be useful to run D code in a
 browser, so your work is important.

 Integration with asm.js too is useful. (Expecially when asm.js gets a
 garbage collection, as Mozilla says). Currently only C and C++ are
 perhaps the only two languages usable to write asm.js+WebGL games for
 the browser. This could become one of the few niches open for D. There
 is also WebCL (http://www.khronos.org/webcl/ ) for heavy computations in
 the browser.


Also D is garbage collected like JS. This means that high level code 
translation (like Adam D. Ruppe's work) should be more straightforward. 
On the other hand translating LLVM IR opens the possibility to mix D 
with C/C++ libraries.


 I have found some related activity from Rust people:
 https://github.com/mozilla/rust/issues/2235
 https://github.com/Yoric/Mozilla-Student-Projects/issues/33
 https://mail.mozilla.org/pipermail/rust-dev/2012-April/001607.html

 Once your work is more more completed, the dlang site could show (in a
 sub-page) the compiler that compiles the online examples of the docs
 that's able to produce html+JS on the fly from the D code written in the
 browser.


Yes, and it could be used to write rich web applications (which is the 
reason I'm working on it). JavaScript certainly wasn't created for big 
codebases...

The other big advantage would having one codebase shared between server, 
browser (including mobile) and desktop apps.
Aug 15 2013
next sibling parent Manu <turkeyman gmail.com> writes:
On 16 August 2013 07:55, Piotr Szturmaj <bncrbme jadamspam.pl> wrote:


 bearophile:

  Piotr Szturmaj:

  Then open sdl.html in the web browser. It should print sorted and

 mapped array contents and run simple graphics demo.


 Very nice. D is meant to run efficiently, but the Web is very important.
 There are many situations where it could be useful to run D code in a
 browser, so your work is important.

 Integration with asm.js too is useful. (Expecially when asm.js gets a
 garbage collection, as Mozilla says). Currently only C and C++ are
 perhaps the only two languages usable to write asm.js+WebGL games for
 the browser. This could become one of the few niches open for D. There
 is also WebCL (http://www.khronos.org/webcl/ ) for heavy computations in
 the browser.


 Also D is garbage collected like JS. This means that high level code
 translation (like Adam D. Ruppe's work) should be more straightforward. On
 the other hand translating LLVM IR opens the possibility to mix D with
 C/C++ libraries.


  I have found some related activity from Rust people:

 https://github.com/mozilla/**rust/issues/2235<https://github.com/mozilla/rust/issues/2235>
 https://github.com/Yoric/**Mozilla-Student-Projects/**issues/33<https://github.com/Yoric/Mozilla-Student-Projects/issues/33>
 https://mail.mozilla.org/**pipermail/rust-dev/2012-April/**001607.html<https://mail.mozilla.org/pipermail/rust-dev/2012-April/001607.html>

 Once your work is more more completed, the dlang site could show (in a
 sub-page) the compiler that compiles the online examples of the docs
 that's able to produce html+JS on the fly from the D code written in the
 browser.


 Yes, and it could be used to write rich web applications (which is the
 reason I'm working on it). JavaScript certainly wasn't created for big
 codebases...

 The other big advantage would having one codebase shared between server,
 browser (including mobile) and desktop apps.


^^ this!
I've been looking into this too recently.
Aug 15 2013
prev sibling parent reply Gambler <fake feather.org.ru> writes:
On 8/15/2013 5:55 PM, Piotr Szturmaj wrote:

 bearophile:

 Piotr Szturmaj:
 I have found some related activity from Rust people:
 https://github.com/mozilla/rust/issues/2235
 https://github.com/Yoric/Mozilla-Student-Projects/issues/33
 https://mail.mozilla.org/pipermail/rust-dev/2012-April/001607.html

 Once your work is more more completed, the dlang site could show (in a
 sub-page) the compiler that compiles the online examples of the docs
 that's able to produce html+JS on the fly from the D code written in the
 browser.


 
 Yes, and it could be used to write rich web applications (which is the
 reason I'm working on it). JavaScript certainly wasn't created for big
 codebases...


Never understood the excitement about things like these. Yes, it's
somewhat interesting and technically impressive, but in the end, the
only language that benefits here *is* JavaScript. And it's already
spreading like cancer. Why help it if you don't like it?

If even 1/10th of the effort spent on compile-everything-to-JS projects
was directed towards properly bringing other languages into the browser
land, the web would be a much better place now.


 The other big advantage would having one codebase shared between server,
 browser (including mobile) and desktop apps.


Yes, in theory. In practice, this is just something Node.JS people came
up with for advocacy of their platform. It's false. In-browser
JavaScript has so many constraints imposed on it that it will never
behave exactly like server-side code. (For example, your gist doesn't
work in IE. Not that I use IE normally, but you get my point.)

Worse, no one took time to actually design a sensible model of
interaction between server and the client for a "shared" codebase. It's
all a jumbled mess of ad-hoc implementations and subverted web
technologies that were originally meant for an entirely different
purpose. I sometimes see JS examples like this:

if (imOnTheServer){
    //do one thing
} eles {
    //do another thing
} //Yay, "shared" code!!!

Every time I do, I get the urge to abandon programming and change my
occupation.
Aug 17 2013
next sibling parent reply "Rob T" <alanb ucora.com> writes:
On Saturday, 17 August 2013 at 14:42:19 UTC, Gambler wrote:

 Every time I do, I get the urge to abandon programming and 
 change my
 occupation.


My thoughts too, The Internet is ripe for another revolution, but 
the old ways need to be abandoned rather than continually propped 
up with duct tape and thread. You can barely create simple 
applications using current html+js tools, and Flash and so forth 
consume vast amounts of memory and cpu power which can  stress 
out even a full blown desktop computer if you are a heavy browser 
user like I am, yet most "personal computers" are now low powered 
mobile devices which makes the situation really bad.

IMO the current direction leads to a dead end.

The big boys like Google, Mozilla and MS seem more interested in 
fighting each other over world domination rather than come up 
with viable alternatives that can lead the way out of this mess.

--rt
Aug 17 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Aug 17, 2013 at 05:30:28PM +0200, Rob T wrote:

 On Saturday, 17 August 2013 at 14:42:19 UTC, Gambler wrote:

Every time I do, I get the urge to abandon programming and change
my occupation.


 
 My thoughts too, The Internet is ripe for another revolution, but
 the old ways need to be abandoned rather than continually propped up
 with duct tape and thread. You can barely create simple applications
 using current html+js tools, and Flash and so forth consume vast
 amounts of memory and cpu power which can  stress out even a full
 blown desktop computer if you are a heavy browser user like I am,
 yet most "personal computers" are now low powered mobile devices
 which makes the situation really bad.
 
 IMO the current direction leads to a dead end.
 
 The big boys like Google, Mozilla and MS seem more interested in
 fighting each other over world domination rather than come up with
 viable alternatives that can lead the way out of this mess.


[...]

It's just like Nick Sabalausky always likes to rant about. In 1975, we
had slow 8-bit computers with 8kHz CPUs and 64kB of RAM, and our
applications ran rather slowly.  Then processor speed increased
exponentially, RAM increased exponentially, and today we have 64-bit
computers with 4GHz CPUs (and multicore!) and who knows how many GBs of
RAM, and our (web) applications run at about the same speed as in 1975.
Clearly, *something* is very, very wrong with this picture.


T

-- 
The fact that anyone still uses AOL shows that even the presence of options
doesn't stop some people from picking the pessimal one. - Mike Ellis
Aug 17 2013
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Saturday, 17 August 2013 at 16:35:46 UTC, H. S. Teoh wrote:

 On Sat, Aug 17, 2013 at 05:30:28PM +0200, Rob T wrote:

 On Saturday, 17 August 2013 at 14:42:19 UTC, Gambler wrote:

Every time I do, I get the urge to abandon programming and 
change
my occupation.


 
 My thoughts too, The Internet is ripe for another revolution, 
 but
 the old ways need to be abandoned rather than continually 
 propped up
 with duct tape and thread. You can barely create simple 
 applications
 using current html+js tools, and Flash and so forth consume 
 vast
 amounts of memory and cpu power which can  stress out even a 
 full
 blown desktop computer if you are a heavy browser user like I 
 am,
 yet most "personal computers" are now low powered mobile 
 devices
 which makes the situation really bad.
 
 IMO the current direction leads to a dead end.
 
 The big boys like Google, Mozilla and MS seem more interested 
 in
 fighting each other over world domination rather than come up 
 with
 viable alternatives that can lead the way out of this mess.


 [...]

 It's just like Nick Sabalausky always likes to rant about. In 
 1975, we
 had slow 8-bit computers with 8kHz CPUs and 64kB of RAM, and our
 applications ran rather slowly.  Then processor speed increased
 exponentially, RAM increased exponentially, and today we have 
 64-bit
 computers with 4GHz CPUs (and multicore!) and who knows how 
 many GBs of
 RAM, and our (web) applications run at about the same speed as 
 in 1975.
 Clearly, *something* is very, very wrong with this picture.


 T


How do we fix it? We have a great language here, let's 
revolutionise the web :p
Aug 17 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Aug 17, 2013 at 08:41:39PM +0200, John Colvin wrote:

 On Saturday, 17 August 2013 at 16:35:46 UTC, H. S. Teoh wrote:

On Sat, Aug 17, 2013 at 05:30:28PM +0200, Rob T wrote:

On Saturday, 17 August 2013 at 14:42:19 UTC, Gambler wrote:

Every time I do, I get the urge to abandon programming and change
my occupation.


My thoughts too, The Internet is ripe for another revolution, but
the old ways need to be abandoned rather than continually propped up
with duct tape and thread. You can barely create simple applications
using current html+js tools, and Flash and so forth consume vast
amounts of memory and cpu power which can  stress out even a full
blown desktop computer if you are a heavy browser user like I am,
yet most "personal computers" are now low powered mobile devices
which makes the situation really bad.

IMO the current direction leads to a dead end.

The big boys like Google, Mozilla and MS seem more interested in
fighting each other over world domination rather than come up with
viable alternatives that can lead the way out of this mess.


[...]

It's just like Nick Sabalausky always likes to rant about. In 1975,
we had slow 8-bit computers with 8kHz CPUs and 64kB of RAM, and our
applications ran rather slowly.  Then processor speed increased
exponentially, RAM increased exponentially, and today we have 64-bit
computers with 4GHz CPUs (and multicore!) and who knows how many GBs
of RAM, and our (web) applications run at about the same speed as in
1975.  Clearly, *something* is very, very wrong with this picture.


T


 
 How do we fix it? We have a great language here, let's revolutionise
 the web :p


Yeah! vibe.d FTW! :) And the client-side version thereof. :)


T

-- 
Bomb technician: If I'm running, try to keep up.
Aug 17 2013
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Saturday, 17 August 2013 at 18:51:23 UTC, H. S. Teoh wrote:

 On Sat, Aug 17, 2013 at 08:41:39PM +0200, John Colvin wrote:

 On Saturday, 17 August 2013 at 16:35:46 UTC, H. S. Teoh wrote:

On Sat, Aug 17, 2013 at 05:30:28PM +0200, Rob T wrote:

On Saturday, 17 August 2013 at 14:42:19 UTC, Gambler wrote:

Every time I do, I get the urge to abandon programming and 
change
my occupation.


My thoughts too, The Internet is ripe for another 
revolution, but
the old ways need to be abandoned rather than continually 
propped up
with duct tape and thread. You can barely create simple 
applications
using current html+js tools, and Flash and so forth consume 
vast
amounts of memory and cpu power which can  stress out even a 
full
blown desktop computer if you are a heavy browser user like 
I am,
yet most "personal computers" are now low powered mobile 
devices
which makes the situation really bad.

IMO the current direction leads to a dead end.

The big boys like Google, Mozilla and MS seem more 
interested in
fighting each other over world domination rather than come 
up with
viable alternatives that can lead the way out of this mess.


[...]

It's just like Nick Sabalausky always likes to rant about. In 
1975,
we had slow 8-bit computers with 8kHz CPUs and 64kB of RAM, 
and our
applications ran rather slowly.  Then processor speed 
increased
exponentially, RAM increased exponentially, and today we have 
64-bit
computers with 4GHz CPUs (and multicore!) and who knows how 
many GBs
of RAM, and our (web) applications run at about the same 
speed as in
1975.  Clearly, *something* is very, very wrong with this 
picture.


T


 
 How do we fix it? We have a great language here, let's 
 revolutionise
 the web :p


 Yeah! vibe.d FTW! :) And the client-side version thereof. :)


 T


Yeah the server-side is relatively easy to pull off, seeing as 
you're completely in control there.

The client side is an eensy little bit harder haha. It would 
probably require heavily modifying/creating a new web-browser and 
then convincing people to use it.

I wonder how powerful browser extensions can be these days...
Aug 17 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Aug 17, 2013 at 09:07:20PM +0200, John Colvin wrote:

 On Saturday, 17 August 2013 at 18:51:23 UTC, H. S. Teoh wrote:

On Sat, Aug 17, 2013 at 08:41:39PM +0200, John Colvin wrote:

On Saturday, 17 August 2013 at 16:35:46 UTC, H. S. Teoh wrote:






[...]

It's just like Nick Sabalausky always likes to rant about. In 1975,
we had slow 8-bit computers with 8kHz CPUs and 64kB of RAM, and our
applications ran rather slowly.  Then processor speed increased
exponentially, RAM increased exponentially, and today we have
64-bit computers with 4GHz CPUs (and multicore!) and who knows how
many GBs of RAM, and our (web) applications run at about the same
speed as in 1975.  Clearly, *something* is very, very wrong with
this picture.








[...]

How do we fix it? We have a great language here, let's revolutionise
the web :p


Yeah! vibe.d FTW! :) And the client-side version thereof. :)




[...]

 Yeah the server-side is relatively easy to pull off, seeing as
 you're completely in control there.
 
 The client side is an eensy little bit harder haha. It would
 probably require heavily modifying/creating a new web-browser and
 then convincing people to use it.
 
 I wonder how powerful browser extensions can be these days...


Hmm. That's an idea, write an extension that can run code through rdmd.
(You have to deliver the source rather than the object code, since you
don't know what OS your client is running on.)

Requiring an extension puts it in the same boat as Flash, though. :-(

And you'd have to sandbox the code since arbitrary D code running wild
on the user's computer is a Bad Thing(tm). Which runs into GC-related
issues when your client is a low-memory handheld device. Though arguably
this would still be an improvement over JS, since an interpreted
language necessarily uses more resources.


T

-- 
Prosperity breeds contempt, and poverty breeds consent. -- Suck.com
Aug 17 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 17 August 2013 at 20:42:33 UTC, H. S. Teoh wrote:

 And you'd have to sandbox the code since arbitrary D code 
 running wild
 on the user's computer is a Bad Thing(tm). Which runs into 
 GC-related
 issues when your client is a low-memory handheld device. Though 
 arguably
 this would still be an improvement over JS, since an interpreted
 language necessarily uses more resources.


You are getting pretty close to NaCl idea :)
Aug 17 2013
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Saturday, 17 August 2013 at 20:58:09 UTC, Dicebot wrote:

 On Saturday, 17 August 2013 at 20:42:33 UTC, H. S. Teoh wrote:

 And you'd have to sandbox the code since arbitrary D code 
 running wild
 on the user's computer is a Bad Thing(tm). Which runs into 
 GC-related
 issues when your client is a low-memory handheld device. 
 Though arguably
 this would still be an improvement over JS, since an 
 interpreted
 language necessarily uses more resources.


 You are getting pretty close to NaCl idea :)


Yeah, I was thinking that :p

NaCl seems designed mostly as native extensions for the 
html/js/css world.

I was thinking bigger: The browser as a (transient, if 
appropriate) application delivery system.

I really dislike html and css for anything other than simple 
documents, it quickly feels like one big patchily supported 
corner-case. Anything other than simple uses ends up requiring 
significant abuses, even if you're lucky enough to be working in 
a hypothetical totally standards compliant environment. Even 
something as simple as a drop-down menu with persistence means 
either: massively abuse css OR use JS.

What I'm imagining is a truly dynamic web-delivered UI with 
native speed and processing capability, not just a faster web-app.
Aug 17 2013
next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Saturday, 17 August 2013 at 21:16:59 UTC, John Colvin wrote:

 On Saturday, 17 August 2013 at 20:58:09 UTC, Dicebot wrote:

 On Saturday, 17 August 2013 at 20:42:33 UTC, H. S. Teoh wrote:

 And you'd have to sandbox the code since arbitrary D code 
 running wild
 on the user's computer is a Bad Thing(tm). Which runs into 
 GC-related
 issues when your client is a low-memory handheld device. 
 Though arguably
 this would still be an improvement over JS, since an 
 interpreted
 language necessarily uses more resources.


 You are getting pretty close to NaCl idea :)


 Yeah, I was thinking that :p

 NaCl seems designed mostly as native extensions for the 
 html/js/css world.

 I was thinking bigger: The browser as a (transient, if 
 appropriate) application delivery system.

 I really dislike html and css for anything other than simple 
 documents, it quickly feels like one big patchily supported 
 corner-case. Anything other than simple uses ends up requiring 
 significant abuses, even if you're lucky enough to be working 
 in a hypothetical totally standards compliant environment. Even 
 something as simple as a drop-down menu with persistence means 
 either: massively abuse css OR use JS.

 What I'm imagining is a truly dynamic web-delivered UI with 
 native speed and processing capability, not just a faster 
 web-app.


This would still be working - to some extent, in the browser:
the end user experience can be as seamless or as seperated as the 
developer wants. Your D app could look just like a webpage and 
behave just like a webpage, or it could be a totally separate 
window that appears to have no relation to the web as we know it.

For an increasing number of users these days, the browser *is* 
the computer. They barely touch anything else. Nobody wants to 
install another program to do every little task, but they'll 
happily click a link to a specialised web-app. Native apps took 
off on mobile, but at the same time they were dying on the 
desktop. Now the view seems to be to want to kill them on mobile 
too and make everything a web-app. Perhaps we can get the best of 
both worlds.

What I want is a true way out from the current obsession with 
trying to shoe-horn every possible use-case in to html/css/js 
with the associated necessary over-reliance on js, which is by 
all accounts a horrible language.
Aug 17 2013
prev sibling parent Gambler <fake feather.org.ru> writes:
On 8/17/2013 5:16 PM, John Colvin wrote:

 On Saturday, 17 August 2013 at 20:58:09 UTC, Dicebot wrote:

 On Saturday, 17 August 2013 at 20:42:33 UTC, H. S. Teoh wrote:

 And you'd have to sandbox the code since arbitrary D code running wild
 on the user's computer is a Bad Thing(tm). Which runs into GC-related
 issues when your client is a low-memory handheld device. Though arguably
 this would still be an improvement over JS, since an interpreted
 language necessarily uses more resources.


 You are getting pretty close to NaCl idea :)


 
 Yeah, I was thinking that :p
 
 NaCl seems designed mostly as native extensions for the html/js/css world.
 
 I was thinking bigger: The browser as a (transient, if appropriate)
 application delivery system.


IMO, fixing the web and creating a simple/secure delivery/sandboxing
system for native apps are two different tasks. Both are very much
needed, but the solutions are unlikely to overlap. MS Research is
working on several projects for app delivery. Joanna Rutkowska has her
Cubes project, which sounds very, very interesting. None of those will
fix the problems Web is facing, though. (Aside from taking away the need
for thick-client-implemented-in-JS applications.)
Aug 18 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Saturday, 17 August 2013 at 20:42:33 UTC, H. S. Teoh wrote:

 On Sat, Aug 17, 2013 at 09:07:20PM +0200, John Colvin wrote:

 On Saturday, 17 August 2013 at 18:51:23 UTC, H. S. Teoh wrote:

On Sat, Aug 17, 2013 at 08:41:39PM +0200, John Colvin wrote:

On Saturday, 17 August 2013 at 16:35:46 UTC, H. S. Teoh 
wrote:






 [...]

It's just like Nick Sabalausky always likes to rant about. 
In 1975,
we had slow 8-bit computers with 8kHz CPUs and 64kB of RAM, 
and our
applications ran rather slowly.  Then processor speed 
increased
exponentially, RAM increased exponentially, and today we 
have
64-bit computers with 4GHz CPUs (and multicore!) and who 
knows how
many GBs of RAM, and our (web) applications run at about 
the same
speed as in 1975.  Clearly, *something* is very, very wrong 
with
this picture.








 [...]

How do we fix it? We have a great language here, let's 
revolutionise
the web :p


Yeah! vibe.d FTW! :) And the client-side version thereof. :)




 [...]

 Yeah the server-side is relatively easy to pull off, seeing as
 you're completely in control there.
 
 The client side is an eensy little bit harder haha. It would
 probably require heavily modifying/creating a new web-browser 
 and
 then convincing people to use it.
 
 I wonder how powerful browser extensions can be these days...


 Hmm. That's an idea, write an extension that can run code 
 through rdmd.
 (You have to deliver the source rather than the object code, 
 since you
 don't know what OS your client is running on.)


not necessarily. The extension would know and could tell the 
server which version to send (with an optional fallback to code 
for systems that you don't have a binary ready for). It could 
also query shared library / dll versions.
Also, you could just send llvm IR...


 Requiring an extension puts it in the same boat as Flash, 
 though. :-(


An extension today, built-in to the browser tomorrow?


 And you'd have to sandbox the code since arbitrary D code 
 running wild
 on the user's computer is a Bad Thing(tm). Which runs into 
 GC-related
 issues when your client is a low-memory handheld device. Though 
 arguably
 this would still be an improvement over JS, since an interpreted
 language necessarily uses more resources.


 T


most, if not all operating systems have good sandboxing, don't 
they? iOS sandboxes the hell out of everything and I presume 
android does something similar. on linux you can use selinux 
utility sandbox or similar.
Aug 17 2013
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 17 August 2013 at 20:42:33 UTC, H. S. Teoh wrote:

 And you'd have to sandbox the code since arbitrary D code 
 running wild on the user's computer is a Bad Thing(tm).


You have to do that with javascript anyway, just in case your 
impl has a security flaw. Run it in a separate process with a 
restricted security token and you'll be in decent shape.

...though, you know, just thinking wildly here, I wonder how well 
it'd work if you used a virtual machine. They are pretty quick 
nowadays thanks to fancy hardware and such. What if your browser 
extension fired up a tiny little virtual machine, ran the one 
process and just mapped its video framebuffer to the browser 
window?

Then the one program can just be a standard program using a 
special library (I've make small executables with an unmodified 
dmd that can run on bare metal), no need to modify the compiler 
like with google's salt thing.

I wonder how hard it would be to write that. Searching the web 
for kvm though always assumes qemu. No, I want to write a 
super-small qemu, and I don't care if it can't boot linux. How 
hard can it be?

but i'd better not get too much into it, I already have other 
plans for the next few weeks. Gotta finish my minigui.d!
Aug 17 2013
parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
W dniu 18.08.2013 03:58, Adam D. Ruppe pisze:

 I wonder how hard it would be to write that. Searching the web for kvm
 though always assumes qemu. No, I want to write a super-small qemu, and
 I don't care if it can't boot linux. How hard can it be?


Someone has written an LLVM backend for DCPU-16 and here's the JS 
emulator of it:
https://github.com/mappum/DCPU-16
Aug 17 2013
prev sibling next sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
W dniu 17.08.2013 16:42, Gambler pisze:

 On 8/15/2013 5:55 PM, Piotr Szturmaj wrote:

 bearophile:

 Piotr Szturmaj:
 I have found some related activity from Rust people:
 https://github.com/mozilla/rust/issues/2235
 https://github.com/Yoric/Mozilla-Student-Projects/issues/33
 https://mail.mozilla.org/pipermail/rust-dev/2012-April/001607.html

 Once your work is more more completed, the dlang site could show (in a
 sub-page) the compiler that compiles the online examples of the docs
 that's able to produce html+JS on the fly from the D code written in the
 browser.


 Yes, and it could be used to write rich web applications (which is the
 reason I'm working on it). JavaScript certainly wasn't created for big
 codebases...


 Never understood the excitement about things like these. Yes, it's
 somewhat interesting and technically impressive, but in the end, the
 only language that benefits here *is* JavaScript. And it's already
 spreading like cancer. Why help it if you don't like it?

 If even 1/10th of the effort spent on compile-everything-to-JS projects
 was directed towards properly bringing other languages into the browser
 land, the web would be a much better place now.


It's not about helping JavaScript. It's about using another language to 
do client side scripting. I hate JS, I really don't like to write bigger 
applications in it.

What happens when you forget a semicolon or a comma? Or make some typos? 
It silently breaks. I don't care if there are tools to help with it. 
It's still a mess. Did you see WAT 
(https://www.destroyallsoftware.com/talks/wat) ? If not, please do. Here 
are some examples of JS "additions" which WAT demonstrated:

[] + [] // yields empty string
[] + {} // [object Object]
{} + [] // 0
{} + {} // NaN

Seriously, WTF!

And again, I don't want to write in it, but I _must_ use it. I just want 
to use another language that translates to JS. There are many of them 
already. Still, no one is even close to D in its usefulness.

The whole problem is that you need to write a web applications _now_, 
when the only supported languages for the web is JS. You really don't 
have a choice. Even if other languages could be widely supported from 
today, you'd still have to support older browsers. This means JS will 
stay in for another couple of years.


 The other big advantage would having one codebase shared between server,
 browser (including mobile) and desktop apps.


 Yes, in theory. In practice, this is just something Node.JS people came
 up with for advocacy of their platform. It's false. In-browser
 JavaScript has so many constraints imposed on it that it will never
 behave exactly like server-side code. (For example, your gist doesn't
 work in IE. Not that I use IE normally, but you get my point.)


Obviously, you can't share every possible code. It's about sharing the 
cross cutting parts. Imagine an application with a server, web frontend 
and desktop frontend. With shared codebases, you could write one client 
code. Just use the same abstractions for the web and for the desktop. 
Then you can create similar interfaces from the same codebase. It's a 
huge win. Duplicating efforts is tiresome, error prone and obviously 
takes time.


 Worse, no one took time to actually design a sensible model of
 interaction between server and the client for a "shared" codebase. It's
 all a jumbled mess of ad-hoc implementations and subverted web
 technologies that were originally meant for an entirely different
 purpose. I sometimes see JS examples like this:

 if (imOnTheServer){
      //do one thing
 } eles {
      //do another thing
 } //Yay, "shared" code!!!

 Every time I do, I get the urge to abandon programming and change my
 occupation.


This is not a new idea. Morfik is a webdev tool that automatically 
splits your code to the server and JS. I remember it was available in 
2005. Also, there is Opa language.

I don't see anything wrong with cross platform code. For D example, I'd 
imagine it could look like this:

void showMsg(string s) {
     version (JS)
         js.alert(s);
     else
         YourDesktopWidgetToolkit.showMessageDialog(s);
}

void main() {
     showMsg("hello world");
}

Compiled with a regular compiler and GTK, will show a dialog.
Compiled with emscripten-like compiler will show a message in the browser.
Aug 17 2013
next sibling parent reply Gambler <fake feather.org.ru> writes:
On 8/17/2013 12:43 PM, Piotr Szturmaj wrote:

 W dniu 17.08.2013 16:42, Gambler pisze:

 On 8/15/2013 5:55 PM, Piotr Szturmaj wrote:

 bearophile:

 Piotr Szturmaj:
 I have found some related activity from Rust people:
 https://github.com/mozilla/rust/issues/2235
 https://github.com/Yoric/Mozilla-Student-Projects/issues/33
 https://mail.mozilla.org/pipermail/rust-dev/2012-April/001607.html

 Once your work is more more completed, the dlang site could show (in a
 sub-page) the compiler that compiles the online examples of the docs
 that's able to produce html+JS on the fly from the D code written in
 the
 browser.


 Yes, and it could be used to write rich web applications (which is the
 reason I'm working on it). JavaScript certainly wasn't created for big
 codebases...


 Never understood the excitement about things like these. Yes, it's
 somewhat interesting and technically impressive, but in the end, the
 only language that benefits here *is* JavaScript. And it's already
 spreading like cancer. Why help it if you don't like it?

 If even 1/10th of the effort spent on compile-everything-to-JS projects
 was directed towards properly bringing other languages into the browser
 land, the web would be a much better place now.


 
 It's not about helping JavaScript. It's about using another language to
 do client side scripting. I hate JS, I really don't like to write bigger
 applications in it.
 
 What happens when you forget a semicolon or a comma? Or make some typos?
 It silently breaks. I don't care if there are tools to help with it.
 It's still a mess. Did you see WAT
 (https://www.destroyallsoftware.com/talks/wat) ? If not, please do. Here
 are some examples of JS "additions" which WAT demonstrated:
 
 [] + [] // yields empty string
 [] + {} // [object Object]
 {} + [] // 0
 {} + {} // NaN
 
 Seriously, WTF!


WAT is one of my favorite language talks of all times. So we're on the
same page here. But I don't think compiling D to JavaScript is a viable
long-term solution.

1. The more languages compile to JS, the more powerful it becomes and
the harder it will be to replace JS with something better. People will
spend more money on optimizing its (not D's) performance, developing its
(not D's) APIs for stuff like sound and graphics. This is already
happening. I recently interviewed a junior developer for a position that
had nothing to do with JavaScript. At some point during the interview he
said: "JavaScript is the future of everything". Yeah, it's the actual
phrasing he used. That's what some people believe in.

2. Compiling things to an intermediate language creates a whole host of
new problems you don't have originally. How do you debug? How do you
print an accurate stack trace?  Etc.

3. Even if the tool-chain is perfect, a lot of real work in the browser
is done by calling APIs. If those APIs are designed for JavaScript,
their usage will not be idiomatic inside translated code unless you
manually create wrappers.

It would still be fine if the whole thing hand some kind of gradual
upgrade path that led to using pure D, but I don't see such path.


 And again, I don't want to write in it, but I _must_ use it. I just want
 to use another language that translates to JS. There are many of them
 already. Still, no one is even close to D in its usefulness.


My personal strategy to mitigate the horrors of JavaScript is to use
progressive enhancement and write small, targeted JS libraries that are
invoked declaratively (i.e. you include them, but then it's all about
HTML markup and there is no application-specific JS). Contrary to
popular opinion, this approach is capable of creating very efficient and
very dynamic websites.


 The whole problem is that you need to write a web applications _now_,
 when the only supported languages for the web is JS. You really don't
 have a choice. Even if other languages could be widely supported from
 today, you'd still have to support older browsers. This means JS will
 stay in for another couple of years.


If things don't change trajectory, I'm afraid JS will not just "stay for
a couple of years". It will become de-facto standard for server-side web
computing and displace all other languages in that domain. In the
company I work for, there is already a number of people calling to
rewrite all the web app for Node. I don't see a single tangible benefit
coming out of it if, though. It would be a maintainability nightmare.


 The other big advantage would having one codebase shared between server,
 browser (including mobile) and desktop apps.


 Yes, in theory. In practice, this is just something Node.JS people came
 up with for advocacy of their platform. It's false. In-browser
 JavaScript has so many constraints imposed on it that it will never
 behave exactly like server-side code. (For example, your gist doesn't
 work in IE. Not that I use IE normally, but you get my point.)


 
 Obviously, you can't share every possible code. It's about sharing the
 cross cutting parts. Imagine an application with a server, web frontend
 and desktop frontend. With shared codebases, you could write one client
 code. Just use the same abstractions for the web and for the desktop.
 Then you can create similar interfaces from the same codebase. It's a
 huge win. Duplicating efforts is tiresome, error prone and obviously
 takes time.


This is another reason why I try to design everything using progressive
enhancement. It results in very little duplication between client-side
and server-side code. Each side has a clearly designated purpose and
they rarely overlap. I wish there were more JS libraries that encourages
this kind of development style, though.


 Worse, no one took time to actually design a sensible model of
 interaction between server and the client for a "shared" codebase. It's
 all a jumbled mess of ad-hoc implementations and subverted web
 technologies that were originally meant for an entirely different
 purpose. I sometimes see JS examples like this:

 if (imOnTheServer){
      //do one thing
 } eles {
      //do another thing
 } //Yay, "shared" code!!!

 Every time I do, I get the urge to abandon programming and change my
 occupation.


 
 This is not a new idea. Morfik is a webdev tool that automatically
 splits your code to the server and JS. I remember it was available in
 2005. Also, there is Opa language.
 
 I don't see anything wrong with cross platform code. For D example, I'd
 imagine it could look like this:
 
 void showMsg(string s) {
     version (JS)
         js.alert(s);
     else
         YourDesktopWidgetToolkit.showMessageDialog(s);
 }
 
 void main() {
     showMsg("hello world");
 }
 
 Compiled with a regular compiler and GTK, will show a dialog.
 Compiled with emscripten-like compiler will show a message in the browser.


What you're talking about is compiling the same code to run in the
browser and as a standalone client. But that's not the same as running
the same code on the client and server side, because in that case there
would be message sender code (on the server) and message receiver code
(on the client). They would need to communicate in some manner. That's
not a trivial problem to solve.
Aug 17 2013
parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
W dniu 17.08.2013 23:05, Gambler pisze:

 On 8/17/2013 12:43 PM, Piotr Szturmaj wrote:

 W dniu 17.08.2013 16:42, Gambler pisze:

 On 8/15/2013 5:55 PM, Piotr Szturmaj wrote:

 bearophile:

 Piotr Szturmaj:
 I have found some related activity from Rust people:
 https://github.com/mozilla/rust/issues/2235
 https://github.com/Yoric/Mozilla-Student-Projects/issues/33
 https://mail.mozilla.org/pipermail/rust-dev/2012-April/001607.html

 Once your work is more more completed, the dlang site could show (in a
 sub-page) the compiler that compiles the online examples of the docs
 that's able to produce html+JS on the fly from the D code written in
 the
 browser.


 Yes, and it could be used to write rich web applications (which is the
 reason I'm working on it). JavaScript certainly wasn't created for big
 codebases...


 Never understood the excitement about things like these. Yes, it's
 somewhat interesting and technically impressive, but in the end, the
 only language that benefits here *is* JavaScript. And it's already
 spreading like cancer. Why help it if you don't like it?

 If even 1/10th of the effort spent on compile-everything-to-JS projects
 was directed towards properly bringing other languages into the browser
 land, the web would be a much better place now.


 It's not about helping JavaScript. It's about using another language to
 do client side scripting. I hate JS, I really don't like to write bigger
 applications in it.

 What happens when you forget a semicolon or a comma? Or make some typos?
 It silently breaks. I don't care if there are tools to help with it.
 It's still a mess. Did you see WAT
 (https://www.destroyallsoftware.com/talks/wat) ? If not, please do. Here
 are some examples of JS "additions" which WAT demonstrated:

 [] + [] // yields empty string
 [] + {} // [object Object]
 {} + [] // 0
 {} + {} // NaN

 Seriously, WTF!


 WAT is one of my favorite language talks of all times. So we're on the
 same page here. But I don't think compiling D to JavaScript is a viable
 long-term solution.

 1. The more languages compile to JS, the more powerful it becomes and
 the harder it will be to replace JS with something better. People will
 spend more money on optimizing its (not D's) performance, developing its
 (not D's) APIs for stuff like sound and graphics. This is already
 happening. I recently interviewed a junior developer for a position that
 had nothing to do with JavaScript. At some point during the interview he
 said: "JavaScript is the future of everything". Yeah, it's the actual
 phrasing he used. That's what some people believe in.

 2. Compiling things to an intermediate language creates a whole host of
 new problems you don't have originally. How do you debug? How do you
 print an accurate stack trace?  Etc.


This is known problem and many JS-like languages use "source maps" to 
solve it.


 3. Even if the tool-chain is perfect, a lot of real work in the browser
 is done by calling APIs. If those APIs are designed for JavaScript,
 their usage will not be idiomatic inside translated code unless you
 manually create wrappers.


Yes, but we don't want to be strictly idiomatic. We just want to call JS 
code (modify the DOM, enable a button, or interface to JS widget 
toolkit). Idiomatic JS code more or less boils down to creating objects 
and calling functions. GWT is another example of such effort. It 
translates Java code to JS. "GWT is used by many products at Google, 
including AdWords, AdSense, Flights, Hotel Finder, Offers, Wallet, 
Blogger." - from GWT website.


 It would still be fine if the whole thing hand some kind of gradual
 upgrade path that led to using pure D, but I don't see such path.


There must be a first step :-)


 And again, I don't want to write in it, but I _must_ use it. I just want
 to use another language that translates to JS. There are many of them
 already. Still, no one is even close to D in its usefulness.


 My personal strategy to mitigate the horrors of JavaScript is to use
 progressive enhancement and write small, targeted JS libraries that are
 invoked declaratively (i.e. you include them, but then it's all about
 HTML markup and there is no application-specific JS). Contrary to
 popular opinion, this approach is capable of creating very efficient and
 very dynamic websites.


This approach is limiting in some scenarios. Think about RIAs and 
interfacing to existing JS libraries.


 The whole problem is that you need to write a web applications _now_,
 when the only supported languages for the web is JS. You really don't
 have a choice. Even if other languages could be widely supported from
 today, you'd still have to support older browsers. This means JS will
 stay in for another couple of years.


 If things don't change trajectory, I'm afraid JS will not just "stay for
 a couple of years". It will become de-facto standard for server-side web
 computing and displace all other languages in that domain. In the
 company I work for, there is already a number of people calling to
 rewrite all the web app for Node. I don't see a single tangible benefit
 coming out of it if, though. It would be a maintainability nightmare.


Yes it would be a mess. But, IMHO even if great number of people talk 
about "JS everywhere" it's not going to happen. Nobody wants to rewrite 
tens of thousands lines of code if it already works. Why create the same 
product multiple times? I understand rewriting JS to other lang, but not 
the other way.


 The other big advantage would having one codebase shared between server,
 browser (including mobile) and desktop apps.


 Yes, in theory. In practice, this is just something Node.JS people came
 up with for advocacy of their platform. It's false. In-browser
 JavaScript has so many constraints imposed on it that it will never
 behave exactly like server-side code. (For example, your gist doesn't
 work in IE. Not that I use IE normally, but you get my point.)


 Obviously, you can't share every possible code. It's about sharing the
 cross cutting parts. Imagine an application with a server, web frontend
 and desktop frontend. With shared codebases, you could write one client
 code. Just use the same abstractions for the web and for the desktop.
 Then you can create similar interfaces from the same codebase. It's a
 huge win. Duplicating efforts is tiresome, error prone and obviously
 takes time.


 This is another reason why I try to design everything using progressive
 enhancement. It results in very little duplication between client-side
 and server-side code. Each side has a clearly designated purpose and
 they rarely overlap. I wish there were more JS libraries that encourages
 this kind of development style, though.


For client/server this is a regular approach if you don't take a desktop 
frontend into account. Otherwise you'd have two client-side frontends, 
desktop and the web and they must overlap.


 Worse, no one took time to actually design a sensible model of
 interaction between server and the client for a "shared" codebase. It's
 all a jumbled mess of ad-hoc implementations and subverted web
 technologies that were originally meant for an entirely different
 purpose. I sometimes see JS examples like this:

 if (imOnTheServer){
       //do one thing
 } eles {
       //do another thing
 } //Yay, "shared" code!!!

 Every time I do, I get the urge to abandon programming and change my
 occupation.


 This is not a new idea. Morfik is a webdev tool that automatically
 splits your code to the server and JS. I remember it was available in
 2005. Also, there is Opa language.

 I don't see anything wrong with cross platform code. For D example, I'd
 imagine it could look like this:

 void showMsg(string s) {
      version (JS)
          js.alert(s);
      else
          YourDesktopWidgetToolkit.showMessageDialog(s);
 }

 void main() {
      showMsg("hello world");
 }

 Compiled with a regular compiler and GTK, will show a dialog.
 Compiled with emscripten-like compiler will show a message in the browser.


 What you're talking about is compiling the same code to run in the
 browser and as a standalone client. But that's not the same as running
 the same code on the client and server side, because in that case there
 would be message sender code (on the server) and message receiver code
 (on the client). They would need to communicate in some manner. That's
 not a trivial problem to solve.


I don't know, but you probably meant automatic splitting a single 
function to client and server code. This is not what I want (yet ;-)). 
Communication would be done regular way such as this:

ran in the web browser:

version(JS)
string getData(string id) {
     // this would need async to blocking code transform
     return js.ajaxRequest("/getData", id);
}

ran on the server:

void handleRequest(Request req) {
     if (req.relativeUrl == "/getData") {
	auto data = db.getData(req.requestData /* id */);
         req.respond(data);
     }
}

Nothing magical here.
Aug 17 2013
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 17 August 2013 at 16:43:14 UTC, Piotr Szturmaj wrote:

 What happens when you forget a semicolon or a comma? Or make 
 some typos? It silently breaks. I don't care if there are tools 
 to help with it. It's still a mess. Did you see WAT 
 (https://www.destroyallsoftware.com/talks/wat) ? If not, please 
 do. Here are some examples of JS "additions" which WAT 
 demonstrated:

 [] + [] // yields empty string
 [] + {} // [object Object]
 {} + [] // 0
 {} + {} // NaN

 Seriously, WTF!


I could explain, but I'm not sure you are interested. The 
ambiguity on that one come from {} being either an object literal 
or a block statement.

I feel pretty confident I can do a wat speech for D.


 Obviously, you can't share every possible code. It's about 
 sharing the cross cutting parts. Imagine an application with a 
 server, web frontend and desktop frontend. With shared 
 codebases, you could write one client code. Just use the same 
 abstractions for the web and for the desktop. Then you can 
 create similar interfaces from the same codebase. It's a huge 
 win. Duplicating efforts is tiresome, error prone and obviously 
 takes time.


It has already been done, but didn't caught up. Actually I can't 
even find theses project in google, so I guess ti was a compete 
fail.

It worked, but cause many problem, especially securitywise.
Aug 17 2013
next sibling parent Gambler <fake feather.org.ru> writes:
On 8/18/2013 12:52 AM, deadalnix wrote:

 On Saturday, 17 August 2013 at 16:43:14 UTC, Piotr Szturmaj wrote:

 What happens when you forget a semicolon or a comma? Or make some
 typos? It silently breaks. I don't care if there are tools to help
 with it. It's still a mess. Did you see WAT
 (https://www.destroyallsoftware.com/talks/wat) ? If not, please do.
 Here are some examples of JS "additions" which WAT demonstrated:

 [] + [] // yields empty string
 [] + {} // [object Object]
 {} + [] // 0
 {} + {} // NaN

 Seriously, WTF!


 
 I could explain, but I'm not sure you are interested. The ambiguity on
 that one come from {} being either an object literal or a block statement.


This is what slays me about JavaScritpt community. There is always
someone who says "I can explain!" and starts posting type conversion
trivia. Which is irrelevant, because no one cares *how* exactly this
happens. What's important is *why* and there are no graceful
explanations for that. JavaScript's type system is a bloody mess.

[0, -1, -2].sort() returns [-1, -2, 0].

["1", "2", "3", "4", "5", "6", "7", "8", "9"].map(parseInt) returns [1,
NaN, NaN, NaN, NaN, NaN, NaN, NaN, NaN].

2147483648 | 0 returns -2147483648.

But I'm not even sure that's the worst part of the language. I think the
absolute worst aspect of JS is that it's missing huge chunks of *basic*
functionality, so everyone invents their own "design patterns" by
abusing the hell of what's available.

Actual example from StackOverflow with 145 upvotes:

var CONFIG = (function() {
     var private = {
         'MY_CONST': '1',
     };

     return {
        get: function(name) { return private[name]; }
    };
})();
alert(CONFIG.get('MY_CONST')); //I invented constants!!!

So in the end every project ends up using their own little set of ugly
hacks that's both hard to read and differs from whatever everyone else
is doing.


 I feel pretty confident I can do a wat speech for D.


Not with such succinct, hilarious, obviously broken examples, I bet.


 Obviously, you can't share every possible code. It's about sharing the
 cross cutting parts. Imagine an application with a server, web
 frontend and desktop frontend. With shared codebases, you could write
 one client code. Just use the same abstractions for the web and for
 the desktop. Then you can create similar interfaces from the same
 codebase. It's a huge win. Duplicating efforts is tiresome, error
 prone and obviously takes time.


 
 It has already been done, but didn't caught up. Actually I can't even
 find theses project in google, so I guess ti was a compete fail.
 
 It worked, but cause many problem, especially securitywise.
Aug 18 2013
prev sibling next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Sunday, 18 August 2013 at 04:52:16 UTC, deadalnix wrote:

 I feel pretty confident I can do a wat speech for D.


I can't think of many wats. There are questionable design 
decisions, annoying things that look like they should compile but 
don't (local variable alias to non-global template errors 
anyone?) and performance pitfalls, but nothing so gloriously 
broken as what javascript achieves.

Coming from a C(++) perspective has prevented a lot of complete 
gibbering insanity from occurring. In particular, having a basic 
respect for data-layout at the machine level and an ethos of not 
doing very costly implicit type type-conversions has staved off a 
whole horde of crazy.
Aug 18 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 18 August 2013 at 11:21:52 UTC, John Colvin wrote:

 On Sunday, 18 August 2013 at 04:52:16 UTC, deadalnix wrote:

 I feel pretty confident I can do a wat speech for D.


 I can't think of many wats. There are questionable design 
 decisions, annoying things that look like they should compile 
 but don't (local variable alias to non-global template errors 
 anyone?) and performance pitfalls, but nothing so gloriously 
 broken as what javascript achieves.


I know many of them. That is probably because I'm working on SDC, 
so I have to dig into dark corner of the language, nevertheless, 
it is really possible to do.

In fact I planned to do it, but Denis Korskin warned me about the 
bad image it would create of D, and I have to admit he was right, 
so I abandoned the idea.


 Coming from a C(++) perspective has prevented a lot of complete 
 gibbering insanity from occurring. In particular, having a 
 basic respect for data-layout at the machine level and an ethos 
 of not doing very costly implicit type type-conversions has 
 staved off a whole horde of crazy.


I'm not here for nothing :D
Aug 18 2013
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Sunday, 18 August 2013 at 12:48:49 UTC, deadalnix wrote:

 On Sunday, 18 August 2013 at 11:21:52 UTC, John Colvin wrote:

 On Sunday, 18 August 2013 at 04:52:16 UTC, deadalnix wrote:

 I feel pretty confident I can do a wat speech for D.


 I can't think of many wats. There are questionable design 
 decisions, annoying things that look like they should compile 
 but don't (local variable alias to non-global template errors 
 anyone?) and performance pitfalls, but nothing so gloriously 
 broken as what javascript achieves.


 I know many of them. That is probably because I'm working on 
 SDC, so I have to dig into dark corner of the language, 
 nevertheless, it is really possible to do.

 In fact I planned to do it, but Denis Korskin warned me about 
 the bad image it would create of D, and I have to admit he was 
 right, so I abandoned the idea.


I presume they are at least documented somewhere? A page on the 
wiki? I'd be interested to see them myself. Who knows, maybe some 
of them are fixable?


 Coming from a C(++) perspective has prevented a lot of 
 complete gibbering insanity from occurring. In particular, 
 having a basic respect for data-layout at the machine level 
 and an ethos of not doing very costly implicit type 
 type-conversions has staved off a whole horde of crazy.


 I'm not here for nothing :D


good point :)
Aug 18 2013
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Aug 18, 2013 at 06:52:14AM +0200, deadalnix wrote:
[...]

 I feel pretty confident I can do a wat speech for D.


[...]

Please do, I'm curious to hear it. :)

I can't think of any major WATs in D that come from the language itself.
Compiler bugs, OTOH, often elicits a "wat?!" from me, one recent example
being this gem from a friend:

	import std.algorithm, std.stdio;
	void main()
	{
	        int[] arr = [3,4,2,1];
	
	        bool less(int a, int b)
	                { return a < b; }
	        bool greater(int a, int b)
	                { return a > b; }
	
	        {
	                auto dg = &less;
	                sort!(dg)(arr);
	        }
	        //this dg *should* be different from older destroyed dg
	        //rename to dg2 and everything works as expected
	        auto dg = &greater;
	        sort!(dg)(arr);
	
	        writeln(arr);
	        //outputs [1,2,3,4] instead of [4,3,2,1]
	        //change dg variable name in either place and it works
	        //also, if you don't do the 1st sort, it works correctly even with
same variable name
	}


http://d.puremagic.com/issues/show_bug.cgi?id=10619


T

-- 
We've all heard that a million monkeys banging on a million typewriters will
eventually reproduce the entire works of Shakespeare.  Now, thanks to the
Internet, we know this is not true. -- Robert Wilensk
Aug 18 2013
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.186.1376878962.1719.digitalmars-d puremagic.com...

 On Sun, Aug 18, 2013 at 06:52:14AM +0200, deadalnix wrote:
 [...]

 I feel pretty confident I can do a wat speech for D.


 [...]

 Please do, I'm curious to hear it. :)


import std.algorithm : filter, map;

void main()
{
    foreach(c; map!"a"("hello")) // Identity map function
        static assert(c.sizeof == 4); // Passes

    foreach(c; filter!"true"("hello")) // Pass-all filter
        static assert(c.sizeof == 4); // Passes

    foreach(c; "hello")
        static assert(c.sizeof == 4); // Fails
}


WAT.
Aug 18 2013
prev sibling parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
W dniu 17.08.2013 16:42, Gambler pisze:

 (For example, your gist doesn't
 work in IE. Not that I use IE normally, but you get my point.)


This is because the code was compiled with typed arrays support. It's 
possible to compile without TA support and then it will work in IE.
Aug 17 2013
prev sibling parent reply "nazriel" <spam dzfl.pl> writes:
On Thursday, 15 August 2013 at 20:21:46 UTC, Piotr Szturmaj wrote:

 This is SDL and std.algorithm code translated to JavaScript 
 with emscripten. I've used the latest git versions of LDC and 
 emscripten (the latter needed some modifications).

 https://gist.github.com/pszturmaj/6244260
 https://gist.github.com/pszturmaj/6244266

 I couldn't manage to post it as single gist, and it seems 
 there's a bug in the sdl.html gist (it looks empty). Just click 
 Download Gist or '< >' icon (view raw) and save it as sdl.html.

 Then open sdl.html in the web browser. It should print sorted 
 and mapped array contents and run simple graphics demo.

 I'm starting to work on this to fix the rest of the druntime so 
 it can work under JS VM. Any help with this will be appreciated 
 :-)


This is very interesting subject.

I bet lots of people will want to help.
Give a shout when you setup repository etc ;)
Aug 20 2013
parent reply "Ramon" <spam thanks.no> writes:
I agree with those who are against it.

For a variety of reasons, one of them being that, yes, anything 
that produces javasc*t does a) recognize js and b) embold and 
support it.

Web pages are/should be about *content* not about eye candy and 
gadgets. Furthermore, increasingly many (like myself) have js 
filters, often in "brutal" mode (cutting out *all* js and 
enabling it expressly if needed/wished).

The real solution isn't to add one more way to the existing 3 
gazillion ways for js but to create a real alternative.
Seen from D's perspective a D interpreter would be a start. 
Although, frankly, most web hackers won't like it; it's too 
unfriendly and hard, they want some kind of web basic (which js 
happens to be).

And why and what for? HTML5 is rich enough. If I want to put 
serious computing work on the client I'd rather put it in a web 
server (written in D). And if I just want to put fancy blabla 
into a browser I can chose from 2,5 gazillion toys.
Aug 20 2013
next sibling parent reply "Ramon" <spam thanks.no> writes:
Ha! Expanding on myself:

Have simple web server written in D on the client and then a 
"D-script" interpreter in that server. Possibly some minimalist 
"friendly" interpreter thingy like Lua too (or optionally).

Only problem I see: Does D compile to/for Arm w/ Android and 
iphone "OS"?

Might be important as increasingly many users browse from their 
gadgets (rather than from their PCs)
Aug 20 2013
parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
W dniu 21.08.2013 01:49, Ramon pisze:

 Ha! Expanding on myself:

 Have simple web server written in D on the client and then a "D-script"
 interpreter in that server. Possibly some minimalist "friendly"
 interpreter thingy like Lua too (or optionally).

 Only problem I see: Does D compile to/for Arm w/ Android and iphone "OS"?


Don't worry. My solution just needs HTML + JS so it will work _everywhere_.


 Might be important as increasingly many users browse from their gadgets
 (rather than from their PCs)
Aug 20 2013
parent "Ramon" <spam thanks.no> writes:
On Wednesday, 21 August 2013 at 00:41:58 UTC, Piotr Szturmaj 
wrote:

 W dniu 21.08.2013 01:49, Ramon pisze:

 Ha! Expanding on myself:

 Have simple web server written in D on the client and then a 
 "D-script"
 interpreter in that server. Possibly some minimalist "friendly"
 interpreter thingy like Lua too (or optionally).

 Only problem I see: Does D compile to/for Arm w/ Android and 
 iphone "OS"?


 Don't worry. My solution just needs HTML + JS so it will work 
 _everywhere_.


 Might be important as increasingly many users browse from 
 their gadgets
 (rather than from their PCs)




I still disagree. But I understand your point of view and wish 
you the best of luck. May the keyboard be with you ;)
Aug 20 2013
prev sibling parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
W dniu 21.08.2013 01:43, Ramon pisze:

 I agree with those who are against it.

 For a variety of reasons, one of them being that, yes, anything that
 produces javasc*t does a) recognize js and b) embold and support it.

 Web pages are/should be about *content* not about eye candy and gadgets.
 Furthermore, increasingly many (like myself) have js filters, often in
 "brutal" mode (cutting out *all* js and enabling it expressly if
 needed/wished).


It's not about simple web pages with fancy gadgets. It's about RIAs.


 The real solution isn't to add one more way to the existing 3 gazillion
 ways for js but to create a real alternative.


This is unreal. Consider a business case: your employer wants some 
dynamic behavior on a web page (and it must work on IE6).


 Seen from D's perspective a D interpreter would be a start. Although,
 frankly, most web hackers won't like it; it's too unfriendly and hard,
 they want some kind of web basic (which js happens to be).


They will still use JS. I don't want to replace JS, because I want to 
support existing browsers.


 And why and what for? HTML5 is rich enough. If I want to put serious
 computing work on the client I'd rather put it in a web server (written
 in D). And if I just want to put fancy blabla into a browser I can chose
 from 2,5 gazillion toys.


What about Facebook?

But I rather have RIAs in mind. For example: 
http://www.smartclient.com/#showcaseApp . Among the others are ExtJS, 
GWT, qooxdoo, etc.

In this case code doesn't need to be very fast. It just need to be 
reliable and _maintainable_. All I currently want is using those RIA 
libraries from D code. This should give me huge productivity boost when 
writing _complex_ web applications.

Another case is WebGL and online games. I'd rather go to hell than write 
and maintain 100k lines of code in JS.

Even if you do not see a reason for it, there _is_ a demand for it. And 
money behind it.
Aug 20 2013