Code Golf Stack Exchange is a question and answer site for programming puzzle enthusiasts and code golfers. It only takes a minute to sign up.
Sign up to join this community
Which language usually produces shorter golfed code: Pyth, CJam or Golfscript?
In asking this, I do not mean which has a prettier syntax or which has the most useful commands, I mean overall, which one is usually the shortest? What types of problems would we expect each language to have an advantage in?
There is no simple answer to this question.
GolfScript almost never beats CJam. It has a lot less built-ins than CJam and the overall syntax is a bit more verbose. For example, print and {+}* become
o and :+ in CJam.
The only exceptions are extremely trivial problems where the fact that GolfScript implicitly reads from STDIN is an advantage and the few occasions where block concatenation is useful (example).
With CJam and Pyth, it's a bit more complicated. Both languages can beat the other in particular challenges, although, by my completely unscientific observation, Pyth seems to have the upper hand on more occasions.
A few particular cases where picking one over the other is rather easy:
Choose Pyth if it has a built-in that CJam lacks and significantly simplifies the task.
For example, Pyth has r<iterable>2, which is Python's swapcase(). If that's useful in a challenge (example), it will be hard to beat with CJam.
On occasions, you have to build the output piece by piece. After finishing the program, CJam implicitly prints the entire stack, so you can just dump the pieces and let the interpreter do the rest.
For example, ascii-art challenges are usually won by CJam.
The length of a single built-in may be a decisive factor in a challenge.
Here, Pyth's C, which is shorter than CJam's 256b, was enough to outgolf CJam.
This would be longer in Pyth, partly because trigonometric functions are 3-character built-ins in Pyth and 2-character built-ins in CJam.
To sum it up, there is no single language that will magically make you win all code golf competitions. You haven't even considered APL, J, K, O, Q, TI-BASIC, Retina, Perl, sed and Mathematica, which all have beaten both CJam and Pyth in a few occasions.
You have several options:
Learn Pyth and CJam. Use the one that's more suited for each task.
Learn the one (first) you like better.
Personally, I'm crazy about stack-based languages, which I find much more easier to write and read.
Learn the one suited better for the challenges you enjoy.
ascii-art is your thing? Go with CJam. Nothing beats array-manipulation? Forget about both and learn J.
Doorknob posted the following statistics on Chat, which I understand are based on answers to existing challenges. All credit goes to him. They certainly agree what I would have imagined.
golfscript is shorter than pyth 6 times (~13.043%)
golfscript is shorter than cjam 16 times (~20.513%)
pyth is shorter than golfscript 39 times (~84.783%)
pyth is shorter than cjam 59 times (~60.204%)
cjam is shorter than golfscript 57 times (~73.077%)
cjam is shorter than pyth 31 times (~31.633%)
I was going to leave these to Doorknob to post, but I found them interesting and thought if the question is going to stay open a while longer, it would be nice to post them for posterity, before it gets closed.
Obviously the best language will depend on each specific challenge, and this data only considers the corpus of challenges that we have at the moment. A change in the type of challenges would alter the balance between the languages.
Additionally, this data reflects the state of the languages today (Aug 2015). The languages are still in development, so it will be interesting to see how they perform in later versions.
This only covers challenges where at least two of the languages participated, which is probably fairer than considering all challenges. Nevertheless, as in virtually any statistical analysis, it is arguable that there could be some selection bias. It's possible that many challenges were so suited to a particular language that the others were not even considered.
Considering that the point of code golf is to think in terms of a given language's kolmogerov complexity, in my opinion it doesn't matter much which language you use as long as you are clever. All of {Golfscript,CJam,Pyth,J} allow you to exercise creativity as do non-golfing languages. While code-golf technically claims "shortest code wins" this typically only really matters within each language. Often more important (as far as I can tell from looking at voting patterns, etc) is how creative or difficult your solution is.
For example HQ9+ while hilarious doesn't really win a 99 bottles of beer competition, because writing 9 isn't exactly showing effort. Meanwhile the Malbolge execution of 99 bottles of beer is considered incredibly cool despite being very lengthy due to its creative nature and the effort put in to make it. If HQ9+ did win we could merely define a language L which states: L outputs the solution to this problem, otherwise the code is compiled as C and executed.
This is why most old golfing sites still in operation are language-specific (Perl, Vim, C [if you count IOCCC]) because comparing code-sizes of different languages just doesn't make much sense. Most languages will have at least one challenge where they win. That doesn't make them 'better' than the alternatives.
Interestingly enough I have found that if you stretch the definition of language too much you get very creative/odd solutions to problems. (EG: many ASCII-art competitions could be won by a series of Vim keystrokes over at vimgolf.com).
If code-length is really all you care about, there are even more terse languages then the mentioned Golf-oriented languages. The reason they are often used for golfing is that their code-size is typically directly related to algorithmic complexity, whereas in for example C, you may sacrifice algorithmic complexity for shorter syntax to out-golf the competition. Meanwhile the even terser languages aren't really designed to be human programmable, and are more oriented to approximating kolmogorov complexity or theoretical applications.
My recommendation: learn whichever golfing language is based on a language you like. If you enjoy Python, learn Pyth. If you enjoy Ruby, learn GolfScript. If you like C/C++/Java learn CJam (and if you find you enjoy CJam you may wish to look into Joy which is a similarly concatenative-stack-based language designed for usability rather than golfability)
