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

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

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.

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.

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.

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

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?

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.

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.

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