Live data from Hacker News

Ten predictions (2004)

sites.google.com

271–280 of 324 posts

Re: Ten predictions (2004)

#271
post #118

Earlier 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 was thinking more of StackOverflow as an answer to this one.

Same, Steve Yegge doesn't use facebook.

Re: Ten predictions (2004)

#272
Steve Yegge is usually a talented and entertaining writer. Having said that, his strengths lie in writing about computer science and far less in actually creating real systems. These predictions aren't very good (as time as shown) and are on par with the poor judgment he exercised in bashing his former employer in a 'private' post.

Re: Ten predictions (2004)

#273

Earlier quoted context omitted.

Ah, sorry. I thought they were still in start-up mode. It does seem a bit early for them to be turning a profit; I hope they are investing enough.

So, you were assuming that they weren't making a profit based on some sort of gut feeling that they were "still in start-up mode", but you used quite absolute language suggesting personal knowledge of the state of their books.

Why the heck would GitHub take $100 million in investment and still push for earning a profit every quarter? Does it make any sense to you? Now you can see why I'm confused.

Re: Ten predictions (2004)

#274

Earlier quoted context omitted.

> We got NoSQL (esp. JSON based ones) instead of XML. Close enough though. 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 forma…

It's true that JSON document databases very closely follow the model set out by earlier XML document databases, and have succeeded for the reason Yegge spelled out. 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 woul…

JSON is traditional: dictionaries, arrays. OO languages have built-in syntax to deal with those, via [] and dot notation, and the array objects nowadays have ways to do map() apply() grep() etc. on the collections.

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.

Re: Ten predictions (2004)

#275

Earlier quoted context omitted.

So, you were assuming that they weren't making a profit based on some sort of gut feeling that they were "still in start-up mode", but you used quite absolute language suggesting personal knowledge of the state of their books.

Why the heck would GitHub take $100 million in investment and still push for earning a profit every quarter? Does it make any sense to you? Now you can see why I'm confused.

The idea that taking investment automatically means you would actively forgo earning a profit is kinda odd. You take investment to grow, not because you have an allergy to profits.

Re: Ten predictions (2004)

#276

Earlier quoted context omitted.

What about bob?

I'm sure you're capable of filling in the pattern with yourself.

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.

Re: Ten predictions (2004)

#277

Earlier quoted context omitted.

So, you were assuming that they weren't making a profit based on some sort of gut feeling that they were "still in start-up mode", but you used quite absolute language suggesting personal knowledge of the state of their books.

Why the heck would GitHub take $100 million in investment and still push for earning a profit every quarter? Does it make any sense to you? Now you can see why I'm confused.

I get the feeling we don't know why yet.

Re: Ten predictions (2004)

#278

Earlier 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 the capacity of being as simple as you want it to be 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 standard…

Guarantee? Do you actually know how "enterprise" projects work?

Re: Ten predictions (2004)

#279
post #275

Earlier quoted context omitted.

Why the heck would GitHub take $100 million in investment and still push for earning a profit every quarter? Does it make any sense to you? Now you can see why I'm confused.

The idea that taking investment automatically means you would actively forgo earning a profit is kinda odd. You take investment to grow, not because you have an allergy to profits.

Not really. Say you take $100 million in finance, so you are now $100 million in debt and you are probably not going to put the money in the bank, but spend it. When you spend (invest) the money, that is taken away from earnings and you can spend more than you earn thanks to the financing. Even if the company's valuation goes up because of these investments, they are still taking a loss now. You have to take a hit now to grow and earn more later.

I'm not an accountant, and this is just my uninformed understanding.

Re: Ten predictions (2004)

#280

Earlier quoted context omitted.

XML has the capacity of being as simple as you want it to be 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 standard…

Guarantee? Do you actually know how "enterprise" projects work?

bank of america, t. rowe price, wall st on demand, ebay, aflac, adobe, ge, nielson, navy federal...do you want me to open my entire client archive? You should see what java devs try to shove into xml structures.
Post reply on HN