I really like CouchDB. It is wonderful if you want that kind of DB. However, if you want a relational DB (and there are many, many, many reasons to want one), do not pick CouchDB. It works very poorly as a relational DB.
I have a legacy project that didn't quite understand this point and we have ended up paying the price for a document oriented DB in which it is hard to migrate and where we are constantly having to worry about the bandwidth to the view server. And then all the amazing, wonderful features of couch? We don't use a single one :-P Fail all the way around. However, I still like it and instead of retiring it, I've been slowly trying to start using the features that make it awesome, while mitigating some of the problems that have piled up over the years.
The problem I had with CouchDB is integrating it into a framework like Rails. CouchDB on its own does so much cool stuff. The "free" HTTP API and client replication via PouchDB are the two huge ones. But it just wasn't smooth enough to get the data out, use it where I wanted, and then save it back.
But after that, it was very nice.
I just remember that (possessive) pronouns don't have apostrophes. "My", "your", "his", "her", "their", and "our" don't have apostrophes, so why would "its"?
Meanwhile, contractions do have apostrophes. "Haven't", "should've", "that's", "you're", and "I'll" have apostrophes, so "it's" (meaning "it is" or "it has") should too.
I've been thinking about this and, I think having a "grammar patrol" that had the ability to alter other people's comments for grammar on a site like HN or Reddit might be useful. Maybe. Of course there is potential for abuse. So you'd need a second group of people at the very least, who were given the ability to vote on the edits themselves as good or bad.
This second group would be the most difficult to establish and maintain at scale I think. Because whereas you could in theory allow anyone to volunteer as grammar patrol, you'd need to have a trusted group of people for group two. Otherwise, a group of trolls could sign up for both groups and make bad edits and then approve them.
At the end of the day it would probably require a lot more effort than what it's worth. Grammar mistakes are a bit of an eyesore but at the end of the day they usually aren't the end of the world.
Also, language is ever-evolving. So if in 50 years 80% of the population is consistently making a common set of grammar mistakes then that just means that the way to spell those words has changed.
In order to prevent people from abusing it as another way to get their reply seen by everyone, you could make it a private communication between the comment author and the user giving feedback. Or make it possible for other users to see it, but make it hidden by default.
That way, if the author wants to correct their comment, they can, but nobody else has to see the clutter.
I am sleep deprived. I hope my idea comes across properly. It sounds good to me right now, might not sound good tomorrow. :P It is definitely complicated though and not sure it is worth the effort to implement and maintain.
Maybe... just maybe memes could be the key to AI /s
Spelling checkers which cannot read do not help. here and hear are both legal in the sentence parse in some ways, so cannot be detected as the wrong form without a higher semantic model. Few systems have this. Therefore, many small mistakes can creep through, apart from the ones I mis-type the system may itself be making them, in ways which our own spellchecking brain do not pick up. Here what I say, Hear what I say...
While it's missing some popularity from MongoDB and having wide adoption of things like mongoose in lots of open source CMS-type projects, it wins for the (i believe) unique take on map / reduce and writing custom javascript view functions that run on every document, letting you really customize the way you can query slice and access parts of your data...
Example: I'm building a document analysis app that does topic + keyword frequency vectorization of a corpus of documents, only a few thousand for now.
I end up with a bunch of documents that have "text": "here is my document text..." and "vector": [ array of floating point values ...].
What I can do with couchdb is store that 20d vector and emit integers of it as a query key:
Then I can match an input document's vector (calculated the same as corpus documents), calculate a 'range' of those vectors, pass it as start and end keys, and super quickly get a result from the database of 'here are documents that have vectors similar to your input'...Super fun, quick and flexible to work with!