Considering that "Semantic Web" standards deal with the use of tightly structured data, XML is a good fit and JSON just isn't.
XML has structures, standards, validation and flexibility that JSON sorely lacks. As someone else wrote above, the main thing JSON has going for it is that it's already JavaScript. Big deal.
I linked to a clear example further up. XML preserved my simple data structure. JSON threw away information about my data that I would have to supply myself later, if I were to use JSON to transfer that data. When working with structured data, that's a very bad thing.
The most common complaints I've heard about XML has been that it's "too verbose". Well, great. Try to come up with a standard for well-structured data that isn't. I'll wait.
In a prior job I had to deal with large complex data sets in XML. The tools were not as good at the time, and dealing with such a large, complex set of data required a plugin ("gem") and some very involved data definition files.
"No, you do not have an inalienable right to act out your aggressions on a publicly-funded highway."
That's certainly true. But I think we'd be better off treating the cause, rather than the symptoms. I might not have a right to "act out aggressions" on the highway. But you don't have a right to drive like an asshole and piss off everybody around you, either.
"And to preach to the choir, but shouldn't the conversation shift to asking:
Which risks are we (as a society) willing to take
What does the intelligence community need to fulfill its social responsibility?"
NO. We already have answers to these questions.
The Constitution clearly shows us the safeguards to use: strictly limited government is the only solid answer to the first question, and government's actions outside the Constitution have only been further proving the validity of that. (Though why we should need even more proof than history had already given us might actually be a valid question.)
As for what the intelligence committee "needs": that is also pretty damned clear. The first thing they need is to ensure the government stops spying on all American citizens who aren't prior suspects of espionage... with probable-cause EVIDENCE of the latter.
The second thing they need is to make sure the government stops doing stupid spy shit to our allies and pissing them off.
"We have a group that monitors the NSA. The NSA lied to them."
BS. Do you really think the chair of the Intelligence Committe, Dianne Feinstein, didn't have a pretty good idea of what was going on? She was one of the people pushing for it.
The fact that this uproar is only happening now, when she found out that *SHE* was being spied on, would be hilarious if it weren't such a goddamned tragedy and parody of justice.
Doesn't matter. It's a blatant attempt to commercialize on the success of using this method in a very narrow field.
I read the article on minimum wages, and they left out some glaringly obvious factors, like how many on minimum wage are collecting government assistance of some kind. I mean, let's get real here. It's not realistic to discuss the economics of the one without taking the other into account.
Also, it's pretty hard for me to take seriously a website that requires you to log in via Facebook in order to leave a comment.
"The government only spends money trying to decrease the inequity between the middle and lower class."
Where did you get that idea? I agree that the government isn't doing it right, but I think you are overstating it a bit.
"This just makes the problem worse, just as this H1B visa suggestion is only designed to decrease inequity between the middle and lower class while increassing the disparity between the upper and middle/lower class."
No, it isn't. It's designed to make the rich richer, at your expense. It has nothing to do with middle class versus poor. It isn't the "middle class" who are hiring H1B workers or lobbying governments. It's the CEOs of multi-billion-dollar corporations. They aren't the middle class.
" I have not seen any programs that address the disparity between the truly wealthy and the poor."
Yet that's what they always CLAIM the programs are about. That's what Obama is always railing against. "Income inequity", in Government-speak, is the gap between the richest and the poorest, not the poor and the middle class.
I agree that government programs do not really address those issues, but that is how they are always sold: rich vs. poor. And the middle class has almost invariably been the victim. That was my whole point.
Whenever you get government involved, that's what's going to happen. So the answer is to get government UN-involved.
"No it is not weird. XML is weird because it contains and is based on printer control cruft. Lots of printer control cruft. An unnecessary tag is a tag is a tag is a fucking tag."
It does nothing of the sort. XML is a data description language. It's parent language -- SGML -- had a LOT of printer specification stuff in it. But XML has NONE. Not one little bit.
Jeez, guy. Pick up a book.
"An unnecessary tag is a tag is a tag is a fucking tag."
Then show me how to do the same thing without those tags that you call "unnecessary". Where are you going to get the information necessary to validate your data?
I linked to an example further up the page. XML preserved the data type, while JSON just turns any data it doesn't understand into a string. If I receive that data at the other end, and I don't already know what the data is supposed to contain, how do I know what that string represents? For all a program knows (unless you tell it ahead of time), it's somebody's fucking middle name, when it was actually supposed to be a timestamp.
They're useful for different things, as I originally stated. But there are A LOT of situations where JSON drops the ball when XML handles it with ease.
You can make a printer that uses XML for control. But XML, by itself, doesn't contain any "printer tags". Not one.
"Motorola Mobility was losing a billion dollars a year before Google came in."
Okay. Conceded. But it's still the Google exception, not the rule. Look at all the other companies Google acquired and destroyed. Look at all the other projects Google built up that were flops.
"How did YOU make $2 billion in two years? Yeah, me neither."
If I had $10 billion in spending money, it would be dirt simple. It's not that hard to make lots of money when you already have lots of money. But where did that money come from? Again, it was originally search. They HAD THE MONEY to acquire a few other already-successful businesses, which made them even more money. Big deal.
YOU tell ME: what was the last good idea that Google had, on their own, that they were able to make lots of money off of, without relying on their already ridiculously deep pockets? Huh? What Google project would have made it as a good startup?
Maybe a couple. But as big a company as Google is, and as deep as the pockets of Google are, it should have been a hell of a lot more. There must be some reason for that, eh?
Look at what Elon Musk did with the profits of PayPal. Two subsequent startups that are in some ways even more succesful: Tesla Motors and SpaceX.
If I were looking for business savvy, I'd go ask Elon Musk, or Richard Branson, long before I'd even look in the direction of Google or Facebook.
Pardon me. I should have added that JSON is pretty much as easy: just use "to_json" and "from_json".
But the problem is -- as I mentioned in a post further up the page -- that JSON throws away some data type information. So when I use JSON, I have to reconstruct some of my data types when I use from_json. But I don't have to do that with XML.
And that's definitely a problem with JSON, not Ruby.
"Yes. I'm lucky LISP can parse XML since they are really only just a special case of S-Expressions. Once out of that horrid mess of printer tags it was much more straightforward to validate them and insert them in all their complexity into a nicely normalized relational database."
You are conflating XML and SGML. While technically XML is a subset of SGML, it doesn't contain "printer tags". It literally doesn't have any. XML tags are strictly data description.
Saying that XML is SGML is kind of like saying "car" is LISP. The former is a clearly-specified tool used for certain specific things. The latter is a generalized tool for many things. You wouldn't write an entire language like LISP to perform the function car performs. Nor would you write a specification like SGML (which does indeed contain printer tags) to perform the function that XML performs. One may be a subset of the other, but trying to say they're the same is just wrong. And weird.
To what "scripting languages" do you refer? I do most of my work in Ruby, and dealing with XML is as simple as using the "to_xml" and "from_xml" methods on your data.
Yes, it is. If you don't believe me, I have posted a link to a simple example below. Not only is the JSON harder to read, it throws away data type information unnecessarily.
"When dealing with any format that's a hierarchy, you should be able to view the top level and click a little '+' or something to open it."
This is old stuff. TextMate (just for one example), has been doing that for a long time. Here's an example. Notice how the line numbers skip where the code is collapsed.
You can also open XML in Firefox, and again it does exactly the same thing: you can expand and collapse levels at will.
"Neither JSON nor XML is easily writable without special tools. "
Sure they are. Take just about any object in Ruby and call [object].to_xml or [object].to_json.
More relevant to the discussion though, I think, is what someone else said above:
"XML has standardized schemas, validation, querying, transformation, a binary format and APIs for interoperability from any language. All JSON really has going for it is that it's already JavaScript."
I would have to say the same for RSON.
While it is true that they are syntactical versions of one another, XML is far less ambiguous. In a way, XML versus JSON is a lot like Java versus JavaScript. The former have more tightly defined specifications, and less ambiguity. (I.e., Java will not let you treat a string like an integer or vice versa.) Tighter specifications can be a PITA sometimes, but other times they'll save your butt. JSON, on the other hand, throws away information about the data that you will probably have to supply yourself later. Here's a very simple example:
While it's true XML is a lot more verbose, there is no ambiguity. Take a look at the element labeled "created_at" (or "created-at" in the XML) for example. In JSON, it comes out as a string? WTF?
Not only do I argue that XML is a lot easier to read, you don't have to mess around with translating your data into different types when it you convert back. If I take that XML and convert it back to a Ruby object (one simple method call), I get the correct data types back. If I try to convert that JSON back to a Ruby object, I have to convert those dates (and other things if I had used a different example) back to the types they're supposed to be myself.
I should not have to do that. I am manually replacing information that JSON threw away. It requires that I build a special conversion routine for each kind of data set I am expecting to receive. Yuck. Why would I want to torture myself like that?
"Really. Non of that totally unnecessary tag BS inherited from a printer definition spec (of all absurd things.) And key/value pairs are a hell of a lot easier to insert into a database in addition to being easier to read."
Key-value pairs are a tiny subset of all data types. There are many data types that they have to struggle to represent very well. And when they try, the result (to the human eye) is a huge mess.
You're entitled to your opinion of course. But I think you're looking at it from a very narrow perspective. Have you ever actually had to program for the exchange of complex data sets? By that I mean something quite a bit more involved than a web store?
"Less than half of Google's revenue is from search."
Okay. I'll grant you YouTube and Hulu were successes. But they were also not something that Google invented or tried to develop in-house. They were already quite successful when Google purchased them. AND, Google was mainly smart enough to leave them alone (except for the "one account for all of Google" debacle, which has caused a huge drop in comments on the site).
So that's about 2/3 of their revenue that come from things other people invented and built up into successful businesses. And it totals 2 whole businesses.
How many other things has Google acquired, fucked up, and then dumped? Like Motorola for just one recent example.
When you take their history as a whole, I stick by my comment: Google makes bad business decisions. Other than those two acquisitions, the VAST majority of things they either bought or developed in-house were major flops.
"Kickstarter doesn't do investing. It is a pre-purchase..."
No.
Kickstarter is very careful to explain in their documentation that your investment is not a purchase. You are betting that the owners of the campaign will come up with a viable product.
Sometimes, your "investment" only reaps you something like a T-Shirt or even a bumpersticker, or dinner with the inventor. In any case, it's not a "purchase" of the product, even if the "rewards" sometimes make it look more like a purchase than an investment.
"They ARE investors.. The whole point of Kickstarter is for people with a good idea to solicit capital from interested investors. If the original terms of the agreement are not honored, perhaps the original investors can sue for their percentage of ownership of the entire profits of the operation."
Yes, BUT...
They are "investors", in the sense they are investing money in the product, but they aren't "investors" in the usual sense of investing in something in order to make a profit later. You are "investing" for a fixed reward that has little or nothing to do with the product's eventual success.
"The funny thing is that, at the end of the day, JSON and XML are the same thing, only syntactically different."
Yes, exactly. But XML is readable by people. JSON is not. Just try to read any big dataset in JSON, especially if it's minified. Good luck. At least with XML you have a shot.
Having said that: there are lots of good tools for converting from one to the other, so it could be a lot worse.
You make a good point about standards and validation, though, too. That's why business data interchanges are generally built on XML, and not JSON. Even though JSON is generally more efficient.
IF the situation calls for HUMANS to read the data, I sure as hell do prefer XML. No contest. JSON is virtually unreadable.
Like I said: it's fine for computer data interchange, but when it comes to human intervention, give me XML any day.
I'm not claiming XML is perfect, by any stretch of the imagination. But when humans rather than computers need to deal with the data, it beats the shit out of JSON.
"Most certainly, though, he achieved what thousands of other smart people couldn't."
Just as I was saying: as with Mr. Gates, luck had a big hand in it. There isn't anything "obvious" about it at all.
And Google is not a good example because they're just plain shitty at making business decisions. They've proven that time and time and time again. They had one great success with their search engine. They've tried leveraging that into other successes elsewhere. And even given their huge pile of money, their success rate has been dismal at best.
Their recent "one account for all of Google" has suffered a tremendous backlash, and it was long PREDICTED that it would be a really dumb thing to do. No hindsight necessary.
"Kind of reminds me of all the Bill Gates haters from 15 years ago... He was just lucky! He stole his ideas! It was some other guy that deserves what he has! Gee you don't sound bitter at all..."
I don't much care what it "sounds like" to you. No, I am not bitter, I am just stating historical facts.
Bill Gates WAS lucky. But he was also a very good manager and businessman. But the historical FACT here is that if Gary Kildall had not thumbed his nose at IBM, Microsoft would never have happened. Look it up. That was luck.
Zuckerberg was also lucky -- as well as unscrupulous -- and he isn't even that great of a manager. His own firm nearly kicked him out, if you recall. All fact. Look it up.
"Disney is a corporation, the artists etc etc are the people."
Irrelevant. You are tossing out the entire context of this thread.
By this logic, you could also say that Chrysler does not make automobiles, and Apple does not make computers.
In a very technical, ridiculously hair-splitting sense you are correct, but in a way that is irrelevant to the whole point of the conversation that is going on here.
Slashdot Mirror
Considering that "Semantic Web" standards deal with the use of tightly structured data, XML is a good fit and JSON just isn't.
XML has structures, standards, validation and flexibility that JSON sorely lacks. As someone else wrote above, the main thing JSON has going for it is that it's already JavaScript. Big deal.
I linked to a clear example further up. XML preserved my simple data structure. JSON threw away information about my data that I would have to supply myself later, if I were to use JSON to transfer that data. When working with structured data, that's a very bad thing.
The most common complaints I've heard about XML has been that it's "too verbose". Well, great. Try to come up with a standard for well-structured data that isn't. I'll wait.
In a prior job I had to deal with large complex data sets in XML. The tools were not as good at the time, and dealing with such a large, complex set of data required a plugin ("gem") and some very involved data definition files.
But it's easier now.
"No, you do not have an inalienable right to act out your aggressions on a publicly-funded highway."
That's certainly true. But I think we'd be better off treating the cause, rather than the symptoms. I might not have a right to "act out aggressions" on the highway. But you don't have a right to drive like an asshole and piss off everybody around you, either.
"And to preach to the choir, but shouldn't the conversation shift to asking:
Which risks are we (as a society) willing to take
What does the intelligence community need to fulfill its social responsibility?"
NO. We already have answers to these questions.
The Constitution clearly shows us the safeguards to use: strictly limited government is the only solid answer to the first question, and government's actions outside the Constitution have only been further proving the validity of that. (Though why we should need even more proof than history had already given us might actually be a valid question.)
As for what the intelligence committee "needs": that is also pretty damned clear. The first thing they need is to ensure the government stops spying on all American citizens who aren't prior suspects of espionage... with probable-cause EVIDENCE of the latter.
The second thing they need is to make sure the government stops doing stupid spy shit to our allies and pissing them off.
After that, we will see.
"We have a group that monitors the NSA. The NSA lied to them."
BS. Do you really think the chair of the Intelligence Committe, Dianne Feinstein, didn't have a pretty good idea of what was going on? She was one of the people pushing for it.
The fact that this uproar is only happening now, when she found out that *SHE* was being spied on, would be hilarious if it weren't such a goddamned tragedy and parody of justice.
THIS!!!
There is never greater need for the rule of law than when society is at war or otherwise under attack.
In fact, artificial creation of "emergencies" is a classic ploy of governments to grab more power over the people.
Doesn't matter. It's a blatant attempt to commercialize on the success of using this method in a very narrow field.
I read the article on minimum wages, and they left out some glaringly obvious factors, like how many on minimum wage are collecting government assistance of some kind. I mean, let's get real here. It's not realistic to discuss the economics of the one without taking the other into account.
Also, it's pretty hard for me to take seriously a website that requires you to log in via Facebook in order to leave a comment.
"The government only spends money trying to decrease the inequity between the middle and lower class."
Where did you get that idea? I agree that the government isn't doing it right, but I think you are overstating it a bit.
"This just makes the problem worse, just as this H1B visa suggestion is only designed to decrease inequity between the middle and lower class while increassing the disparity between the upper and middle/lower class."
No, it isn't. It's designed to make the rich richer, at your expense. It has nothing to do with middle class versus poor. It isn't the "middle class" who are hiring H1B workers or lobbying governments. It's the CEOs of multi-billion-dollar corporations. They aren't the middle class.
" I have not seen any programs that address the disparity between the truly wealthy and the poor."
Yet that's what they always CLAIM the programs are about. That's what Obama is always railing against. "Income inequity", in Government-speak, is the gap between the richest and the poorest, not the poor and the middle class.
I agree that government programs do not really address those issues, but that is how they are always sold: rich vs. poor. And the middle class has almost invariably been the victim. That was my whole point.
Whenever you get government involved, that's what's going to happen. So the answer is to get government UN-involved.
"No it is not weird. XML is weird because it contains and is based on printer control cruft. Lots of printer control cruft. An unnecessary tag is a tag is a tag is a fucking tag."
It does nothing of the sort. XML is a data description language. It's parent language -- SGML -- had a LOT of printer specification stuff in it. But XML has NONE. Not one little bit.
Jeez, guy. Pick up a book.
"An unnecessary tag is a tag is a tag is a fucking tag."
Then show me how to do the same thing without those tags that you call "unnecessary". Where are you going to get the information necessary to validate your data?
I linked to an example further up the page. XML preserved the data type, while JSON just turns any data it doesn't understand into a string. If I receive that data at the other end, and I don't already know what the data is supposed to contain, how do I know what that string represents? For all a program knows (unless you tell it ahead of time), it's somebody's fucking middle name, when it was actually supposed to be a timestamp.
They're useful for different things, as I originally stated. But there are A LOT of situations where JSON drops the ball when XML handles it with ease.
You can make a printer that uses XML for control. But XML, by itself, doesn't contain any "printer tags". Not one.
"Motorola Mobility was losing a billion dollars a year before Google came in."
Okay. Conceded. But it's still the Google exception, not the rule. Look at all the other companies Google acquired and destroyed. Look at all the other projects Google built up that were flops.
"How did YOU make $2 billion in two years? Yeah, me neither."
If I had $10 billion in spending money, it would be dirt simple. It's not that hard to make lots of money when you already have lots of money. But where did that money come from? Again, it was originally search. They HAD THE MONEY to acquire a few other already-successful businesses, which made them even more money. Big deal.
YOU tell ME: what was the last good idea that Google had, on their own, that they were able to make lots of money off of, without relying on their already ridiculously deep pockets? Huh? What Google project would have made it as a good startup?
Maybe a couple. But as big a company as Google is, and as deep as the pockets of Google are, it should have been a hell of a lot more. There must be some reason for that, eh?
Look at what Elon Musk did with the profits of PayPal. Two subsequent startups that are in some ways even more succesful: Tesla Motors and SpaceX.
If I were looking for business savvy, I'd go ask Elon Musk, or Richard Branson, long before I'd even look in the direction of Google or Facebook.
Pardon me. I should have added that JSON is pretty much as easy: just use "to_json" and "from_json".
But the problem is -- as I mentioned in a post further up the page -- that JSON throws away some data type information. So when I use JSON, I have to reconstruct some of my data types when I use from_json. But I don't have to do that with XML.
And that's definitely a problem with JSON, not Ruby.
"Yes. I'm lucky LISP can parse XML since they are really only just a special case of S-Expressions. Once out of that horrid mess of printer tags it was much more straightforward to validate them and insert them in all their complexity into a nicely normalized relational database."
You are conflating XML and SGML. While technically XML is a subset of SGML, it doesn't contain "printer tags". It literally doesn't have any. XML tags are strictly data description.
Saying that XML is SGML is kind of like saying "car" is LISP. The former is a clearly-specified tool used for certain specific things. The latter is a generalized tool for many things. You wouldn't write an entire language like LISP to perform the function car performs. Nor would you write a specification like SGML (which does indeed contain printer tags) to perform the function that XML performs. One may be a subset of the other, but trying to say they're the same is just wrong. And weird.
To what "scripting languages" do you refer? I do most of my work in Ruby, and dealing with XML is as simple as using the "to_xml" and "from_xml" methods on your data.
"No it isn't. Neither of them is. Not directly."
Yes, it is. If you don't believe me, I have posted a link to a simple example below. Not only is the JSON harder to read, it throws away data type information unnecessarily.
"When dealing with any format that's a hierarchy, you should be able to view the top level and click a little '+' or something to open it."
This is old stuff. TextMate (just for one example), has been doing that for a long time. Here's an example. Notice how the line numbers skip where the code is collapsed.
You can also open XML in Firefox, and again it does exactly the same thing: you can expand and collapse levels at will.
"Neither JSON nor XML is easily writable without special tools. "
Sure they are. Take just about any object in Ruby and call [object].to_xml or [object].to_json.
More relevant to the discussion though, I think, is what someone else said above:
"XML has standardized schemas, validation, querying, transformation, a binary format and APIs for interoperability from any language. All JSON really has going for it is that it's already JavaScript."
I would have to say the same for RSON.
While it is true that they are syntactical versions of one another, XML is far less ambiguous. In a way, XML versus JSON is a lot like Java versus JavaScript. The former have more tightly defined specifications, and less ambiguity. (I.e., Java will not let you treat a string like an integer or vice versa.) Tighter specifications can be a PITA sometimes, but other times they'll save your butt. JSON, on the other hand, throws away information about the data that you will probably have to supply yourself later. Here's a very simple example:
Here is a picture of the same data represented both ways. (I would have just posted it here but Slashdot's bizarre character formatting will not allow.)
While it's true XML is a lot more verbose, there is no ambiguity. Take a look at the element labeled "created_at" (or "created-at" in the XML) for example. In JSON, it comes out as a string? WTF?
Not only do I argue that XML is a lot easier to read, you don't have to mess around with translating your data into different types when it you convert back. If I take that XML and convert it back to a Ruby object (one simple method call), I get the correct data types back. If I try to convert that JSON back to a Ruby object, I have to convert those dates (and other things if I had used a different example) back to the types they're supposed to be myself.
I should not have to do that. I am manually replacing information that JSON threw away. It requires that I build a special conversion routine for each kind of data set I am expecting to receive. Yuck. Why would I want to torture myself like that?
"Really. Non of that totally unnecessary tag BS inherited from a printer definition spec (of all absurd things.) And key/value pairs are a hell of a lot easier to insert into a database in addition to being easier to read."
Key-value pairs are a tiny subset of all data types. There are many data types that they have to struggle to represent very well. And when they try, the result (to the human eye) is a huge mess.
You're entitled to your opinion of course. But I think you're looking at it from a very narrow perspective. Have you ever actually had to program for the exchange of complex data sets? By that I mean something quite a bit more involved than a web store?
s/on the site/on YouTube
"Less than half of Google's revenue is from search."
Okay. I'll grant you YouTube and Hulu were successes. But they were also not something that Google invented or tried to develop in-house. They were already quite successful when Google purchased them. AND, Google was mainly smart enough to leave them alone (except for the "one account for all of Google" debacle, which has caused a huge drop in comments on the site).
So that's about 2/3 of their revenue that come from things other people invented and built up into successful businesses. And it totals 2 whole businesses.
How many other things has Google acquired, fucked up, and then dumped? Like Motorola for just one recent example.
When you take their history as a whole, I stick by my comment: Google makes bad business decisions. Other than those two acquisitions, the VAST majority of things they either bought or developed in-house were major flops.
"Kickstarter doesn't do investing. It is a pre-purchase..."
No.
Kickstarter is very careful to explain in their documentation that your investment is not a purchase. You are betting that the owners of the campaign will come up with a viable product.
Sometimes, your "investment" only reaps you something like a T-Shirt or even a bumpersticker, or dinner with the inventor. In any case, it's not a "purchase" of the product, even if the "rewards" sometimes make it look more like a purchase than an investment.
"They ARE investors.. The whole point of Kickstarter is for people with a good idea to solicit capital from interested investors. If the original terms of the agreement are not honored, perhaps the original investors can sue for their percentage of ownership of the entire profits of the operation."
Yes, BUT...
They are "investors", in the sense they are investing money in the product, but they aren't "investors" in the usual sense of investing in something in order to make a profit later. You are "investing" for a fixed reward that has little or nothing to do with the product's eventual success.
"The funny thing is that, at the end of the day, JSON and XML are the same thing, only syntactically different."
Yes, exactly. But XML is readable by people. JSON is not. Just try to read any big dataset in JSON, especially if it's minified. Good luck. At least with XML you have a shot.
Having said that: there are lots of good tools for converting from one to the other, so it could be a lot worse.
You make a good point about standards and validation, though, too. That's why business data interchanges are generally built on XML, and not JSON. Even though JSON is generally more efficient.
I didn't say that. But since you asked:
IF the situation calls for HUMANS to read the data, I sure as hell do prefer XML. No contest. JSON is virtually unreadable.
Like I said: it's fine for computer data interchange, but when it comes to human intervention, give me XML any day.
I'm not claiming XML is perfect, by any stretch of the imagination. But when humans rather than computers need to deal with the data, it beats the shit out of JSON.
"Most certainly, though, he achieved what thousands of other smart people couldn't."
Just as I was saying: as with Mr. Gates, luck had a big hand in it. There isn't anything "obvious" about it at all.
And Google is not a good example because they're just plain shitty at making business decisions. They've proven that time and time and time again. They had one great success with their search engine. They've tried leveraging that into other successes elsewhere. And even given their huge pile of money, their success rate has been dismal at best.
Their recent "one account for all of Google" has suffered a tremendous backlash, and it was long PREDICTED that it would be a really dumb thing to do. No hindsight necessary.
Google makes dumb decisions.
"Kind of reminds me of all the Bill Gates haters from 15 years ago... He was just lucky! He stole his ideas! It was some other guy that deserves what he has! Gee you don't sound bitter at all..."
I don't much care what it "sounds like" to you. No, I am not bitter, I am just stating historical facts.
Bill Gates WAS lucky. But he was also a very good manager and businessman. But the historical FACT here is that if Gary Kildall had not thumbed his nose at IBM, Microsoft would never have happened. Look it up. That was luck.
Zuckerberg was also lucky -- as well as unscrupulous -- and he isn't even that great of a manager. His own firm nearly kicked him out, if you recall. All fact. Look it up.
"Disney is a corporation, the artists etc etc are the people."
Irrelevant. You are tossing out the entire context of this thread.
By this logic, you could also say that Chrysler does not make automobiles, and Apple does not make computers.
In a very technical, ridiculously hair-splitting sense you are correct, but in a way that is irrelevant to the whole point of the conversation that is going on here.