It looks like you're using GAE. Not having much experience with it, I'm wondering if GAE provides the CPU jailing, or did you have to write some voodoo yourself?
I ask because it's trivially easy to send a statement containing a single bytecode that takes a really long time to execute, at least in CPython:
>>> print 999 * 0 # => 0, so not a bandwidth issue
If I send this to your backend in a bunch of tabs (I didn't) could that be a DoS?
Also, are you thinking of putting the backend code on github?
EDIT: HN swallowed my exponentiation. That should read "print nine to the nine to the nine, times zero". Without the times zero, that's a huge number.
Text after a blank line that is indented by two or more spaces is reproduced verbatim. http://news.ycombinator.com/formatdoc (the help link is in the bottom-right corner)
On the other hand, in Dvorak, Q is directly above the left ⌘ key (where X usually is), and W is directly above the right ⌘ key (where , usually is). I'm always reminded of this serendipitous symmetry whenever people complain about ⌘Q and ⌘W being adjacent on QWERTY.
Bravo! Seeing this app makes me want to get an iPad just to play around with it. Well, almost:
As a fairly serious amateur pianist, I definitely appreciate that this could let me ditch my dusty bookshelf of heavy scores, turn pages for me, and keep track of my location on the page. But the real deal-breaker for me is that it doesn't look like I can annotate the music with fingerings and expressive marks. When first learning a piece I probably spend as much time scribbling on the score [in pencil!] as I do reading it with fingers.
This would still be immensely useful for sight-reading though, where page-turns are a much bigger issue than fingering and expression. But it seems ironic to start out learning a piece with Etude, only to graduate back to paper later.
All in all though, this is some really exciting technology.
Nitpick: the built-in synthesizer seems to have a pretty lazy right foot. Pedagogically speaking it'd actually be better to drop the pedaling altogether rather than obscure the harmony -- make it a setting? Even better: make it respect pedaling marks in the score!
That's an extreme example. How many people are going to fight to keep their home after having power and water cut and a 30-foot pit dug around it?
Keep in mind that on the whole, Chinese people are much more likely to give up personal property/liberty for the benefit of the state. It's a massive generalization of course, but the difference between Chinese and American mindsets is really significant.
Disclaimer: I was a Director of 6.370 for four years, so I think I have a decent understanding of your requirements and the motivations behind them.
As you mentioned, using bytecodes to measure computation time is a good approach since it results in deterministic gameplay -- and that's one of the reasons 6.370 stuck with Java for so long. A nice corollary to this approach is that if you can instrument the contestants' bytecodes, you can easily run your game engine alongside contestant code in the same VM, which is a pretty clean and fast architecture. And of course that still allows for JIT compilation if you really care about speed.
As for the programming language, I'd cast a vote for Python, since it shouldn't be too hard to instrument [I've never tried] and contestants will be happier coding in a more productive language. If you want to keep Java around, I believe Jython compiles Python source to Java bytecode, under the hood. Java contestants would have a home turf advantage, but perhaps the Python language is worth it? I don't know anything off the top of my head about compiling Java source to Python bytecode, but I imagine that situation would put Java at a heavy disadvantage.
Of course, any bytecode will work, so if you're considering going multi-lingual an obvious suggestion would be the .NET CIL which nets you all languages in the .NET framework. But my impression, at least from my time at MIT, is that contestants would be less happy with .NET.
You could also just instrument machine code. Piece of cake right?
On the penultimate paragraph, and somewhat of a tangent:
Wow, I'd completely forgotten that you could have Unicode in domain names, and I suspect a lot of people don't think about it very much either. In my limited experience, even Chinese-only websites rarely stray from normal alphanumeric domains, even though the people visiting those sites could easily type out URLs with Chinese glyphs.
Perhaps I'm missing something here, but it seems that with good alphanumeric domains becoming less available, cool/clever/classy Unicode domains could be a viable alternative, given an appropriate purpose -- Google would probably not want one -- and a techie enough audience. When [for which sites?] and how often do people actually type URLs?
Example: a friend of mine did a cheeky web branding project a while ago named "Heart Star Heart"... ♥★♥.com would have been perfect.
EDIT: I should probably do more research on this myself, but it looks like there's some mysterious isomorphism between Unicode domains and "normal" domains. Firefox renders U+272A in http://✪df.ws/e7m correctly but changes its text to http://xn--df-oiy.ws/e7m and when I access ♥★♥.com my ISP complains that xn--p3hxmb.com doesn't exist. Anybody know what the isomorphism actually is?
I believe it has something to do with security, when browsers first added unicode url support there were issues with hackers and spammers using blank and lookalike unicode characters to trick people into visiting shady domains.
That said, non-ASCII URLs suck because not everyone can type them. Imagine being a tourist in Tokyo who has to lookup a restaurant on your laptop or having to lookup the product page for this gadget you bought in China…
Right. As I noted above, it's absolutely not acceptable for some situations, particularly those where you want lost or confused people to look you up. But I can still think of plenty of other situations, and was merely pointing out the disparity between the number of Unicode URLs I've encountered and the number I'd expect to have encountered, given all the possibilities.
Extrapolating strictly from my own browsing behavior while reading the first few on this list, I've noticed that the more interesting I find an article, the more tabs to linked Wikipedia articles I open up for further reading.
Of course, articles with more links are likely to spawn more tabs, so this score would be expressed as a fraction of the total links in the article that were followed.
That's just for starters; none of this considers the actual text of the article. Once you throw in semantics...
EDIT: I generally don't follow links to articles on more well-known topics [e.g. places], but that shouldn't penalize the article. So there needs to be a ranking for well-known-ness, and consider the fraction of followed links to articles that are less well-known.
Agreed. One of the most important skills I picked up in college was not the ability to code in whatever the hot language du jour was, but the ability to learn a new language quickly, and to pick out its important characteristics: Garbage collection? Dynamic typing? Closures?
After that, yes, it's nice to be fluent in a fast, productive language like Python, and to understand a lower-level one like C.
I ask because it's trivially easy to send a statement containing a single bytecode that takes a really long time to execute, at least in CPython:
>>> print 999 * 0 # => 0, so not a bandwidth issue
If I send this to your backend in a bunch of tabs (I didn't) could that be a DoS?
Also, are you thinking of putting the backend code on github?
EDIT: HN swallowed my exponentiation. That should read "print nine to the nine to the nine, times zero". Without the times zero, that's a huge number.