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.

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

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.

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

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

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

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.

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.

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.

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.