J and GolfScript suck all the enjoyment out of Code Golf

Question

I have found code-golf a fascinating pastime for several weeks now.

However, I’m already losing interest because the contests allow any language, and because of that it is pretty much impossible for anything other than J or GolfScript to get anywhere close to winning. As soon as I see a less-than-100-character solution in J or GolfScript, there’s already no point even trying.

If you are tempted to downvote this post and/or post an answer saying you don’t care or don’t agree, please consider the following important point. If you did care, you’d probably have already left. The fact that you are still here, reading this, puts you in the unrepresentative sample of people who are still interested in the challenge. Try to overcome this bias for a moment and think of all the people who will have already left without telling you like I am doing now.

There are several ways that I can think of to mitigate the problem, but unfortunately both seem to be unpracticable...

1. For each challenge, maybe there should be a separate contest for each programming language? A C# program ideally shouldn’t have to compete against Perl, much less GolfScript. Unfortunately this would mean an explosion of threads. Using tags could mitigate this a bit, and perhaps each post could link to all other posts for the same challenge in other programming languages.

2. Perhaps there should simply be more upvoting, more comments, more involvement, more praise. Remember that having no activity on one’s answer feels to the poster like it’s receiving no attention and nobody is interested. Perhaps losing with a C# entry wouldn’t be quite so bad if there were at least a few upvotes and a few comments saying “well done” or something?

Edit

This is quite an old thread. I am surprised that it has received this many upvotes. Looks like my suggestion #2 appears to have been implemented, thanks! :D Since I posted this, I think I no longer consider competing and winning to be a source of enjoyment. It’s nice to receive some upvotes and some encouraging comments, and that’s all I need. Since I posted this, I have invented Sclipting and even though it doesn’t achieve its goal (it doesn’t beat GolfScript or J, not by a long shot), I enjoy writing solutions in it. I also enjoy challenges that aren’t code-golf :)

Answer 1

My first thought when I found this community was: "there should be language handicaps based on the average number of machine code instructions executed per statement." Can you tell I'm a C/asm guy? :D

I did it for fun, in C, and knew when I started that the interpreted languages were all going to win. Who cares?

Here's a fun comparison for you. I provided a 675 char C solution to a problem. I was thoroughly trounced by the same algorithm in Perl weighing in at just 137 chars. I compiled mine to assembly, and ran the Perl solution through perlcc+gcc to get it into assembly, too.

The assembly output includes labels, but is roughly one line per instruction:

• Lines of assembly for C solution: 437
• Lines of assembly for Perl solution: 7385

That doesn't include the standard libraries, which in the C solution is printf, and in Perl's case is the entire bytecode interpreter. But at this layer, Perl is 1/5th the source code, and 16x the CPU instructions. Of course, the perlcc output is... something. Probably not exactly what the CPU executes, but at least representative.

But that's just the nature of the challenge. We're comparing apples to avocados, and deciding the winner based on the number of seeds. They're both still delicious.

Answer 2

