<quote><p>Except for ending slavery, the Nazis, communism, & securing American independence, war has never solved anything.</p></quote>
There is still slavery.
There are still Nazis.
American independence is far from secure.

So that's that then. War is just a brutish, stupid way of stating one's opinion.

See what 'cursory' reading gets you? I thought the array was integral to the chip. Makes me wonder if one were to modify a Sony NEX(since the sensor is totally exposed with the lens off) with a similar array that you might get the same thing. For that matter any Canon that can employ CHDK might be able to do the same thing using a script or a special build of the firmware.

Thanks for taking the time to read it right.

I don't believe that it is. From the cursory second reading of the paper- it's a new type of sensor.

My point is that if you walked in to Mr Pointyheads office and started rattling things off like MD5, plain text or ROT-13- eyes would just roll back and he would grumble how much he hates IT and that it should just be stuffed in to the Cloud because the Cloud just works and is safe and makes toast and answers help desk support calls and installs the latest patches and and and... All while saving "8 billion dollars" of salary of those horrible IT people who just sit there an complain all the time and put up resistance to his brillian company saving 1 week implementation schedule listed on the micro-transaction slide in his power point presentation.

Or to say it another way, the patch for the web server and code that we read about here only appears to him as down time and dollars spent on surly cave dwellers- an expensive line item for the unwashed that he will be forced to comprehend.

And this is the same guy who will have moved on to some other department when the DB containing all the credit cards and passwords ends up on a tweet and the fingers get pointed at the surly cave dwllers who have been telling Pointyhead to prioritize the patch over his ill thought through bullet points.

Sorry. These stories really touch a nerve with me.

Doesn't this all eerily fit in with the slashdot story about the hating of IT and all the Anon 'hacking' activity lately? Or should I just keep my mouth shut?

This is probably the clearest explanation I have seen of this problem in ever. Yes, in ever. It makes it look just as nice as it can which is ugly as hell. If I may hang on to it to share?

Also, I was looking around the other day for 'promise' type stuff in JS and found this:
http://blog.jcoglan.com/2011/03/05/translation-from-haskell-to-javascript-of-selected-portions-of-the-best-introduction-to-monads-ive-ever-read/

Ahh gotcha. Have never actually run in to that being a problem. I guess that's from know that is one of the quirks is helpful and allows me to code with that in mind. Now, I am just beginning work on a pure JS application. Perhaps it will come up there. Lots of fingers in this pie.

Crazy rules for var? Like every child object of the object in which var is declared has access to that variable? Doesn't sound like too much mayhem if you use closure. And for scoped code like interfaces I quite like the 'require' pattern. var Foo = require(foo.js); Where foo.js: require.exports = {random assortment of scoped objects}

I don't see these as cleanup problems, just ability to write clean code to begin with.

Although I am not sure I am getting to the root of your issue. The problem isn't really clear.

Dunno if I would have worded it quite that way. Probably would have left out the fucks. I probably would have gone on to say that both Ruby and Python syntax are absurd to look at and decipher if you are blessed with the gift of understanding C-like syntax. The notion that white space is syntactically crucial is ridiculous.

Nah, the Ruby/Python quirks are as numerous and odd as JS so it appears that the thesis of the parent's statement is mostly invalid.

Here's an idea- don't be a lazy good-for-nothing and use 'this'. Try working with var self = this. You'll find your headache magically disappears because scope is clear.

And I'll betcha a fin that little piece of advice is in the book. It's in Javascript: The Good Parts.

http://www.html5rocks.com/tutorials/workers/basics/

There's probably a lot of concurrency one could get away with using workers.

Yes- I agree with you on this. JS is simple but you should always be concerned with handling data asynchro- especially with JS where one frozen or busy thread will bring the whole thing to a halt. <Ballmer>Callbacks, callbacks, callbacks</Ballmer>

And if anyone is up for some reading this series is pretty nice:
http://howtonode.org/object-graphs

As well as 'JavaScript: The Good Parts'- Douglass Crockford

Uhh, I quite like how the module and 'require' patterns work in JS. <-- read: I am extolling their virtues. I am a big fan of quick and dirty object decoration as well (as long as you keep it in the closure). Webworkers do processing in other threads. And V8 has a whole debugging API.

Never have been entirely sure why people are so quick to pee all over JS. After having done Perl, Python, C# and Actionscript for corporate production as well as private there are benefits to all of them (less so Actionscript after learning how to deal with the wild nature of JS). I guess it'a all about knowing when to hold them, when to fold them and when to walk away.

Are you saying that you keep the product managers and marketing from feature bombing you 3 days from code complete by employing some magical force barrier? DO WANT!

Well, as there is no retooling to do on motor production (hydrogen can be used in existing conventional internal combustion engines with some slight modifications) and you have stuff like this:

http://www.physorg.com/news183914624.html

And there are no tons of terrifically toxic battery waste to deal with, I'd say it's cleaner than burning existing fuel (even biodiesel), generating new electric motor models and batteries and knocks off a whole set delivery and production supply chains.