In summary, he nailed it as far as where the the wind is blowing but was wrong on timing; on all accounts except the last one. This is no bad feat as nailing both the direction and timing is nearly impossible.

Compare with, for instance, Bill Gates, who has been claiming that speech recognition as a primary means to control computers is just five years away, for over twenty-five years now.

Sorry, but there's a saying in investing: "Right but early is wrong. Right but late is wrong."

Any fool can make a very long list of predictions that will all turn out to be correct, even in the stock market, as long as he doesn't have to give them a timeline. Plenty of people saw the housing crash, for example, and plenty of them understood that certain banks were underwater, and regardless of their actions, they were going to go under. However, just knowing that isn't actually worth anything -- a short position carries a heavy premium in interest, and in the famous words of Keynes: "The markets can remain irrational longer than you can remain solvent."

In your 'sayings' early and late are ambiguous. As far as investing is concerned being right in a prediction means you profited, so the early-late error bar is defined by the time in which you could profit by your prediction. Applying this same rationale here the early-late error bar is harder to define, since profit is not clear and somewhat subjective. So taking some liberties with early-late and right-wrong is I feel appropriate.

Taking into consideration that these predictions are 5+ years old I think they are pretty good. He clearly spotted several trends whose future significance was at the time not obvious. If someone started a business believing one of these trends had promise it is possible that the business would have been successful. I do feel that for what he was trying to accomplish being early or late by a couple of years or off on a detail but correct in spirit is not significant.

Also, I think it is important to add that making predictions like these is very important becuase the future develops from our perceptions of what it will be.

Security prices have two basic outcomes: "up" and "down." Usually they fluctuate, so almost any call will "eventually" be proven correct. Sporting events are also mostly binary outcomes, so "the Cubs will reach the World Series" will probably be right if given 200 years.

But with technology predictions, there's an almost infinite set of outcomes, so being right in direction but not timing is significant. For instance, someone who says "Little Rock, Arkansas will win the Super Bowl within 5 years" will look pretty smart even if it takes 6 years for Little Rock to (very unexpectedly) get an NFL franchise and 9 years to reach the Super Bowl.

Granted, technology predictors can use also use some tricks to narrow the possibility space in their favor.

Hey, hey, speech recognition is really here. In fact, I ham dict eating too the come pewter write now.

I launched Dragon Naturally Speaking and said, "I ham dict eating too the come pewter write now", which it transcribed as "I am dictating to the computer right now."

It's like an automatic mondegreen generator.

He nailed it but was wrong on timing? That's like really nailing it on flying cars and the return of the Messiah. Maybe in a few centuries we'll be reaping the benefits of XML databases and salute Steve Yegge's prophetic vision. Come on.

Flying cars are nowhere to be seen, neither is the return of messiah.

The point is that Steve's predictions are actually observable, though some of them are advancing at a slower pace than he thought (and a tiny bit different, like JSON instead of XML, which IMHO is irrelevant).

They are 'observable' if you bend your critical faculties to a point where small airplanes are flying cars and the Messiah is your favourite politician. Most of Steve's predictions are nonsense. Most predictions are, so it's hardly Steve's fault. But going through great logical contortions to defend some predictions the guy was either brave or foolish enough to commit to paper in 2004? I'll say again, come on.

Small airplanes already existed in 2004, and politician and son-of-god is quite a bit different than XML and JSON which are basically interchangeable serialization formats for the purposes they are both used.

Remind me again what that has to do with the point at hand, please.

There are a few people trying [struggling] to make flying cars too!

(but I agree with you :))

He's still wrong on most of them, whether you strongly disagree or not.

1. This one is so mushy, it's wrong just because of it. Substituting your favourite representation format (JSON instead of XML) doesn't make it any better or really anything to do with databases.

2. It's happening if you think EC2, Github and Heroku are somehow comparable. Also which one of these is making 'a lot of money' as predicted?

3. Your response doesn't actually address the prediction. Also, Clojure, Erlang, blah blah.

4. Just hasn't happened.

5. See above.

6. And Twitter and 'a new internet community hangout will appear' in 5 years is the most solid bet you can make on the internet.

7. It happened to be 5 years out or under. Oh well.

8. Nobody, statistically, pays Google for anything. Other than adwords.

9. Straight out wrong.

I think that easily qualifies for 'wrong on most of them'.

Regarding 1:

* XML is the most popular vehicle for representing loosely-structured, heirarchical data. Relational databases can't do this very well. ...XML can be mapped straightforwardly to the objects and data structures of modern programming languages, so it works better than relational modeling for serializing things like object graphs.*

