www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D For A Web Developer

reply "James" <jamesmp98 gmail.com> writes:
I have a friend that is a web developer. I, however want to 
collaborate with him, so I am trying to get him to learn D. I  
don't know how to persuade him! How can D be used to greatly 
assist an HTML5/JavaScript web developer? I decided to go here to 
get some good answers. How can D be used to interopt with modern 
web development?
Apr 29 2014
next sibling parent Etienne <etcimon gmail.com> writes:
On 2014-04-29 10:41 AM, James wrote:
 I have a friend that is a web developer. I, however want to collaborate
 with him, so I am trying to get him to learn D. I don't know how to
 persuade him! How can D be used to greatly assist an HTML5/JavaScript
 web developer? I decided to go here to get some good answers. How can D
 be used to interopt with modern web development?

You should ask this in http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/ But while we're here, maybe you could send him a link to http://vibed.org/ along with a link to http://dlang.org/phobos/std_algorithm.html that he could read when he has 10 minutes I don't know how else you could convince him. Possibly benchmarks? http://atilanevesoncode.wordpress.com/2013/12/05/go-vs-d-vs-erlang-vs-c-in-real-life-mqtt-broker-implementation-shootout/ Or an example of a dynamic web project backend? https://github.com/rejectedsoftware/vibe.d/tree/master/examples/web He might not be so familiar with type safety though, so then your arguments will have to be more technical - type safety is the only way you can ever scale a project because most bugs are caught by the compiler. He can keep using his front-end libraries too. Browsers don't run D code, they simply request bytes from it. Good luck!
Apr 29 2014
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
I recently started a Ruby on Rails job and using it makes me 
really, really miss the high productivity and ease of use D 
offers. (And, of course, a dynamic site in D runs about 3x faster 
out of the box than hello world served by Rails, zero effort in 
optimization. And "rake test", just shoot me, I'd rather rebuild 
a C++ project from scratch, at least that'll finish before the 
heat death of the universe.)
Apr 29 2014
next sibling parent reply Etienne <etcimon gmail.com> writes:
On 2014-04-29 11:27 AM, Adam D. Ruppe wrote:
 I recently started a Ruby on Rails job and using it makes me really,
 really miss the high productivity and ease of use D offers. (And, of
 course, a dynamic site in D runs about 3x faster out of the box than
 hello world served by Rails, zero effort in optimization. And "rake
 test", just shoot me, I'd rather rebuild a C++ project from scratch, at
 least that'll finish before the heat death of the universe.)

That's funny b/c most people say RoR made them love web development. If the D community could organize itself the same way RoR is around web dev, I doubt any other web scripting language could pursue existence.
Apr 29 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/29/2014 11:55 AM, Etienne wrote:
 On 2014-04-29 11:27 AM, Adam D. Ruppe wrote:
 I recently started a Ruby on Rails job and using it makes me really,
 really miss the high productivity and ease of use D offers. (And, of
 course, a dynamic site in D runs about 3x faster out of the box than
 hello world served by Rails, zero effort in optimization. And "rake
 test", just shoot me, I'd rather rebuild a C++ project from scratch, at
 least that'll finish before the heat death of the universe.)

That's funny b/c most people say RoR made them love web development. If the D community could organize itself the same way RoR is around web dev, I doubt any other web scripting language could pursue existence.

Ruby on Rails popularized MVC web frameworks, and that was a significant step forward from the stuff that came before, like PHP, ASP or even arguably ASP.NET (or *shudder* ColdFusion). I think that's always been RoR's main benefit and appeal. But since then, every other language under the sun (or rather, under florescent lights?) has grown its own MVC web framework, so Rails's biggest distinguishing characteristic now is just that it's in Ruby. And Ruby is kinda famous for having little significance outside of Rails itself. (Although, I did find Rake quite beneficial in an older project with a rather complex build. Course, these days D/Phobos has gotten good enough I'd just do a build script in D.) At least that's my impression of Ruby and Rails.
Apr 29 2014
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 29.04.2014 19:45, schrieb Nick Sabalausky:
 On 4/29/2014 11:55 AM, Etienne wrote:
 On 2014-04-29 11:27 AM, Adam D. Ruppe wrote:
 I recently started a Ruby on Rails job and using it makes me really,
 really miss the high productivity and ease of use D offers. (And, of
 course, a dynamic site in D runs about 3x faster out of the box than
 hello world served by Rails, zero effort in optimization. And "rake
 test", just shoot me, I'd rather rebuild a C++ project from scratch, at
 least that'll finish before the heat death of the universe.)

That's funny b/c most people say RoR made them love web development. If the D community could organize itself the same way RoR is around web dev, I doubt any other web scripting language could pursue existence.

Ruby on Rails popularized MVC web frameworks, and that was a significant step forward from the stuff that came before, like PHP, ASP or even arguably ASP.NET (or *shudder* ColdFusion). I think that's always been RoR's main benefit and appeal. But since then, every other language under the sun (or rather, under florescent lights?) has grown its own MVC web framework, so Rails's biggest distinguishing characteristic now is just that it's in Ruby. And Ruby is kinda famous for having little significance outside of Rails itself. (Although, I did find Rake quite beneficial in an older project with a rather complex build. Course, these days D/Phobos has gotten good enough I'd just do a build script in D.) At least that's my impression of Ruby and Rails.

I was already doing RoR back in 1999, but it was with our own in-house TCL Apache/IIS module in a Portuguese startup, far far away from Silicon Valley and loosely based in AOL Server concepts. We eventually moved into .NET, at the time only known to Microsoft partners like our mother company, before it was announced to the world. It was a very good learning experience, building a whole stack from the ground up, back in the early web days. We already had Active Record and MVC with security layers and scaffolding, just in TCL and unknown to the world. -- Paulo
Apr 29 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-04-29 17:27, Adam D. Ruppe wrote:
 I recently started a Ruby on Rails job and using it makes me really,
 really miss the high productivity and ease of use D offers.

I'm curious to why you think D is more productive and easier to use. -- /Jacob Carlborg
Apr 29 2014
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 30/04/14 00:09, Adam D. Ruppe wrote:

 A lot of things, mostly focusing around having the compiler to help
 refactor with confidence (the importance of this really can't be
 understated) and having libraries that fit better.

I think one of the great things about Rails and Ruby is all the libraries and plugins that are available. If I want to do something, in RoR there's a big chance there's already a library for that. In D, there's a big chance I need to implement it myself.
 The speed is a nice
 bonus too, having to spend half a minute just waiting for the tests to
 run really grates me.

Yeah, it's sucks that Rails is so slow to boot. But unit tests in D suck as well. I mean, how do I run a single unit test in D? Also, my text editor (TextMate) already has support for the unit tests frameworks used in Ruby.
 But wrt libraries, ActiveRecord is unbelievably awful, for example. It
 is a bad idea from the ground up: why, oh why are we reinventing the
 database?

How do you mean? It just adds an object oriented layer on top of it. BTW, what should I use in D. I need a library that is database independent and I don't want to write SQL for the common use cases?
 erb templates are painful to use too

I prefer HAML (similar to Jade in vibe.d) but I don't think it's that bad. What do you use?
 , and so is the routing. I
 don't understand why routing isn't done automatically for the common case.

I don't know how you do you're routing but the first thing I do when generating a new Rails application is to remove the default routing. The default routing opens every public method in a controller to be a routing end point. It's a complete mess.
 The scaffolding is a pain too. Contrast to what web.d does: given a
 function signature, it automatically generates a form for it (using type
 information to select correct widgets) and can format the response in
 several forms automatically including plain text, html list, html table,
 json, xml, csv, and a custom template.

There's a plugin [1] for Rails for generating a form based on a type. I don't understand how anyone can manage without that. It can automatically respond in a couple of formats as well. By default JSON, XML and Erb template. The most basic example will look something like this: class FoosController < ApplicationController respond_to :json, :xml def index respond_with Foo.all end end
 Maybe Rails can do this stuff and I'm too much of a n00b, but the other
 experienced team members say the way we're doing it is pretty standard
 and I'm just not impressed.

Sure, it depends on what's "standard". Only using what's installed by default. Then yes, perhaps that's standard. But it's not always the best idea. At my previous work I did quite a lot different compared to the "experienced" team members.
 I can just get stuff done in D in a fraction of a time it takes to do
 even less in RoR.

You don't think that's because you're used D for quite a while and developed your own web framework. Compared to Rails where you're completely new. The biggest problem I have with D is have to do everything myself. I'm getting a bit tired of that. [1] https://github.com/plataformatec/simple_form -- /Jacob Carlborg
Apr 30 2014
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/30/2014 3:14 AM, Jacob Carlborg wrote:
 There's a plugin [1] for Rails for generating a form based on a type. I
 don't understand how anyone can manage without that. It can
 automatically respond in a couple of formats as well. By default JSON,
 XML and Erb template. The most basic example will look something like this:

Automatic forms generated from a type are nice for quick-n-dirty stuff, but I find they tend to work against (or at least be much less useful for) the tweaking and customization usually needed in public-facing production sites. So I started doing it in reverse: Instead of defining the form in the server-side code and then awkwardly trying to make it generate the HTML I want, I just define the form in HTML. (Or rather, in an HTML template that's still more-or-less valid HTML, with a few additional non-standard tags to help with metadata like "how to validate this field"). Then I use Adam's dom.d (in non-strict mode) to read the HTML form template (preserving the templating stuff), and automatically infer everything I need to automate the form's behavior (and to strip out the non-standard metadata I added). I've been pretty happy with that so far. It combines the DRY simplicity of "define a form in ONE place and it 'just works'" with the full power and control of hand-written HTML. What I really need to do is fully de-entange that stuff from my cluttered mess of a homemade web framework <https://github.com/Abscissa/SemiTwistWeb> and release as a separate cleaned-up lib.
Apr 30 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/30/2014 10:53 AM, Adam D. Ruppe wrote:
 On Wednesday, 30 April 2014 at 12:26:06 UTC, Nick Sabalausky wrote:

 Then I use Adam's dom.d (in non-strict mode) to read the HTML form
 template (preserving the templating stuff)

I use strict mode for that stuff, keep in mind strict mode is about well-formedness, not validation. So it accepts custom tags and attributes easily enough.

Well, I've been using mustache-d as my main templating engine, which is just a general text preprocessor (Although I'm kinda eyeing that other text preprocessor that uses actual D code). IIRC, I think there were some cases where the my templates involved some non-well-formedness that the DOM's non-strict mode was perfectly happy with. Whatever it was, I'm sure there was *something* I was doing that strict mode was tripping up on. May have been an old version of the DOM, too. Granted there are still things I have to refrain from doing in my HTML form templates because it would violate well-formedness *too much* even for an ultra-relaxed HTML DOM. But those cases always have other (arguably more sanitary) ways to accomplish the same thing.
Apr 30 2014
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
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.
Apr 30 2014
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 4/30/14, 11:25 AM, Dicebot wrote:
 On Wednesday, 30 April 2014 at 14:18:37 UTC, Ary Borenszweig wrote:
 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.

Output from the failing test will always be the last one in console. Pipe to tail -> profit. This sounds as pure aesthetics issue.

That's good. What if you have tests against a database that where each take some time? I don't want to wait for the whole tests to run...
Apr 30 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/30/2014 10:58 AM, Ary Borenszweig wrote:
 What if you have tests against a database that where each take some
 time? I don't want to wait for the whole tests to run...

Collapse block, [Home], [Shift]-[Down] (select), [Ctrl]-/ (comment) ;) Just FWIW, though. I'm not arguing for or against an ability to run specific unittests.
Apr 30 2014
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/30/14, 7:18 AM, Ary Borenszweig wrote:
 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.

Yah, naming unittests is key here. With names one can specify which to run/not run, regex patterns (i.e. "run only quick*") etc. -- Andrei
Apr 30 2014
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/30/2014 11:04 AM, Adam D. Ruppe wrote:
 A big difference though is the compiler helps you a lot in D. In Ruby,
 for example, the main reason we use the unit tests (so far) is to help
 ensure consistency after refactoring something. It catchings things like
 a renaming we missed, or a removed method still in use.

This has a lot to do with why I don't buy the common argument that dynamic languages are all about "just getting shit done". Anytime I use them, they just create more work for me. Writing more sanity checks. More hours debugging. More work to optimize hotspots. More time figuring out Tracebacks I'm getting from code I didn't even write or from tools I'm simply trying to install. Etc.
 In D, you just recompile and those things are found almost instantly
 without needing to actually run any code.

Gotta love it :)
Apr 30 2014
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-04-30 11:43, Dicebot wrote:

 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.

Why would I run more tests than I have to? BTW, I would probably use the "unittest" keyword for other kinds of tests than unit tests as well. -- /Jacob Carlborg
Apr 30 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/30/14, 12:25 PM, Dicebot wrote:
 On Wednesday, 30 April 2014 at 19:08:15 UTC, Jacob Carlborg wrote:
 On 2014-04-30 11:43, Dicebot wrote:

 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.

Why would I run more tests than I have to?

Because you hardly notice difference between 0.1 and 0.5 seconds

*cough* std.datetime *cough* :o) One good example is networking tests - if I worked on an airplane I'd love to not test tests that need connectivity with a simple regex. Andrei
Apr 30 2014
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/30/2014 4:36 PM, Andrei Alexandrescu wrote:
 One good example is networking tests - if I worked on an airplane I'd
 love to not test tests that need connectivity with a simple regex.

The biggest thing for me has been unittests in third party libraries (hence the idiom of -version=unittest_myProjectName, but sometimes libs don't do that). Although I seem to remember being told there's a way around that, some hook into the unittest system or something.
Apr 30 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/30/2014 1:36 PM, Andrei Alexandrescu wrote:
 One good example is networking tests - if I worked on an airplane I'd love to
 not test tests that need connectivity with a simple regex.

I am suspicious that testing networks with a unit test is an inappropriate use of unit tests. Unit tests should be testing individual functions. The "network" for those tests should be a mockup, not the actual network. A mock network: 1. can model extreme, unusual, perverse, and corner cases of networks, whereas real networks try to avoid that 2. will generate reproducible results Testing networks should be more of a system test, not a unit test.
May 03 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 5/3/2014 3:32 PM, Walter Bright wrote:
 On 4/30/2014 1:36 PM, Andrei Alexandrescu wrote:
 One good example is networking tests - if I worked on an airplane I'd
 love to
 not test tests that need connectivity with a simple regex.

I am suspicious that testing networks with a unit test is an inappropriate use of unit tests. Unit tests should be testing individual functions. The "network" for those tests should be a mockup, not the actual network. A mock network: 1. can model extreme, unusual, perverse, and corner cases of networks, whereas real networks try to avoid that 2. will generate reproducible results Testing networks should be more of a system test, not a unit test.

I'm not sure mock networks can really be used for testing a client-only lib of some specific protocol. There may also be other examples. There's also the question of whether or not D's "unittest {...}" should *expect* to be limited to tests that are *technically* "unit tests". Currently, "unittest {...}" is useful for more forms of testing than just "unit" tests. I think it's debatable whether we want kill off those uses without offering a comparable alternative with reasonable migration.
May 03 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/3/2014 6:57 PM, Nick Sabalausky wrote:
 I'm not sure mock networks can really be used for testing a client-only lib of
 some specific protocol. There may also be other examples.

 There's also the question of whether or not D's "unittest {...}" should
*expect*
 to be limited to tests that are *technically* "unit tests". Currently,
"unittest
 {...}" is useful for more forms of testing than just "unit" tests. I think it's
 debatable whether we want kill off those uses without offering a comparable
 alternative with reasonable migration.

I'm not suggesting killing off anything. I'm suggesting it may not be good practice to use unit tests for testing actual networks.
May 03 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 5/4/2014 12:34 AM, Jonathan M Davis via Digitalmars-d wrote:
 Regardless, unittest blocks don't really put any restrictions on what kind of
 code can go in them, and I'd prefer that that stay the case. The discussion
 on parallelizing unit tests threatens that on some level, but as long as we
 have the means to mark unittest blocks in some manner that tells the test
 runner not to run them in parallel with any other unittest blocks, then I
 think that we should be fine on that front.

Yes, this.
May 04 2014
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-04-30 22:11, Russel Winder via Digitalmars-d wrote:

 This cannot be a good idea. If the block says unittest then it contains
 unit tests, not integration tests or system tests, just unit tests.

Then we need to come up with a separate framework for doing all other kinds of tests. -- /Jacob Carlborg
May 01 2014
next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
On 5/1/14, 6:58 AM, Jacob Carlborg wrote:
 On 2014-04-30 22:11, Russel Winder via Digitalmars-d wrote:

 This cannot be a good idea. If the block says unittest then it contains
 unit tests, not integration tests or system tests, just unit tests.

Then we need to come up with a separate framework for doing all other kinds of tests.

Yes. And then you need two different commands to check if the system works. And if you want, for example, coverage analysis I wonder how you'd do that... That can't be good.
May 01 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-05-03 21:51, Atila Neves wrote:

 This is why I started to learn Cucumber.

Cucumber is for acceptance tests. There are also functional and integration tests. -- /Jacob Carlborg
May 04 2014
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/1/14, 3:50 AM, John Colvin wrote:
 On Wednesday, 30 April 2014 at 19:25:40 UTC, Dicebot wrote:
 On Wednesday, 30 April 2014 at 19:08:15 UTC, Jacob Carlborg wrote:
 On 2014-04-30 11:43, Dicebot wrote:

 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.

Why would I run more tests than I have to?

Because you hardly notice difference between 0.1 and 0.5 seconds

The compilation time is often more of a problem than the runtime.

That's the case for phobos. -- Andrei
May 01 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-05-03 21:52, Atila Neves wrote:

 For me it's the output. I don't want to see the output of other
 tests when I'm debugging a failure.

That's a good point. -- /Jacob Carlborg
May 04 2014
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-04-30 17:04, Adam D. Ruppe wrote:

 I like implementing things myself :P

 That's the question I dread most at meetings now: "is there a gem for
 this?" idk, in the time it takes to search for and evaluate third party
 code, I could have just written it myself. Especially since libraries
 almost always need some kind of customization for our specific case anyway!

I don't agree with this.
 A big difference though is the compiler helps you a lot in D. In Ruby,
 for example, the main reason we use the unit tests (so far) is to help
 ensure consistency after refactoring something. It catchings things like
 a renaming we missed, or a removed method still in use.

Then you're not using unit tests correctly ;)
 In D, you just recompile and those things are found almost instantly
 without needing to actually run any code.

Yeah, sometimes it would be nice with static typing.
 They deliberately avoid the most important parts of a relational database:

 http://guides.rubyonrails.org/migrations.html

 "The Active Record way claims that intelligence belongs in your models,
 not in the database. As such, features such as triggers or foreign key
 constraints, which push some of that intelligence back into the
 database, are not heavily used."

I don't really agree with that. Although I'm not a fan of store procedures/functions in the database. But I don't mind foreign key constraints. We used that at my previous work. Via a gem :)
 ORM is something I only like in very small quantities, but ActiveRecord
 uses it for *everything*, well, except for the things it doesn't even
 support.

 The problem here is one of encapsulation and of correctness. If
 something bypasses the model - which is required for tasks the library
 doesn't even support and also likely to happen if there's a second app
 using the data - all kinds of stuff can get in there that is bad.

 You also have problems like race conditions:

 account = BankAccount.find(1)
 account.balance -= 10
 account.save!

I think most Rails application are run single threaded. But with multiple processes instead.
 What if two of those run concurrently? I searched the web quickly for
 this and haven't found a good answer yet...

 Then, with referential integrity, the docs suggest DIY or getting some
 third party gem, because their godawful library doesn't really support
 it. The best it does is offer you a square wheel with the dependent
 thing. Stupid stupid stupid.

All libraries have positive and negative sides.
 idk, I use my database.d which has a little bit of overlap with what
 active record does, but since I generally see ORM as being a nasty
 anti-pattern and horribly leaky abstraction, I didn't go far with it.

Using a random D module for this doesn't feel very comfortable, no offense. No documentation, no way to find examples and so on.
 There's really nothing to fear with writing SQL, except the cases where
 the language sucks.

ActiveRecord will hide all the ugliness of SQL. Properly escape values, to type conversions, time zone conversions and so on. It's also database independent.
 (UPDATE and INSERT being so different, and the
 solutions being different for the various vendors, ugh. That's why I
 made my DataObject, it gathers the changes together then issues one of
 those commands. It can also be gotten from a query, making it a kind of
 simple active record:

 auto obj = mysql.queryDataObject("select * from foo limit 1").front;
 obj.whatever = "something";
 obj.commitChanges(); // calls UPDATE foo SET whatever='something' WHERE
 id = ?

 which also works on joined queries on MySQL btw and offers easy support
 for multiple primary keys or ones not named "id" (as an argument to
 commitChanges), something active record as far as i can tell doesn't
 even try to do, but it doesn't try to fetch child objects or anything
 like that.

 I have considered adding child object fetching, but I don't really see
 the need, it is easy to write a method that does that if you want to.)

 I prefer HAML (similar to Jade in vibe.d) but I don't think it's that
 bad. What do you use?

The ruby thing looks like this <span class="foo"><%= some_value %></span>. For my D stuff, I have two options: 1) create the HTML right in D using dom.d. I like to use this for objects that know how to format themselves and output strictly semantic XML/HTML. The visual styling is then done with CSS. This works better than you might expect!

Are you using some kind of proxy for this or are you pushing back the view layer to the model?
 2) web.d also has a fairly simple replacement system too:

 <span class="foo">{$some_value}</span>

 it also supports inserting partials

 <div html-from="{$dynamic_html}"></div> or <include partial="foo" />,
 though the include thing takes a wee bit of helper code from the app
 because it needs to find the html somewhere.

Well, that's the same as in Rails. The HAML version would be: <div html-from="#{ dynamic_html}"></div> or = render "foo". In Rails the partial is just a template prefixed with an underscore. It fill find it relative to the controller's view directory.
 And the variable replacement can be piped: {$some_count|plural user
 users} for example, which is kinda cool.

I'm not sure I understand this piping.
 It does NOT support intertwined code. Other things are done with
 attributes, such as class="if-logged-in" or <ul from="data_thing" />
 (infinitely extensible with the server-side DOM).

What do you mean with "intertwined code"?
 It looks like this

    root "home#index"

    get "/users/login", to: "users#login"

    namespace :admin do
      resources :users do
        resources :children
      end
    end


 and so on. It isn't awful (especially now that I get what they mean by
 "resources"), but my web.d rarely uses explicit routing at all, it
 figures it out automatically by the names, protection level, and types
 of child members.

