Dude spent his last years trying to cause pain and suffering in other people. What a waste of a life.

Commenting for the first time in over ten years...

*EVERYONE* at Google is required to take courses about how to carefully write things with a mind to legal discovery (ie, *anything* you write needs to done with an assumption that it will be used in the most negative possible way, regardless of actual intent on your part). There's no way this person didn't know that.

First Solar only does photovoltaics, so no birds will be incinerated.

No, that is 100% wrong.

The purpose of QA isn't to *find* bugs; the purpose of QA is to *verify* that *there are no bugs*.

If you are giving something to QA with unknown deficiencies, and expect them to find them for you, you should be looking for another line of work.

(Known deficiencies of a work-in-progress are a different story, of course...)

Code review is purposefully a politically loaded process which enables management to divide and conquer and keep wages down.

You must have an awfully dysfunctional management. On my current team, code reviews came about by demand from the engineers, not from management.

Re: anonymous code reviews, meh, that could be made to work, I guess, but I don't see the point -- I'd rather have a discussion in the open.

> Compared to a Silverlight solution, the JS player is 3.5 times larger (535kb vs 154kb), uses about 3.6 times as
> much CPU power (25% vs 7%), and has to have significant modifications to work in multiple browsers. Not really progress. ...compared to a Flash solution, the JS player is >100 times larger (a Flash version could be under, say, 4k, including UI, since the MP3 decoder is built in).

My 20-year-old dead-tree comics are still readable. (And yes, I still re-read the good ones.)

Will the same be true of the digital versions? Magic 8-Ball says, "Signs point to No".

Optional type annotations (a la ActionScript3) were considered for JavaScript in the ECMAScript4 standard, but the committee decided it didn't want to go in that direction.

See also http://www.masonchang.com/blog/2011/4/21/tamarin-on-llvm-more-numbers.html for a take on trying to use LLVM for ActionScript.

A guy did in fact transplant LLVM in place of Nanojit (in Tamarin rather than SpiderMonkey, but close enough):

http://www.masonchang.com/blog/2011/4/21/tamarin-on-llvm-more-numbers.html

And found that LLVM didn't really produce an overall win for this sort of code generation. LLVM is nice for ahead-of-time-compilation, but isn't a good fit for just-in-time.

Same is true of the Flash vuln -- it was patched by Adobe on March 21.

This isn't a remote exploit. It's a Flash file that was embedded in an Excel file that was emailed and opened on a local system.

Err... how did parent get modded "offtopic"? It's precisely ON topic in terms of a reply; a vulnerability that allows a jailbreak is no less a vulnerability that allows an exploit. They're both an "own the system" gambit.

Smaller does NOT automatically mean "easier to read", in Python I often find the opposite is the case.

If I'm scrolling through unfamiliar Python code and see

      def foo(somearg):

If I want to know the expectations of "somearg" I'm going to have to (1) hope for a comment, (2) analyze the body of foo, or (3) analyze all the callers of foo. Or some combination.

If I'm scrolling thru similar Java code and see

      public function void foo(SomeType somearg)

I have a much better idea about the input specifications.

Stop right there: it's not a question of writing, it's a question of reading.

I spend *waaaaay* more time *reading existing code* than I do writing new code. Designing a language to optimize readability is IMHO far more important than trying to save a few keystrokes.

In the example above, I find the Java syntax completely readable, though clearly not as terse as it could be. The second example I find readable as well, but not vastly more so than the Java example.

If you're optimizing for coding time, you're doing it wrong.