Earlier quoted context omitted.
They are becoming popular but there is no way they surpass relational databases in use.
That brings up an interesting question of where the line of what is a database gets drawn. Does a JSON interface to a CRUD application that uses a relational database behind the scenes count as a JSON database? A part of me thinks it should. CouchDB positioned itself with a JSON API that allowed you to skip the CRUD middleware, so from the API consuming point of view there is essentially no difference.
Ten predictions (2004)
261–270 of 324 posts
Re: Ten predictions (2004)
#262This is a pretty incredible list of predictions. I'm not just impressed at how 'correct' some are, but also that these predictions turned out to be so important to the tech industry. It's interesting how everyone has a different take on #2. When I read it, I thought of Heroku and I think that's pretty close. With the git integration many people do `git push github && git push heroku` which is pretty cool. As fir #10,…
I think github.com is the best example of #2.
Re: Ten predictions (2004)
#263(General response to a trend in the comments.) I believe #2 refers to things like Wordpress.com or CloudFoundry.com. Wikipedia.org might qualify as well. If Discourse.org offers hosted instances, (and they make a lot of revenue), they could qualify too. As far as I know, GitHub never opened their source.
Yes, but GitHub makes a lot of money by hosting something that is open-source: git.
Re: Ten predictions (2004)
#264Earlier quoted context omitted.
XML has a few issues compared to JSON: * attributes v. tagnames * no "anonymous list" * infinitely large surface area [ {name: joe, age: 12 }, {name: bob, age: 23} ] joe 12 bob 23 The access pattern for json is much easier: obj[1].name The infinitely large surface area of XML is painful. Namespaces, entities, xsd/schema, cdata, cdata-in-cdata. It's an alright data / interchange format and especially suited to certain…
What about bob?
Re: Ten predictions (2004)
#265Earlier quoted context omitted.
> 3. Multi-threaded programming will fall out of favor by 2012. Not really. We are already in the multicore age, and it will only get moreticore. What that prediction missed was that Moore's Law finally broke down for single-threaded performance. Single cores got only about 3x faster from 2004 to today, rather than continuing the historical trend with four more doublings. Moore's Law is alive and well but now require…
Here's a 6.6Ghz overclock: http://www.custompcreview.com/news/intel-core-i7-3770k-overc... with liquid Nitrogen cooling. So how much is it a room-temperature a physical limit, and how much an economic limit?
We're not that far from the speed of light barrier. There's a fixed amount of time it takes for any information to get from one end of a chip to the other and back. Only shrinking the die will decrease that.
Re: Ten predictions (2004)
#2661. XML databases will surpass relational databases in popularity by 2011. We got NoSQL (esp. JSON based ones) instead of XML. Close enough though. 2. Someone will make a lot of money by hosting open-source web applications. Github is cool but with all the cheapskate web devs (no offense, I am one of them) I don't think it is _that_ profitable. 3. Multi-threaded programming will fall out of favor by 2012. Not really.…
> We got NoSQL (esp. JSON based ones) instead of XML. Close enough though.
NoSQL still stores tables, not trees (or at least the NoSQLs I've paid attention to do). That's the change he was predicting. You still need a tabular schema for your NoSQL database.
Re: Ten predictions (2004)
#267Earlier quoted context omitted.
JSON is basically XML with 50% less bullshit. I don't get this. XML has the capacity of being as simple as you want it to be. You don't need schemas, namespaces, xpath, and so on, and can make your XML life every bit as easy as JSON. In many ways easier given that JSON doesn't even have a bloody date or time type. But if you do want strong-type validation, schemas and namespaces are there for you. If you want an easy…
I don't understand the complant that JSON doesn't support a date/time format. It supports numbers and strings. You can use unix timestamps, you can use ISO 8601, you can use any format that makes sense for your application. JSON doesn't support a Date/Time object because it's a data format. XML doesn't support a Date/Time object either. Now if you want to complain that the JSON parsers don't automatically convert ISO…
Right, but xml "objects" are annotated with some name, whereas json nodes aren't. This is a hassle, but it's also very convenient when you want to represent something that doesn't map 100% perfectly onto the underlying structure. So as you say, you _could_ represent a date in lots of different ways. In xml that's doable, and somewhat comprehensible. In JSON it's usually jibberish. And that's just dates - good luck with anything more complex.
I still think JSON is a more promising format in the long run. But it certainly isn't great - it's just bad in a different way, and somewhat more minimalist (which is good).
Also, I can't for the life of me understand why someone would dislike xpath. It's like the one best thing about xml - it's simple, concise, and easy to read. I'd absolutely love an xpath equivalent for json, which just doesn't exist.
Just expressing obvious things like "person[name='bla']/nickname" is so much more wordy in an explicit function style. And notice how the rest of the world - including most major js(on) libs have long gravitated towards that (monadic) style of querying - it's not just me, almost everyone prefers it. CSS; SQL; jquery selectors; even a filesystem glob - every complex datastore gravitates to some variant of the same pattern, and it's something json consuming libs do not yet do very well. I'm sure they will someday - but it's a real lack right now.
Re: Ten predictions (2004)
#268Earlier quoted context omitted.
3: He explicitly mentions message passing and multi-process as opposed to multi-threaded, and that's dead on right. F#, Clojure, Scala, Erlang and Node are all approaches to concurrency that doesn't involve the developer dealing with threads.
+1. I thought that prediction was the most impressive one on the list.
me too :-).
Re: Ten predictions (2004)
#2691. XML databases will surpass relational databases in popularity by 2011. We got NoSQL (esp. JSON based ones) instead of XML. Close enough though. 2. Someone will make a lot of money by hosting open-source web applications. Github is cool but with all the cheapskate web devs (no offense, I am one of them) I don't think it is _that_ profitable. 3. Multi-threaded programming will fall out of favor by 2012. Not really.…
> We got NoSQL (esp. JSON based ones) instead of XML. Close enough though. NoSQL still stores tables, not trees (or at least the NoSQLs I've paid attention to do). That's the change he was predicting. You still need a tabular schema for your NoSQL database.
Hmmm - not really. You're storing complex object(or document or xml or json). In other words, you're not using the db schema to destructure your model, but just using it to get at the bits you want.
It's close enough in essence.
Re: Ten predictions (2004)
#270Earlier quoted context omitted.
Out of interest, how does an enterprise developer (whatever that means) ensure consistency of data and good performance, the two competing aims of a decent mutex/lock strategy? Is it taken on trust that someone else handles this, and therefore hidden in 'safe' data structures or... ?
One place you see a lot of good "under the covers" stuff going on is with .Net 4.5. The task parallel stuff they have is really decent. You still have to think a little bit about concurrency issues, but if you are careful to use their thread safe structures, they have taken care of a lot of the harder parts for you. It is a neat model that just plays out pretty nicely. Another cool product is Disruptor - they have fi…
If threads or processes or distributed computing is being used under the covers, does it still count as multi-threaded programming? I could go out and design an machine/OS that didn't use what we would think of threads (think Atari's Transputer [1]), and all these implicit threaded schemes would still work with my new construct. Now, we might not have transputers, but some of us get to use GPUs and such (still niche, but growing), where the unit of parallelism no longer resembles a thread very much.
My point was that multi-threaded programming hasn't taken off because it hasn't needed to. We just get some really smart experienced guys to write our infrastructure that encapsulates thread use and all of us get to reuse that.