# Language Handicap [duplicate]

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: Perl handicap 12

\$_=<>;print


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.

• 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. – YOU Feb 10 '11 at 7:00
• @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. – Joey Feb 10 '11 at 14:03
• @Joey, I couldn't agree more, thats true if we go more deep inside language components. – YOU Feb 11 '11 at 6:13
• 0 doesn't look like a factor. So shall that be a term for substraction? Java: 400 chars => 400 - 109 = 291? – user unknown Apr 13 '11 at 2:55
• print<> would be shorter. – Konrad Borowski Jan 2 '14 at 21:15

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 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

• 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, ... – ninjalj Feb 10 '11 at 1:03
• Only 1.5 upvotes even. – Joey Feb 10 '11 at 13:50
• @ninjali: Unfortunately there is rarely more than one car in each class. – Martin York Feb 15 '11 at 18:02
• 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. – Martin York Feb 15 '11 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 :)

• 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. – Peter Taylor Nov 27 '13 at 14:19