In Rails that would be: match ":controller(/:action(/:id))" So "/foo/bar/1" would route to "bar" action in the FooController with "1" assigned as the "id" parameter in "params". Only works with public methods. I really hate this. It quickly becomes a big mess. You can also do a catch all route: match "*path" => "home#page_not_found"
 Responding with json, xml, and html Just Work with web.d, it figures it
 out from the static type of the function return value.

In my experience it's rarely so easy. Most of the time I need to do some customization of the format anyway so the built-in formatting isn't suitable.
 Yes, obviously that's some of it, but there's other things that I don't
 expect to change, especially things like runtime errors for what the D
 compiler would catch.

Yes, sure.
 i love that, different strokes i guess.

I don't mind it but sometimes I just want to get some work done. I mean, I've started out (or planed to) with some project in D but then I needed to create all the support libraries and tools so I've almost forgot what I was going to do in the first place. I want to use Sass, CoffeeScript and HAML. But I don't want to write three compilers just to do some web development. -- /Jacob Carlborg
Apr 30 2014
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/30/2014 3:53 PM, Jacob Carlborg wrote:
 On 2014-04-30 17:04, Adam D. Ruppe wrote:
 You also have problems like race conditions:

 account = BankAccount.find(1)
 account.balance -= 10
 account.save!

I think most Rails application are run single threaded. But with multiple processes instead.

Aren't you talking about databases? Single-threading won't save you from races there unless the DBMS itself is single-threaded (which would be a pretty undesirable DBMS). Or does the ORM above automatically lock the row/table behind-the-scenes?
Apr 30 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-04-30 22:36, Nick Sabalausky wrote:

 Aren't you talking about databases? Single-threading won't save you from
 races there unless the DBMS itself is single-threaded (which would be a
 pretty undesirable DBMS).

Are you referring to if one process executes line 1 while another executes line 2? I don't see how ActiveRecord make this any worse.
 Or does the ORM above automatically lock the row/table behind-the-scenes?

It does saves in transactions but I don't think it locks. -- /Jacob Carlborg
May 01 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-04-30 22:38, Adam D. Ruppe wrote:

 Yeah, foreign keys are really an absolute must. So are uniqueness
 constraints. Rails can kinda do these, but in its own reinvented ways
 that don't actually hit the DB (at least not without add on gems)

Rails unique constraints do hit the DB, but they can be painfully slow. It's usually faster to let the DB handle it and handle the exception in Ruby.
 I also find myself really missing outer joins and views.

For outer joins: 1. You can always use raw SQL, also in combination with ActiveRecord Post.joins(:comments).joins("outer join foos on foos.post_id = posts.id").where(title: "bar") 2. My preferred choice, using Squeel [1] (another gem). With Squeel the above would look like this: Post.joins(:comments).joins{ foos.outer }.where(title: "bar") It also supports queries like this: Post.where{ |q| q.id >= 3 } For views you can use raw SQL in the migration to create the view. Then it behaves just like a regular table. ActiveRecord won't know the difference. At my previous work we used the SchemaPlus [3] gem. It supports foreign keys, views and indexes.
 That doesn't change the race condition because the database is still
 shared across those processes. With a regular SQL query, the database
 guarantees consistent, atomic operations in the DB engine itself, but
 with active record pattern, you give that up... while still having the
 shared data.

I'm not sure I understand. ActiveRecord does regular SQL queries. The example you wrote: account = BankAccount.find(1) account.balance -= 10 account.save! Are you referring to if one process executes line 1 and another line 2?
 It also hides all the beauty of it :(

 Properly escape values

If you're escaping values, unless you're writing some low level database library, you're almost certainly doing it wrong.

I don't know how other libraries do it these days but last time I didn't use ActiveRecord it looked something like this: query("select * from foo where name = ?", "foobar"); BTW, this is still how you need to do it in ActiveRecord when needing something more than the equal operator. It was quite similar in Rails 2 as well. Rails 3 and later makes it a bit better. Very ugly. All values are far to the right and the query is to the left. It's get a quick overview of which values go where. Therefore I prefer Squeel as soon I need to do something more advanced than the equal operator: Foo.where{ |q| q.size >= 4 } You can also use SQL functions: Foo.where{ |q| q.created_at == q.getdate() }
 CSS is the view in that scenario. The HTML the object returns is just
 its fields wrapped up in tags and classes. Works really well, for my
 last big job, the designer worked almost exclusively in CSS and we got a
 lot of stuff done.

I never get that working. The HTML always need to change when the design changes.
 It calls functions on the variable. So like {$foo|capitalize} would be
 kinda like <%= capitalize(foo) %>. The plural example uses arguments to
 the function too so we can customize the words if it is plural or no.

Ah, I see.
 <html><% some ruby here %></html>

 I hate that stuff, especially when the view starts doing implicit
 database queries! Defeats the whole point of MVC separation if you ask me.

That's useful for looping and if-statements. I also sometimes but a variable there at the top. In Haml: - posts.each do |post| %h3= post.title .body= post.body - if current_url == post_url(post) = post.title - else = link_to post.title, post This would of course be better handled with a partial and a view helper. Yeah, I agree that it's ugly with database queries in the view. But it's very easy to end up with something like this, instead of the above: - Post.all.each do |post| Queries in the view can be good, it depends on how you look at it. If you write the query in the controller and then access the result in the view, the query will be executed in the view because since Rails 3 queries are lazy. The advantage of this is the you can stream out the response [2].
 meh, with my libs, they might not be accessible to others, being poorly
 documented and all, but I know them and have used them for almost
 everything that's come up over the years. So for me, getting work done
 means spending an hour using D instead of days searching the web for
 some gem that won't even work right anyway.

For me it's the same with Rails. I know Rails and know a lot of useful gems. [1] https://github.com/activerecord-hackery/squeel [2] http://asciicasts.com/episodes/266-http-streaming [3] https://github.com/lomba/schema_plus -- /Jacob Carlborg
May 01 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 2014-05-01 15:54, "Marc Schütz" <schuetzm gmx.net>" wrote:

 You can also use the built-in `includes()`, which does a LEFT OUTER JOIN:

      Post.includes(:comments).where(comments: {title: "bar"})

 (It also eager-loads the comments, but this is usually desired anyway,
 because an OUTER JOIN doesn't make sense if you're not going to use the
 joined records.)

The SQL code "includes" generates is unspecified. Sometimes it can do an extra "select" instead of a "join". -- /Jacob Carlborg
May 01 2014
parent Jacob Carlborg <doob me.com> writes:
On 01/05/14 21:55, "Marc Schütz" <schuetzm gmx.net>" wrote:

 You're probably right. I thought that changed in a recent release, but
 can't find it anymore.

I don't know. I wouldn't trust it. It's the behavior in Rails 3. I haven't used Rails 4 yet. -- /Jacob Carlborg
May 02 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-05-02 19:25, brad clawsie wrote:

 this has been the fundamental issue for me. its not just missing libs,
 its libs that are surfaced via a C-binding, which in my limited

I've had problems with ImageMagick, basically every time. But that's the only one I can think of, at least for now. -- /Jacob Carlborg
May 04 2014
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-04-30 15:38, Adam D. Ruppe wrote:

 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.

Ruby has gotten faster in each release. -- /Jacob Carlborg
Apr 30 2014
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 30.04.2014 22:12, schrieb Russel Winder via Digitalmars-d:
 On Wed, 2014-04-30 at 21:06 +0200, Jacob Carlborg via Digitalmars-d
 wrote:
 On 2014-04-30 15:38, Adam D. Ruppe wrote:

 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.

Ruby has gotten faster in each release.

Especially if you run JRuby on the JVM :-)

