zerothehero

This post is pretty vague. Having heard of Couch a few times over the years but not used it, it would been more helpful if he said something like: "I started a company and forked the open source CouchDB project that I founded. The company and new commercial product is CouchBase and it will be better for these reasons..." And I would be curious about some examples of where the open governance limited the CouchDB project as he's implying.

Those seem to be orthogonal things -- he could have just created a non-Apache open source project rather than making it commercial.

He is beating around the bush so much and using such vague wording that I wonder if he is hiding something, or just ashamed that he's cashing in on his creation. There's no shame in making money and no shame in making a commercial fork of your own project. But the CouchBase website looks awfully "enterprisey" now and I think there is some shame in that...

It's great to see a researcher with such passion and love for his subject. I never knew about Oberon -- my only exposure to this side of the universe was programming Pascal in high school. This was a great read.

I meant actually give code for the exploit.

This is cool, can someone do the same for Python? (And other languages?)

Yeah I fail to understand why a separate interpreter is desirable for this problem. Seems like something for a Python library.

This article is pretty disgusting... I'm surprised that the wall street journal would print what is essentially a big troll.

Is it really? Scaling today means running on more than one machine (google, facebook, twitter, etc.)

That means no shared memory. He helpfully makes this distinction on his front page ("I'm mostly interested in shared-memory system, so if you are looking for information about clusters, web-farms, distributed databases and the like, it's the wrong place")

According to Google's Jeff Dean, "to Google, multi-core computers look like separate servers with really fast interconnections" (i.e. memory).

So if you are running your applications on many machines anyway, you might as well drastically simplify your code by writing it "single-threaded" and running #cores copies on each machine.

Exactly, tons of different technologies are POSSIBLE. But it's a matter of what's economically feasible (what consumers will pay for, etc.)

We could have had Web TV in 1995 if it was really economically feasible... but no on figured out the business model. And it looks like it still hasn't been figured out, although Google is trying again with Google TV.

That said, I think Kurzweil, while grading himself overgenerously, did a pretty good job, and no one else is making these kinds of predictions. I actually did the same thing back in 2009, since I am a Kurzweil fan. It's a little interesting how many things came true in 2010 -- he cheated by a year but it helped him a lot!

Absolutely... have to say Michael Pollan is onto something with "nutritionism". Food isn't a linear combination of nutrients.

> So, the only reason you would now use yacc is parsing speed.

"speed" means a couple different things. Someone might say the only reason you would use C++ rather than Python is speed -- i.e. you can always get within a constant factor with Python. Ignoring other aspects of the languages, let's call that true.

But Russ Cox is saying that you would also use yacc when you want a O() bound on the parsing algorithm (a linear algorithm). That is, the technique they advocate will produce parsers more than a constant factor slower than yacc.

Frankly I don't understand their rebuttal at all. The rebuttal is that it doesn't matter for practical purposes? That doesn't sound like computer science to me.

And practically speaking, it does matter, because plenty of people write exponential time regexps and don't know it, and it will blow up in their face on large input.