I hate that people upvote Golfscript answers just because they are short. ^{I can't help but imagine some very excited people with their mouth half open exclaiming "omg i cant believe thats a real program upvote lolz!!1!" These people will do so so for every piece of Golfscript code they see.}

Usually you find for instance Ruby/Python/Perl answers that are longer, but display a whole lot more creativity with bending the syntax and misusing all sorts of features just to shorten it as much as possible, with much fewer upvotes. Still, these answers usually impress me much more.

I can't remember being truly impressed by a golfscript answer; usually the problem seem to be solved in a completely straightforward manner, which just happens to be very short.

An impressive Golfscript answer to me would be one that utilizes the stack-based nature of the language to solve the problem in a different manner than the rest.

On the other hand, I'm rarely truly impressed by codegolf answers written in for instance Java, because Java is so verbose and I can't help thinking that the person have chosen wrong language for the job. Also Java isn't a language that is possible to abuse in the same way that for example Python or Ruby is, which thend to make Java answers boring and straightforward too.

In short:

I think an upvote should mean I dig your style rather than I hereby acknowledge that this piece of code contains very few characters.

Answer 3

Of course programming languages are created unequal when it comes to producing the shortest possible source code for a given task. Java can never beat J, c'est la vie. But why should this stop you from enjoying codegolf?

• You can compete against the solutions in your language of choice
• No need to upvote the shortest solution, choose those you understand and enjoy the most
• Isn't it nice when the other solutions copy your algorithm? ;-)

To actually learn something, you need to participate; looking at your profile it seems that you haven't submitted a single golf answer yet? Oops, I was looking at your meta profile...

Answer 4

It's 2016, nearly 5 years later, and the golfing-language situation has grown more extreme.

Golfing languages have grown in number and in power. Users have created many general-purpose golfing languages with expressive syntax and a wide array of built ins. On some challenges, a reader who is a typical coder needs to scroll down 5 answers before they see a language they have heard of and code that doesn't look like a jumble of random letters and symbols.

It's natural that people want to probe the extremes of golfing in search of the absolute shortest code. It's exciting to see how far tools we make can take us.

Yet, I think the spread of golfing languages has been helped by some unfair advantages and unintended incentives.

• Answers in golfing languages are written and posted quickly because of their powerful feature sets. This makes them rise to the top and stay there because of the FGITW effect and HNQ attention.
• People like seeing small byte counts. "8 bytes" certainly looks more impressive that "73 bytes", even when those 73 bytes are clever and painstakingly golfed C code compared to 8 bytes of obvious "chain-the-built-ins" in a golfing language. Accepting the overall shortest answers glue a golfing-language solution to the top spot and gives it additional rep and recognition.
• Using a golfing language lets the answerer reap rewards for the language creator's efforts and golfing skills. When people upvote a golfing language solution, it is often for the impressiveness of the language to allow a short solution, not the solution itself. Yet, it is the answerer that gets the rep and attention, which gives them an incentive to use the golfing language.

I don't think users of golfing languages are purposely trying to exploit these advantages, but that these incentives have given golfing languages a big push. And, that push has promoted golfing languages to a central position in the site that they should not hold.

Answer 5

• There are a lot of good questions where shortest answer is not the highest voted.
• I suppose that you first have to make the community and then the rules. If people here gather to golf in J/golfscript/dc then people here have to learn J/golfscript/dc. If they come to golf in their language they'll do so and eventually they'll get pissed of the j/g/d guys and try to impose some rules on them :)
• There are tasks where j/g/d lose their edge. We should have more of those.
• This site is also meant for puzzles. We should have more of them.
• We should all vote more.

As soon as I see a less-than-100-character solution in J or GolfScript, there’s already no point even trying.

Code golf is fun^* and educating. Just ignore the other answers and post your own.

it is pretty much impossible for anything other than J or GolfScript to get anywhere close to winning

Who's the winner when you have a 1 vote / 100 chars answer and a 10 votes / 200 chars answer?

^{*It really is more fun in some languages (like ruby, perl, python, J, etc). There is not much we can do about that.}

Answer 6

I understand the collective sentiment against GolfScript and J and I would probably share it too, if I didn't happen to use a language that can usually compete on the same ground, APL

An apology of APL

Whatever the community will choose to do with GolfScript (ban it, score it with a penalty, score it separately) I hope APL won't be banned outright, because it's a truly remarkable language with a long history, not to mention a lot of fun to code in. Maybe it should just be scored differently, so that people don't feel like it's competing unfairly. I'll give my suggestions below.

As for the language itself, I was originally drawn to it by its strange symbolic alphabet, which I'm sure baffles most people who see it for the first time:

⌽ ⍉ ⊖ ↑ ↓ ≤ ≠ ≥ ≡ ⎕ ⍞ ⍤ ⍥ ⍨ ⌹ ⍬ ⍕ ⍎ ⍳ ∊ ⍷ ⌿ ⍀ ⊂ ∩ ∪ ⊃ ⍟ ⍣ …

Most symbols were taken straight from mathematics and have the same meaning, others were invented by APL's author (Kenneth E. Iverson) and some of those even found their way back into mainstream mathematics (⎣⎦ and ⎡⎤ for the floor and ceiling functions, for example.)

The symbols sure make for a different way of coding, but it's not an arid exercise in golfing. It's not harder to learn how to use ⌽, for example, or how to type it on a keyboard, than if it were called reverse() as in most other languages, because the shape of the symbol is usually a mnemonic for what it does (in the case of ⌽, it represents horizontal reflection.) I'd wager it's even easier: I have less trouble remembering how to use APL symbols, than I have with the order of arguments of common functions such as replace() in other languages.

As I said, I was originally drawn to APL by the weird symbols, but I stayed for the array-oriented nature of the language. After learning how to code in APL, and how to manipulate entire arrays with a couple symbols, it just feels wrong to write for loops by hand. This is also one of the reasons APL fares so well in code golf.

J and K/Q people will share this view, because those languages derive from APL and are based on the same array programming concepts. But those languages chose to forego the mnemonic nature of the symbols (or twist them into ugly ASCII digraphs) making them somewhat harder to use and remember, and less pleasing to the eye, in my very humble opinion.

About scoring

