Thank god we dodged that bullet. I'm just glad people see XML for what it really is (useful, but not that useful).
> Not really. We are already in the multicore age, and it will only get moreticore.
The problem is multi-threaded has never really took off, even with all the cores we have today. There is still no silverbullet to harnessing parallelism.
> Apple's laptop sales will exceed those of HP/Compaq, IBM, Dell and Gateway combined by 2010. No way, thanks God.
Apple's profits on laptop sales (not other iOS devices) exceed those of HP, Lenovo, and Dell (everyone else being dead). Apple has been in no hurry to capture the unit shipped crown (and if we count iPads, they are already there).
> In five years' time, most programmers will still be average.
A tautology if I ever heard one.
MMmmm..... yeah it has. I'll agree on the silver bullet, but I don't think they need one.
Threads are all over the place, and easier than ever to use. They do require intelligence to use well, and people to think about things like locking strategies, but they really are not all that hard. It amazes me that people seem to be so scared of them for some reason.
Perhaps it's the problem domain I work in (back-end server systems) but I come across them all the time. When dealing with lots of distinct tasks for lots of distinct clients you can make good use of threads without needing to do the kind of hard-core mathematical analysis that you would apply to splitting single tasks across parallel systems.
(And no, I'm not suggesting that a one-thread-per-client model is a silver bullet, there are more efficient async ways of doing things)
Another cool product is Disruptor - they have figured out a good, fast way to do message passing that minimizes the need for concurrent data structures between worker threads. (Provided of course you can model your app in that way). Under the hood, they have some crazy dep memory barrier based stuff, but for most of the programmers on a team, thinking about that stuff is just not needed. (as an aside, I think if Beautiful Code 2 was being written, I think Disruptor should be included, that source code is downright inspiring.)
The point being, once you have a good, trusted and vetted set of primitives, and are willing to put a little effort into working in a paradigm someone else sets, you get a lot of benefit. This is no different than using RoR or Django instead of rolling your own web framework.
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.
I really don't get on with this mindset that someone else can fix it.
In fact, using any thread or concurrency mechanism in JEE code is considered a code smell, you should be handling it with the Spring/JMS/Jboss setup
I've had the sort of career that involved highly-optimised in-memory databases, high-volume, low-latency payment processing and stuff like that. So I'm used to dealing with this stuff direct.
Consider this set of programmer "skill levels" where most (80%!) are above average: {10, 10, 10, 10, 1}
Because I'm somewhat tired of seeing this exact comment every time the word "average" is mentioned.
It's not a tautology, it's the asymptotic equipartition property.
> Of course most programmers will still be average, by definition. The problem is that the average level of quality and productivity probably won't have changed all that much.
It would appear not.
It's always funny how people take a serious person who has otherwise written a very insightful article, take a sentence out of context, and proclaim it silly.
RTFA
XML, JSON, MUMPS-storage are semantically equivalent.
XML is not about "<" and ">".
+ 1
> Apple's profits
With all respect, I have hard time seeing Apple laptops outside the US. Not counting some fanboys who acquired the taste trough some snob blogs.
Indeed. And where I am (also outside the US) I have a hard time seeing non-Apple laptops. Anecdotal evidence isn't really that useful when we're talking about global trends.
Not counting some fanboys who acquired the taste trough some snob blogs.
Making statements like this cause you come across as overly emotionally invested in your platform, and make others less likely to take your arguments seriously.
No. I happen to use anything. I am not against Apple, I am against the Apple fanboyism. And any type of fanboyism.
> Anecdotal evidence
http://en.wikipedia.org/wiki/Usage_share_of_operating_system...
"For example, most desktop and laptop computers use Microsoft Windows"
'Fanboy' is a pejorative term used on the internet to try and infer irrationality in others. It's like hipster. It doesn't make you magically qualified to judge others opinions or motivations just by using it.
"For example, most desktop and laptop computers use Microsoft Windows"
That is not anecdotal, though it's also not the fact being discussed. Note that I'm not trying to argue that Apple sells more laptops combined than the other main manufacturers, I don't believe they do.
Apples and oranges (no pun intended). We were talking about unit sales, not market share.
Turns out that Apple's laptop sales do not exceed those of HP/Compaq, IBM, Dell and Gateway combined but Apple's iPad sales was already doing it one year ago: http://www.computerworld.com/s/article/9223707/iPad_sales_be... and from profit POV I bet it is the same.
Maybe Africa? I live in China and I see a lot of them here; China is Apple's second largest market now.
The fanboy argument is funny to no end. I mean, I still can't find a freaking non-Apple laptop that isn't a huge piece of crap. Maybe the X1 will change my mind, but they are on hold right now due to faulty touch screens.
I'm scared to death that only Apple is willing to produce non-crappy laptops these days, that the other PC vendors have given up and are content putting out cheap crap (and expensive crap for the enterprise). Depressing.
Language like this seeds religious discussions. Please avoid it.
Well, I see tons of Apple laptops in places ranging from France, to poverty striken Greece to SE Asia.
If you live in some Eastern European country, Latin America or Africa you might see way less. Macs are for the richer part of the computing buying public.
Worldwide Apple commands around 4-5% of laptop shipments, but in places like US and Japan that can get to 15-20%, and for specific categories like ultraportables it can get to 60%.
More than half of our students (agriculture/environment at University of Copenhagen) have Macs, the fraction being higher in the earlier classes.
JSON is basically XML with 50% less bullshit. It does less but it does it so much more elegantly than XML - and has the further benefit of a syntax similar to that of structured data in such languages as Javascript (duh), Python and Ruby - that it was a shoo-in to squeeze XML out of most non-enterprise uses, at least on the data transfer format side.
However, to this day most data still resides in SQL databases, which have the net advantages of speed, stability and reliability that come from long lead time. What has changed is that object-relational mapping has gotten vastly better than it was in 2004, so programmers can mostly enjoy the best of both worlds.
There's also the fact that SQL is an easy enough DSL to understand, read and write that it isn't a barrier to use even in edge cases where ORMs fall down.
The big lack is the equivalent of XQuery and XPath, in my opinion. Javascript plays this role in some systems, but I don't think there is anything for Javascript matching the power and flexibility of XQuery/XPath for querying and transforming data.
I would be happy to learn about query languages for JSON document databases that prove me wrong.
The main thing missing is that XML has attributes, so you can query against those.
I won't say that the JS stuff is better, but it's one less thing to learn, and what you learn is directly applicable to writing apps in JS.
> object-relational mapping has gotten vastly better than it was in 2004
The differences between something like Hibernate and something like ActiveRecord is pretty vast, at least in terms of usage, and I think one of the key learnings we've made since 2004 is that it's not practical or feasible to treat ORM as a silver bullet.
Honestly, no one should be surprised that ORM isn't a silver bullet. NoSQL isn't either - there's plenty of caveats that should be considered before deciding on using NoSQL. I'd still argue that about 80% of database interactions can be solved by a decent ORM. Anything that lets me ignore 80% of my trivial problems and focus on the 20% that's actually challenging is a net win in my book.
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, standard way to query, XPath/XQuery are there for you. If you want to wholesale completely restructure entire documents/data blobs, XSLT is there for you.
I have never gotten the hate for XML. I suspect -- and this is not some sort of slur against those who don't like something I like, but rather is an observation about general tech trends -- that many programmers were simply too lazy to understand all of XML, so rather than work in an area where they felt ignorant (again, nothing stops you from making bespoke XML at your desire), JSON and things like it seem so appealing.
{"mynumber" : 5, "mylist" : ["one", "two", "three"]}
In XML this has to be
<!DOCTYPE some-magic-string-nobody-can-remember>
<topnode>
<mynumber><int>5</int></mynumber>
<mylist>
<str>one</str>
<str>two</str>
<str>three</str>
</mylist>
</topnode>
Maybe there are libraries that do this automatically. If there are, the XML community does an excellent job of hiding them from developers; I've worked a fair bit with XML, and haven't found them.
2. Easy interface with popular languages. You can just copy-paste a JSON string into a Javascript / Python app. (Warning: If you do this programmatically, it's going to be a security vulnerability.) Whereas if you want to use XML, you have to jump through a lot of hoops. Especially with Java; AFAIK the Java standard lib only ships a specification for XML parsing. So while the org.w3c.xml namespace is there (or whatever it's called, it's been a while), you have to install some Apache lib called Xerces or Xalan or Xavier (or whatever it's called, it's been a while) in order to have XML support.
This is Java's fault, not XML's; but XML was a shiny cool thing at about the same time Java was, so a lot of peoples' main XML experience (or at least mine) is in Java.
3. Is a subset of many popular languages. A lot of people -- especially web developers -- only know one language. If you know JS, then you know JSON. But XML syntax and semantics is very different from most programming languages, and that's a barrier. (General XML is much different than HTML. In particular, you can always see what HTML "does" by loading it in the browser because everything has default styles; not so with a general XML format, unless you go through the pain of writing a complete style yourself.)
Point #2 isn't very strong. Every language has good support for both technologies these days.
Point #3 is absurd. If you know JS and you know HTML, you're not far from the basics of XML. If you're contemplating JSON as a replacement, you're either assuming our poor web developer is really stupid or you're comparing apples to oranges.
In general, your argument here is that JSON is shorter and more popular. Sure. But unless your top concern is bandwidth (hey, maybe it is) there might exist other technical reasons to make the choice which are less childish.
2. Maven is a nightmare too. Every time I've used it (usually because I'm compiling someone else's code and they wrote the build in maven), it downloads hundreds of megabytes of who-knows-what from random Internet sites. I want to pin versions of dependencies (and dependencies-of-dependencies) so my builds are repeatable, and I want to be sure everyone who's forked my git repo can still build the code if the Maven URL's for the deps have gone out of business. I recall trying to read the Maven manual, but both the manual and the concepts were incomprehensible -- there's so much automagic, when things break, it's difficult to even come up with a hypothesis of what might be going wrong. (And anyone who has any experience with any build system knows that the build always breaks.)
I usually just use Ant. It's a bit of a pain shuttling jar's around (symlinks help), but at least I can understand the build.
3. Part of the problem is that I don't want this alphabet soup of technologies. If I'm running in Python, and I'm developing a prototype or a one-off hack, I just write a file called whatever.py. (I can "import json" in whatever.py if I don't want to use hacks like eval()/repr() or copy-and-paste for parsing/serializing.)
I want to be able to build a quick one-file prototype to process my XML, without enabling the "Java EE 6 web profile" (whatever that is) and writing a Maven build file. I want using XML to be this simple:
sudo apt-get install default-jdk
javac Whatever.java && java Whatever
2. You may not like Maven--I hate it too--but it's how things are done. In practice the only people complaining about installing libraries and managing jar dependencies are people using ant without ivy. 90% of folks just use Maven and get on with it.
3. You're turning your complaint from "Java's XML support is weak" to "Java's XML support isn't Pythonic like Python's." This is a weak argument. You're saying you want to live the Python dream in Javaland. Well, it isn't going to happen, no matter what the Play guys tell you. But if you have to use Java--and sometimes you do--adding four lines to your maven config--which you will have--so you can use EE 6 or JAXB is not a big deal, and neither is putting a few annotations on a class.
I don't love Java. In fact I dislike it. I would rather be using Haskell, Python, or Ruby. Or any number of other things. But you can't be mad at Java for being Java and not Python.
That's by default in maven - you have to do something really stupid to get non-repeatable builds (usually involves specifying open version ranges or some weird plugin magic)
>everyone who's forked my git repo can still build the code if the Maven URL's for the deps have gone out of business
One of the main advantages of maven is just the opposite of that - you don't have to bundle your dependencies and get them to other people - they can just ask maven to fetch them. And maven is not going away.
I think they changed it now but for years the default behaviour was to get the latest versions of every plugin, making builds non-repeatable by default.
This got me up to speed pretty quickly to learn JAX-RS providing XML and JSON.
<http://androidexample.com/Camera_Photo_Capture_And_Show_Capt...
Java integrates everything you need to parse and generate XML. Most API are XSD driven (either through annotation in the code, or with the mapping code generated from the XSD), so you get plenty of types like data, int, ... You also get streaming parser (pull or push) and DOM.
Obviously, that is no longer plain XML, that is XML + XSD + Namespaces.
The J2SE (not JEE) also has built-in support to expose and consume webservices, without requiring to worrying about WSDL and the rest.
At the end of the day, that does not mean that dealing with XML is a great experience. Most real life XML is awful. And well although the basic tooling is there, that is in the usual java fashion with factories of factory of creator of generator and very little "high level" utility.
The S stands for simple... <<Sob>>
* attributes v. tagnames
* no "anonymous list"
* infinitely large surface area
[ {name: joe, age: 12 }, {name: bob, age: 23} ]
<list><user><name>joe</name><age>12</age></user><user><name>bob</name><age>23</age></user></list>
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 multi-vendor use cases, but the disadvantages cost more than the benefits compared to "simple" anonymous json.
<user name='joe' age='12' />I wasn't trying to show XML is as compact as JSON, only that it can be more compact than the claim "it's so verbose" made it look.
JSON always comes with ready made parsing.
{'users': [{'name': 'joe', 'age': '12' }, {'name': 'bob', 'age': '23'}]}
<users><user name='joe' age='12' /><user name='bob' age='23' /></users>{ name: 'joe', dob: { m: 1, d: 2, y: 1934 } }
<user name='joe' dob='...???...'>
<user><name>joe</name><dob><m>1</m><d>2</d><y>1934</y></dob></user>
I actually wasn't trying to make the "XML is bigger" joke because that isn't what's important to me. Structurally XML is harder to use.
{users: [{name: 'joe', age: 12}, {name: 'bob', age: 23}]}
<users><user name='joe' age='12' /><user name='bob' age='23' /></users>Unfortunately in practice it never is. I've seen programmers do too many dumb things with data structures in XML, which then becomes "part of the spec" so it never goes away.
Take an xml api in a fortune 500 and run it through 10 developers over the course of 5 years, then do the same thing with a json api, I guarantee you the json one will be more standardized and easier to consume.
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 8601 dates into Date/Time objects, I understand.
To me 50% less bullshit means 50% less typing and maybe getting something wrong. JSON is easy to read and write by hand, which happens a lot.
XPath/XQuery and XSLT are nightmares in my opinion. I'd much rather type `Foo.bar` or `_.each(Foo.items, function(item) {...})` and be able to easily debug when something goes wrong.
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.
XML doesn't support objects, but there was enough thought put into the implementation that it has an easy way to document and define the types, with validated ways of representation. ISO 8601 for the xsd:dateTime, for instance. There is no ambiguity or uncertainty, no hand-rolled varieties of crazy, quite unlike JSON world where there are a hundred ways to represent a date or date/time, all of them broken in some way or other.
XML remains the lingua franca or most enterprise systems and interchanges (meaning the ones that people are most interested in trying to compromise
That is one of the reasons attackers are so happy. They are not trying to compromise. They are succeeding. Show me a SOAP/XMLRPC web service and I will show you a compromised machine, with very high probability.
See, for instance, last year's BlackHat presentation about SAP. Root with 1 request. Granted, there was an overflow involved, but the entry point was XML. Many more instances of this are available (I've compromised tens of systems in the last six months through the "magic" of XXEs, but unfortunately can't talk about them).
http://media.blackhat.com/bh-us-12/Briefings/Polyakov/BH_US_...
XLST is a friggin nightmare to code and I can't think of any reason why one would want to use it. It's much better to first parse the XML and then reshape to your needs rather than trying to do both at the same which XSLT does. In short, XSLT violates separation of conerns. Furthermore, if you think XML is hard to read, just try reading someone else's XL
XML data model (trees with attributed nodes and special kinds of leaves) is not native to any language: XPath/XQuery and XSLT exist to bridge the alien world of XML to regular programming languages. Taking them out doesn't make XML simpler.
JSON doesn't have them because it can be represented with maps and lists, object types fundamental to many programming languages (it practically maps almost exactly to every scripting language created in the last 20 years). That's why it doesn't have, and doesn't need, XPath or XSLT equivalents. And that's also why it feels more natural to most programmers (ie. 50% less bullshit).
You could build a stronger case for the need of schemas and namespaces but IMHO that's actually bullshit, even in XML. But you can ignore them in XML too, as you noted, so it doesn't really matter.
I think he means more like wordpress.com, WPEngine and those ilk. Those are currently the most lucrative, but there are other examples of businesses monetising open source by hosting it.
Saying that, it all falls under the general trend of providing system administration as a service. Given how much ongoing effort is required to maintain secure, up to date and efficient servers, this is probably a good thing.
> most small development shops would pay a monthly fee not to have to administer the apps themselves.
and
> But would an external dev team trust some big company like Amazon with with their intellectual property?
and
> So I predict that someone will come along and offer an innovation hosting service, and make a lot of money off it.
OP had his finger on the pulse of tech, though, that much is certain.
This is one he nailed - Facebook.
Not in my circles... Facebook didn't even begin to pop up on my radar until 2009. Social media adoption is extremely dependent on where you live and what type of people you know. Generalizations based on personal observation are invariably going to be wrong.
To add some actual data to this: in February 2009, Facebook had recently surpassed 175 million users[1]. It's now got a billion. So 2008 is definitely too early to place your "pretty much everybody" statement.
[1] http://www.insidefacebook.com/2009/02/14/facebook-surpasses-...
2. Someone will make a lot of money by hosting open-source web applications. Ya know, he might be onto something there. In retrospect, it relies on fulfillment of #7.
3. Multi-threaded programming will fall out of favor by 2012. It's just too obvious a technique to not use. Alternatives may be cleaner, but not as clear. "Get it done" trumps "make all the pieces play in perfect harmony".
4. Java's "market share" on the JVM will drop below 50% by 2010. That assumed robust use of JVM. iOS & Android exploded onto the market, changing the landscape he was addressing.
5. Lisp will be in the top 10 most popular programming languages by 2010. Nope. But I assume he never expected Objective-C would be.
6. A new internet community-hangout will appear. One that you and I will frequent. Facebook. EVERYBODY is on Facebook. Wasn't so important that "you and I" use it, but that our mothers would.
7. The mobile/wireless/handheld market is still at least 5 years out. Odd that he was more predicting something not happening; we'll say he was right insofar as what constitutes "happened" is squishy and took a few years to get going, but wrong insofar as when it did happen it did so to a far greater degree than he expected. Half of the then-absurd snide "promises" he listed as others making have pretty much come true: HDTV pixel counts on a pocket device, LTE data rate 10x faster than T1, etc.
8. Someday I will voluntarily pay Google for one of their services. He couldn't grok what Google would be able to offer for free.
9. Apple's laptop sales will exceed those of HP/Compaq, IBM, Dell and Gateway combined by 2010. Had to invent the smartphone and tablet markets to do so, but insofar as an iPhone 5 is on par with notebooks back then, we'll count this as a big win.
10. In five years' time, most programmers will still be average. More a tautology than anything. What's "average" is pretty friggin' capable given a cheap modern toolset. For $99 and a Mac darned near any competent idiot can whip up a practical app and have it available to the world in a few days, no need for mad skillz.
The thing about predictions is the difficulty of articulating how discoveries along the way will affect manifestation of the prediction. One may be right in the spirit of the prediction, but not the letter thereof.
Shame we still don't have microsecond latencies, though.
The company I work for pays $250 a year for Github Enterprise per developer for about 400 developers... That is just one company. 100k/year! They are thinking about extending it to all 2,000 developers.
A few months ago they raised $100 million!
http://techcrunch.com/2010/07/24/github-one-million/
Or this: http://www.linuxuser.co.uk/news/github-gets-100-million-inve...
Announcing the investment on the GitHub blog, CEO Tom Preston-Warner admitted it wasn’t that they necessarily needed it: “Our company has been profitable for years, is growing fast, and doesn’t need money. So why bother? Because we want to be better. We want to build the best products.”
I'm not an accountant, and this is just my uninformed understanding.
Venture capital is not a loan; it's a purchase of equity. You are not in debt after taking money.
It must be. Github raised 100m from investors led by Andreesen Horowitz in 2012. You don't get that kind of funding from that level of quality investors without a seriously good financial trajectory.
I don't know about hard. I can now imagine a day where Clojure is the predominant JVM language--whereas if you told me five years ago a Lisp would be even as popular as Clojure is now, I would have scoffed.
Now, the by 2010 part is wrong, indeed. But I see these predictions as being more about acceleration than current velocity.
While it's not as totally obscure as many other Lisp, Scheme or Lisp-like language implementations, it's not very widely used at all. Its penetration is minimal, even compared to Scala (which has seen much more significant usage, but still pales in comparison to Java).
While Clojure is a step in a better direction, I don't think it's gaining traction all that quickly. There's a whole lot of existing Java and Scala code that would need to be completely discarded or ignored in order for Clojure's usage to be considered as having any impact.
3. He's not talking about using multiple cores, he's talking about using multiple threads vs (for example) multiple processes.
6. Reddit, Hacker News
3. Gotta reread that.
6. Oh come on, facebook, youporn, whatever. As I said, too vague.
Yeah, so he didn't call out a specific "type" of socializing, or draw up the wireframe for facebook here. But he just recognized there is a huge trend of people wanting to share their lives and communicate in near real time. I think he nailed it. Facebook and twiiter are just that. Even look at his move example. These days, you watch you movie or TV show, then laugh and comment on it with your friends not in the theater, but on facebook or twitter. I'd say he NAILED that prediction.
Git is open source.
That being said, GitHub does indeed match the description, though I think people are thinking about the code they are hosting for other people ... but I think where they fit the description is with the fact that they are hosting Git for you (and making some money through enterprise services).
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 at host level, multiple processes spread over the hosts)?
8. Someday I will voluntarily pay Google for one of their services. You don't say? They are one of the biggest players out there, even if they are not primarily known for payware but still.
While most individuals just use the free service level, you can pay for the use and support of Google Docs and some groups do. Same with Google Drive: while many won't need more than the free 5Gb it costs per month for more than that (if you are using it to store music and video 5Gb isn't hard to fill).
10. In five years' time, most programmers will still be average. This makes no sense, but anyway, we are getting better. Slowly though, version control, more languages, testing is infiltrating even some dumber dev companies too.
It makes perfect sense in a pointless way: most of everyone are average at everything. As people get better/worse the average shuffles around too. If he is talking about following best (or at least good) practises I can tell you thre are a lot of average people out there despite the tools avaliable to make it easier to do things right.
Concurrent programming isn't all "jump off a cliff into the atomic<T> 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.
Supporting both (multiple processes for multi-host scalability, threads for speeding up CPU intensive operations and such) might not be much more hassle, but it is at least some more hassle.
Obviously we will never have single-threaded systems, they would be blocking all the time.
On contrary, for me this one was one of the strongest predictions. In my opinion, predictions should be taken in spirit and not by letter. Looking at the rise of Clojure, i dare say that was a great foresight.
Err, that prediction talks about something like Amazon AWS and Heroku, which very much happened. Not about hosting open source CODE.
>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.
Nope. Multi-threaded programming he talks about has long fallen out of favor. Multicore programming in 2013 is all about message passing, STM et al --where threads are hidden from the programmer.
>5. Lisp will be in the top 10 most popular programming languages by 2010. This failed hard.
If you count Clojure, it didn't fail that bad. But the general trend towards functional programming and its concepts means that the prediction sort of have been proven true, despite Lisp not being the language that brought it.
>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.
Are you kidding me? This is all about Facebook, before there was facebook.
>7. The mobile/wireless/handheld market is still at least 5 years out. Happened sooner.
Well, the iPhone appeared on 2007, so not that much sooner. And he is correct that the whole market exploded a little afterwards (the first iPhone wasn't even 3G, remember?).
>9. Apple's laptop sales will exceed those of HP/Compaq, IBM, Dell and Gateway combined by 2010. No way, thanks God.
Actually not that off. Especially if you include the iPad: http://photos.appleinsider.com/deutsche-120206.jpg
And even without it, Apple has 1) that exact share of profits (of all those others combined), 2) that share of the high-end (> $1000) market.
>10. In five years' time, most programmers will still be average. This makes no sense
Makes no sense? If anything it's an absolutely true tautological statement, mathematically speaking.
iPad.
Not according to http://visual.ly/most-popular-programming-languages-2013. Clojure alone is in 10th place for code submitted to codeeval.com in 2013.
Edit: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.... appears less focused on web development and startups (it puts VB ahead of Ruby and leaves Clojure and Scala out completely) and even this ranking puts Lisp (presumably CL) at #13 overall.
If you count laptop+tablet sales, it may be close.
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 requires parallel architecture to exploit. But you can't blame an armchair pundit for missing this one. The 3 GHz clock speed barrier was hardly something a layman could have predicted; it's an artifact of extremely sophisticated manufacturing processes and infinitesimally detailed subatomic physics. A layman couldn't have said whether the physical limits of clock speed would be reached at 1 GHz or 100 GHz and in 2005 or 2025.
> 6. A new internet community-hangout will appear. One that you and I will frequent.
This succeeded way more than anyone thought. More than "you and I", our moms and grandparents even hang out there. It is Facebook.
So how much is it a room-temperature a physical limit, and how much an economic limit?
It happened June 29, 2007.
Tiobe has "Lisp" ranked 13, not clear what they included as "Lisp". (Specific Lisps like Scheme, Common Lisp, and Clojure rank much lower, so must be some kind of aggregate.)
http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
Interestingly, the "Very Long Term History" table has Lisp going from rank 20 in 2008 to 13 in 2012. So Yegge clearly missed his top 10 prediction, but may have been on to something in regard to Lisp increasing in popularity (depending on how much credence you give Tiobe rankings, of course).
However, good ideas are resilient even if the face of death. People such as Paul Graham kept the flame alive. People like Rich Hickey brought it into the modern age. There is no question that Lisp is on the comeback trail.
There is also, of course, the broader victory of Lisp: the impact it has had on all other languages. Paul Graham wrote about that here:
But I can agree the spirit of the prediction lives on in the form NoSQL and JSON.
There are cases where XML is a great format. For example in the past I wrote a system for interfacing with a government department.
The thing was an epic of about 30 different schemas, however being able to actually look at a concrete schema for specification and actually be able to test against it was invaluable.
Trying to build that thing with JSON would have driven me to tears.
I too like the ability to validate XML against a schema and found it invaluable when dealing with a set of (needlessly) complex ant-plugins a couple of years back.
XML, JSON, MUMPS are semantically equivalent.
But in fact: you add javascript - you have all strictness and structure of XML.
It peaked[1] in 2010 and is now settled on the 13th place, so I got to give him some credit for this prediction. If you include other dialects including newcomers such as Clojure, we might be talking at least close to the 10th most popular.
[1]: http://www.tiobe.com/index.php/paperinfo/tpci/Lisp.html
Anyone know if there's a NoSQL/SQL market share comparison out there?
I'd be surprised if it was much above 1%.
My initial thoughts on #2 were AWS and the PAAS companies (Heroku, EngineYard, etc.) but maybe they're to broad to fit. The people who mention WordPress have a good point.
Overall quite spot on i'd say..
* Gateway was bought at a firesale price by Acer
* IBM sold off their PC business to Lenovo
* both Dell and HP have been in the doldrums in terms of PC/laptop sales and they both desperately have tried to milk the enterprise software and services business
Apple's total revenues come to about 69% of the combined revenue of HP, Dell, Acer and Lenovo ... so a miss since the iPhone/iPad have been what boosted Apple rather "laptops" per se (and certainly not to complete equality in revenues by 2010), but it's an interesting miss.
I don't think it did. Lisp itself didn't become popular, but a lot of functional ideas are being implemented in more mainstream programming languages, and some functional languages are also becoming popular.
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.
It's close enough in essence.
How do you see the market share dropping? There is this little thing called Android...
You must be a shitty developer for hating on Java. Didn't you read thru the article about how useful and awesome Java is. The worlds top websites, mobile apps heavily run on Java and JVM.
Well he wasn't that far.
The high-end laptop market is utterly dominated by Apple: already in 2007 they had more than 30% (growing by 8% from 2006) of the high-end laptop market and now they're at more than 50%. So their sales there exceed those of all the other players combined.
They're also the uncontested winner in the ultra-thin laptops market.
Granted, there's a market for IBM Thinkpads but you simply cannot say he was far off regarding is Apple laptops prediction.
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 are already in the multicore age, and it will only get moreticore.
4. Java's "market share" on the JVM will drop below 50% by 2010. Not in 2010, not even yet, but we are certainly on the road. No surprise considering how shit Java is.
5. Lisp will be in the top 10 most popular programming languages by 2010. This failed hard.
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.
7. The mobile/wireless/handheld market is still at least 5 years out. Happened sooner.
8. Someday I will voluntarily pay Google for one of their services. You don't say? They are one of the biggest players out there, even if they are not primarily known for payware but still.
9. Apple's laptop sales will exceed those of HP/Compaq, IBM, Dell and Gateway combined by 2010. No way, thanks God.
10. In five years' time, most programmers will still be average. This makes no sense, but anyway, we are getting better. Slowly though, version control, more languages, testing is infiltrating even some dumber dev companies too.
--
I give this guy a mental thumbs up for points 1 and 4, and the cynicism in point 10.