I would really, really love to know the answer to this too.

It's hard to describe my surprise that my 5-year-old PC, with a low power 1.6Ghz CPU, can easily breach 100fps while playing JamLegend, and my 9-month old, dual-core 2.66Ghz MacBook Pro can barely squeak out 40fps.

Speaking of framerate in Flash, setting the framerate on a particular SWF does not actually make the SWF run at that framerate, even if the client machine can run at that framerate. Rather, the framerate seems to be more a measure of CPU resources dedicated to running the SWF.

For example, back to JamLegend: My MBP can run JamLegend at 40fps, but not if the framerate is set to 40fps. If it's set to 40fps, I'll get 20. It it's set to 60fps, I'll get 30. In order to get 40fps, the framerate has to be set to 100. Meanwhile, on my old XP machine, setting it to 40 gets 40, 60->60, and 100->100.

So, very good question, why is it that Flash performance is so different on OS X than Windows?

True on the framerate -- it's an upper gate. Static video which overburdens a configuration can drop frames to keep up. But interactive presentations need to display each intended frame, and so will drop framerate instead. More here: http://www.kaourantin.net/2006/05/frame-rates-in-flash-playe...

For the "why", that's Adobe Corp's tale to tell, but I haven't yet met a person inside Adobe who wouldn't be very, very happy if Mac/Win performance differences could be made to disappear.

That's a great link, I had not seen that article before. Though, in practice,the actual framerate to vary from the specified by much more than the -10 / +5 fps that he lists.

His final sentences might be relevant to this topic:

On high CPU load we might actually cut [the max framerate] into half, e.g. 30 frames/sec. OS X already does this in certain conditions.

Wish he had expanded on that a little more. Any idea what conditions cause OS X to halve the framerate?

Criticizing Dustin for an incident regarding which you have not sought his side is very poor form. Similarly, criticizing his argument ad hominem highlights only your own bias without refuting or examining any of his points.

To quote John Stewart Mill here, "He who knows only his own side of the case, knows little of that. His reasons may be good, and no one may have been able to refute them. But if he is equally unable to refute the reasons on the opposite side; if he does not so much as know what they are, he has no ground for preferring either opinion."

Nice! That's great to hear, since it's always perplexing when native code ISN'T the fastest... Kind of makes you have to ask, "If there is a better way, why isn't that the native way?" But, for Tamarin, that question will be moot.

Cuil made it on in the special category for the "Failure to Launch" award as did MobileMe.

Hm. Cuil didn't fail to launch so much as it failed at launch.

Hmmm... a larger version of the most annoying kind of flash ad on the web. I want those 15 seconds of my life back.

In case "viral" and some CNN buzzwords weren't giveaways :).

I think it's catering to the masses not the typical HN crowd, but it appears to be an experiment, which is kinda fun.

I'm more interested in the results than the game itself.

This is something we looked at for a while when starting out, and even posted on HN to ask about (http://news.ycombinator.com/item?id=203864). In the end, we chose Flex because it seemed like we could get good enough performance while enjoying the benefits of quicker development. We mostly use pure AS3, but we saved some time with a few components. Hopefully someday we can strip those out and cut the Flex framework overhead.

But yes, Flash player has an unpredictably crappy internal clock and performance varies significantly based on the browser and OS, so synchronizing the notes with the music has been a challenge. For the most part, I think we've done a fairly good job compared to the existing players. We scale intense tasks dynamically in game but there is definitely room to improve (custom a/v delay, controller delay, really-crappy-performance mode, etc).

Sorry, I made a mistake: I was thinking you are producing sound when the player hits a key - but you aren't. I think that's not part of the "guitar hero" concept anyway (it is in a drum version I saw in an arcade; a different story).

Anyway, I found that java can play user-triggered sounds instantly (or perceived as such), whereas Flash can't. I experimented with this in Flash, researched it/asked about it on FlashKit - and all the Flash music games I found with triggered sounds suffered from this same problem. So it's very likely true, but not relevant for you. :-)

It's not a programming book but... "The Dream Machine: J.C.R. Licklider and the Revolution That Made Computing Personal"

It's an awesome book about the history of computing, human-computer interaction, and all sorts of things you're familiar with but may never have known where they came from or how they evolved.

http://www.amazon.com/Dream-Machine-Licklider-Revolution-Com...

Vote for JamLegend too! Gotta love the underdog in the music category...

It would be nice if all the TechCrunch trolls could go back to TechCrunch.

Those links are all to companies who have the puzzle sent in with the application, not given in the interview. Also, on that note, Joel Spolsky advises (http://www.joelonsoftware.com/articles/SortingResumes.html) that this will reduce the number of applicants you get, but not increase the quality. The reasoning is that, since great programmers will have options, including the problems will be equally likely to dissuade good candidates and bad candidates from applying and what you're left with will be desperate candidates that are willing to jump through any hoop. Perhaps just one take. Anybody that has used the with-application puzzles, how did they do for you?

As for in-interview questions, Joel also had some good advice (http://www.joelonsoftware.com/articles/GuerrillaInterviewing...), use two types of questions: (1) softballs, and (2) complex questions requiring a grasp of multiple layers of abstraction, like C pointers or recursion. With type 1, he recommends caring more about how quickly they do it than if they eventually get it right. For type 2, the goal is more to see how they think, and you're free to help them along with the trivia that is easy to forget but easy to find on Google in 15 seconds.