All of the ReQL examples are completely unreadable relative to SQL.
Call it declarative, format it however you want - a purpose-built DSL like SQL is always going to be easier to grok than a Javascript-inspired functional language (for me at least).
Call it declarative, format it however you want - a purpose-built DSL like SQL is always going to be easier to grok than a Javascript-inspired functional language (for me at least).
See, for instance, http://rethinkdb.com/api/python/
(You can easily translate most doc pages to the language of your choice using the links at the top of each page.
However, I am imagining a contest where SQL people write SQL and functional people write functional queries... I would bet money that SQL people could identify basic facts about SQL queries faster than functional people could identify the same facts about functional queries.
Could be a fun programming game.
Because SQL is very familiar and ReQL is not.
r.table('users').filter(r.row('age').gt(30))We did the best we could with JavaScript. IMO the Ruby implementation of ReQL is dramatically more beautiful. Ruby's blocks fit so well that we don't even provide the `r.row` shortcut in ruby:
r.table('users').filter{|row| row['age'] > 30} r.table('users').filter(row => row('age').gt(30))If you python you use python's native constucts, which if you use python you're naturally familiar with.
r.table('users').filter(r.row['age'] > 30)I don't actually agree with this, but one solution to this would be -- as Google has done with several of its not-traditional-db storage products -- to build a library that takes strings in an SQL-like language (SQL with additions/deletions to align with RethinkDB's features and capabilities) and builds ReQL objects from them. But, while it might have utility, its probably not as high a priority for the RethinkDB team as getting the core features right.
My be an interesting third-party add-on, though.