Would a class-writing code golf challenge be appropriate?

Question

There are a lot of challenges that get you to write programs and/or functions, but (almost) none that get you to write classes. I thought of a way to lay out class-writing challenges - it's quite specific (and might be a bit longer than a code-golf challenge of similar complexity), but does ensure that the challenge is unambiguous and fair for all users.

Questions would include:

• An interface section which describes what public variables/functions the class should have, including the name of the functions and any parameters and return values. The underlying mechanics of the class are up to the user.
• A demo section: an algorithm/some pseudocode that describes a program that will be used in order to test the class. The demo code is separate from the class implementation, so its length not included in the submission's character count. This section exists so that any other user can quickly test a submission using the same code.
• Specifying any disallowances that would make the challenge trivial (e.g. already existing implementations of the challenge, where the user's class just acts as a wrapper). These may be implicit as per the standard loopholes.

Answers would include:

• A class code section, which contains the implementation of the class as described. Essentially, this is the same as any other code golf challenge - the user posts their character length and tries to get the lowest score!
• A demo code section, which contains the code for a program that can be run in order to test the user's class. This should perform the tests that were mentioned in the question. This section's code is not included in the character count.

For example, a challenge to write an integer queue class may be laid out like this:

• The interface would include functions such as push(), peek() and pop().
• The demo pseudocode would contain things such as "push 12 to the queue, then pop an item from the queue and print it to the screen, then add all of the integers from [0-100) to the queue"...
• The disallowances would include barring any existing implementations of a queue or dynamic data structure (e.g. std::queue<T>, std::deque<T>, std::vector<T>, std::list<T>... in C++).

Here's why I think these types of challenges are a good idea:

• It encourages usage of "less popular" languages, as none of the Big Three (Small Three?) - Pyth, CJam and GolfScript - are object-oriented.
• The usage of named functions ensures that everyone's code has the same interface. It would also expose cheating (e.g. reducing print() to p()).
• Class challenges could introduce some new and interesting simple questions (which I personally prefer to the more complex/mathematically demanding challenges), but there is scope to expand these to something more complex.

I'd like to know what you think. Feel free to make any suggestions or changes.

Answer 1

I'm not going to say it's inappropriate, but I personally don't see the advantages you list.

It encourages usage of "less popular" languages, as none of the Big Three (Small Three?) - Pyth, CJam and GolfScript - are object-oriented.

I don't really think those three languages are as popular as you think. According to this query, at least, the top three languages on the site are Python, Javascript, and Ruby. C, Perl and Haskell are all ahead of any of those three as well, and Java has about as many as Cjam or Golfscript.

The usage of named functions ensures that everyone's code has the same interface. It would also expose cheating (e.g. reducing print() to p()).

I'm not sure how reducing the name of a function is "cheating". If everybody's code uses print(), it's seven characters. If they use p() instead, it's three, but this is a standard reduction, and it's even in the code golf tag wiki. It's not like one guy is winning these things by doing it, everybody should be.

Class challenges could introduce some new and interesting simple questions (which I personally prefer to the more complex/mathematically demanding challenges), but there is scope to expand these to something more complex.

Maybe I'm just seeing it wrong, but to me it sounds like it adds more boilerplate without more functionality. If a challenge is simple, and is only remotely interesting because it's "in a class", I would just skip on by. It was a good day when writing a function (rather than a full program) became a default option here, because boilerplate just isn't fun, at least not to me.