Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ten predictions (2004)

sites.google.com

Post reply on HN
Print view View original

201–210 of 324 posts

Re: Ten predictions (2004)

#201

Post by Taylorious »

friendly_chap wrote: post #29

1. 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.…

@your answer to number 4

How do you see the market share dropping? There is this little thing called Android...

Re: Ten predictions (2004)

#202

Post by ramses0 »

corresation wrote: post #187
RyanMcGreal wrote: post #68

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…

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} ]

joe12bob23

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.

Re: Ten predictions (2004)

#203

Post by moron4hire »

justin_vanw wrote: post #186
moron4hire wrote: post #99

On the Lisp thing, looking around the programming world in 2004, you didn't see proliferation of functional concepts like you do today. In those days, "functional" meant Lisp, at least popularly. I think the big lesson of Lisp has been disseminated, though, and that is that it is more productive to write code-that-writes-code. But I also think we learned a broader lesson that it's better to not pigeon-hole people dow…

To whom did 'functional' mean the same thing as 'lisp'? I'm always astonished when people conflate these two things. Lisp encourages you to put the forms that evaluate to a value in the position you would otherwise put a variable that has been set to that value, sortof code in place. That is kindof like functional programming. However, lisp does not avoid side effects or mutability, in fact virtually all operators in…

That's an interesting point about infix and postfix calculators but no prefix calculators. Though I wouldn't go so far to say there aren't any, I feel pretty sure I've seen one before--though don't care enough to go looking--they do seem pretty rare. I wonder what lisp/scheme/whatever-I-need-to-say-to-get-you-to-stop-being-pedantic would look like with post-fix evaluation.

Re: Ten predictions (2004)

#204

Post by seanalltogether »

corresation wrote: post #187
RyanMcGreal wrote: post #68

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…

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 standardized and easier to consume.

Re: Ten predictions (2004)

#205

Post by callmeed »

friendly_chap wrote: post #29

1. 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.…

>> 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.

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.

Re: Ten predictions (2004)

#206

Post by reginaldo »

reginaldo wrote: post #196
corresation wrote: post #187

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…

I think the 50% less bulshit figure is pretty generous. Let's not forget that, unless you opt out of it, most XML parsers, when given user-generated input, will do lots of crazy stuff. In the best case scenario, the machine that parsed the input will fall victim to DoS. In the worst, we have good old remote code execution. Tipically, an attacker will be able to read lots of files from the servers and make arbitrary n…

corresation: I can't answer your post directly, so I'll answer my own. It's absolutely not vague handwaving. HTML or JSON parsers can't make arbitrary network connections. XML parsers often can.

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_...

Re: Ten predictions (2004)

#207

Post by lifeisstillgood »

justin_vanw wrote: post #195
lkrubner wrote: post #188

Earlier quoted context omitted.

I got a new job in December. This company mostly uses Ruby and PHP. I was given an assignment for which they scheduled 2 weeks. I wrote the whole thing in Clojure, my new favorite language. I got it done in 1 week (6 days). After I was done, I asked if it was okay if I used Clojure. The folks I work with had no problem with that. They asked were impressed with my speed, part of which I attribute to Clojure. I am the…

So, if I were to do your two week assignment in one day, in C, would that mean that C is much better than Clojure? What if I gave your Sysadmin a make file that would build a Debian package or RPM package rather than expecting him to maintain some complex and silly deployments system? The sysadmin would be my new best friend, but would that imply that the language I used was better? You are doing some seriously slopp…

I have to disagree - he was talking about the eco-system of clojure as well as the language.

We do get mixed up with complicated frameworks at the expense of simple (dare I say composable) solutions. Clojure is small and simple enough that it has not yet had the weight of working in a thousand different environments imposed on it.

Re: Ten predictions (2004)

#208

Post by aleyan »

zeeboo wrote: post #185
DoubleMalt wrote: post #124

Earlier quoted context omitted.

If we take your very narrow definition, the chances of any programmer to be (exactly) average are zero, if we relax a little bit we're back at tautology.

It's not my fault the definition of average is very narrow.

The definition of average[1] is not narrow. It could be mean, median, or mode or something else.

[1] http://en.wikipedia.org/wiki/Average

Re: Ten predictions (2004)

#209

Post by huxley »

friendly_chap wrote: post #29

1. 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.…

9. I agree it's a miss but since then:

* 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.

Re: Ten predictions (2004)

#210

Post by bcoates »

stiff wrote: post #170
moron4hire wrote: post #99

On the Lisp thing, looking around the programming world in 2004, you didn't see proliferation of functional concepts like you do today. In those days, "functional" meant Lisp, at least popularly. I think the big lesson of Lisp has been disseminated, though, and that is that it is more productive to write code-that-writes-code. But I also think we learned a broader lesson that it's better to not pigeon-hole people dow…

Being a "Lisp" is a very broad category and I always wondered about people calling Lisp a functional language. I would love to see a list of things that are today considered functional that originated in Lisp, I think there is not that many of them in the end. However, there is a ton of things that have nothing to do with being functional that originated or got popularized by Lisp: garbage collection, lists as the fu…

I think the common programmer considers first-class functions and closures as 'functional' features. This is from the bad old days when procedural languages didn't usually have these things.
Post reply on HN