7 ms·

You guys seem to be saying he was wrong on most of them. I strongly disagree. Sure, he didn't nail every one exactly, because he's not psychic, but for all of t

You guys seem to be saying he was wrong on most of them. I strongly disagree. Sure, he didn't nail every one exactly, because he's not psychic, but for all of them, he correctly saw the trend, and he's very in the ballpark. 1. This is happening, just not as quickly as he thought, and with JSON. (XML Databases) 2. If you actually read what he wrote, this is obviously happening. EC2, Github, Heroku. (Open Source Hosting) 3. Using processes instead of threads is absolutely rising in popularity. 4. Off on the timing, but we are in the middle of an explosion of other JVM languages. The JVM has clearly established itself as the best way to launch a new language. 5. Off on the timing, possibly off completely. Clojure is gaining in popularity, which ties in with #4. (Lisp in the Top 10) 6. Facebook. This one was easy. (Community Hangout) 7. He was actually late on this one. iPhone obviously. (Mobile Computing 5 Years Out) 8. Google Apps. (I'll Pay Google) 9. Wrong literally, but if you take out netbooks, which weren't around, Apple sells the large majority of $1000+ laptops, and they obviously sell a ton of iPhones, which are just small computing devices. (Apple Selling Laptops)

j_baker 17y ago
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.
qeorge 17y ago
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.
pvg 17y ago
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'.
- deleted 17y ago
  [deleted]
- yummyfajitas 17y ago
  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.
  - pvg 17y ago
    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'.
    - yummyfajitas 17y ago
      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?
      - deleted 17y ago
        [deleted]
        deleted 17y ago
        [deleted]
      - 17y ago
shin_lao 17y ago
3. Not really. What is rising in popularity is making multi threaded programming easier. I'm thinking about STM and lock free structures.
tjogin 17y ago
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.
- pvg 17y ago
  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.
  - tjogin 17y ago
    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).
    - ErrantX 17y ago
      There are a few people trying [struggling] to make flying cars too! (but I agree with you :))
    - pvg 17y ago
      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.
      - tjogin 17y ago
RyanMcGreal 17y ago
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.
- evgen 17y ago
  So it is essentially XML except for all of the things that make XML any different than csv or some other text-based representation?
  - RyanMcGreal 17y ago
    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).
- neilk 17y ago
  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.
10ren 17y ago
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 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.

j_baker 17y ago

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.

qeorge 17y ago

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.

pvg 17y ago

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'.

deleted 17y ago
[deleted]
yummyfajitas 17y ago
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.
- pvg 17y ago
  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'.
  - yummyfajitas 17y ago
    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?
    - deleted 17y ago
      [deleted]
      - deleted 17y ago
        [deleted]
    - 17y ago

shin_lao 17y ago

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

tjogin 17y ago

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.

pvg 17y ago
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.
- tjogin 17y ago
  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).
  - ErrantX 17y ago
    There are a few people trying [struggling] to make flying cars too! (but I agree with you :))
  - pvg 17y ago
    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.
    - tjogin 17y ago

RyanMcGreal 17y ago

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.

evgen 17y ago
So it is essentially XML except for all of the things that make XML any different than csv or some other text-based representation?
- RyanMcGreal 17y ago
  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).
neilk 17y ago
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.

10ren 17y ago

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 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.