"If you don't like it, it must be because you haven't taken the time to understand it" is cognitive poison. What evidence will convince you that someone has understood well enough to judge that something doesn't make sense?
I've spent many years using schemas, and I know well how they work and what they achieve. I'm saying they're a lousy tradeoff.
My primary point was just that SQL is old, and I think the reason it is the way it is has more to do with history and compatibility than what we'd want it to look like if we started from scratch today.
SQL is still around because it was successful. And there are reasons to value compatibility, and to avoid changing things for no reason. But my personal experience using a database without using SQL was pleasant, and I'm anxious to see the world move on to something new and improved.
You're right that I was lumping transactions and data integrity guarantees in with "relational". I was thinking about normalization, and protecting data integrity in ways that lead to joins and transactions.
"They don't exist, if you don't construct SQL queries by concatenating strings and variables."
My point is, people still do this. You never hear about REST-injection or memcached-injection attacks, even though those are possible in principle, because those protocols don't encourage this mistake the way using SQL as a database API does.
We keep things we might need to search in regular columns (typically with indexes). The JSON object is just a way to add extra data to rows, which we can fetch and deal with on the app side. That works fine for a lot of things, and we're hoping it will give us some flexibility around when we need to do schema migrations in some cases.
A number of us know MySQL fairly well, and in particular I've seen how it's used by some of the biggest internet companies. We have some postgres experience on our team as well, but it's a little more of an unknown. So experience trumped feature set in this case.
One thing I would say about postgres is that it has a lot of features. As a new user, it's hard to know which ones to use in which ways, and what the downsides might be.
I'm one of the authors of a Python framework called monocle for doing async programming in this style. It works with twisted and tornado. http://github.com/saucelabs/monocle
I'm not sure I understand your concern here. How does monocle make decomposing logic into functions difficult?
The "yield" keyword is an indicator of where control is returned back up to the event loop and other things can happen. We like that in monocle, because we view it as dangerous; in thread-and-lock terms, it's sort of like "unlock everything".
Eventlet (http://eventlet.net/) is an example of a similar framework that decided not to require "yield" at these points.
Well, monocle is headed in its own direction. We're abstracting the generator-style concurrency stuff out from the underlying I/O framework, so monocle works with both Twisted and Tornado, and we're prepared to interoperate with other frameworks in the future. On top of that base, we're developing a framework for working in this style; there are some early ideas in monocle.experimental. We're also building simplified base networking APIs in a way that only makes sense if you're committed to this style of concurrency.
I think the question is really whether you're more compelled by generator-style concurrency, or Twisted itself. If you want to work deeply with Twisted, inlineCallbacks lets you use generator-style where you want, and is maintained along with Twisted. If you want to use generator-style concurrency to its full advantage in simplifying complex evented servers, that's where monocle is going.
I don't think it's very credible to hold Perl 6 up as the standard for how to encourage and enable complete implementations, considering that ten years in, it still has only partial implementations.
Yeah, we know our front page is lousy right now; we've got a redesign and a much clearer explanation in the works.
You need our service to make sure your web apps work in all the popular browsers.
We've got a bunch of web browsers in the cloud which you can remote-control via and API, to make sure the features of your site work cross-browser. We use a popular open source browser automation tool called Selenium, which my cofounder Jason Huggins created.
I'm curious whether the above description makes sense, or still leaves you scratching your head!
The JVM is threaded, and threads will require a little bit of (careful!) work for the codepad security sandbox to support. I haven't had time for that project yet.
That's me. Sauce Labs has indeed been keeping me ridiculously busy. But codepad is my favorite side-project, and I don't mean to neglect it. I'll find a free weekend and update interpreter versions once things are less crazy here!