While his estimate of market share is off (he suggested >50%), he was right about the future popularity of document databases. The only thing he got wrong was the specific serialization format.

So he was wrong on the market share, the format, and the everything else. I think that's still a solid 'completely wrong'. He is, of course, right, about every single thing you choose to read into the statements that he doesn't actually make. I don't see him predicting the 'future popularity of document databases'.

From his article: Many common types of data are intrinsically heirarchical and loosely structured, so storing them in an RDBMS can be difficult. Examples: books, articles, and most other written documentation. HTML. Search indexes. Filesystems. Game worlds. Classical music scores. It's just easier to model some things this way.

I don't see how to interpret this as anything other than a document database. Could you explain to me?

Sure. Let's take another look at the article -

"Prediction #1: XML databases will surpass relational databases in popularity by 2011."

It's still completely wrong. I don't see how to interpret it as anything other than wrong. Yes we can sift carefully through it to find some way in which it's kind of, maybe right, sort of. We're discussing Steve Yegge's actual predictions not whether filesystems or the Library of Congress are really a special case of document databases.

You are arguing syntax, I'm arguing semantics. {"foo" : 25, "bar" : 32} is just not significantly different from <foo>25</foo><bar>32</bar> in my view (and I imagine in his view as well).

I think we should just agree to disagree on this one.

Its kind of like astrology - they are almost all right if you want them to be right.

In fact, he was the first to point out that most of them were wrong. But he did get the general concept right in most cases.

re: 1. "JSON databases" are starting to displace Relational Databases?

Your terms - json databases - do not have enough search volume to show graphs. http://www.google.com.au/trends?q=json+databases

OODB were all the rage a decade or two ago, and they solved the O/R impedance mismatch - but they didn't become mainstream. What has changed, that will make "JSON databases" succeed?

EDIT Actually, hierarchical databases were popular before Relational DB were invented, and then everyone switched. Why? Normalization of RDB is said to be important, but it seems little used in practice. It seems more a selling point, but it usually takes more than a good pitch to motivate deep organizational change (maybe it was different in those early days, when new installations quickly outnumbered old ones?)

It is because databases often outlive the application that created them. They also often serve more than one application, for more than one purpose (e.g. operations vs. business intelligence). For this, you need a data representation that is in terms of the data itself rather than the use. The problem with data structures in a programming language, such as objects is that they are designed in terms of their use; a data representation is chosen that makes sense for what you want to do with the data.

The O/R impedance mismatch is not just between "media" (objects vs. tables), but also between the specific representations chosen within that media. If you store your objects directly in a DB, your data is closely coupled to your use; the same problem occurs with OR mappers. I surmise that the advantage of relational over hierarchical databases was that they could better represent the data in terms of itself.

JSON databases will have the same problem - the data representation will be designed in terms the application that generated them, and this close-coupling will make it difficult to interoperate with a later application, and with other applications, with other purposes. The data representation will not be designed in terms of itself.

Re #2, I don't think its fair to count EC2, Github, or Heroku, unless you're also counting any shared hosting that lets you run PHP.

I think what Steve was referring to was people paying for hosted versions of specific pieces of open source software, e.g., a hosted version of SugarCRM, not the ability to run open source software in general.

It was still prescient though, because we're starting to see that. For instance, you can do this with Azure + SugarCRM.

It's important to note here that JSON is essentially XML without the boilerplate - and in fact was invented at least partly to address this very XML pain point.

Absolutely not.

XML has its roots in document creation for large organizations, and has a structure appropriate for that -- mostly an ordered graph of text nodes, which do not need to be declared (and indeed are not consistent between parsers), with provision for special node types with their own contents. But early in its history XML got hijacked by a lot of comp-sci theorists who wanted to create highly abstract notions of messaging, separating message validity and provenance from application logic. This gave the world things like XML Schemas and SOAP and worse.

Meanwhile, JSON is a straight representation of common scripting language data structures. Arrays, dictionaries. Simple. Node boundaries are syntactically explicit. In this philosophy is taken for granted that message validity will be ascertained at the application level. There are no fantasies of doing so at the document parsing level.

So it is essentially XML except for all of the things that make XML any different than csv or some other text-based representation?

I don't think your comparison is fair. CSV has only one structure (tabular data) and only one datatype (string). JSON supports multiple datatypes and data structures (objects, lists, hash tables).

3. Not really. What is rising in popularity is making multi threaded programming easier. I'm thinking about STM and lock free structures.