Poll HN: What language for a programming competition? | Hacker News Reader

Poll HN: What language for a programming competition?

For a programming competition most comparable to MIT's 6.370 that would draw from a large base of programmers, both hard core professionals and amateurs, what programming language would be most accessible for people?

The goal would be to not scare anyone away from the competition and actively encourage non/infrequent programmers to participate. At the same time, we would want the language to offer flexibility to the competitors in their approaches and styles.

Please comment on your choice and what aspects of the language influenced your decision.

EDIT: For clarification, this contest would be most directly comparable to MIT's Battlecode (6.370) http://battlecode.mit.edu/2010/info. This competition involves programming the AI for robots in a simplified RTS game. However, there's no reason why we would necesarily have to build it on the java JVM.

View on HN

The ACM international programming contest used to require either C/C++ or Java (as of 2004 that is). The thing is, aside from their server doing compiling, I don't see why it couldn't have been any other language. They were incredibly anal about getting output exactly correct for their automated script checkers, and since that worked with stdin/stdout, most programming languages would have been perfectly fine.

If you can avoid limiting which languages are allowed, do so. If you need to provide some sort of library, would XML-RPC work for it? You could easily write a client for a large number of languages.

Explain why you need to enforce one particular language instead of letting contestants pick their own?

Because the players need to plug into the game engine in real time.

What's wrong with forking off a process to handle the AI?

Text interfaces over std{in,out} are a "good thing" - especially for sandboxing and on-demand connecting/disconnecting. They also protect you from people trying to manipulate the game server.

The thing is that we would want to run the competition in a controlled environment on a local machine, and somehow enforce computation limits per turn.

If anyone has good ways of doing this across programming languages/across machines, please let me know, but something like 6.370's approach (fixed number of bytecodes per turn) seems like the most reasonable and fair.

If you try to control too much, you'll make the task harder. Just use a hard timeout. Rounds are X seconds or milliseconds.

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?

I host a similar competition at my university. We offer client binding for C++, Java, and Python. We have a C core that provides the game engine, and use code generation to generate the language specific APIs.

Here's the source we used for code generation this semester. http://github.com/joshbohde/megaminer-framework/tree/megamin...

We used templates to create the game stuff. Unfortunately, it's not quite a stand-alone library, but hopefully someone else can use it.

It really depends on what are the questions like and whether you're concentrating on the result or the design. If you're concentrating on the results only, then I would recommend the standard acm judge (and similar competitions) technique - put the input on standard input and get the output from standard output. This way you can support all the languages that you're able to run (and you will get less people saying that they cannot use their favourite language X). But choose languages you know how to compile - I remember one competition from highschool times where Pascal people had their code optimised by default, but C people didn't - that sucked.

If it's about design, then look at your audience... there's not that much of a difference between python and java - just choose one. Although with java you'll get loads more boilerplate code which might be tedious to look through.

Just read your edit. If "under the hood it runs a Java virtual machine loaded up with its team's player program" still applies, then I don't see a reason not to allow any language which can run on jvm. (java, scala, jruby, jython, groovy, ...)

Why specify the language? Any language should be a possible choice. What is the purpose of the contest? If it is about demonstrating the team's skills at solving a well specified problem, the choice of language should be part of the solution, not the problem statement. Languages get chosen for a variety of reasons including familiarity, ease of interface to supporting systems like game engines, and so forth. But that is precisely why you ought to let the teams make their own choices, good or bad.

On the other hand, if you are interested in leveling the playing field and removing rote skills, you might consider specifying a language with which the teams are unfamiliar such as go, erlang, clojure, or the like. That will tend to force the programming team to think about what they are trying to accomplish in abstract, conceptual terms rather than just hacking.

Perl, Javascript, or Ruby might be worth considering too.

If you restrict it to a specific language then the judging will be skewed towards "how well do you know language X" instead of "how well can you translate the problem into data+algorithms." However, allowing multiple languages might bias the competition into a language rather than a programmer contest. PG has said (somewhere, can't find the ref) that one reason they were able to implement ViaWeb as well and quickly as they did was the language choice - Lisp.

The logistics of supporting multiple languages might constrain that decision, of course, but a well-designed API might be more language-agnostic.

JavaScript would likely be the largest base of programmers and is certainly used by many amateurs and professionals. This would be included in the "any JVM language" option with Rhino.

BASIC. Everybody can learn it in 10 minutes (slight exaggeration). Nobody gains an advantage from having mastered some other intricate language. Non-programmers can play too.

Or, since it's for robots, why not consider a new minimalist language specifically for the competition. That way it's more about strategy instead of solving programming problems. It's tailored specifically to robot capabilities with nothing to distract or confuse.

I've heard Lua is popular for scripting game AIs, so perhaps that deserves some consideration.

Why not just let them use whatever language they want?

provide a REST api, make the whole thing a web app, provide python dev framework to get people going.

VBA -- because of office macros, it's used and understood by the most people (unfortunately)

Reply on news.ycombinator.com