In my APL posts, up to now, I've always added a footnote claiming that APL could be scored as
1 char = 1 byte.

This claim rests on the fact that a few (mostly commercial) APL implementations still support some form of legacy single-byte encoding, where the APL symbols are mapped to the upper 128 byte values.

Although strictly true, this is probably a bit of a stretch.

I wouldn't mind if this community decided to score APL as UTF-8 or UTF-16 bytes, since it does use a different alphabet than most other programming languages. As long as a similar penalty was chosen for J and GolfScript, that is.

One possible way would be to choose a few classic code golfs and score each language proportionally to how it fared in those competitions.

In a way, we would be borrowing the concept of par from real golf.

Answer 7

The golfing languages always win. I am not having fun.

Four years later, people are still complaining about this. Whether or not this complaint has any merit, if people say they aren't having fun, then they aren't having fun. I think I have a solution.

We can start commenting on code golf challenges with this:

Some users find it fun to only compete against languages that are in the same league. If you want to encourage this, consider adding this stack snippet (and the explanation that goes with it) to your post to generate an automatic per-language leaderboard.

If we do this and more people have fun, then mission accomplished.

If we don't do this, then that means the people who are complaining don't care enough to take action (or they haven't read this post yet).

Answer 8

Enjoyment is primarily a function of the golfer, not of the rules of golfing.

Having just submitted my first-ever golf answer on CG.SE in T-SQL after a long period of lurking contentedly, I can assure you that for me there's plenty of enjoyment in losing, and losing by a very, very wide margin.

But I am the sort of person who thinks playing a round of real golf with nothing but a sand wedge could be great fun.

Answer 9

On SO we often faced Python and Ruby being beaten time and time again by Perl, sometimes only by a few chars and those Perl answers would get an astronomical number of votes, while the others were lucky to get 10.

Having Perl win all the time was a little frustrating, but often you would have fun shootouts with other answers that were a similar length to your own.

Some people like me, turned to golfscript to see if it was possible to beat Perl. What I found was that golfscript is quite a cool language in it's own right and it can be quite difficult to find the shortest answer, and quite fascinating to see another GS answer substantially smaller than your own.

One interesting thing was that the Perl answers often continued to get a lot of votes and Golfscript got less than Python/Ruby. The point is that people will vote however they feel regardless of the rules and restrictions in the question (and it's really hard to predict what people will vote for).

I got an upvote for using ~:o) in one answer and it didn't even work properly :)

So if you are more interested in votes use the most popular (with the voters) language and make you answer fun/clever as well as short.

If you want to have the shortest code, be a polygot. Don't bring a sword to a gunfight.

Answer 10

I really do agree, it isn't a lot of fun to compete with so different preconditions. Having a competition in all languages for a single problem doesn't seem like a great solution though, we have too few user and too many languages to make that viable. I have previously suggested that the author for each question state a main language, let any language participate, but choose the winner only from the main language. That way there should be a more even spread between the languages.

Answer 11

I think one of the problems here — as many have pointed out — is that brevity seems to be the most important criterion. That's probably because of the fact that the site's rules demand some kind of objective criterion for getting the correct answer. Cleverness, reliability, and all of that other stuff aren't completely objective.

I think it would be better if there were multiple "right answers" based on language, e.g., shortest C# answer, shortest J answer, etc., but I realize that would require quite a change to the StackOverflow infrastructure, and so is probably not practical.

As an aside, I think it's a testament to the natural readability of some languages that they aren't well suited to obfuscation and brevity. For instance, I know both REBOL and J, but am not about to answer any CodeGolf.SE questions using REBOL. In a way, I think that's a testament to one of REBOL's design goals. The same to a lesser extent is true of C#.

Answer 12

I am feeling exactly the same way! Getting beaten by Golfscript etc. all the time, I think I will give up soon.

• It's not fair because these languages were created just for the challenge, to be brief.
• In many cases, they use non-ascii characters to "compress" source code (Sclipting, APL)
• For me it's fun is to see a surprisingly short code or a trick in language which I use for serious things, not a squeezed code of some esoteric language, even if it's shorter, because that's not surprise - you already expected it, the language was created for that.

The solution would be to make specific challenges for non-esoteric languages only. It could bring the enjoyment back!

For this to happen, there should be a definition of what esoteric language is. Basicly, esoteric language is a language that is not normally used for any real bussiness and was created just for challenges. More objective criteria for what esoteric language could be:

• It is listed in Esoteric language list - with the exception of PERL and perhaps other mistakes.
• It doesn't have a tag on StackOverflow with at least 2000 questions.
• Is not part of any standard OS release (meant as an exception for small standard tools like awk, sed, dc etc. even if they don't have enough questions at SO).
• Uses non-ASCII characters.
• Yours "Can you find at least a project using that language on the web?" is a very good idea, but there might be very alternative and very esoteric projects too...
• You can also name specific languages you are sure you want to exclude just to prevent finding a hole in the rules :-)

Other ideas to develop (just brainstorming):

• Is not used for teamwork programming of products that other people use.
• Is not used for products other people pay for.
• Majority of operations use postfix notation and take operands implicitly from a stack.

Answer 13

Since the game is called golf, a sports for which I'm far to young, we could adopt their handicap scheme, or something similar.

However, this is much work.

Ideally, one would measure the last 10 golfs with many languages participating, and calculate the average for each language. Then you would sum the values up, and generate an inverse handicap from that.

Example:

absolute:

Quizz golfscript Scala Java  avg 
--------------------------------
1          50    150    250  150
2         300    400    500  400  
3          70    120    200  130

relative (inexact numbers)

    Quizz golfscript Scala Java
   ------------------------------
    1         1/3      1    5/3  
    2         3/4      1    5/4  
    3         1/2      1    3/3  
---------------------------------
sum           19/12    3    47/12
/3  (about)    1/2     1     4/3

So every solution in CodeGolf would be multiplied by 2, every Solution in Java multiplied by 3/4. It would be a self correcting process. Only the best solution would always do it in the table.

It would be work, and not work best for new languages. These would always start at level 1.

We would need a page at community wiki, to protocol the best solution per challenge and language, mostly in a form which would allow for automatic evaluation. The appropriate challenge would be to write a golf, which calculates the correct weights from the table of input, and produces a well readable output.

Independently, people could vote up favorite solutions, and compare the absolute length of their code.

Answer 14

Maybe there should be another site called "challenges.SE.com" or something, and have the non-golf questions slowly migrated over there?

I guess I have no right to complain since this site is obviously called "codegolf.SE", but I for one joined hoping to see more interesting implementations than short ones.

The interesting-code-to-short-code ratio is too low to keep me interested.

Answer 15

Consider the best criteria for your challenge

Maybe the best approach to solving this is reassessing winning conditions. I've seen many awesome code-golf questions that were about optimizing an algorithm or using data in a unique way. Perhaps the winning condition for these shouldn't be shortest code, but optimal algorithm or more interesting use of language capacities.

Answer 16

Well, I'm new here, but CodeGolf seems to exist because it has hard criterions for defining the winner. But you could also define other criterions without losing the CodeGolf principle:

The longest of the shortened programs which provides the expected output wins.

Of course, we're still in CodeGolf, so it's not just about writing nonsense code. Still, the goal is to reduce any unnecessary character. We might downvote if someone seems to cheat by adding unnecessary characters.

Maybe this needs a new tag like code-golf-reversed. Maybe this can be applied to other challenges as well, and we would introduce winner-reversal which can be applied in addition to existing tags.

Example:

While the question remains unchanged, the winner of the Reverse stdin and place on stdout question would be the C++ version. The longer C version would not win, because it didn't make a reasonable attempt to shorten the code.

Hard to understand? Well, not harder than any golfed code...

Answer 17

A new scoring mechanism could be made. Instead of counting the bytes of the source code, count how many operators are used (maybe with defines, functions called, variables declared (including struct and array elements) such as:

//Still inefficient to show examples
#include <iostream> //Includes are free, because "built in's" are already global
#define ret return //Doesn't make returns free by using r, still counts as a return.
//Comments are free too
int add (int, int);//Declaring functions is free
void printMe();

int main(){ //Free, main function is free, as long as all returns in this function return the same value. (I.E. No return 0 if this, return 1 if that.)
    printMe();
    ret 0;
}

int add(int a, int b){ //This is also free. But, calling functions makes points, depending on what it returns and what arguments are passed. This would be 3 points, because it has two arguments, uses the + operator which takes two numbers, and has a return. Using a default argument in an overloaded function (such as 
    ret a+b;
}

void printMe(){
    std::cout << "The sum of 3 and 5 is " << add(3, 5) << '\n'; //Two function calls: operator<<, and add 
    //std::cout is a basic output function. If all a function does is present data to the user, then it is only 1 point. The string argument does not add a penalty.
    //The add and the newline also is free. It counts as the same call. printf(string);, printf(add);, and printf('\n'); are all just one point.
}

And golf languages could be

Д (Print "The sum of 3 and 5 is" and the sum of 3+5 to console), equivalent to three

Or something like that. Could be good to discuss.