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

321–324 of 324 posts

Re: Ten predictions (2004)

#321

Post by dspillett »

zanny wrote: post #259
dspillett wrote: post #82

Earlier quoted context omitted.

3. Multi-threaded programming will fall out of favor by 2012. Not really. We are already in the multicore age, and it will only get moreticore. A lot of things server-side are moving back towards multiple processes rather than threading, driven by "cloud" based scaling: if you code is designed to handle being spread over many nodes then why complicate things by having two concurrency models on the go at once (threads…

> (threads at host level, multiple processes spread over the hosts) Concurrent programming isn't all "jump off a cliff into the atomic and mutex lock sea and worry about deadlock or run everything in serial". There is a middle ground where you take apart the easily discretized parts of your task at hand, that have little or no communication between them, and thread those. For example, if you have a system to scrape a…

I wasn't meaning to suggest it was (or should be) considered dangerous: just that supporting two concurrency models it that same time is a complication many would prefer not to bother with unless their application really needs the efficiency boost threading may offer within a single process on a single node. Unless you can justify working with both due to some measurable and significant efficiency gain or don't need multi-host scaling you go with the option you have to have (multiple processes).

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.

Re: Ten predictions (2004)

#322

Post by ramses0 »

mattmanser wrote: post #289
ramses0 wrote: post #202

Earlier quoted context omitted.

XML has a few issues compared to JSON: * attributes v. tagnames * no "anonymous list" * infinitely large surface area [ {name: joe, age: 12 }, {name: bob, age: 23} ] joe 12 bob 23 The access pattern for json is much easier: obj[1].name The infinitely large surface area of XML is painful. Namespaces, entities, xsd/schema, cdata, cdata-in-cdata. It's an alright data / interchange format and especially suited to certain…

{'users': [{'name': 'joe', 'age': '12' }, {'name': 'bob', 'age': '23'}]}

Yeah, that's cool and all, but I avoided using XML with attributes because attributes can't / don't nest.

{ name: 'joe', dob: { m: 1, d: 2, y: 1934 } }

joe121934

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.

Re: Ten predictions (2004)

#324

Post by androidexample »

Yhippa wrote: post #236
csense wrote: post #233

Earlier quoted context omitted.

1. What's a good tutorial to learn JAXB and JAX-RS? 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…

http://www.mkyong.com/webservices/jax-rs/integrate-jackson-w... http://www.mkyong.com/webservices/jax-rs/download-xml-file-f... This got me up to speed pretty quickly to learn JAX-RS providing XML and JSON.

Camera Photo Capture And Show Captured Photo On Activity

http://androidexample.com/Camera_Photo_Capture_And_Show_Capt...

Post reply on HN