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.

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!

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

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.

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.

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.

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

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

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

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