On Wednesday, 30 April 2014 at 12:56:03 UTC, Nick Sabalausky wrote:
> FWIW, IMO the big selling point of D is it's fairly unique knack for letting you eat your cake and still have it. I rather like to think we can manage merging the "full stacks" with the "lightweights".

Ugh, avoid the full stacks like the plague. They tend to be lockin solutions. Reminds me of Tango in D1 where you risked pulling in all kinds of dependencies.

You might dislike this, but I think nimble servers and clean separation with javascript heavy clients are the future.

What I don't want:

- I have started to avoid server processing of forms, javascript/ajax gives better user experience.

- I avoid advanced routing, it adds little and leads to harder to maintain code, give me a regexp based routing table in one location binding request-handlers.

- Server side generation should be kept minimal, prevents caching.

- Would never consider using serverside javascript generation.

What I do want:

- Transparent fast distributed in-memory database with logging to a exchangable backing store and with consistency guarantees.

- No filesystem dependencies.

On Wednesday, 30 April 2014 at 04:32:33 UTC, Rikki Cattermole wrote:
> Although I definitely would like to hear more about asynchronous javascript instead of my synchronous based code and how I can combine it at some point.

The way it works in mine is the proxy object sets a kinda magical helper value in the URL params, telling it to evaluate the named function instead of just trying to convert the data to the right time.

So for that one, the regular might be /add?a=1&b=2. With the nested call, we want a={the result of /add?a=1&b=2)&b=3.

So it passes it as something like this: "/add?" + urlencode("a=/add?a=1&a=2") + "&b=2&a-type=ServerResult";

So the special "a-type=" tells it that a should not be converted to an integer, but instead parsed and called.

The same url parser deconstructs it into a function call and gets the data out (currently, the implementation does it through string intermediaries for ease; it almost literally replaces that with the result in the URL, then re-parses it).

This avoids extra calls to the server since it is all done in one set. There's also ways to filter the results that way, for example running a querySelector() call on the server to filter a HTML result for JS.



Then, the JS call itself is either synchronous or asynchronous. The sync calls are done with the .getSync method. This generally sucks so I rarely use it, but one cool thing about it is exceptions from the D side are propagated to the Javascript side, making error handling natural. (This is also the way my web.d.php works - it uses PHP's version of opDispatch to make a little class that translate's PHP function calls to http requests for talking to the server. It always uses synchronous calls.... which sucks btw, but it is awfully easy to use: $a = $Foo->add(1, 2).getSync();)

The asynch ones just do pretty regular AJAX requests with a callback. The only thing that's interesting is I used the apply function in JS to make it kinda nice:

   return callback.apply(callbackThis, ourArguments);

So things like this kinda works sanely, arguments you pass are forwarded, etc.


function someFunction(something, another, result) {}

Foo.add(1,2).get(someFunction, "hey", this); // will call someFunction("hey", this, 3);


Naturally, there's on error callbacks too that can work the same way. D exceptions are passed as JS objects. (Indeed, in general, all the results from D are passed as objects, it does some JSON.parse action on the JS side and automatic serialization on the D side so many things just work.)

On Wednesday, 30 April 2014 at 13:37:33 UTC, Rikki Cattermole wrote:
> On Wednesday, 30 April 2014 at 13:28:28 UTC, John Colvin wrote:
>> On Wednesday, 30 April 2014 at 13:03:43 UTC, Rikki Cattermole wrote:
>>> On Wednesday, 30 April 2014 at 12:55:36 UTC, Dicebot wrote:
>>>> On Wednesday, 30 April 2014 at 12:52:36 UTC, Rikki Cattermole wrote:
>>>>> On Wednesday, 30 April 2014 at 12:38:32 UTC, Dicebot wrote:
>>>>>> There are definitely several benefits of having aggregated compile-time known list of routes. Actually I have added it as one of examples for my DConf talk just yesterday :) This list, however, can possibly be built automatically via reflection provided single root entry point.
>>>>>>
>>>>>> I think good flexible framework should provide user both options and infer as much as possible by convention.
>>>>>
>>>>> Hmm interesting idea, although I'd feel a lot happier about it if the compiler was able to (with a switch most likely) infer/create automatically package.d files with auto import of all sub modules if it doesn't exist.
>>>>
>>>> Sounds like typical use case for imaginary dub plugin system.
>>>
>>> Perhaps but in the compiler, the file system wouldn't actually be changed. And the explicit package.d files would merely be overrides.
>>
>> There's nothing stopping you from automatically making a temporary directory structure for building. No need to alter it in-place.
>
> The way this discussion is going I'll have a new build manager built specifically for web development. This is where I'm gonna say 'no'.
>
> Hmm now if only I understand assembly better. And was able to write a JIT then maybe. Maybe then I could implement my evil ideas.

