Earlier quoted context omitted.
I think he is talking about the actual devices rather than a "market for apps" for these devices.
That doesn't really make a lot of sense. Cell phones existed in 2004. So did "smartphones". Really, the only major difference that you could use the word "market" to describe is the notion of a platform for general-purpose mobile computing, the key part of which is a general market for apps, instead of just baked in features on a phone.
Ten predictions (2004)
251–260 of 324 posts
Re: Ten predictions (2004)
#252Earlier quoted context omitted.
"6. A new internet community-hangout will appear. One that you and I will frequent. This is such a vague prediction does not even worth mentioning." This is one he nailed - Facebook.
I thought of Reddit. People don't really "hang out" on facebook, and it's more about friends and family, not communities.
Re: Ten predictions (2004)
#253Earlier quoted context omitted.
1. JSON has an easy way to specify data types. In XML you have to have multiple nested tags. In JSON my document can be: {"mynumber" : 5, "mylist" : ["one", "two", "three"]} Simple, neat, and fits on one line. In XML this has to be 5 one two three Of course, I don't know what you're talking about "JSON doesn't even have a bloody date or time type" when XML doesn't have anything but strings. In order to parse this, I'…
Your ideas about Java and XML are very dated. JAXB makes it essentially transparent to convert an object to XML and back, and with JAX-RS I can give you a REST API that returns XML or JSON, your pick, for basically no effort on my part. These are part of the Java EE 6 web profile, so basically everybody gets them for free. Most of us don't "install libraries" anymore so much as add four lines to our Maven POMs. Point…
Re: Ten predictions (2004)
#2541. 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.…
Re: Ten predictions (2004)
#2551. 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.…
"6. A new internet community-hangout will appear. One that you and I will frequent. This is such a vague prediction does not even worth mentioning." This is one he nailed - Facebook.
Re: Ten predictions (2004)
#256Earlier 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…
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…
Re: Ten predictions (2004)
#2571. 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.…
> 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…
So how much is it a room-temperature a physical limit, and how much an economic limit?
Re: Ten predictions (2004)
#2581. 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.…
In #2 isn't he describing wordpress.com? You see, wordpress is a open source plataform, but people pay money to have their blogs on it.
Re: Ten predictions (2004)
#2591. 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.…
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. A lot of things server-side are moving back towards multiple processes rather than threading, driven by "cloud" based scaling: if you code is designed to handle being spread over many nodes then why complicate things by having two concurrency models on the go at once (threads…
Concurrent programming isn't all "jump off a cliff into the atomic and mutex lock sea and worry about deadlock or run everything in serial".
There is a middle ground where you take apart the easily discretized parts of your task at hand, that have little or no communication between them, and thread those. For example, if you have a system to scrape a user profile, processing the personal information, hobbies, and pictures in separate threads only requires sending work to threads in a thread pool saying scrape X. That X gets scraped, database calls are asynchronous and work up to the thousands of workers, and you don't even need to wait - pass off the profile, let the threads run and wait for a new connection.
Threaded parallelism only becomes dangerous when you start using shared data. That is where you need to ask if its worth the cost. You shouldn't be afraid of threading entirely just because you can back yourself into deadlock hell if you don't plan ahead.
Re: Ten predictions (2004)
#260Every time I hear that, I always think of "abcd will be the year of the Linux desktop". I want it to happen, but at the same time, I realize how absurd I am being.