Or shell out money for an AOT compiler like RubyMotion.
Apr 30 2014
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 4/30/14, 10:38 AM, Adam D. Ruppe wrote:
 On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via
 Digitalmars-d wrote:

 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.

Nah, that will never happen. But you can get very close ( http://crystal-lang.org/ ), although you loose some dynamism at runtime...
Apr 30 2014
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 01.05.2014 01:05, schrieb Ary Borenszweig:
 On 4/30/14, 10:38 AM, Adam D. Ruppe wrote:
 On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via
 Digitalmars-d wrote:

 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.

Nah, that will never happen. But you can get very close ( http://crystal-lang.org/ ), although you loose some dynamism at runtime...

Nice to see Crystal still alive.
Apr 30 2014
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/30/2014 4:17 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 On Wednesday, 30 April 2014 at 20:00:59 UTC, Russel Winder via

 (*) Are we allowed to have gotos any more since Dijkstra's letter?

You better ask the dining philosophers.

Nah, they're too busy trying to figure out how to use their forks.
May 02 2014
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/29/2014 10:41 AM, James wrote:
 I have a friend that is a web developer. I, however want to collaborate
 with him, so I am trying to get him to learn D. I don't know how to
 persuade him! How can D be used to greatly assist an HTML5/JavaScript
 web developer? I decided to go here to get some good answers. How can D
 be used to interopt with modern web development?

Show him forum.dlang.org (written in D) and point out that modern HTML5/JS sites are freaking horrid. </admitted-curmudgeon>
Apr 29 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/29/2014 3:48 PM, JN wrote:
 On Tuesday, 29 April 2014 at 15:28:00 UTC, Nick Sabalausky wrote:
 Show him forum.dlang.org (written in D) and point out that modern
 HTML5/JS sites are freaking horrid. </admitted-curmudgeon>

forum.dlang.org is written in HTML/JS too.

Anything on the web involves HTML, the difference is whether the HTML is the platform (ie HTML5) or just the renderer. And forum.dlang.org uses very little JS (and only optionally). It's certainly not built out of JS.
Apr 29 2014
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Tuesday, 29 April 2014 at 15:17:10 UTC, Etienne wrote:
 On 2014-04-29 10:41 AM, James wrote:
 I have a friend that is a web developer. I, however want to 
 collaborate
 with him, so I am trying to get him to learn D. I don't know 
 how to
 persuade him! How can D be used to greatly assist an 
 HTML5/JavaScript
 web developer? I decided to go here to get some good answers. 
 How can D
 be used to interopt with modern web development?

You should ask this in http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/ But while we're here, maybe you could send him a link to http://vibed.org/ along with a link to http://dlang.org/phobos/std_algorithm.html that he could read when he has 10 minutes I don't know how else you could convince him. Possibly benchmarks? http://atilanevesoncode.wordpress.com/2013/12/05/go-vs-d-vs-erlang-vs-c-in-real-life-mqtt-broker-implementation-shootout/ Or an example of a dynamic web project backend? https://github.com/rejectedsoftware/vibe.d/tree/master/examples/web He might not be so familiar with type safety though, so then your arguments will have to be more technical - type safety is the only way you can ever scale a project because most bugs are caught by the compiler. He can keep using his front-end libraries too. Browsers don't run D code, they simply request bytes from it. Good luck!

Agree. Give vibe.d a try. If your friend uses dub to build it, it should be pretty easy to get started. A basic server app is very simple and straight forward to implement with vibe.d. Once the server is running he can use his existing html / js files (the server app just, well, "serves" them), or he can do more fancy script like stuff with diet templates: http://vibed.org/docs#html-templates and http://vibed.org/templates/diet And yes, vibe.d is by an order of magnitude faster than your usual web infrastructures.
Apr 29 2014
prev sibling next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Apr 29, 2014 at 11:55:11AM -0400, Etienne via Digitalmars-d wrote:
 On 2014-04-29 11:27 AM, Adam D. Ruppe wrote:
I recently started a Ruby on Rails job and using it makes me really,
really miss the high productivity and ease of use D offers. (And, of
course, a dynamic site in D runs about 3x faster out of the box than
hello world served by Rails, zero effort in optimization. And "rake
test", just shoot me, I'd rather rebuild a C++ project from scratch,
at least that'll finish before the heat death of the universe.)

That's funny b/c most people say RoR made them love web development.

That's not what I hear. My cousin, who does RoR, hates it with a passion, and wishes she could get out of it. But unfortunately, she can't. I don't use RoR personally, though, so I can't speak for it myself. T -- I see that you JS got Bach.
Apr 29 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 29 April 2014 at 15:55:13 UTC, Etienne wrote:
 That's funny b/c most people say RoR made them love web 
 development.

That's probably because they went into it with very little experience with the alternatives. I was spoiled by my web.d and friends, as well as knowing how to use a real relational database, so getting on the Rails to me is like going back into the stone age. But if you came from mysql 3 and PHP 4 or some other primitive trash, RoR might seem like the best thing ever. I do kinda like the rails console repl tho. Of course, I kinda have that with cgi.d too, you can call its methods on the regular command line pretty easily, but that doesn't let you build up state as easily for quick changes and I do like that. (Maybe I'll offer such with my script.d, should be easy to add :P) the rest of it tho is just awful.
Apr 29 2014
prev sibling next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Tue, 29 Apr 2014 14:41:17 +0000
James via Digitalmars-d <digitalmars-d puremagic.com> wrote:
just show him vibe.d. it's what node.js wants to be, but failed. ;-)
Apr 29 2014
prev sibling next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Tue, 29 Apr 2014 11:55:11 -0400
Etienne via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 That's funny b/c most people say RoR made them love web development.
 If the D community could organize itself the same way RoR is around
 web dev, I doubt any other web scripting language could pursue
 existence.

Apr 29 2014
prev sibling next sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2014-04-29 at 20:04 +0200, Paulo Pinto via Digitalmars-d wrote:
[…]
 I was already doing RoR back in 1999, but it was with our own in-house 
 TCL Apache/IIS module in a Portuguese startup, far far away from Silicon 
 Valley and loosely based in AOL Server concepts.

 We already had Active Record and MVC with security layers and 
 scaffolding, just in TCL and unknown to the world.

Californians insist that everything is invented in California, and all other USAnians believe them. It is about time Europeans stopped believing them. Especially as everything in the future will be invented in China. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Apr 29 2014
prev sibling next sibling parent "JN" <666total wp.pl> writes:
On Tuesday, 29 April 2014 at 15:28:00 UTC, Nick Sabalausky wrote:
 Show him forum.dlang.org (written in D) and point out that 
 modern HTML5/JS sites are freaking horrid. 
 </admitted-curmudgeon>

forum.dlang.org is written in HTML/JS too.
Apr 29 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 29 April 2014 at 19:06:59 UTC, Jacob Carlborg wrote:
 I'm curious to why you think D is more productive and easier to 
 use.

A lot of things, mostly focusing around having the compiler to help refactor with confidence (the importance of this really can't be understated) and having libraries that fit better. The speed is a nice bonus too, having to spend half a minute just waiting for the tests to run really grates me. But wrt libraries, ActiveRecord is unbelievably awful, for example. It is a bad idea from the ground up: why, oh why are we reinventing the database? erb templates are painful to use too, and so is the routing. I don't understand why routing isn't done automatically for the common case. The scaffolding is a pain too. Contrast to what web.d does: given a function signature, it automatically generates a form for it (using type information to select correct widgets) and can format the response in several forms automatically including plain text, html list, html table, json, xml, csv, and a custom template. Maybe Rails can do this stuff and I'm too much of a n00b, but the other experienced team members say the way we're doing it is pretty standard and I'm just not impressed. I can just get stuff done in D in a fraction of a time it takes to do even less in RoR.
Apr 29 2014
prev sibling next sibling parent reply "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Tuesday, 29 April 2014 at 14:41:19 UTC, James wrote:
 I have a friend that is a web developer. I, however want to 
 collaborate with him, so I am trying to get him to learn D. I  
 don't know how to persuade him! How can D be used to greatly 
 assist an HTML5/JavaScript web developer? I decided to go here 
 to get some good answers. How can D be used to interopt with 
 modern web development?

If you want to show him what's possible with D, just show him Cmsed[0] ;) All I'm saying is, if you ever not want to write ajax code again, Cmsed is your friend [1]. [0] https://github.com/rikkimax/Cmsed [1] https://gist.github.com/rikkimax/11043210
Apr 29 2014
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/30/2014 1:24 AM, Russel Winder via Digitalmars-d wrote:
 I would say from anecdotal observation, so no real significance, that
 most languages end up with a number of frameworks:

 1A. Full stack Web framework.
 1B. Lightweight HTTP framework.
 2A. Full feature networking framework.
 2B. Lightweight networking framework.

 In 1A we have JavaEE, Spring, RoR, Django, Grails, etc. In 2B we have
 Sinatra, Ratpack, Flask, Bottle, etc. For 2A there is Twisted and 2B
 asyncio (showing my Python bias here :-)

That does seem to happen. 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".
Apr 30 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/30/2014 9:47 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 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.

That definitely is the direction things are moving right now. Granted, I don't like it, but you're right it's undoubtedly the popular direction and it's unlikely to slow or reverse anytime soon. That said, I don't have an issue with fat clients in general. I usually tend to prefer them (ex: desktop email client). Just not when the "fat client" happens to be inside a web browser, because that tends to not be "fat" client so much as "needlessly bloated" client with an awkward, temperamental UI (example: MS Word and OpenOffice have never lost one keystroke for me from a network hiccup or anything equally trivial).
 What I don't want:

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

JS can definitely help improve the UX of form validation, no doubt about that, but it's important to remember that server-side validation is still necessary anyway, regardless of what you do on the client.
 - 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.

Same here. I don't like having my available HTTP interfaces scattered across my codebade, and I definitely don't like having them implicit based on member-function visibility (I've used such frameworks before. Not personally my cup of tea). What I *do* love is having a canonical table defining my entire HTTP interface in one easy location. The extra typing or non-DRYness of that is a mere triviality in my experience (and I'm normally a huge DRY buff).
 - Server side generation should be kept minimal, prevents caching.

Ehh, yes and no. Server side generation is usually fine, just not when it's done more often than necessary. And traditional server-side web technologies definitely tend to do it more than necessary, For example, consider a page containing a blog post with (non-Disqus) user comments: It's a complete waste for the server to regenerate such a page upon every request, PHP/ASP-style. That's because it doesn't *change* upon every viewing - it only changes on every post and edit (and not even every one of those, if there's enough comments to trigger paging). So unless the page's rate of comment "submissions/edits" approaches the rate of comment "views" (unlikely...except maybe on YouTube ;) ), then it's best to re-generate upon posts/edits and then cache that. So you still get caching benefits, but with no need to make *all* the clients duplicate the exact same page-generating effort as each other upon every viewing. Supporting login stuff (ex: "Hello, [your name here]! Logout?") doesn't really mess this up either. The vast majority of the page can still be cached by the server. Then, "generating" it for each user doesn't need to be anything more resource-intensive than this: void loginUser(string name) { session.user.loggedIn = true; session.user.name = name; // Whatever template engine you want: session.user.loggedInUI = `Hello <b>`~name~`</b>! <a href="/logout">Logout</a>`; } enum commonLoggedOutUI = `Login: <form>Username:<input...> Pass:<input...></form>`; void showMyPage(OutRange response, User user) { // myPage was automatically split into parts A and B // last time it was updated: response.put(myPagePartA); if(session.user.loggedIn) response.put(session.user.loggedInUI); else response.put(commonLoggedOutUI); response.put(myPagePartB); }
 - Would never consider using serverside javascript generation.

Heh, I've actually done that on old-style ASP (ages ago). It was both confusing and interesting.
 What I do want:

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

 - No filesystem dependencies.

I'll take those, plus a large vanilla latte, please. :) "Thank you, come again!"
Apr 30 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/30/2014 12:32 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 On the other side of the fence the Wordpress authors are having a lot of
 power. Whatever Wordpress makes easy will dominate a large portion of
 the web. I think that is so sad, because the Wordpress codebase is… err…
 junk.

I've used Wordpress. Its codebase isn't the only thing bad about it ;)
 I am not even going to use the term «a pile of junk» which would
 suggest that there is some sense of structure to it. I think it is more
 like a scattered mutating spaghetti dinner gone terribly wrong, slowly
 emerging from every toilet in every household taking over the earth…
 like the classic horror movies from the 1950s.

Sounds pretty much exactly what I'd expect from just about any PHP-based application. :/
 JS can definitely help improve the UX of form validation, no doubt
 about that, but it's important to remember that server-side validation
 is still necessary anyway, regardless of what you do on the client.

Yup. So a must have is a good infrastructure for specifying database invariants and transactions. Ideally it should execute like a stored procedure thus leaving the server logic pretty clean.

I have to admit I've been in the habit of avoiding anything beyond basic SELECT/INSERT/UPDATE/DELETE and CREATE TABLE. Not that I haven't used them, but I really should have more familiarity with the other stuff than I do. Ugh, but SQL can be such a pain, especially with all the vendor differences, and when compared to accomplishing something in whatever language I'm invoking SQL from.
Apr 30 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-05-01 19:56, "Marc Schütz" <schuetzm gmx.net>" wrote:

 Exactly. I just feel that client-side validation is unnecessary
 duplication in most cases. But sure, it can be used where it makes sense.

There's a gem [1] for that. Although it seems that one is not maintained anymore. [1] https://github.com/DockYard/client_side_validations-simple_form -- /Jacob Carlborg
May 01 2014
prev sibling parent Etienne <etcimon gmail.com> writes:
 A JIT for D? That would be many, many man-years of work.

Wrong! It would be quite easy. I've figured it out myself. I've thought of using Pegged with PEG/BNF ParseTrees, made faster using ParseTree serialization matched to the source's CRC32-encoding for memoization, with a multi-threaded model of tree-generation when branching in Or! steps. Then, the interpretation stage can re-create the D environment with hash maps of a "Entity" Variant of D types, functions, values and instantiations added with their respective identifiers, each as a single Entity struct containing their instructions as a simple array. e.g. struct Entity { Entity[] scope; Entity[] instructions } Once that's done, you should have all your types and objects in HashMaps, ready to execute with an entry point. You move through the instructions with a foreach loop by looking up function calls and expecting the appropriate return type. Call me crazy, but I think typed variants would be easier and faster to handle than the regular casting methods that interpreted languages use currently. Anyway, the hardest part again would be to write a good garbage collector.
Apr 30 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 30 April 2014 at 02:43:43 UTC, Rikki Cattermole 
wrote:
 All I'm saying is, if you ever not want to write ajax code 
 again, Cmsed is your friend [1].

My web.d does some javascript generation too. D: import arsd.web; class Foo : ApiProvider { export int add(int a, int b) { return a+b; } } mixin FancyMain!Foo; Javascript: Foo.add(1, 2).get(alert); // calls alert(3) when it returns The generated JS code creates an object with the same name as the D class with all the export functions as methods that return a proxy object, setting the arguments. You can then modify it and eventually fire off the request with methods like get, getSync, and getHtml which take a function to call with the result. Just one of the many things I miss when doing RoR instead of D :(
Apr 29 2014
prev sibling next sibling parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Wednesday, 30 April 2014 at 03:09:43 UTC, Adam D. Ruppe wrote:
 On Wednesday, 30 April 2014 at 02:43:43 UTC, Rikki Cattermole 
 wrote:
 All I'm saying is, if you ever not want to write ajax code 
 again, Cmsed is your friend [1].

My web.d does some javascript generation too. D: import arsd.web; class Foo : ApiProvider { export int add(int a, int b) { return a+b; } } mixin FancyMain!Foo; Javascript: Foo.add(1, 2).get(alert); // calls alert(3) when it returns The generated JS code creates an object with the same name as the D class with all the export functions as methods that return a proxy object, setting the arguments. You can then modify it and eventually fire off the request with methods like get, getSync, and getHtml which take a function to call with the result. Just one of the many things I miss when doing RoR instead of D :(

We should probably work together on this sort of stuff! As we seem to have similar ideas
Apr 29 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 30 April 2014 at 02:43:43 UTC, Rikki Cattermole 
wrote:
 On Tuesday, 29 April 2014 at 14:41:19 UTC, James wrote:
 I have a friend that is a web developer. I, however want to 
 collaborate with him, so I am trying to get him to learn D. I  
 don't know how to persuade him! How can D be used to greatly 
 assist an HTML5/JavaScript web developer? I decided to go here 
 to get some good answers. How can D be used to interopt with 
 modern web development?

If you want to show him what's possible with D, just show him Cmsed[0] ;) All I'm saying is, if you ever not want to write ajax code again, Cmsed is your friend [1]. [0] https://github.com/rikkimax/Cmsed [1] https://gist.github.com/rikkimax/11043210

Having a quick look at Cmsed I must admit I like plain vibe.d much more despite the added features :( Forced module coupling and OO-heavy design is big loss compared to design simplicity and independence of base vibe.d modules. For example I can't imagine a single case when I'd prefer class-based route definition to stock delegate-based.
Apr 29 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 30 April 2014 at 03:20:16 UTC, Rikki Cattermole 
wrote:
 We should probably work together on this sort of stuff! As we 
 seem to have similar ideas

Yea, I wrote my version several years ago (IIRC 2009 or early 2010) and since then D has grown as has my knowledge of it. I kinda want to write a web.d 2.0 that cleans everything up but eh I have a lot of things I want to do and web.d 1.0 works so no big rush. The 1.0 has a lot of cool stuff though, like it can avoid JS calls by referencing the result of another function in the URL, all pretty transparently. So like if you wrote, in JS: Foo.add(Foo.add(1,2), 3).get(alert), it should only result in one HTTP request. The proxy object when used as an argument just emits an indirect reference through magic URL params. Kinda cool, though it doesn't go as far as I'd like. Among what I'd like to clean in web.d 2.0: web.d supports what it calls "ApiObjects", which map to RESTful uris: class Poo : ApiObject { this(ApiProvider parent, string identifier) {} auto GET() { } auto POST() {} // etc auto bar() {} } If you went to: /Poo/cool-beans it would call (new Poo(parent, "cool-beans")).GET(). Then /Poo/a/bar calls new Poo("a").bar and so on. The problem is this is really reliant on things like the ending slash, and it issues redirects to force it to be there or not be there. The implementation is also kinda buggy in general, it is supposed to beautifully nest, but it only kinda does. Getting an index of all things also doesn't work quite right, you have to write a separate method for that. So I'd like to clean all that up and actually design it instead of growing on cool hacks as they come to mind. Nested ApiProviders don't work exactly right either. They are supposed to do a chain of magic: class Foo : ApiProvider { auto whatever() {} } class Bar : ApiProvider { alias Foo foo; } Then, /foo/whatever does (new Foo((new Bar))).whatever. That part works. The things is each class can also provide a postProcess method to modify the document after it is generated. That's *supposed* hit everything, but sometimes it doesn't, I think it only works two levels deep right now, really hairy implementation. The other problem is the Javascript generator doesn't really understand nesting. Ideally, nested ApiProviders are made available through dots and nested ApiObjects are workable through JS proxy objects. This looks like what you managed to do so that's cool. I also need to clean up the reflection generation to make it easier to use and make path info accessible outside just the automatic routing (or the low level Cgi.pathInfo which doesn't tell you where it starts!). Reflection should be generated once upon startup then reused forever as an immutable object. Currently, reflection is partially regenerated on each request - eek. I also wrote a _register*Processor family fairly recently (like December 2012) that kinda obviates the old postProcess and back in January this year, changed the session to put it all in cookies instead of files. That stuff is awesome, so much better than the old way. Should consider doing them from the ground up now! (Also, ironically, I was a big pusher for UDAs for web.d... but I barely actually used them after they were made available. I really wanted to put them on parameters tho, otherwise convention over configuration is kinda how i play it LOLOL) oh yeah and it could be documented somewhere other than my brain, the sloppy source, and random forum posts so ppl can know about it all. but meh. All that said, it manages to get the job done for me so I'm not in a huge rush to actually fix any of it.
Apr 29 2014
prev sibling next sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2014-04-29 at 22:09 +0000, Adam D. Ruppe via Digitalmars-d
wrote:
[…]
 I can just get stuff done in D in a fraction of a time it takes 
 to do even less in RoR.

This is the stuff marketing campaigns are made from. As well as informing the cabal that is this mailing list, there needs to be tweets, Facebook, G+, and proper publishing articles of people switching from RoR, Grails, Django to web.d and vibe.d and discovering (measured and guaranteed) significant performance benefits in both time to market and run time. Go has gained much of it's traction from provably and consistently producing simpler, faster and more reliable systems that C, C++, Python, etc. and getting articles about the success out there. HN is all very well but it is really another inward looking cabal. Articles about rewrites of systems written in sober yet humorous tones presenting real benefits will over a period of a couple of year generate a groundswell of support. D may be a lot older than Go, but there is a lot to be learned from the way non-Google folk created the "buzz" for Go by doing and publishing data about, as well as chatting on the mailing list. It also helped that a faction in Canonical switched from Python to Go and got on and did things that contributed positively to Ubuntu. Whatever your feelings towards Canonical and Ubuntu, their use of Go has contributed strongly to the progress and acceptance of the language. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Apr 29 2014
prev sibling next sibling parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Wednesday, 30 April 2014 at 04:10:14 UTC, Dicebot wrote:
 On Wednesday, 30 April 2014 at 02:43:43 UTC, Rikki Cattermole 
 wrote:
 On Tuesday, 29 April 2014 at 14:41:19 UTC, James wrote:
 I have a friend that is a web developer. I, however want to 
 collaborate with him, so I am trying to get him to learn D. I
  don't know how to persuade him! How can D be used to greatly 
 assist an HTML5/JavaScript web developer? I decided to go 
 here to get some good answers. How can D be used to interopt 
 with modern web development?

If you want to show him what's possible with D, just show him Cmsed[0] ;) All I'm saying is, if you ever not want to write ajax code again, Cmsed is your friend [1]. [0] https://github.com/rikkimax/Cmsed [1] https://gist.github.com/rikkimax/11043210

Having a quick look at Cmsed I must admit I like plain vibe.d much more despite the added features :( Forced module coupling and OO-heavy design is big loss compared to design simplicity and independence of base vibe.d modules. For example I can't imagine a single case when I'd prefer class-based route definition to stock delegate-based.

The classes are unfortunately just a container for routes. So if you got a better way, that can provide the same functionality, I'd love for a plan on how to do it! Basically my idea is that you register as little as possible. That was why I went with a class for routes. I'm really gunning for less, simpler = more. And for medium-large sites thats kinda important.
Apr 29 2014
prev sibling next sibling parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
It may be a good time to repeat, we need a marketing manager for 
D!
Somebody really really needs to focus on getting us out there.
Apr 29 2014
prev sibling next sibling parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Wednesday, 30 April 2014 at 04:12:59 UTC, Adam D. Ruppe wrote:
 On Wednesday, 30 April 2014 at 03:20:16 UTC, Rikki Cattermole 
 wrote:
 We should probably work together on this sort of stuff! As we 
 seem to have similar ideas

Yea, I wrote my version several years ago (IIRC 2009 or early 2010) and since then D has grown as has my knowledge of it. I kinda want to write a web.d 2.0 that cleans everything up but eh I have a lot of things I want to do and web.d 1.0 works so no big rush. The 1.0 has a lot of cool stuff though, like it can avoid JS calls by referencing the result of another function in the URL, all pretty transparently. So like if you wrote, in JS: Foo.add(Foo.add(1,2), 3).get(alert), it should only result in one HTTP request. The proxy object when used as an argument just emits an indirect reference through magic URL params. Kinda cool, though it doesn't go as far as I'd like. Among what I'd like to clean in web.d 2.0: web.d supports what it calls "ApiObjects", which map to RESTful uris: class Poo : ApiObject { this(ApiProvider parent, string identifier) {} auto GET() { } auto POST() {} // etc auto bar() {} } If you went to: /Poo/cool-beans it would call (new Poo(parent, "cool-beans")).GET(). Then /Poo/a/bar calls new Poo("a").bar and so on. The problem is this is really reliant on things like the ending slash, and it issues redirects to force it to be there or not be there. The implementation is also kinda buggy in general, it is supposed to beautifully nest, but it only kinda does. Getting an index of all things also doesn't work quite right, you have to write a separate method for that. So I'd like to clean all that up and actually design it instead of growing on cool hacks as they come to mind. Nested ApiProviders don't work exactly right either. They are supposed to do a chain of magic: class Foo : ApiProvider { auto whatever() {} } class Bar : ApiProvider { alias Foo foo; } Then, /foo/whatever does (new Foo((new Bar))).whatever. That part works. The things is each class can also provide a postProcess method to modify the document after it is generated. That's *supposed* hit everything, but sometimes it doesn't, I think it only works two levels deep right now, really hairy implementation. The other problem is the Javascript generator doesn't really understand nesting. Ideally, nested ApiProviders are made available through dots and nested ApiObjects are workable through JS proxy objects. This looks like what you managed to do so that's cool. I also need to clean up the reflection generation to make it easier to use and make path info accessible outside just the automatic routing (or the low level Cgi.pathInfo which doesn't tell you where it starts!). Reflection should be generated once upon startup then reused forever as an immutable object. Currently, reflection is partially regenerated on each request - eek. I also wrote a _register*Processor family fairly recently (like December 2012) that kinda obviates the old postProcess and back in January this year, changed the session to put it all in cookies instead of files. That stuff is awesome, so much better than the old way. Should consider doing them from the ground up now! (Also, ironically, I was a big pusher for UDAs for web.d... but I barely actually used them after they were made available. I really wanted to put them on parameters tho, otherwise convention over configuration is kinda how i play it LOLOL) oh yeah and it could be documented somewhere other than my brain, the sloppy source, and random forum posts so ppl can know about it all. but meh. All that said, it manages to get the job done for me so I'm not in a huge rush to actually fix any of it.

It does look like web.d was a bit of a precursor to Cmsed (unintentionally) strangely enough. 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.
Apr 29 2014
prev sibling next sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2014-04-30 at 04:12 +0000, Adam D. Ruppe via Digitalmars-d
wrote:
[…]
 Yea, I wrote my version several years ago (IIRC 2009 or early 
 2010) and since then D has grown as has my knowledge of it. I 
 kinda want to write a web.d 2.0 that cleans everything up but eh 
 I have a lot of things I want to do and web.d 1.0 works so no big 
 rush.

I disagree. 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. Yes for using 1.0 on the current jobs, but definitely yes to starting on 2.0 now, especially if there are other to join in and help with the work. Web is not my area per se and I don't have a web-related project I can pin helping out with this effort on, but I would encourage you to work on 2.0. I will have to be looking at Python's asyncio which is Python's "play" in the arena that Twisted used to be king; more vibe.d than web.d. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Apr 29 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via 
Digitalmars-d wrote:
 On Tue, 2014-04-29 at 22:09 +0000, Adam D. Ruppe via 
 Digitalmars-d
 wrote:
 […]
 I can just get stuff done in D in a fraction of a time it 
 takes to do even less in RoR.

This is the stuff marketing campaigns are made from. As well as informing the cabal that is this mailing list, there needs to be tweets, Facebook, G+, and proper publishing articles of people switching from RoR, Grails, Django to web.d and vibe.d and discovering (measured and guaranteed) significant performance benefits in both time to market and run time.

I have a friend who has switched to vibe.d after being Erlang Cowboy devoted user for years. Trying to convince him to write an article about it but no luck so far :( Reason to switch in two words : "static typing".
Apr 29 2014
prev sibling next sibling parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Wednesday, 30 April 2014 at 04:32:37 UTC, Russel Winder via 
Digitalmars-d wrote:
 On Wed, 2014-04-30 at 04:12 +0000, Adam D. Ruppe via 
 Digitalmars-d
 wrote:
 […]
 Yea, I wrote my version several years ago (IIRC 2009 or early 
 2010) and since then D has grown as has my knowledge of it. I 
 kinda want to write a web.d 2.0 that cleans everything up but 
 eh I have a lot of things I want to do and web.d 1.0 works so 
 no big rush.

I disagree. 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. Yes for using 1.0 on the current jobs, but definitely yes to starting on 2.0 now, especially if there are other to join in and help with the work. Web is not my area per se and I don't have a web-related project I can pin helping out with this effort on, but I would encourage you to work on 2.0. I will have to be looking at Python's asyncio which is Python's "play" in the arena that Twisted used to be king; more vibe.d than web.d.

I've been working on Cmsed/Dvorm/Dakka specifically in the mind of a rather (major) web service. Haven't started it yet, but possibly next semester. I'm of the opinion that we all need to work together to get a damn nice web service framework together. I split up my ORM for this purpose so even if you don't want to use Cmsed you can use it at least. Won't be very nice for normal Vibe users though. I really do want help, Dakka (Actor framework) needs somebody who knows threading/networking communication. I'll eventually get it communicating with other nodes but.. Will opensource if there is interest. Dvorm needs work to make it be usable with relational databases. At worse that means I need OpenDBX dlls for 32/64bit (wasn't as easy to compile as I thought). The hardest part really is how to handle indexes. Cmsed needs documentation by the bucket load. Its also blocked at the moment on dub to make it sensible to do reloading of templates/routes/models. Which will change the way you structure it. Cmsed is already at the point of comparable to other web service frameworks in most other languages.
Apr 29 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via 
Digitalmars-d wrote:
 Go has gained much of it's traction from provably and 
 consistently
 producing simpler, faster and more reliable systems that C, 
 C++, Python,
 etc. and getting articles about the success out there.

Python is simpler than Go for web. There is a reason for why Go is still not in production on App Engine, you end up with more convoluted code as far as I can tell. Faster, yep.
Apr 29 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 30 April 2014 at 04:42:09 UTC, Dicebot wrote:
 I have a friend who has switched to vibe.d after being Erlang 
 Cowboy devoted user for years. Trying to convince him to write 
 an article about it but no luck so far :( Reason to switch in 
 two words : "static typing".

Yes, static typing is a main selling point. I would also consider switching to D or Go for webstuff if it was production ready/supported. But they will need to reach Java maturity to gain traction in a wider audience...
Apr 29 2014
prev sibling next sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2014-04-30 at 04:52 +0000, Rikki Cattermole via Digitalmars-d
wrote:
[…]
 I've been working on Cmsed/Dvorm/Dakka specifically in the mind 
 of a rather (major) web service. Haven't started it yet, but 
 possibly next semester.
 I'm of the opinion that we all need to work together to get a 
 damn nice web service framework together.

I would say from anecdotal observation, so no real significance, that most languages end up with a number of frameworks: 1A. Full stack Web framework. 1B. Lightweight HTTP framework. 2A. Full feature networking framework. 2B. Lightweight networking framework. In 1A we have JavaEE, Spring, RoR, Django, Grails, etc. In 2B we have Sinatra, Ratpack, Flask, Bottle, etc. For 2A there is Twisted and 2B asyncio (showing my Python bias here :-)
 I split up my ORM for this purpose so even if you don't want to 
 use Cmsed you can use it at least. Won't be very nice for normal 
 Vibe users though.

Grails is doing this at last (necessitated by supporting NoSQL as well as SQL in the full stack). This is a positive aspect of "componentizing" such large frameworks.
 I really do want help, Dakka (Actor framework) needs somebody who 
 knows threading/networking communication. I'll eventually get it 
 communicating with other nodes but.. Will opensource if there is 
 interest.

I would love to help here, and indeed on a review of std.parallelism, but I have committed my time to a revamp of GPars for Groovy 2.3 and Java 8, so cannot take on another big task in the short term.
 Dvorm needs work to make it be usable with relational databases. 
 At worse that means I need OpenDBX dlls for 32/64bit (wasn't as 
 easy to compile as I thought).
 The hardest part really is how to handle indexes.

Pass I'm afraid, I cannot contribute on this front at all.
 Cmsed needs documentation by the bucket load. Its also blocked at 
 the moment on dub to make it sensible to do reloading of 
 templates/routes/models. Which will change the way you structure 
 it.

Is it viable for Dub to support this? Is someone working on it to create a pull request? Can SCons be an alternative here?
 Cmsed is already at the point of comparable to other web service 
 frameworks in most other languages.

So why would I use it rather than RoR, Grails, Django, Java EE, Spring? Not entirely a rhetorical question. It is good to know early in development why it is worth doing the development rather than using pre-existing tools. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Apr 29 2014
prev sibling next sibling parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Wednesday, 30 April 2014 at 05:25:15 UTC, Russel Winder via 
Digitalmars-d wrote:
 On Wed, 2014-04-30 at 04:52 +0000, Rikki Cattermole via 
 Digitalmars-d
 wrote:
 […]
 I've been working on Cmsed/Dvorm/Dakka specifically in the 
 mind of a rather (major) web service. Haven't started it yet, 
 but possibly next semester.
 I'm of the opinion that we all need to work together to get a 
 damn nice web service framework together.

I would say from anecdotal observation, so no real significance, that most languages end up with a number of frameworks: 1A. Full stack Web framework. 1B. Lightweight HTTP framework. 2A. Full feature networking framework. 2B. Lightweight networking framework. In 1A we have JavaEE, Spring, RoR, Django, Grails, etc. In 2B we have Sinatra, Ratpack, Flask, Bottle, etc. For 2A there is Twisted and 2B asyncio (showing my Python bias here :-)
 I split up my ORM for this purpose so even if you don't want 
 to use Cmsed you can use it at least. Won't be very nice for 
 normal Vibe users though.

Grails is doing this at last (necessitated by supporting NoSQL as well as SQL in the full stack). This is a positive aspect of "componentizing" such large frameworks.
 I really do want help, Dakka (Actor framework) needs somebody 
 who knows threading/networking communication. I'll eventually 
 get it communicating with other nodes but.. Will opensource if 
 there is interest.

I would love to help here, and indeed on a review of std.parallelism, but I have committed my time to a revamp of GPars for Groovy 2.3 and Java 8, so cannot take on another big task in the short term.
 Dvorm needs work to make it be usable with relational 
 databases. At worse that means I need OpenDBX dlls for 
 32/64bit (wasn't as easy to compile as I thought).
 The hardest part really is how to handle indexes.

Pass I'm afraid, I cannot contribute on this front at all.
 Cmsed needs documentation by the bucket load. Its also blocked 
 at the moment on dub to make it sensible to do reloading of 
 templates/routes/models. Which will change the way you 
 structure it.

Is it viable for Dub to support this? Is someone working on it to create a pull request? Can SCons be an alternative here?

I have already posted on the dub forum about this, Sonke Ludwig said he would be working on variables which will at least allow for copying libraries templates ext.
 Cmsed is already at the point of comparable to other web 
 service frameworks in most other languages.

So why would I use it rather than RoR, Grails, Django, Java EE, Spring? Not entirely a rhetorical question. It is good to know early in development why it is worth doing the development rather than using pre-existing tools.

Because Vibe already supports a good amount of functionality I am already a step up (like file uploading and templates). I have a wiki page to what I currently have done vs what I want to do [0]. I really need to do another release of it and Dvorm and give a better indication of what it can do. I posted somewhere else some of the more advanced functionality being ajax generation from routes/models [1]. But I really need some sort of time cost research to reference with regards to how much time it could save (I also need this for a research paper). I basically had to make my own web service framework primarily because from my experience and knowledge of what currently is available, nothing meet my requirements. It would be more work creating it in other languages than to just do it in D from the start. Not to mention I can get pretty good performance out of D in both memory and requests/second. Now if only I could get the ram requirement to compile Cmsed below half a gig I'd be alright (a long shot given my CTFE usage). [0] https://github.com/rikkimax/Cmsed/wiki/Road-map [1] https://gist.github.com/rikkimax/11043210
Apr 29 2014
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 30 April 2014 at 05:00:47 UTC, Ola Fosheim Grøstad
wrote:
 On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via 
 Digitalmars-d wrote:
 Go has gained much of it's traction from provably and 
 consistently
 producing simpler, faster and more reliable systems that C, 
 C++, Python,
 etc. and getting articles about the success out there.

Python is simpler than Go for web. There is a reason for why Go is still not in production on App Engine, you end up with more convoluted code as far as I can tell. Faster, yep.

Only because developers don't reach for PyPy and Cython as much as they should, rather re-writing everything from scratch and they stating how they are impressed by Go.
Apr 30 2014
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 30 April 2014 at 04:42:09 UTC, Dicebot wrote:
 On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via 
 Digitalmars-d wrote:
 On Tue, 2014-04-29 at 22:09 +0000, Adam D. Ruppe via 
 Digitalmars-d
 wrote:
 […]
 I can just get stuff done in D in a fraction of a time it 
 takes to do even less in RoR.

This is the stuff marketing campaigns are made from. As well as informing the cabal that is this mailing list, there needs to be tweets, Facebook, G+, and proper publishing articles of people switching from RoR, Grails, Django to web.d and vibe.d and discovering (measured and guaranteed) significant performance benefits in both time to market and run time.

I have a friend who has switched to vibe.d after being Erlang Cowboy devoted user for years. Trying to convince him to write an article about it but no luck so far :( Reason to switch in two words : "static typing".

I do like dynamic typed languages, but mostly for prototyping, scripting and tiny scale projects. The type of code that we get to write at enterprise level, static typing is very valuable, specially given how management tends to enforce "write code not tests" and the skillset of certain developers across regions. Code bases being worked on with 30+ developers across multiple sites get fragile very easily. -- Paulo
Apr 30 2014
prev sibling next sibling parent "Mengu" <mengukagan gmail.com> writes:
On Wednesday, 30 April 2014 at 07:18:49 UTC, Paulo Pinto wrote:
 On Wednesday, 30 April 2014 at 05:00:47 UTC, Ola Fosheim Grøstad
 wrote:
 On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via 
 Digitalmars-d wrote:
 Go has gained much of it's traction from provably and 
 consistently
 producing simpler, faster and more reliable systems that C, 
 C++, Python,
 etc. and getting articles about the success out there.

Python is simpler than Go for web. There is a reason for why Go is still not in production on App Engine, you end up with more convoluted code as far as I can tell. Faster, yep.

Only because developers don't reach for PyPy and Cython as much as they should, rather re-writing everything from scratch and they stating how they are impressed by Go.

thank god i'm not the only one who thinks like that. rob pike mentioned that there are much more conversion of python / ruby developers than c / c++ developers. and as we all know the reason is the speed and there's a trade off. they're trading beauty, elegance, simplicity with ugly speed. i also think many go users are caught NIH syndrome. they are re-inventing everything. heck, they are even re-inventing nginx, redis, etc. because they are _not written_ in go. on ruby on rails side, it is fairly very easy. i've built apps with rails and i've always been happy with it. some apps used rails defaults, some apps were very customised. the thing with ror is that it is never getting in your way when you open up your editor and start building your application and that's what i look for in a web framework.
Apr 30 2014
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Tuesday, 29 April 2014 at 17:09:53 UTC, Adam D. Ruppe wrote:
 On Tuesday, 29 April 2014 at 15:55:13 UTC, Etienne wrote:
 That's funny b/c most people say RoR made them love web 
 development.

That's probably because they went into it with very little experience with the alternatives. I was spoiled by my web.d and friends, as well as knowing how to use a real relational database, so getting on the Rails to me is like going back into the stone age. But if you came from mysql 3 and PHP 4 or some other primitive trash, RoR might seem like the best thing ever. I do kinda like the rails console repl tho. Of course, I kinda have that with cgi.d too, you can call its methods on the regular command line pretty easily, but that doesn't let you build up state as easily for quick changes and I do like that. (Maybe I'll offer such with my script.d, should be easy to add :P) the rest of it tho is just awful.

Is there any documentation for web.d, including example apps? I'm using vibe.d at the moment and rolled my own customized DOM tree stuff (that was before I knew dom.d existed). I basically implemented the most important JS features for DOM manipulation and added stuff I'd always wanted in JS.
Apr 30 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 30 April 2014 at 04:21:20 UTC, Rikki Cattermole 
wrote:
 Having a quick look at Cmsed I must admit I like plain vibe.d 
 much more despite the added features :( Forced module coupling 
 and OO-heavy design is big loss compared to design simplicity 
 and independence of base vibe.d modules.

 For example I can't imagine a single case when I'd prefer 
 class-based route definition to stock delegate-based.

The classes are unfortunately just a container for routes. So if you got a better way, that can provide the same functionality, I'd love for a plan on how to do it! Basically my idea is that you register as little as possible. That was why I went with a class for routes. I'm really gunning for less, simpler = more. And for medium-large sites thats kinda important.

Why can't stand-alone annotated function be a valid route? Route is pretty much method + url + handler and first two can be inferred by convention in many cases (as done in vibe.web.rest & Co). Right now your approach actually results in more code than stock vibe.d (stand-alone function + explicit route registration).
Apr 30 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Apr 30 2014
prev sibling next sibling parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Wednesday, 30 April 2014 at 09:41:36 UTC, Dicebot wrote:
 On Wednesday, 30 April 2014 at 04:21:20 UTC, Rikki Cattermole 
 wrote:
 Having a quick look at Cmsed I must admit I like plain vibe.d 
 much more despite the added features :( Forced module 
 coupling and OO-heavy design is big loss compared to design 
 simplicity and independence of base vibe.d modules.

 For example I can't imagine a single case when I'd prefer 
 class-based route definition to stock delegate-based.

The classes are unfortunately just a container for routes. So if you got a better way, that can provide the same functionality, I'd love for a plan on how to do it! Basically my idea is that you register as little as possible. That was why I went with a class for routes. I'm really gunning for less, simpler = more. And for medium-large sites thats kinda important.

Why can't stand-alone annotated function be a valid route? Route is pretty much method + url + handler and first two can be inferred by convention in many cases (as done in vibe.web.rest & Co).

The only way I know of that doesn't result in a container is registerRoutes!"mymodule"; Instead of registerRoute!MyRoute; Now if I could get access to a list of all the modules and hence all routes at CTFE then that wouldn't be an issue. Same deal for models. Basically give me a way that doesn't impose upon the user to manually register a route and the symbol is available at CTFE, then I'll use it. I just don't know it. There is some benefits of having a container for routes however. Being able to add UDAs to that group of routes. I.e. Don't generate javascript, give them a name/grouping. While its possible without it, its a bit more distinct.
Apr 30 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 30 April 2014 at 10:01:51 UTC, Rikki Cattermole 
wrote:
 Why can't stand-alone annotated function be a valid route? 
 Route is pretty much method + url + handler and first two can 
 be inferred by convention in many cases (as done in 
 vibe.web.rest & Co).

The only way I know of that doesn't result in a container is registerRoutes!"mymodule"; Instead of registerRoute!MyRoute;

Well you need to specify this only once with root module (usually app.d) supplied as a parameter. You can query all imported modules recursively from it.
 Now if I could get access to a list of all the modules and 
 hence all routes at CTFE then that wouldn't be an issue. Same 
 deal for models.

This can't be done with same guarantees as runtime reflection because of separate compilation. Requirement to transitively to import everything from root module is necessary. I don't see it much of a burden though.
 There is some benefits of having a container for routes however.
 Being able to add UDAs to that group of routes. I.e. Don't 
 generate javascript, give them a name/grouping.
 While its possible without it, its a bit more distinct.

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.
Apr 30 2014
prev sibling next sibling parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
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.
Apr 30 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Apr 30 2014
prev sibling next sibling parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
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.
Apr 30 2014
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
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.
Apr 30 2014
prev sibling next sibling parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
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.
Apr 30 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Apr 30 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Apr 30 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
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.)
Apr 30 2014
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
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.
Apr 30 2014
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
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
Apr 30 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Apr 30 2014
prev sibling next sibling parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
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.
Apr 30 2014
prev sibling next sibling parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
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.

the first languages I'd have a go at.
Apr 30 2014
prev sibling next sibling parent "logicchains" <jonathan.t.barnard gmail.com> writes:
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.
Apr 30 2014
prev sibling next sibling parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
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
Apr 30 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 30 April 2014 at 14:18:37 UTC, Ary Borenszweig 
wrote:
 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.

Output from the failing test will always be the last one in console. Pipe to tail -> profit. This sounds as pure aesthetics issue.
Apr 30 2014
prev sibling next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Apr 30, 2014 at 02:25:05PM +0000, Dicebot via Digitalmars-d wrote:
 On Wednesday, 30 April 2014 at 14:18:37 UTC, Ary Borenszweig wrote:
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.

Output from the failing test will always be the last one in console. Pipe to tail -> profit. This sounds as pure aesthetics issue.

What I usually do is to be writefln at the start and end of the failing test, so I know exactly which part of the output belongs to the failure: unittest { writeln("Starting failing test"); ... // stuff writeln("debug value = %s", ...); ... // stuff writeln("End failing test"); } Then just pipe it to: sed -ne/^Starting\ failing\ test/,/^End\ failing\ test/p and you're good to go. :-) (The "End" message is there so that you're sure the failure is coming from this test, not somewhere else, and also serves as an indicator of when the problem gets fixed and it moves on to the next test.) T -- It's amazing how careful choice of punctuation can leave you hanging:
Apr 30 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 30 April 2014 at 09:22:06 UTC, Chris wrote:
 Is there any documentation for web.d, including example apps?

Not much, I've done some before but it is pretty scattered and I don't even know where it all is right now.
 I basically implemented the most important JS features for DOM 
 manipulation and added stuff I'd always wanted in JS.

Yeah, dom.d is kinda my magical group of nice convenience too. The .addChild() helper makes building a tree in code so simple that I rarely even thing about innerHTML anymore. addChild takes a tag name and two child strings which are customized based on the tag name: addChild("a", "Link test", "http://link-target.com/"); // makes <a href="httpp....">Link test</a> addChild("span", "foo", "bar"); // makes <span class="bar">foo</span> addChild("div", Html("<b>lol</b>")); // <div><b>lol</b></div> (normally, the second argument is innerText and the third argument is the big customization point.) dom.d's Form class makes them stupid-simple to use too. auto form = document.requireSelector!Form("#my-form"); form.setValue("something", "else"); setValue finds the element with that particular name and sets teh value based on what it is. So if it is an <input>, it sets value. If it is a <textarea>, it sets innerText. If it is <select>, it sets the attribute on the right <option>, or can add an option if needed. It can also implicitly create a hidden element if needed. The Link class has a similar function for link URL params. And, of course, these can be done in a loop: void forwardParams() { foreach(k, v; cgi.post) form.setValue(k, v); } so simple!
Apr 30 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 30 April 2014 at 12:26:06 UTC, Nick Sabalausky 
wrote:
 Automatic forms generated from a type are nice for 
 quick-n-dirty stuff, but I find they tend to work against (or 
 at least be much less useful for) the tweaking and 
 customization usually needed in public-facing production sites.

Aye, I rarely use my automatic forms on live sites either.... but they are really nice for backend CRUD stuff or a quick-n-dirty first-draft. Sometimes though, I can get away with just modifying an automatic form and kinda want to make web.d 2.0 better at that.
 Instead of defining the form in the server-side code and then 
 awkwardly trying to make it generate the HTML I want, I just 
 define the form in HTML. (Or rather, in an HTML template that's 
 still more-or-less valid HTML, with a few additional 
 non-standard tags to help with metadata like "how to validate 
 this field").

Yes, rox rox rox. This is what my html.d originally was for btw, expanding non-standard tags. Many of them are obsolete now tho, I use html5 attributes instead. Of course, html.d also includes other cool stuff like CSS expansion and JS foreach macros too, as we fairly recently talked about.
 Then I use Adam's dom.d (in non-strict mode) to read the HTML 
 form template (preserving the templating stuff)

I use strict mode for that stuff, keep in mind strict mode is about well-formedness, not validation. So it accepts custom tags and attributes easily enough.
Apr 30 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 30 April 2014 at 13:47:11 UTC, Ola Fosheim Grøstad 
wrote:
 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 don't really agree, I do as much work as I can on the server, I like the AJAX stuff to be as stupid simple as setting innerHTML. (Indeed, web.d's automatic javascript has helper functions for this: Server.getSomeData(args).useToReplace(some_element); ) It makes it a lot simpler and gives good compatibility since the client is pretty thin.
 - 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.

aye, I think routing is generally ridiculous.
 - Server side generation should be kept minimal, prevents 
 caching.

That's not really true. You can cache individual parts on the server and in some cases, cache the whole page on the client too. Of course, doing things on the server may not need to be cached anyway because you don't have the lag of a million http requests in putting it together.
Apr 30 2014
prev sibling next sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
On Wednesday, 30 April 2014 at 13:52:25 UTC, John Colvin wrote:
 On Wednesday, 30 April 2014 at 13:38:28 UTC, Adam D. Ruppe 
 wrote:
 But still, one person's productivity is too subjective to 
 focus a lot on IMO.

Calculated dishonesty is healthy in a marketing campaign :p

Put another way, one data point is not data but a lot of them is. Every anecdote carries some weight. And even as one person, there are probably a non-trivial number of people who think roughly the same way and would benefit from...err, from being proselytised? ;) -Wyatt
Apr 30 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 30 April 2014 at 14:58:20 UTC, Ary Borenszweig 
wrote:
 That's good.

 What if you have tests against a database that where each take 
 some time? I don't want to wait for the whole tests to run...

Tests with I/O are not unit tests. And built-in D feature is not called unit-or-somet-other-tests. For integration testing you need some different approach where being able to run separate cases is indeed useful. But it is not a fault of D _unit_ test design.
Apr 30 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 30 April 2014 at 07:14:34 UTC, Jacob Carlborg wrote:
 I think one of the great things about Rails and Ruby is all the 
 libraries and plugins that are available. If I want to do 
 something, in RoR there's a big chance there's already a 
 library for that. In D, there's a big chance I need to 
 implement it myself.

I like implementing things myself :P That's the question I dread most at meetings now: "is there a gem for this?" idk, in the time it takes to search for and evaluate third party code, I could have just written it myself. Especially since libraries almost always need some kind of customization for our specific case anyway! There's a few exceptions where something is hard to write, but most things just aren't that hard.
 But unit tests in D suck as well.

A big difference though is the compiler helps you a lot in D. In Ruby, for example, the main reason we use the unit tests (so far) is to help ensure consistency after refactoring something. It catchings things like a renaming we missed, or a removed method still in use. In D, you just recompile and those things are found almost instantly without needing to actually run any code.
 How do you mean? It just adds an object oriented layer on top 
 of it.

They deliberately avoid the most important parts of a relational database: http://guides.rubyonrails.org/migrations.html "The Active Record way claims that intelligence belongs in your models, not in the database. As such, features such as triggers or foreign key constraints, which push some of that intelligence back into the database, are not heavily used." ORM is something I only like in very small quantities, but ActiveRecord uses it for *everything*, well, except for the things it doesn't even support. The problem here is one of encapsulation and of correctness. If something bypasses the model - which is required for tasks the library doesn't even support and also likely to happen if there's a second app using the data - all kinds of stuff can get in there that is bad. You also have problems like race conditions: account = BankAccount.find(1) account.balance -= 10 account.save! What if two of those run concurrently? I searched the web quickly for this and haven't found a good answer yet... Then, with referential integrity, the docs suggest DIY or getting some third party gem, because their godawful library doesn't really support it. The best it does is offer you a square wheel with the dependent thing. Stupid stupid stupid. When you actually use the database as it is intended, it takes care of these things for you with very easy syntax that works across business logic languages. Nothing new to learn there.
 BTW, what should I use in D. I need a library that is database 
 independent and I don't want to write SQL for the common use 
 cases?

idk, I use my database.d which has a little bit of overlap with what active record does, but since I generally see ORM as being a nasty anti-pattern and horribly leaky abstraction, I didn't go far with it. There's really nothing to fear with writing SQL, except the cases where the language sucks. (UPDATE and INSERT being so different, and the solutions being different for the various vendors, ugh. That's why I made my DataObject, it gathers the changes together then issues one of those commands. It can also be gotten from a query, making it a kind of simple active record: auto obj = mysql.queryDataObject("select * from foo limit 1").front; obj.whatever = "something"; obj.commitChanges(); // calls UPDATE foo SET whatever='something' WHERE id = ? which also works on joined queries on MySQL btw and offers easy support for multiple primary keys or ones not named "id" (as an argument to commitChanges), something active record as far as i can tell doesn't even try to do, but it doesn't try to fetch child objects or anything like that. I have considered adding child object fetching, but I don't really see the need, it is easy to write a method that does that if you want to.)
 I prefer HAML (similar to Jade in vibe.d) but I don't think 
 it's that bad. What do you use?

The ruby thing looks like this <span class="foo"><%= some_value %></span>. For my D stuff, I have two options: 1) create the HTML right in D using dom.d. I like to use this for objects that know how to format themselves and output strictly semantic XML/HTML. The visual styling is then done with CSS. This works better than you might expect! 2) web.d also has a fairly simple replacement system too: <span class="foo">{$some_value}</span> it also supports inserting partials <div html-from="{$dynamic_html}"></div> or <include partial="foo" />, though the include thing takes a wee bit of helper code from the app because it needs to find the html somewhere. And the variable replacement can be piped: {$some_count|plural user users} for example, which is kinda cool. It does NOT support intertwined code. Other things are done with attributes, such as class="if-logged-in" or <ul from="data_thing" /> (infinitely extensible with the server-side DOM).
 I don't know how you do you're routing but the first thing I do 
 when generating a new Rails application is to remove the 
 default routing. The default routing opens every public method 
 in a controller to be a routing end point. It's a complete mess.

It looks like this root "home#index" get "/users/login", to: "users#login" namespace :admin do resources :users do resources :children end end and so on. It isn't awful (especially now that I get what they mean by "resources"), but my web.d rarely uses explicit routing at all, it figures it out automatically by the names, protection level, and types of child members.
 There's a plugin [1] for Rails for generating a form based on a 
 type. I don't understand how anyone can manage without that.

thx, I'll take a gander.
 It can automatically respond in a couple of formats as well. By 
 default JSON, XML and Erb template. The most basic example will 
 look something like this:

Responding with json, xml, and html Just Work with web.d, it figures it out from the static type of the function return value.
 You don't think that's because you're used D for quite a while 
 and developed your own web framework. Compared to Rails where 
 you're completely new.

Yes, obviously that's some of it, but there's other things that I don't expect to change, especially things like runtime errors for what the D compiler would catch. I had to rename a thing last night. Took two hours to do the db migrations and then rename the classes and update all the files. I'm still not completely sure I did it right too! I've done similar things in D in about 5 minutes, the compiler catches everything so I have confidence.
 The biggest problem I have with D is have to do everything 
 myself. I'm getting a bit tired of that.

i love that, different strokes i guess.
Apr 30 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 30 April 2014 at 14:57:00 UTC, Adam D. Ruppe wrote:
 - Server side generation should be kept minimal, prevents 
 caching.

That's not really true. You can cache individual parts on the server and in some cases, cache the whole page on the client too.

Mhh… I think there are several different types of files and caching strategies: 1. static files (the ones that never change can be stored at edge caches) 2. pregenerated files (files served from Amazon AWS, Google Cloud Storage, CDNs) 3. proxy cachable files / client cachable files 4. server memcached files 5. fully dynamic files Ola.
Apr 30 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 30 April 2014 at 15:27:48 UTC, Nick Sabalausky 
wrote:
 That definitely is the direction things are moving right now. 
 Granted, I don't like it, but you're right it's undoubtedly the 
 popular direction and it's unlikely to slow or reverse anytime 
 soon.

I'm not sure if I like it either, but I think websites are getting more usable now. For a while it was a shitty stuttering mess of HTML and JS that made me longing for an AntiWeb browser with community maintained per-site AI that turns the horrible HTML-mess into semantic markup that you can style yourself. I actually have a file called antiweb.d here… ;) I also had high hopes for XSLT. I remember requiring studentprojects to serve XML from the server, and transform it to HTML using XSLT in the browser back in 2002 or so. And XSLT support was actually quite good, at least until the mobile shit hit the fan. Unfortunately connections were still slow so XSLT based rendering had to wait until the whole XML was downloaded. Today I think it might work out quite nicely, but I doubt anyone even remembers that browser can do XSLT today. Actually, I am not even sure if they all still support it? The weird thing is that SEO and search engine priorities are the ones that keep the dynamic websites from going fully dynamic by their anti-dynamic measures (punishing non-static content) and they are also the ones that are pushing semantic markup such as itemscope/itemprop microdata. On the other side of the fence the Wordpress authors are having a lot of power. Whatever Wordpress makes easy will dominate a large portion of the web. I think that is so sad, because the Wordpress codebase is… err… junk. I am not even going to use the term «a pile of junk» which would suggest that there is some sense of structure to it. I think it is more like a scattered mutating spaghetti dinner gone terribly wrong, slowly emerging from every toilet in every household taking over the earth… like the classic horror movies from the 1950s.
 JS can definitely help improve the UX of form validation, no 
 doubt about that, but it's important to remember that 
 server-side validation is still necessary anyway, regardless of 
 what you do on the client.

Yup. So a must have is a good infrastructure for specifying database invariants and transactions. Ideally it should execute like a stored procedure thus leaving the server logic pretty clean.
 What I *do* love is having a canonical table defining my entire 
 HTTP interface in one easy location. The extra typing or 
 non-DRYness of that is a mere triviality in my experience (and 
 I'm normally a huge DRY buff).

Yep, it also acts like always-up-to-date documentation when you come back to the source code 6 months later trying to figure out the main structure.
 So unless the page's rate of comment "submissions/edits" 
 approaches the rate of comment "views" (unlikely...except maybe 
 on YouTube ;) ), then it's best to re-generate upon posts/edits 
 and then cache that. So you still get caching benefits, but 
 with no need to make *all* the clients duplicate the exact same 
 page-generating effort as each other upon every viewing.

Well, I would probably use JS… ;-) But I am pragmatic. Caching and pregeneration can lead to bugs and complications. So it is usually a good idea to just do a dynamic version first and then add caching when needed. I also sometimes use a dynamic template during development, and then just save a static version for release if I know that it won't change.
 I'll take those, plus a large vanilla latte, please. :) "Thank 
 you, come again!"

You're welcome! I think it is realistic now for smaller sites (say 1-8 servers) where you have enough RAM to hold perhaps 10 times the information the site will ever provide. One should be able to sync 8 servers that have relative few write operations easily. So, reading the log might take some time during startup, but with an efficient format… it probably could complete quickly for 1GB of data.
Apr 30 2014
prev sibling next sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2014-04-30 at 12:41 -0400, Nick Sabalausky via Digitalmars-d
wrote:
[…]
 This has a lot to do with why I don't buy the common argument that 
 dynamic languages are all about "just getting shit done".

Interesting use of the word shit. I tend to find that the average programmer produces shit code in whatever language they use. This is a sad reflection on the whole of computing.
 Anytime I use them, they just create more work for me. Writing more 
 sanity checks. More hours debugging. More work to optimize hotspots. 
 More time figuring out Tracebacks I'm getting from code I didn't even 
 write or from tools I'm simply trying to install. Etc.

Using a static language mindset when working with a dynamic language has this effect. Likewise the reverse, using a dynamic language mindset with a static language. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Apr 30 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 30 April 2014 at 16:56:11 UTC, Nick Sabalausky 
wrote:
 Sounds pretty much exactly what I'd expect from just about any 
 PHP-based application. :/

Modern PHP isn't so bad. I can write acceptable code in PHP. Though, I only do so when there is no other option, since it is the least desirable option next to Perl. The good thing about PHP is that default installs tend to have good C libraries. I think it would have died without that. So, if PHP is ok then it must be the PHP programmers that are to blame. I shudder to think what happens with a niche community if they pick it as the next fad… It could destroy any upcoming programming community with spaghetti-hell. Are you sure you want to market D as a web platform?
 familiarity with the other stuff than I do. Ugh, but SQL can be 
 such a pain, especially with all the vendor differences, and 
 when compared to accomplishing something in whatever language 
 I'm invoking SQL from.

You can implement it in the ORB or wherever unit that provides transactions. I was more pointing to what I find useful conceptually in terms of layers: 1. user input on the client 2. validate on client 3. post using ajax 4. server unwraps the data and blindly inserts it into the database 5. if transaction fails, notify client, goto 1 6. done. Another good reason for fat clients is that the edit/run cycle is tighter and it is easier to run a debugger on it. It makes sense to put most of the code where you can mutate it easily.
Apr 30 2014
prev sibling next sibling parent Byron <byron.heads gmail.com> writes:
On Wed, 30 Apr 2014 17:17:01 +0000, Ola Fosheim Grøstad wrote:

 4. server unwraps the data and blindly inserts it into the database 

ummmm...... wtf? This is why hackers keep stealing my credit card.... Client side validation should only be used for giving users immediate fed back and saving cycles. You do know I can look at your js, find all of your ajax calls and send what ever data I want right..
Apr 30 2014
prev sibling next sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2014-04-30 at 05:00 +0000, via Digitalmars-d wrote:
[…]
 Python is simpler than Go for web. There is a reason for why Go 
 is still not in production on App Engine, you end up with more 
 convoluted code as far as I can tell. Faster, yep.

I disagree. A good Python Web application would be using Flask, Bottle, Tornado, Pyramid, Django as a framework and a design and idioms to suit. A good Go Web application has a very different architecture, design and code idioms due to the use of CSP via the goroutines. I do non-HTTP networking rather than HTTP networking and end up with very different solutions to the same problem using Python and Go. If QtD were in a better state I could do a D version… -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Apr 30 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 30 April 2014 at 17:23:39 UTC, Byron wrote:
 Client side validation should only be used for giving users 
 immediate fed
 back and saving cycles. You do know I can look at your js, find 
 all of
 your ajax calls and send what ever data I want right..

If the security model depends on code being hidden then there is something very wrong with it. The database should do all the veracity checks and apply all the consistency constraints. The server should merely prepare the data. If any constraints triggers the transaction is rolled back. This becomes even more important when you have multiple servers and versions of the server software maintained by various divisions writing to the same database.
Apr 30 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 30 April 2014 at 17:23:49 UTC, Russel Winder via 
Digitalmars-d wrote:
 Tornado, Pyramid, Django as a framework and a design and idioms

I've looked closely at Django. I find it more convenient to use smaller independent libraries inspired by Django than using the framework itself. The problem with frameworks that are supposed to support a plugin architecture is that they become complex and not very transparent. That makes debugging harder, and you need to debug because plugins don't always integrate well with each other. So at the end of the day you spend time struggling with debugging complex mechanics that you only need to support plugins. With a more nimble environment you spend less time debugging (or trying to figure out what a plugin actually does) and more time coding stuff that fits the requirements. Frameworks requires you to invest time, that can pay off, but frameworks have trouble moving with the times so… that investment does not pay off long term when you realize that you need to switch to a different framework. As an example: some of the frameworks I've looked at predated UTF-8 and contains an insane amount of code just for dealing with different character sets. The same is true for the client side. Some of the javascript frameworks contains a silly amount of code for dealing with IE6 and other browsers that you can safely ignore…
 A good Go Web application has a very different architecture, 
 design and code idioms due to the use of CSP via the goroutines.

Well, I only know Go from Google App Engine. Browse the hello-world tutorial and you'll see that the Python version is more legible (?): https://developers.google.com/appengine/docs/go/gettingstarted/introduction https://developers.google.com/appengine/docs/python/gettingstartedpython27/introduction
Apr 30 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 30 April 2014 at 19:08:15 UTC, Jacob Carlborg wrote:
 On 2014-04-30 11:43, Dicebot wrote:

 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.

Why would I run more tests than I have to?

Because you hardly notice difference between 0.1 and 0.5 seconds
 BTW, I would probably use the "unittest" keyword for other 
 kinds of tests than unit tests as well.

This is main problem with your expectations I think.
Apr 30 2014
prev sibling next sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2014-04-30 at 18:04 +0000, via Digitalmars-d wrote:
[…]
 I've looked closely at Django. I find it more convenient to use 
 smaller independent libraries inspired by Django than using the 
 framework itself.

If you have a "full stack" solution to a problem then Django does work quite well, however most of my use is far from "full stack" so Flask, Bottle, Twisted and Tornado are my "go to" (*) Python frameworks
 The problem with frameworks that are supposed to support a plugin 
 architecture is that they become complex and not very 
 transparent. That makes debugging harder, and you need to debug 
 because plugins don't always integrate well with each other. So 
 at the end of the day you spend time struggling with debugging 
 complex mechanics that you only need to support plugins. With a 
 more nimble environment you spend less time debugging (or trying 
 to figure out what a plugin actually does) and more time coding 
 stuff that fits the requirements.

For "lightweight" problems, "full stack" frameworks are a disaster. Hence the "lightweight" frameworks. Flask + SQLAlchemy is a very popular combination. I'm not sure what the D equivalent is but I guess it is vibe.d + ???. […]
 Well, I only know Go from Google App Engine. Browse the 
 hello-world tutorial and you'll see that the Python version is 
 more legible (?):

I treat GAE as an anti-pattern. (*) Are we allowed to have gotos any more since Dijkstra's letter? -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Apr 30 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 30 April 2014 at 16:02:25 UTC, Nick Sabalausky 
wrote:
 Well, I've been using mustache-d as my main templating engine, 
 which is just a general text preprocessor (Although I'm kinda 
 eyeing that other text preprocessor that uses actual D code).

ah, I see. BTW, fun fact: dom.d can understand ASP and PHP style tags. You need to set a special callback or call enableAddingSpecialTagsToDom() before parse, (The latter will also enable storing comments, <! stuff> and <?stuff>) but then it will work. I did that to enable dual-use templates that have some PHP code too. But it might be interesting to use for template stuff too... BTW (ok this whole post is turning out to be a series of BTWs), web.d also has a template function that is dom-aware which I think is potentially very interesting. Like it could see <span>{$foo}</span> and be aware to add a class to that span or something. Or it could automatically wrap variables in spans iff that makes sense in the html context. Stuff I've never really used despite writing this some time ago... but I still think there's some potential to all this.
 Granted there are still things I have to refrain from doing in 
 my HTML form templates because it would violate well-formedness 
 *too much* even for an ultra-relaxed HTML DOM. But those cases 
 always have other (arguably more sanitary) ways to accomplish 
 the same thing.

yea
Apr 30 2014
prev sibling next sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2014-04-30 at 21:08 +0200, Jacob Carlborg via Digitalmars-d
wrote:
[…]
 Why would I run more tests than I have to? BTW, I would probably use the 
 "unittest" keyword for other kinds of tests than unit tests as well.

This cannot be a good idea. If the block says unittest then it contains unit tests, not integration tests or system tests, just unit tests. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Apr 30 2014
prev sibling next sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2014-04-30 at 21:06 +0200, Jacob Carlborg via Digitalmars-d
wrote:
 On 2014-04-30 15:38, Adam D. Ruppe wrote:
 
 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.

Ruby has gotten faster in each release.

Especially if you run JRuby on the JVM :-) -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Apr 30 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 30 April 2014 at 20:00:59 UTC, Russel Winder via 
Digitalmars-d wrote:
 If you have a "full stack" solution to a problem then Django 
 does work
 quite well, however most of my use is far from "full stack" so

Depends on what "full stack" is meant to cover. I haven't found a single full-fledged forum software framework for Python, but plenty for PhP. So in the end "full stack" isn't really enough. You still end up having to integrate with "foreign" systems.
 Flask,
 Bottle, Twisted and Tornado are my "go to" (*) Python frameworks

Ok, those are so lightweight that they are very close to being libraries.
 For "lightweight" problems, "full stack" frameworks are a 
 disaster.

Yeah, but I think they are a disaster because they don't follow the times. :-) Lightweight do, well at least they are remade or forked.
 Well, I only know Go from Google App Engine. Browse the 
 hello-world tutorial and you'll see that the Python version is 
 more legible (?):

I treat GAE as an anti-pattern.

Hehe, but webapp2 + jinja2 isn't all that different from Flask and Bottle (which also can run on GAE). I am under the impression that Go for GAE is written by the Go Team? So it shouldn't be an anti-pattern… (?)
 (*) Are we allowed to have gotos any more since Dijkstra's 
 letter?

You better ask the dining philosophers.
Apr 30 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 30 April 2014 at 16:42:00 UTC, Nick Sabalausky 
wrote:
 Anytime I use them, they just create more work for me.

def. I like them in small quantities - heck, I'm written dynamic types and scripting languages for D! But they cause me pain pretty quickly.
Apr 30 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 30 April 2014 at 19:53:53 UTC, Jacob Carlborg wrote:
 I don't really agree with that. Although I'm not a fan of store 
 procedures/functions in the database. But I don't mind foreign 
 key constraints. We used that at my previous work. Via a gem :)

Yeah, foreign keys are really an absolute must. So are uniqueness constraints. Rails can kinda do these, but in its own reinvented ways that don't actually hit the DB (at least not without add on gems) I also find myself really missing outer joins and views.
 I think most Rails application are run single threaded. But 
 with multiple processes instead.

That doesn't change the race condition because the database is still shared across those processes. With a regular SQL query, the database guarantees consistent, atomic operations in the DB engine itself, but with active record pattern, you give that up... while still having the shared data. It was a thing like this that recently took a bitcoin exchange down. Literally the textbook example of concurrency, but most these modern newfangled frameworks get it wrong.
 Using a random D module for this doesn't feel very comfortable, 
 no offense. No documentation, no way to find examples and so on.

Yeah, I wrote these for myself and put them on the web just in case somebody else finds them useful, but it is really a take-it-or-leave-it thing to me. Even in my book when I talked about some of these libs, I focused on lessons learned when writing them more than the actual usage - my thought is then maybe people can do their own thing instead of downloading my stuff and using it straight up.
 ActiveRecord will hide all the ugliness of SQL.

It also hides all the beauty of it :(
 Properly escape values

If you're escaping values, unless you're writing some low level database library, you're almost certainly doing it wrong. I agree that using raw SQL with something like the PHP4 method of string concatenation is a huge pain and awful, as well as inefficient and insecure. But that's also the wrong way to do it and any non-crippled database API or library offers ways to separate the sql code and data cleanly and easily.
 Are you using some kind of proxy for this or are you pushing 
 back the view layer to the model?

CSS is the view in that scenario. The HTML the object returns is just its fields wrapped up in tags and classes. Works really well, for my last big job, the designer worked almost exclusively in CSS and we got a lot of stuff done.
 I'm not sure I understand this piping.

It calls functions on the variable. So like {$foo|capitalize} would be kinda like <%= capitalize(foo) %>. The plural example uses arguments to the function too so we can customize the words if it is plural or no.
 What do you mean with "intertwined code"?

<html><% some ruby here %></html> I hate that stuff, especially when the view starts doing implicit database queries! Defeats the whole point of MVC separation if you ask me.
 You can also do a catch all route:

 match "*path" => "home#page_not_found"

Aye, web.d calls a method called catchAll for those too.
 I don't mind it but sometimes I just want to get some work 
 done. I mean, I've started out (or planed to) with some project 
 in D but then I needed to create all the support libraries and 
 tools so I've almost forgot what I was going to do in the first 
 place.

meh, with my libs, they might not be accessible to others, being poorly documented and all, but I know them and have used them for almost everything that's come up over the years. So for me, getting work done means spending an hour using D instead of days searching the web for some gem that won't even work right anyway.
Apr 30 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 30 April 2014 at 20:36:15 UTC, Andrei Alexandrescu 
wrote:
 On 4/30/14, 12:25 PM, Dicebot wrote:
 On Wednesday, 30 April 2014 at 19:08:15 UTC, Jacob Carlborg 
 wrote:
 On 2014-04-30 11:43, Dicebot wrote:

 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.

Why would I run more tests than I have to?

Because you hardly notice difference between 0.1 and 0.5 seconds

*cough* std.datetime *cough* :o)

Pretty much everyone agrees that std.datetime needs to be split into smaller module which was one of my original points.
 One good example is networking tests - if I worked on an 
 airplane I'd love to not test tests that need connectivity with 
 a simple regex.

Again, networking (as well as any other I/O) has no place in unit tests. Never. Supporting such kind of tests natively means designing completely new system not changing existing one. For most simple example, you can't run non-unit tests in parallel without explicit annotations from programmer (your other thread).
May 01 2014
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 30 April 2014 at 19:25:40 UTC, Dicebot wrote:
 On Wednesday, 30 April 2014 at 19:08:15 UTC, Jacob Carlborg 
 wrote:
 On 2014-04-30 11:43, Dicebot wrote:

 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.

Why would I run more tests than I have to?

Because you hardly notice difference between 0.1 and 0.5 seconds

The compilation time is often more of a problem than the runtime.
May 01 2014
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 30 April 2014 at 15:04:53 UTC, Adam D. Ruppe wrote:
 On Wednesday, 30 April 2014 at 07:14:34 UTC, Jacob Carlborg 
 wrote:
 I think one of the great things about Rails and Ruby is all 
 the libraries and plugins that are available. If I want to do 
 something, in RoR there's a big chance there's already a 
 library for that. In D, there's a big chance I need to 
 implement it myself.

I like implementing things myself :P That's the question I dread most at meetings now: "is there a gem for this?" idk, in the time it takes to search for and evaluate third party code, I could have just written it myself. Especially since libraries almost always need some kind of customization for our specific case anyway! There's a few exceptions where something is hard to write, but most things just aren't that hard.

I agree with this, but with a caveat: The valuable work in a 3rd party lib is more often the design than the body of the implementation. Designing a good API and general design for a library requires experience and perspective that I don't have in most problem spaces, but a quick bit of reading and the internals are often trivial to reproduce. I think this is particularly relevant in D; Implementation is made easy, but the flexibility available makes the design stage especially important. That is not to say that it's harder to make good designs with D, more that it's feasible to make *even better* designs if you have the expertise and time.
May 01 2014
prev sibling next sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Wednesday, 30 April 2014 at 17:17:02 UTC, Ola Fosheim Grøstad 
wrote:
 On Wednesday, 30 April 2014 at 16:56:11 UTC, Nick Sabalausky 
 wrote:
 Sounds pretty much exactly what I'd expect from just about any 
 PHP-based application. :/

Modern PHP isn't so bad. I can write acceptable code in PHP. Though, I only do so when there is no other option, since it is the least desirable option next to Perl. The good thing about PHP is that default installs tend to have good C libraries. I think it would have died without that. So, if PHP is ok then it must be the PHP programmers that are to blame. I shudder to think what happens with a niche community if they pick it as the next fad… It could destroy any upcoming programming community with spaghetti-hell. Are you sure you want to market D as a web platform?

This hasn't happened to Ruby (or Rails for that matter), which is definitely marketed as a web platform. Most of the Ruby code that I've seen is of exceptionally high quality. That's true not only regarding the code itself, but also for the interfaces it provides (in the case of libraries), which are usually well thought out. For PHP, on the other hand... I believe this has a lot to do with the language. Apparently it's harder to write bad code in some languages than in others.
 familiarity with the other stuff than I do. Ugh, but SQL can 
 be such a pain, especially with all the vendor differences, 
 and when compared to accomplishing something in whatever 
 language I'm invoking SQL from.

You can implement it in the ORB or wherever unit that provides transactions. I was more pointing to what I find useful conceptually in terms of layers: 1. user input on the client 2. validate on client 3. post using ajax 4. server unwraps the data and blindly inserts it into the database 5. if transaction fails, notify client, goto 1 6. done.

IMO the client shouldn't do any validation, unless you can really, really trust it. That's why I like to do things the following way: 1. user input on the client 2. post using ajax 3. server validates and stores the data 4a. if transaction or data is invalid fails, send errors to the client 4b. if everything's ok, tell the client to redirect to the next page 5. on the client, add error CSS classes to the relevant fields, or execute the redirect I've created a gem that does almost all of that transparently. I just need to mark the form with "remote: true", and adhere to a few simple naming conventions (which Rails' form generators do automatically).
May 01 2014
prev sibling next sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Thursday, 1 May 2014 at 10:44:42 UTC, Jacob Carlborg wrote:
 On 2014-04-30 22:38, Adam D. Ruppe wrote:
 I also find myself really missing outer joins and views.

For outer joins: 1. You can always use raw SQL, also in combination with ActiveRecord Post.joins(:comments).joins("outer join foos on foos.post_id = posts.id").where(title: "bar") 2. My preferred choice, using Squeel [1] (another gem). With Squeel the above would look like this: Post.joins(:comments).joins{ foos.outer }.where(title: "bar")

You can also use the built-in `includes()`, which does a LEFT OUTER JOIN: Post.includes(:comments).where(comments: {title: "bar"}) (It also eager-loads the comments, but this is usually desired anyway, because an OUTER JOIN doesn't make sense if you're not going to use the joined records.)
May 01 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 1 May 2014 at 12:17:56 UTC, Ary Borenszweig wrote:
 On 5/1/14, 6:58 AM, Jacob Carlborg wrote:
 On 2014-04-30 22:11, Russel Winder via Digitalmars-d wrote:

 This cannot be a good idea. If the block says unittest then 
 it contains
 unit tests, not integration tests or system tests, just unit 
 tests.

Then we need to come up with a separate framework for doing all other kinds of tests.

Yes. And then you need two different commands to check if the system works. And if you want, for example, coverage analysis I wonder how you'd do that... That can't be good.

Two commands effectively. `rdmd -unittest` for development cycle of single module and `make test` to verify everything after feature/bugfix is completed. This is what I tend to do with existing tools (by splitting higher level tests in separate applications), adding some in-language support will just make intention a bit more clear.
May 01 2014
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
On Thursday, 1 May 2014 at 13:33:50 UTC, Marc Schütz wrote:
 IMO the client shouldn't do any validation, unless you can 
 really, really trust it. That's why I like to do things the 
 following way:

 1. user input on the client
 2. post using ajax
 3. server validates and stores the data
 4a. if transaction or data is invalid fails, send errors to the 
 client
 4b. if everything's ok, tell the client to redirect to the next 
 page
 5. on the client, add error CSS classes to the relevant fields, 
 or execute the redirect

That's a lot of unnecessary back and forth to the server for a JS-based design. Plus it avoids some of the nicer UX enhancements JS can enable, like validate-as-you-type, and does so without the benefit of not requiring JS. Kind of a worst of both worlds (no offence). Naturally, the server needs to do validation no matter what. But there's nothing wrong with doing an optional preliminary validation on the client side first.
May 01 2014
prev sibling next sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Thursday, 1 May 2014 at 15:11:07 UTC, Nick Sabalausky wrote:
 On Thursday, 1 May 2014 at 13:33:50 UTC, Marc Schütz wrote:
 IMO the client shouldn't do any validation, unless you can 
 really, really trust it. That's why I like to do things the 
 following way:

 1. user input on the client
 2. post using ajax
 3. server validates and stores the data
 4a. if transaction or data is invalid fails, send errors to 
 the client
 4b. if everything's ok, tell the client to redirect to the 
 next page
 5. on the client, add error CSS classes to the relevant 
 fields, or execute the redirect

That's a lot of unnecessary back and forth to the server for a JS-based design. Plus it avoids some of the nicer UX enhancements JS can enable, like validate-as-you-type, and does so without the benefit of not requiring JS. Kind of a worst of both worlds (no offence).

Well, naturally I disagree :-) It's exactly two requests to the server, same as for a normal form submission without JS: - one for the actual submission => server responds either with the errors, or with a redirect URL - and another one for requesting the next page (only if everything was ok) Technically, you could already send the contents of the new page with the server response, but this has several drawbacks (doesn't change the URL, double POST on reload, etc.), so a redirect is pretty much standard. I don't see how you could improve on that in respect to the number of requests... It also degrades gracefully if JS is not enabled: In this case, the form submission will not be intercepted by the JS and therefore won't be turned into an AJAX request. The server notices that it's not an XHR request, and automatically responds by rerendering the form view with all the CSS classes and error messages in place. (This requires a bit more work on the server side, but not a lot.)
 Naturally, the server needs to do validation no matter what. But
 there's nothing wrong with doing an optional preliminary
 validation on the client side first.

Exactly. I just feel that client-side validation is unnecessary duplication in most cases. But sure, it can be used where it makes sense.
May 01 2014
prev sibling next sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Thursday, 1 May 2014 at 18:35:40 UTC, Jacob Carlborg wrote:
 On 2014-05-01 15:54, "Marc Schütz" <schuetzm gmx.net>" wrote:

 You can also use the built-in `includes()`, which does a LEFT 
 OUTER JOIN:

     Post.includes(:comments).where(comments: {title: "bar"})

 (It also eager-loads the comments, but this is usually desired 
 anyway,
 because an OUTER JOIN doesn't make sense if you're not going 
 to use the
 joined records.)

The SQL code "includes" generates is unspecified. Sometimes it can do an extra "select" instead of a "join".

You're probably right. I thought that changed in a recent release, but can't find it anymore.
May 01 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 1 May 2014 at 13:33:50 UTC, Marc Schütz wrote:
 IMO the client shouldn't do any validation, unless you can 
 really, really trust it.

Client side validation is about better feedback. Today's browsers are fast enough for doing field validation for every keystroke.
 4a. if transaction or data is invalid fails, send errors to the 
 client

Without client side validation you need more detailed errors from the server.
May 01 2014
prev sibling next sibling parent "brad clawsie" <brad b7j0c.org> writes:
On Wednesday, 30 April 2014 at 07:14:34 UTC, Jacob Carlborg wrote:

 I think one of the great things about Rails and Ruby is all the 
 libraries and plugins that are available. If I want to do 
 something, in RoR there's a big chance there's already a 
 library for that. In D, there's a big chance I need to 
 implement it myself.

this has been the fundamental issue for me. its not just missing libs, its libs that are surfaced via a C-binding, which in my limited experience have been difficult to use and make portability hard. I think D is a superior language to Go, but Go has a very complete SDK and its all written in Go, so I don't have to worry about chasing down native libs to install. brad
May 02 2014
prev sibling next sibling parent "Atila Neves" <atila.neves gmail.com> writes:
On Thursday, 1 May 2014 at 09:58:32 UTC, Jacob Carlborg wrote:
 On 2014-04-30 22:11, Russel Winder via Digitalmars-d wrote:

 This cannot be a good idea. If the block says unittest then it 
 contains
 unit tests, not integration tests or system tests, just unit 
 tests.

Then we need to come up with a separate framework for doing all other kinds of tests.

This is why I started to learn Cucumber. Atila
May 03 2014
prev sibling next sibling parent "Atila Neves" <atila.neves gmail.com> writes:
On Thursday, 1 May 2014 at 10:50:12 UTC, John Colvin wrote:
 On Wednesday, 30 April 2014 at 19:25:40 UTC, Dicebot wrote:
 On Wednesday, 30 April 2014 at 19:08:15 UTC, Jacob Carlborg 
 wrote:
 On 2014-04-30 11:43, Dicebot wrote:

 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.

Why would I run more tests than I have to?

Because you hardly notice difference between 0.1 and 0.5 seconds

The compilation time is often more of a problem than the runtime.

For me it's the output. I don't want to see the output of other tests when I'm debugging a failure. Atila
May 03 2014
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 03 May 2014 19:36:53 -0700
Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On 5/3/2014 6:57 PM, Nick Sabalausky wrote:
 I'm not sure mock networks can really be used for testing a
 client-only lib of some specific protocol. There may also be other
 examples.

 There's also the question of whether or not D's "unittest {...}"
 should *expect* to be limited to tests that are *technically* "unit
 tests". Currently, "unittest {...}" is useful for more forms of
 testing than just "unit" tests. I think it's debatable whether we
 want kill off those uses without offering a comparable alternative
 with reasonable migration.

I'm not suggesting killing off anything. I'm suggesting it may not be good practice to use unit tests for testing actual networks.

I'd write unit tests which talked to sockets on the same computer if that was what was required to test a particular function, but I would definitely consider it bad practice to have a unit test try to talk to anything on a separate computer. Now, if you're using unittest blocks for something other than unit tests, then I guess that that could be fine, though I question that it's good practice to use unittest blocks for other purposes. Regardless, unittest blocks don't really put any restrictions on what kind of code can go in them, and I'd prefer that that stay the case. The discussion on parallelizing unit tests threatens that on some level, but as long as we have the means to mark unittest blocks in some manner that tells the test runner not to run them in parallel with any other unittest blocks, then I think that we should be fine on that front. - Jonathan M Davis
May 03 2014
prev sibling next sibling parent "Danny Weldon" <danny.weldon gmail.com> writes:
On Wednesday, 30 April 2014 at 04:22:52 UTC, Rikki Cattermole 
wrote:
 It may be a good time to repeat, we need a marketing manager 
 for D!
 Somebody really really needs to focus on getting us out there.

If somebody has some time, they could post a solution in D to this problem: http://codegolf.stackexchange.com/questions/26323/how-slow-is-python-really-or-how-fast-is-your-language It all helps to get the language visible.
May 04 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Danny Weldon:

 If somebody has some time, they could post a solution in D to 
 this problem:

 http://codegolf.stackexchange.com/questions/26323/how-slow-is-python-really-or-how-fast-is-your-language

 It all helps to get the language visible.

Here are my solutions: http://forum.dlang.org/thread/pvojsrqmaksqwokuekhk forum.dlang.org I don't have a Stackexchange account. You are welcome to post the two solutions (of two different problems). Bye, bearophile
May 04 2014
prev sibling next sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 2014-05-04 at 13:44 +0200, Jacob Carlborg via Digitalmars-d
wrote:
 On 2014-05-03 21:51, Atila Neves wrote:
 
 This is why I started to learn Cucumber.

Cucumber is for acceptance tests. There are also functional and integration tests.

We could get into bikeshedding here,… Cucumber is really for supporting BDD. These include functional and integration tests as well as some varieties of acceptance test. It doesn't just have acceptance tests. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
May 04 2014
prev sibling next sibling parent "Meta" <jared771 gmail.com> writes:
On Sunday, 4 May 2014 at 10:04:12 UTC, bearophile wrote:
 Danny Weldon:

 If somebody has some time, they could post a solution in D to 
 this problem:

 http://codegolf.stackexchange.com/questions/26323/how-slow-is-python-really-or-how-fast-is-your-language

 It all helps to get the language visible.

Here are my solutions: http://forum.dlang.org/thread/pvojsrqmaksqwokuekhk forum.dlang.org I don't have a Stackexchange account. You are welcome to post the two solutions (of two different problems). Bye, bearophile

I'm not able to run either version on DPaste. It fails to compile on both examples with no error message. Both example compile fine locally with DMD 2.065, however. Your C++ translation: ~277ms Your second version: ~2.34ms/round I just compiled and ran each binary a few times, so these might not be good measurements. I compiled both versions without -inline, as they ran slower with it enabled. LDC might do a better job with this.
May 04 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Meta:

 Your C++ translation: ~277ms
 Your second version:  ~2.34ms/round

Both D programs are translations of C++ programs.
 LDC might do a better job with this.

I have developed those two programs using ldc2, so the usage of ldc2 is encouraged, and inlining is necessary for both programs. Generally don't use DMD for benchmark contests like this one. Bye, bearophile
May 04 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
The Nimrod version partially unrolls the recursion 4 times. How 
hard is this to do in D?

http://codegolf.stackexchange.com/questions/26459/how-high-can-you-go-a-codingalgorithms-challenge

Bye,
bearophile
May 04 2014
prev sibling parent "Sergey" <httpal gmail.com> writes:
I just want to write a web client app on D for medical 
institutions. It must be a complicated interface. What tools 
(GUI) should I use for quick programming?
Can I somehow abstract from web programming?

Thanks in advance.
Regards, Sergey
May 11 2014