njm

By being made more dense the Earth would shrink, so it is very reasonable to promote the Moon to planethood according to that definition.

I would suspect the poster has already weighed the cost vs. benefit of writing efficient code. Many domains do require careful attention to performance.

This is exactly what I've been looking for! Thank you.

For most American dialects, the sounds are nearly identical, but not quite: at the beginning of a syllable, the "r" is an approximant (a type of consonant that starts with an emphasized vowel sound), rather like "y" or "w", whereas at the end it is a true vowel, again like "ee" or "oo" respectively.

It's not as much data as one might think, especially if you store the deltas -- there's not that much variation between individuals. That fact has actually been exploited to a great extent in enabling the $1,000 genome.

One can easily estimate the cost of a query in a relational database via EXPLAIN.

What relational databases do is decouple such implementation details from semantics, enabling higher levels of abstraction and therefore reasoning. Similarly, I'm happy to abstract the low-levels details of dictionaries in Python and not code my own hash table from scratch, or to use a compiler and not write assembly language. And while there are inevitable corner cases where hand-coded logic will outperform what a system can guess, handicapping yourself for a few extra cycles is something routinely (and rightly) derided in most programming circles.

Nobody debates that NoSQL systems are great for hand-tuning corner cases like these. It's the idea that they are a viable alternative to the relational model that is so objectionable, as it's a step backwards in abstraction.

Sure, I suppose it matters a lot on the type of Web application you're building. If you have a relatively simple domain model with very few relationships, I'm sure a KVS works pretty well. Still, for anything other than applications with simple domain models, or ones that need tremendous performance, a KVS is inappropriate outside of isolated optimization -- in practice, one runs into headaches with non-normalized data very quickly (think MBAs and their giant, messy Excel spreadsheet).

What bothers me most about the NoSQL movement is that it seems to be in conflict with a central tenet of our community: to avoid premature optimization, especially when at the expense of of expressiveness or correctness.

While normalized relational databases are indeed slower than key/value stores, they also foster data integrity and the ability to compose arbitrarily complex queries with little effort (assuming one actually groks SQL). One can always optimize trouble spots in a relational database later on (possible even with a KVS), but using a KVS from the get-go is bound to lead to pain.

If we happily use Ruby, Python, et al. while chanting the mantra of premature optimization being bad (and rightly so!), why does this not apply also to databases?

Not just uninformative, but misleading too: there are many relational query languages besides SQL (e.g. Tutorial D). Is the conference about non-relational database technologies, or any alternative to SQL?

Am I missing something here? If a microgram is 10^-6 gram and a kilogram is 10^3 grams...

This is generally the case across the physical and life sciences too. Even "revolutionary" fields like epigenetics and genomics are effectively refinements and extensions of the pioneering work done in molecular biology during the 1960s and 70s. The same goes for particle physics, where the framework for the standard model is decades old. It seems that scientific innovation occurs in punctuated equilibria.

My rule of thumb: I only import things locally (i.e. within a function) if it is a conditional dependency. This is particularly true if it's something not from the standard library. Example: I might have an application that supports multiple database back ends, such as PostgreSQL, SQLite, etc, but I'll conditionally import only the one applicable DB API module.

eru nailed it. We lived off bulk everything -- oatmeal, rice, beans. For fresh food, we got cheap veggies with lots of nutrition; greens tend to be the best bang for the buck, but also bags of carrots, beets, and such. For protein, it was all about tofu, eggs, milk, yogurt and nuts (mostly peanuts, soy nuts or pepitas, which are much cheaper than tree nuts). For beverages, bulk tea is absolutely the way to go, at just a few cents per cup.

Food prices have really shot up since 2006 though; in particular, bulk beans have almost doubled. Still, I think it would be possible to eat the same diet today for around $35/week for a couple.

Why on earth aren't beans subsidized instead of corn? Among other things, this would cut down immensely on the amount of fertilizer consumed per year.

While this is true in general, it is still possible to eat a balanced, healthy diet for very little money. That said, it requires a lot of discipline and a somewhat sophisticated understanding of nutrition. Still, my wife and I managed to get by on $20-30/week for combined groceries for about a year (we're in AZ, and being vegetarian helps keep costs down), but still managed to eat well.

It's not that SQL queries are difficult to compose, it's that ORMs enable different abstractions to emerge, at least when used appropriately; I'll admit though that junior developers are drawn most to ORMs because they limit exposure to SQL. I'd recommend you check out a legitimate ORM that implements the Data Mapper family of design patterns such as SQLAlchemy or Hibernate.

(Incidentally, DataMapper in Ruby doesn't in fact implement the Data Mapper pattern, which I find irritating.)

I personally advocate a two-pronged approach, where DOM manipulation is done via jQuery (at which it excels), but abstractions are built up via classes (pick your favorite implementation). This avoids overextending either paradigm.

It seems to me (an avid jQuery user, no less) that people are stretching the paradigm too far. There are places where traditional, class-like abstractions are perfectly legitimate, and indeed more natural. Some of the more elaborate applications of jQuery, such as jQuery UI, come across as smelly to me -- sometimes plain old classes and objects are nice.

Pumpkin seeds are mentioned, but pumpkins themselves are fantastic as well -- they make for some really great soups.

Also, I'm certainly not one to knock coffee, but tea is much better in terms of bang for the buck. I buy loose-leaf jasmine tea from an Asian grocery store, and get a month worth of tasty drinks for less than two bucks. It's healthier than coffee to boot.

Quick question, if you'll indulge: where do you find those CDS numbers you mentioned?

I'd actually argue the best approach is to develop both sides fully: I agree that an OO data model is the best fit for non-trivial application logic, but I also believe relational databases make the best data stores. The two can coexist just fine, it's just a matter of selecting the proper design patterns and supporting libraries -- which is why I mentioned SQLAlchemy. In its developer's words:

"SQL databases behave less like object collections the more size and performance start to matter; object collections behave less like tables and rows the more abstraction starts to matter."

This false dichotomy that's always presented is distracting, and leads to people naively taking religious positions about what should in fact be a non-issue.

Would you argue that the ability to form ad hoc queries for answering questions not originally imagined when writing an application fails to make the relational model superior to something without that property?

(I see you develop with Rails though, so probably yes.)

Sigh. There is so much misinformation being spread by today's software engineers without proper CS backgrounds. As anybody who's read Date and friends knows, relational databases are fundamentally more expressive (and therefore better) than network databases (which is the model used by object databases), being grounded in set theory and predicate calculus.

Your bad taste for relational databases is more likely a result of using a crappy ORM pattern (such as Active Record). Go try a proper implementation of Data Mapper (I can't recommend SQLAlchemy highly enough), then come back and tell me how you feel.

Please, go back to reddit.