This question is because my favorite language C++ does not lend itself to code golf. Now I could try and pick up a new scripting language (like golf-script) or brush up on an old favorite (perl), but that takes time.

I was wondering if introducing a language handicap could help level the playing field for those of us who have not yet had time to learn an appropriate scripting language.

The handicap for a language is the cost of reading a line and writing it back out. Thus the actual golf score is: "the number of characters in the program" - "the cost of language handicap". We could then define for the community these handicaps.

Example: C++ handicap: 109

#include <iostream>
#include <string>
int main(){std::string l;std::getline(std::cin,l);std::cout<<l<<"\n";}

Example: Golf-Script handicap: 0

Example: Perl handicap 12


I am sure the perl experts can do better (mine is rusty).

Comments on handicap idea and program needed to define handicap.

This at least would give languages like C++ a fighting chance against more compresses scripting languages.

  • 1
    \$\begingroup\$ agree, but handicap should be different on input type (as a function, from stdin, from file, etc..) imho, golfscript does not need any chars for stdin, but need 4 chars to define a function {}:f If I am not wrong. \$\endgroup\$
    – YOU
    Commented Feb 10, 2011 at 7:00
  • \$\begingroup\$ @S.Mark: If we're going that route we need to break up each solution into its fundamental composite parts, such as »ritual introduction«, »assignment«, »function definition«, »function application«, etc. and then count instructions in our newly-created abstract solution description language. I doubt it's a good idea. And it doesn't cater well for languages that don't have certain concepts but others. Single instructions have varying rages of power across different languages. An addition in J would be a loop with an addition in Java. \$\endgroup\$
    – Joey
    Commented Feb 10, 2011 at 14:03
  • \$\begingroup\$ @Joey, I couldn't agree more, thats true if we go more deep inside language components. \$\endgroup\$
    – YOU
    Commented Feb 11, 2011 at 6:13
  • 1
    \$\begingroup\$ 0 doesn't look like a factor. So shall that be a term for substraction? Java: 400 chars => 400 - 109 = 291? \$\endgroup\$ Commented Apr 13, 2011 at 2:55
  • \$\begingroup\$ print<> would be shorter. \$\endgroup\$
    – null
    Commented Jan 2, 2014 at 21:15

4 Answers 4


I have thought about this before, and I am not convinced that there is a good/fair way to represent handicaps between different languages.

There can only be one winner (accepted answer) on SE, so I think it's still best to encourage people to stretch to look for and learn languages that are better suited to each question.

As far as rep is concerned, accepted answer is only worth 1.5 upvotes, and interesting answers often get far more votes than the shortest, accepted answer

As the site grows you will find multiple answers in C++(for example), and a mini contest of continual improvement starts between those solutions.

There are already questions on this site where this has happened with Python/Ruby for exmple

  • 9
    \$\begingroup\$ In some sense, it's kinda like the different car classes on Le Mans, i.e. everyone competes together, but in different classes: Golfscript/J, Perl/Ruby/Python, C/C++/Java, ... \$\endgroup\$
    – ninjalj
    Commented Feb 10, 2011 at 1:03
  • 15
    \$\begingroup\$ Only 1.5 upvotes even. \$\endgroup\$
    – Joey
    Commented Feb 10, 2011 at 13:50
  • 1
    \$\begingroup\$ @ninjali: Unfortunately there is rarely more than one car in each class. \$\endgroup\$ Commented Feb 15, 2011 at 18:02
  • 1
    \$\begingroup\$ What about dividing answers into two parts. The part the solves the puzzle and the glue code needed by the OS. Provided a count for both parts that are needed by languages that need to specify the glue explicitly. \$\endgroup\$ Commented Feb 15, 2011 at 18:05

Not a bad idea, as such.

I mean, if the idea is to explore cleverness is using your language as choice, then so kind of handicap is clearly necessary.

And given the number of challenges that have "read input" and "write to console" parts, this metric has some validity, but it surely doesn't tell the whole story. I mean various languages I use could be accused of having various advantages and handicaps:

  • awk doesn't require anything to echo the input, but has underpowered associative arrays and needs an unnatural approach to do non-trivil stuff to more than one input file at a time
  • c has no sophisticated data structures built in, and a B&D type system
  • c++ has a better standard library, but it comes with wordy type names and still has that sex dungeon feel
  • fortran 77 has implicit type, built-in complex numbers and inline for loops in in-out-put statements, but has column requirements, lengthy keywords, and no data structures more complicated than an array.

so the degree of handicap depends in a non-trivial way on the problem posed.

Trying to set a single metric is asking for endless arguments which can only be settled by "This is the official word on the subject, so shut up already."

My "solution" has always been to vote for cleverness as well as shortness. That's not objective, and not fair insofar as I can only detect cleverness in language I comprehend, but it's better than nothing.


It seems to me that we have enough data on existing code golf problems to build a table of handicaps that would be easy to use in calculating coring for new golf questions, and further could be updated quarterly so as more expert people start using the larger languages competitively, the handicaps would become more and more accurate a representation of language size.

The easiest would be to apply multipliers - C might be multiplied by 0.45, for instance. A more accurate method would be to use a multiplier and offset, but I don't know that this is necessary, a simple multiplier might be sufficient.

Even if we don't go to such a system, I believe it would be a very interesting investigation into current code golf questions.


My view is that Code Golf challenges should have a set of instructions defined by the asker.

As it stands, someone could code a language with a single command 'a', which is the hardcoded solution to an answer. This seems ridiculous, but it not monstrously far off what some of the languages provide with only a couple of characters.

The answers should all be written in the same pseudo language. Or perhaps we could define a community golfing language as the standard for code golf questions. This would cause the whole thing to be a little more mathematical and well-defined, than "find the language that has a built-in function closest to the solution!"

My two cents :)

  • 4
    \$\begingroup\$ I don't think anyone would accept (and hopefully no-one would vote for) an answer in a language created specifically in response to the challenge post. It's true that there are some pre-existing languages which have 1 or 2 character solutions to some problems: the correct response to that isn't to ban those languages but to ask more interesting problems. \$\endgroup\$ Commented Nov 27, 2013 at 14:19

Not the answer you're looking for? Browse other questions tagged .