While Whole Foods does sell a lot of homeopathy items, that is *hardly* its entire character as a store. I, along with no doubt many others, go there because it's a specialty grocery store that has a lot of interesting foods that you can't find other places, including (and especially) a big variety of craft beers and vegetarian stuff. Their produce and bulk sections are also hard to beat for variety and freshness, and the prepared-foods section is great when you're on your way home and don't feel like cooking.

I'm no Whole Foods shill, and it does have its share of silliness. But comparing it to the Creation Museum is completely ridiculous and has no place in serious discourse.

Ray Kurzweil is no doubt a brilliant thinker and an engaging writer/futurist - I've read some of his books (admittedly, not "Singularity"), and they are fun and thought-provoking. However, disciplined and realistic they are not - his main skill is in firing our imaginations rather than providing realistic interpretations of the evolution of technology.

My favorite case in point is his elevation of Moore's Law into a sort of grand unified theory of computing for all time, and using some very dubious assumptions to arrive at the idea that we'll all have merged with machines into immortal super-beings within the near to mid future. I don't need to pick apart all the reasons why this is fallacious and somewhat silly to treat as a near-term likelihood - the point is, he's basically a sci-fi writer in a lot of ways, and I read most of his statements in the same spirit as I'd read a passage out of "Snow Crash."

That said, Google has some very capable people, and can, in all likelihood, mount our best attempt at human-like intelligence to date. They'll push the envelope, and may make some good progress in working through all the challenges involved, although the notion that they'll create anything truly "human-like" is laughable in the near term.

Amen to that. Their (remotely reasonable) use is probably limited to maintaining legacy systems from back when people thought the database should rule the application stack, and an "app server" meant Perl scripts in the cgi-bin folder.

Clearly, one-time structural updates during system upgrades are a different ballgame. The pattern described is for ongoing use in deployed production code, and my assertion is limited to that context.

For upgrading Hibernate-based systems (or any other O/R-based system), I'd totally agree that short SQL scripts are in many cases the only reasonably performant solution.

As an aside, I don't really like "classical" O/R (meaning, every field is a column and object relations are explicitly embodied in the DB layer) either because it is so brittle. It lacks any ability to "soft-upgrade" the data because the code is so rigidly tied to the DDL that you're forced to write tons of SQL or other migration scripts for every system upgrade. This, in turn, drags the deployment process into an hours-long affair and sharply discourages frequent upgrades. Despite being no fan of Agile overall, I have found that frequent, granular upgrades are usually better than months-long waterfall cycles, which I feel that classical O/R tends to promote.

That's certainly valid that proper organization is far more the key to good code than the use of any language - my comments should not be taken as an ad for Java or any other specific technology.

That said, certain language features lend themselves to good organization much better than others. Where SQL faces challenges is that (1) it's mostly a declarative language using set calculus, which (again, in my opinion) makes it ill-suited for non-trivial business logic, (2) because of the aforementioned, it can't be hooked up to a debugger in any normal sense, making maintenance and troubleshooting that much harder, (3) it's a separate "codebase" and technical competency than the "main" codebase (whether it's in Java, C#, Ruby or whatever), thus creating a competency barrier that must be crossed every time work needs to be done on that code, (4) it's not stored with the main codebase, but as a form of data, raising the issue of out-of-sync deployments with the app servers, and (5) far fewer developers know it well enough for complex uses than typical app-server languages, making staffing difficult.

Finally, I have personally always found large codebases much more manageable when written in a statically typed language (which SQL is obviously not). Not wanting to spark a flame war with Ruby or PHP fans, though, I will caveat my statement that those languages are also much better suited for business logic than SQL's declarative style is.

As background, I am the director of engineering in a small Java/Postgres-based shop. We run a cloud backend for our mobile apps.

This "methodology" reads from the first sentence like an extended infomercial for a consulting shop, or a company trying to create the aura of "thought leadership" to get more investment cash. The formula is simple and time-honored: (1) arbitrarily single out a well-worn software practice to receive a snappy marketing name and be held above all other practices, (2) claim it's new, and (3) offer to implement this bleeding-edge buzzword to clueless executives. For a small fee, of course. It's the same formula that gave us Agile.

In my opinion, what they've described here is a large step *backward.* Not only is this a relatively trivial use of the GoF Observer pattern, but bizarrely, it's done in SQL using triggers, causing immediate database vendor lock-in and creating a maintainability nightmare. It's how software was made back in the 90s when Enterprise SQL database vendors ruled the land. Sprinkling business logic around in the SQL instead of centralizing it in a much more suitable language for logic like Java is a completely terrible idea, unless you're an Oracle sales rep.

This one is safely ignored.

...that we shouldn't want things like identities, families, and lives. It is a joy for us to be interchangeable work-bots. Dissention must be expunged so that we can be assimilated. Obedience is happiness!

Ninja Gaiden 1 or 2 would have been a very different conversation. The way I see it, the Aussies found a way to rack up a symbolic victory to look good to hyper-sensitive parents without actually hamstringing a blockbuster game.

I haven't seen one in a long time. My boss tells me that 7000 man-years isn't anything he shouldn't expect in a good, hard 3-day push.

Focus, focus, focus on getting that product out the door; that alone will take everything you've got. Open-sourcing involves managing a team of people who are distributed in geography and in time zones, and may not care about the mission of your business. It's way more headache than you need right now; I'd definitely not try to add that to your already-full plate.

Open-sourcing isn't really a marketing tool. Once you have a harem of happy customers, they will provide all the buzz you need, and then if you're profitable, you might have some breathing room to think about helping society.

The single biggest line item on my (and probably many people's) productivity costs is interruptions of the form, "hey, I need to answer a question that takes more than a goldfish brain's worth of thought. I'd like you to do that thinking for me."

The second would be, "As my work product, I took a big dump into our codebase. Given that I don't care about anything but going home at 5, and none of our leadership understands what I did anyway, especially since I have two monitors and therefore look smart, why don't you clean it up for me if you are interested in finishing your own work?"

I'd settle for just dumping some dead weight instead of any new technology. Really.