Comment by coffeemug | Hacker News Reader

Comment by coffeemug | Hacker News Reader

Parent Full thread

This feedback is wonderful, thank you. It's often hard to do a good job when you're neck deep in your own concepts because you lose perspective. (I'm responsible for the tutorial, btw, and it's my screwup). I'll make everything work better.

To answer your questions here:

> what is r?

It's a module where all the RethinkDB operations are defined. The tutorial is running the same JavaScript driver code as you'd run if you connected to C++ RethinkDB server from node.js, which is why you have to start with `r`.

> What does db() do?

It refers to a database named 'test'. This is where you're creating the table

> Is there a test database somewhere?

Yes. It's set up by default at the beginning.

> Why do I have to call run() when there's a button saying "Run this query" do you sometimes not run() things?

Because you can type multiple queries in the text box. Every time you end a query with `.run()`, that's when it goes to the server and gets executed there. We've been talking about not having people type `.run` for a single query, but it's a bit difficult to solve.

> What happened to r.db('test') that I needed to use? Is r now that database?

If you omit r.db() at the beginning of the query, it picks a default one (which is 'test'). It's the same as you'd do in MySQL.

> Why didn't I just do r.tableCreate('tv_shows') before?

We thought allowing tableCreate in a default database allows people to make mistakes too easily, so we disallowed it. It confuses people, so we'll add it back. Sorry for confusion.

Just a note for everyone on HN who is starting a business or working on any project: THIS IS HOW YOU SHOULD RESPOND TO CRITICISM! Classy, doesn't expect the user to research beyond the page, etc.

I have to confess: my initial reaction was "isn't this kind of self-explanatory" and "dude, if you want to know what rethinkdb is, look at their damned website" or even the dreaded, and admittedly elitist "if you have to ask, its not targeted at you." However, reading your response, I am reminded that I can be a smug asshole, and I'm going to remember how you responded for the day I release something to the public.

Your response, on top of the fact that I've already examined, installed, and liked your product, adds even more to my confidence that you guys are creating a great longer term product.

I once read a quote by Bertrand Russell that really helped me respond to people better. He was talking about studying philosophy, but it applies to understanding points of view in general. Here it is:

In studying a philosopher, the right attitude is neither reverence nor contempt, but first a kind of hypothetical sympathy, until it is possible to know what it feels like to believe in his theories, and only then a revival of the critical attitude, which should resemble, as far as possible, the state of mind of a person abandoning opinions which he hitherto held. Contempt interferes with the first part of this process, and reverence with the second.

This helped me a lot, hope it helps you too!

I don't have a similarly stylish and philosophical story as coffeemug's but the thing that changed the way I perceive criticism is something I've read a while back: before coming up with any answers or remarks, ask 3 questions about the original thing. Agreed these 3 questions shouldn't be: 1) WTF? 2) who is he to criticize? 3) should I bother?)

Thanks for the response! I completely understand how easy it is to lose perspective when you're the one behind the concepts.

I'd recommend checking out TryRuby from Code School to get a better feel for interactivity in a tutorial. It takes you all the way from "That thing over there is an interactive prompt you are going to type things into."

Writing the code out yourself is extremely helpful for learning. Folks learn better by writing down what they are trying to understand while absorbing the information; the same is true for programming.

Would you mind if I ping you to try things again after I make some changes? Your feedback is really wonderful, it would be immensely helpful to hear what you think after we fix things up. (I know it takes time, so if you're busy, no worries!)

Sure! I hopped in your IRC channel.

I for one have no reason why randomdrake is requesting such extensive pedantry: I thought your API does a wonderful job of speaking for itself, and adding more ceremony to talk about it would only have gotten in my way.

Edit: I totally see the value of the "hack it out yourself" flow he discusses though, and agree that making people do it themselves would be a more likely to be useful learning experience.

I've tried RethinkDB (back when it wouldn't balance shards correctly!), and I liked it a lot. Especially the automatic sharding is magical, I will definitely try it out again when it's stable.

That said, it is also my opinion that the ORM syntax needs a bit of love, for all the reasons stated above. Especially .run() feels a bit weird, can you make queries lazy (like Django's QuerySets, which only run when evaluated)?

P.S. If the rest of the RethinkDB team are as good at DOTA 2 as Marc is, I want to play with you too!

> Especially .run() feels a bit weird, can you make queries lazy (like Django's QuerySets, which only run when evaluated)?

In a way queries are lazy. You can write a query and without calling `run` on it nothing happens. The whole chained ops are executed at once when `run` is called.

> That said, it is also my opinion that the ORM syntax needs a bit of love, for all the reasons stated above.

This is not an "ORM" per se. It's a query API or data manipulation language. The next version will bring a few improvements to it.

> In a way queries are lazy. You can write a query and without calling `run` on it nothing happens.

That's not lazy, though, that's just doing nothing :P Lazy would be not running anything until you evaluated the last link in the chain, so, in Django:

    model = User.objects
    model = model.filter(name="Alex")
    model = model.filter(hero="Dazzle")
    model = model.filter(abandons<2)
    list(model)

and the query would only be executed when wanting to turn the QuerySet into a list.

I think your examples would also be a bit clearer if you forewent the r.db("test") step and just did:

    db = r.db("test")
    db.query("foo").bar().run()

which is more explicit.

Probably this is only "semantics", but I find these two quite similar :). I like the idea of having the query being executed only when needed, but I'm not sure that's always possible (or optimal with large result sets).

thanks,

alex @ rethinkdb

Sure, they are almost identical, but one doesn't need .run() :)

I don't see how it wouldn't be optimal, since lazy evaluation is a superset of eager evaluation (you can invoke it whenever you want).

Both solutions are lazy. While ReQL requires .run(), the Django ORM requires you to do 'list()' (or probably other form of iterator over it). I'd say the only difference is that one is explicit and the other one is implicit.

.run() is also bad. What connection is it being run on? The most recently opened connection? In a global variable somewhere? For anything larger than a short script, you should use query.run(conn), or conn.run(query).

Yes, especially in web applications. Found that out the hard way.

Laziness typically implies something isn't evaluated until you need the data (e.g. you coerce it to a native language data structure, or you need to print it, or write it to a file or network). So saying list(query) lazily evaluates the query, while saying query.run() is a more strict (explicit) evaluation model.

I actually think strict is better here, but that's a different discussion altogether :)

Reply on news.ycombinator.com