A JIT for D? That would be many, many man-years of work.

On Wednesday, 30 April 2014 at 13:38:28 UTC, Adam D. Ruppe wrote:
> On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via Digitalmars-d wrote:
>> This is the stuff marketing campaigns are made from.
>
> Eh, like Jacob said later, I don't think this is a totally fair comparison cuz I'm a world class D expert but a RoR n00b, so there's naturally some difference in speed there.
>
> Of course, I doubt the gap will ever be closed, since Ruby's awfulness isn't dependent on my experience level. It's not like it will ever get static typing even if I used it all the time. It won't get faster. ActiveRecord won't get sane.
>
> But still, one person's productivity is too subjective to focus a lot on IMO.

Calculated dishonesty is healthy in a marketing campaign :p

On Wednesday, 30 April 2014 at 04:32:37 UTC, Russel Winder via Digitalmars-d wrote:
> The lesson from the Bottle/Flask/Tornado experience over the last few years is that it is always better
> to be working on the next version rather than just
> stick to maintaining the current version.

Maybe, but in general, I write what I use, and right now I don't have any significant new D web projects in the pipeline. I still have a couple old ones going, but the new boss said no in switching to D from Ruby (the rest of the team doesn't know it), so the question now is: do I want to spend my nights writing something I won't be using right now or doing something else?

for now, the answer is doing something else. That might change eventually tho.

> in the arena that Twisted used to be king; more vibe.d than web.d.

I think the vibe.d folks are doing pretty cool work too. Actually, my web.d could arguably be used with vibe.d; a vibe backend for my cgi.d is a realistic possibility, and then web.d is a pretty straight-forward add-on on top of that.  In fact, it might not even be very hard, I just haven't tried yet.

(And the other libs are already independent, I think Nick uses my dom.d with vibe already.)

Though, my little httpd isn't awful so again, "works for me" is a lot of inertia to overcome.

On Wednesday, 30 April 2014 at 13:48:07 UTC, Adam D. Ruppe wrote:
> On Wednesday, 30 April 2014 at 04:32:33 UTC, Rikki Cattermole wrote:
>> Although I definitely would like to hear more about asynchronous javascript instead of my synchronous based code and how I can combine it at some point.
>
> The way it works in mine is the proxy object sets a kinda magical helper value in the URL params, telling it to evaluate the named function instead of just trying to convert the data to the right time.
>
> So for that one, the regular might be /add?a=1&b=2. With the nested call, we want a={the result of /add?a=1&b=2)&b=3.
>
> So it passes it as something like this: "/add?" + urlencode("a=/add?a=1&a=2") + "&b=2&a-type=ServerResult";
>
> So the special "a-type=" tells it that a should not be converted to an integer, but instead parsed and called.
>
> The same url parser deconstructs it into a function call and gets the data out (currently, the implementation does it through string intermediaries for ease; it almost literally replaces that with the result in the URL, then re-parses it).
>
> This avoids extra calls to the server since it is all done in one set. There's also ways to filter the results that way, for example running a querySelector() call on the server to filter a HTML result for JS.
>
>
>
> Then, the JS call itself is either synchronous or asynchronous. The sync calls are done with the .getSync method. This generally sucks so I rarely use it, but one cool thing about it is exceptions from the D side are propagated to the Javascript side, making error handling natural. (This is also the way my web.d.php works - it uses PHP's version of opDispatch to make a little class that translate's PHP function calls to http requests for talking to the server. It always uses synchronous calls.... which sucks btw, but it is awfully easy to use: $a = $Foo->add(1, 2).getSync();)
>
> The asynch ones just do pretty regular AJAX requests with a callback. The only thing that's interesting is I used the apply function in JS to make it kinda nice:
>
>    return callback.apply(callbackThis, ourArguments);
>
> So things like this kinda works sanely, arguments you pass are forwarded, etc.
>
>
> function someFunction(something, another, result) {}
>
> Foo.add(1,2).get(someFunction, "hey", this); // will call someFunction("hey", this, 3);
>
>
> Naturally, there's on error callbacks too that can work the same way. D exceptions are passed as JS objects. (Indeed, in general, all the results from D are passed as objects, it does some JSON.parse action on the JS side and automatic serialization on the D side so many things just work.)

