I'm a huge fan of Surprise/Unknown Language Round competition format. Theoretically I enjoy participating in them, but in practice I mostly run them. What's so special about them that makes me like them so much?

1. They are unusual. At some point of time (which arrived pretty soon for me) traditional competitions pall and become a blur. If I give it a thought, I can clearly remember only a couple of the 80 SRMS and CF rounds I've done. The SRM which featured MooresLaw problem (great challenge phase and my only ever room win), TCO elimination round which I passed thanks to a last-minute submission on 500pt, a GCJ round from back when it was held on TopCoder platform, when I got stuck at input parsing and never got to the actual solution... and that's all. Marathon memory is a bit better, probably because I've participated in fewer of them, and each match took more time and effort. But unusual competitions leave the most lasting and vivid impression.

2. They fit my skills. I'm not the one to get intimidated, let alone scared by a language which misses loops, strings or anything else from the commonly used programmer's toolkit. Well, there are a couple of languages which I'm uneasy about, but they are very unlikely to appear in an ULR. Other than that, I really enjoy digging through manuals for something weird (especially when they exist), getting sudden enlightenment about the ways of the language, and finally seeing my code combined from pieces of samples starting to work.

3. They have practical use. After the round (before if I'm the writer) the newly learned language joins the exhibit at Progopedia and RosettaCode.

4. Post-round comments. It's amazing how people are unequally accustomed to languages other than C++, and how emotional they can get about it :-)

From the problemsetter's prospective, an ULR has some more advantages over a Div2 round. The essence is that preparing ULR is easier: simpler problems lead to shorter statements, simpler reference solutions, validators and test generators (not to mention that you can borrow some of them from the previous rounds), less testers' criticism and last-minute changes, and finally fewer questions during the round (though there always is this "Why, isn't C++ allowed?" which never ceases to surprise me). The drawbacks include more problems to prepare (which is hard on its own) and less participation (Befunge round, the best one ever, had 340 participants — any Div2 beats that). However, I hope that in due time (there are plenty of languages to last for decades) the format will win its audience, and the contests will become more populous.

What's that all about? Personally I (though I bet MikeMirzayanov will second me here) would love to see more Surprise Language Rounds, nice and versatile. And it's not enough to pick a fancy language for that — you'd also need a problemsetter who will choose it, learn it (or freshen memory of it) and convert it into a reach full problem set. A single me is not enough for this role (not to mention that I feel like participating sometimes). That's why I'll let myself offer some advice to a would-be ULR writer — you never know what might inspire a person :-)

The key element to the round success is a proper language choice. You hardly can overestimate the importance of this:

• Red-pencil any language which doesn't let one write 10 distinct problems right away (HQ9+).
• There was never a story sadder than that of an "unknown and surprise" procedural language with C- or Pascal-like syntax! Let it differ from the mainstream ones in some subtle detail of object-oriented paradigm implementation or garbage collection, in being web-oriented or suited for team development — you won't be able to select problems which show it in two hours allocated for the contest. So you'll have to shift the focus of the round from learning a whole-new paradigm to solving the good old algorithmic problems with a twist in syntax and library functions — and that's not what you want.
• The language must allow a flying start. How tricky is it to install the compiler and run the sample program? How much information is there about the language — a whole website or a single page? How many example programs are there — a couple included in the distribution or a couple hundred spread over various blogs and programming chrestomathies? For example, Agda requires a ton of effort to install it — I've never managed to do it and had to ask my husband for assistance :-) A lot of lovely esoteric languages are ruled out here, since they have a total of two programs written in them, and one of these is Hello, World!
• Besides, the language has to be available for all major platforms. An Android interpreter is optional, but Windows (for testing system) and Linux (equal rights to Linux users! including me) are a must. Online interpreters are also convenient (make sure that all compiles and interpreters you provide work in the same way as the one you use for testing submissions). I'm not sure whether to recommend ideone if it has the language — I use this site on a regular basis, but most people either don't understand that they have to keep their submissions private (though I note this in each announcement!) or they don't care much about it, while they really should.
• The language must not irritate the programmer. Well, of course any language has people irritated by it (or should I say, there exist people who are irritated by any language?), but if the language unnerves even you, the problemsetter, there's probably something wrong about it. Actually, that's why the COBOL round had only 5 problems: by the time I solved the fifth one, I felt positively fed up with it. I won't give a round in Brainfuck any time soon not only because it's relatively well-known, but also because coding in it requires not just ingenuity but also a lot of patience and attention.
• The choice of the language for a particular round depends not only on its charm itself, but also on the languages featured in the previous rounds. Having two similar languages in consecutive rounds is bad — after all, an ULR is the chance to learn something new, not to repeat what you've done a month ago. The similarity is estimated not by the syntax or general appearance of the programs, but rather based on the main paradigms of the language. Befunge is a stack-based esoteric language, so other esoteric languages (90% of them are based on this or that form of stack usage) will have to wait for a couple of rounds (hmm, looks like these couple of rounds have already passed...). Is COBOL a retro-language? Ada and ALGOL have to be postponed.

Ok, let's assume you've followed the advice and decided on the language you're going to use. Now it's time to select the problems.

An ULR should have 7-10 problems of varying difficulties: one absolutely trivial, a couple of simple ones, several medium-level and one or two hard ones. Ideally each participant should be able to solve a problem or two, and there should be a person (or several) who solve all problems. The experience of the previous rounds makes me want to shift the balance towards easier problems: spending two hours and being unable to solve anything is really upsetting. Have a look at the previous rounds stats to see what I mean. Don't jump to conclusions, though, because there are too many factors distorting the results (whether the round is held on a weekend or on a weekday, how much publicity did it get, whether the participation has any benefits etc.).

How to select the contents of the problems? Personally I believe that the problems should be not about solving something, but rather about implementing it, so the problems should be simple and evident, with a focus on coding them. Different problems of the same complexity levels should highlight various aspects of the language (for example, math, processing arrays and processing strings), while problems of increasing complexity should introduce new concepts (for example, loops and "memory access" in Befunge).

Note that estimating the problem complexity adequately is hard, maybe even harder than in regular rounds. The author writes the problem while already knowing the language and the supposed solution, and despite this it takes a lot of time; it's going to be even harder for the contestant. If coding a problem takes me over half an hour (and at most ten minutes for "easy" problems), I just won't put it into the round, despite of how much I like it.

Inventing so many (compared to a typical Div2 round) simple problems might look tricky, especially if they have to cover various aspects of the language. My constant source of inspiration is RosettaCode — a collection of tasks and sample codes in various languages. Of course, you get to choose only from tasks which are not solved yet in the round language, otherwise there's not much point in them. Sometimes I borrow a problem from previous rounds — they allow me to show how much solutions to the same task in various paradigms differ, and to save effort on preparing the infrastructure of the problem. Harder problems need some consideration, but were problemsetting trivial, the problemsetter profession would be extinct :-)

I guess that's all advice which can be given to a starter ULR writer without going down to "ok, so here's this cool language, here is the list of problems, go ahead" :-) I'll round this up by suggesting a couple of ideas to popularize the ULR format — I will consider my evangelist mission complete not sooner than each round will attract at least 500 people who solve at least one problem each.

1. Ratings. An evident idea for contests held on a regular basis using fixed format is introducing a rating based on their results. That's incredible, but a lot of people enjoy watching the change of digits in their profile and even doing things to change them in the desired direction. A catchy name to reflect the concept of the rounds — something based on "geek" or at least "polyglot" — and you're set.

2. Prizes. If there is one thing people like more than ratings, that's the prizes — the material footprints of the victories. An ULR is a great chance to win something — say, a t-shirt — not only for algorithmists who already have plenty of them, but also for mere mortals who value them over ermine. I don't really know how much it costs in Russia, but I bet one t-shirt with an ironic print (say, "I've learned (language name) in tree hours and all I got is this stupid t-shirt!") for the winner is affordable, isn't it?

3. Achievements. Personally I'm not too enthusiastic about the badges in the profile, but introducing something simple like stars with note "(language name)" and color based on round success would be nice. By the way, the same goes for other achievements — like Cormen medal or winning a Codeforces-based championship.

That's all for today. See you at the next ULR — by the way, who's preparing it? :-)