I see I see. I was assuming there wasn't too much changed on the server side. And mostly in javascript. Netherless quite interesting and advanced usage.
Perhaps it could spawn some changes to the router. And hence the ajax route generation.

On Wednesday, 30 April 2014 at 13:50:18 UTC, John Colvin wrote:
> On Wednesday, 30 April 2014 at 13:37:33 UTC, Rikki Cattermole wrote:
>> On Wednesday, 30 April 2014 at 13:28:28 UTC, John Colvin wrote:
>>> On Wednesday, 30 April 2014 at 13:03:43 UTC, Rikki Cattermole wrote:
>>>> On Wednesday, 30 April 2014 at 12:55:36 UTC, Dicebot wrote:
>>>>> On Wednesday, 30 April 2014 at 12:52:36 UTC, Rikki Cattermole wrote:
>>>>>> On Wednesday, 30 April 2014 at 12:38:32 UTC, Dicebot wrote:
>>>>>>> There are definitely several benefits of having aggregated compile-time known list of routes. Actually I have added it as one of examples for my DConf talk just yesterday :) This list, however, can possibly be built automatically via reflection provided single root entry point.
>>>>>>>
>>>>>>> I think good flexible framework should provide user both options and infer as much as possible by convention.
>>>>>>
>>>>>> Hmm interesting idea, although I'd feel a lot happier about it if the compiler was able to (with a switch most likely) infer/create automatically package.d files with auto import of all sub modules if it doesn't exist.
>>>>>
>>>>> Sounds like typical use case for imaginary dub plugin system.
>>>>
>>>> Perhaps but in the compiler, the file system wouldn't actually be changed. And the explicit package.d files would merely be overrides.
>>>
>>> There's nothing stopping you from automatically making a temporary directory structure for building. No need to alter it in-place.
>>
>> The way this discussion is going I'll have a new build manager built specifically for web development. This is where I'm gonna say 'no'.
>>
>> Hmm now if only I understand assembly better. And was able to write a JIT then maybe. Maybe then I could implement my evil ideas.
>
> A JIT for D? That would be many, many man-years of work.
Nah written in D. But in saying that, it would probably be one of the first languages I'd have a go at.

On Wednesday, 30 April 2014 at 13:37:33 UTC, Rikki Cattermole wrote:
> Hmm now if only I understand assembly better. And was able to write a JIT then maybe. Maybe then I could implement my evil ideas.

You don't necessarily need to understand assembly to write a JIT. You could instead have your bytecode take the form of D functions (such as int16 addI16(int16 a, int16 b), for instance) so you're essentially generating an array of D functions then iterating over them evaluating them. This would obviously be slower than generating assembly directly, but would still be faster than an interpreter, and you could still do some optimisation on it.

On Wednesday, 30 April 2014 at 14:11:20 UTC, logicchains wrote:
> On Wednesday, 30 April 2014 at 13:37:33 UTC, Rikki Cattermole wrote:
>> Hmm now if only I understand assembly better. And was able to write a JIT then maybe. Maybe then I could implement my evil ideas.
>
> You don't necessarily need to understand assembly to write a JIT. You could instead have your bytecode take the form of D functions (such as int16 addI16(int16 a, int16 b), for instance) so you're essentially generating an array of D functions then iterating over them evaluating them. This would obviously be slower than generating assembly directly, but would still be faster than an interpreter, and you could still do some optimisation on it.

Been there. Drunmeta [0]. Theres a reason why I'm not going down that road anymore ;)

[0] https://github.com/rikkimax/drunmeta

On 4/30/14, 6:43 AM, Dicebot wrote:
> On Wednesday, 30 April 2014 at 07:14:34 UTC, Jacob Carlborg wrote:
>> But unit tests in D suck as well. I mean, how do I run a single unit
>> test in D?
>
> This is common complaint I still fail to understand. I have never ever
> wanted to run a single unit test, why would one need it? If running all
> module tests at once creates problems than either module is too big or
> unit tests are not really unit tests.

When I have a bug in my code I usually add a test for it so it never happens again.

Because it's a bug, I might need to debug it. So I add a couple of "writefln" instead of using a debugger (it's faster and I get formatted results easier).

Now, if I run all tests I will get output from all the tests, not the one I'm trying to debug. That's really annoying.