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

17 Answers 17

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.

  • 3
  • 35
    +1 for the analogy at the end. I also tend to compete with a language I have fun golfing in but that has won only a few times so far here. – Joey May 20 '11 at 9:39
  • 7
    Can confirm, avocad is delicious. – Picard Mar 7 '16 at 15:53
  • 1
    I don't like avocados :< – Midnightas Feb 25 '17 at 15:30
  • Though I understand the sentiment, for me J is new so I have to do golfing and a lot of googling. – Bijan Mar 15 '17 at 18:51

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.

  • 1
    "Usually the problem seem to be solved in a completely straightforward manner" because you see the end product, not the process. Often a lot of the cleverness in a GolfScript program is in working around the limitations of the stack in a way which minimises the characters spent on stack manipulation. – Peter Taylor Feb 14 '14 at 11:01
  • @PeterTaylor Yes I know, see the fourth paragraph. Having solved a few answers in dc I know that this can be a challenge. dc is however A LOT more restrictive and verbose than gs, so things need to be worked around, rather than "this one character fixes it". It's actually quite rare that dc can be used to answer a question at all, due to all its shortcomings, while gs'ers will whip out gs without a moment's hesitation. That said, I know that you yourself usually give an explanation to your gs code, which at least makes some of the answers worth reading :P (no really, kudos). – daniero Feb 14 '14 at 17:08
  • 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. What about Java? – dorukayhan Jun 24 '16 at 16:36
  • @dorukayhan Read the fifth paragraph. – daniero Jun 24 '16 at 19:25

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

  • 4
    “But why should this stop you from enjoying codegolf?” — I think I already answered this in the question, but if it helps I’ll give an example — I wrote this C# answer after quite some thought, and I feel it has several interesting ideas in it to fulfill the problem constraints. Yet there is no comment, no upvote, nothing... (I’ve upvoted almost every other answer in that thread because I think most of them were interesting.) – Timwi Apr 4 '11 at 12:36
  • 4
    Also, I’m not sure what you’re trying to accomplish by saying “c’est la vie”, unless you really think the site is more fun for you when there are only very few participants. – Timwi Apr 4 '11 at 12:42
  • 4
    The lack of response might simply be because you answered it over a month after publication, and there was already lot of answers. I have found that I get more upvotes/feedback when I respond to questions with few answers. As for c'est la vie, I just meant that Java being inferior to J is a simple fact of life. > 95% of the time, the whole J solution is shorter than the Java I/O part... – hallvabo Apr 4 '11 at 13:01
  • 4
    @hallvabo: Yes, but if this fact encourages the majority of participants to leave the site in frustration, then “c‘est la vie” is not a very constructive attitude, unless you want them to leave... – Timwi Apr 4 '11 at 13:32
  • 2
    The only constructive advice I can offer then, is to learn GolfScript / J / dc etc. Multi-language golfing has synergies too, i.e. sometimes an insight from golfing the problem in C leads to shortening of my Python code. – hallvabo Apr 4 '11 at 14:31
  • 6
    You really think you can sustain a reasonable online community if it is predicated on having to learn GolfScript or J? Do you really think that many people are going to be interested in that just for the sake of this website? (I am not.) – Timwi Apr 4 '11 at 15:54
  • 1
    @Timwi: I actually approached it from the opposite direction: I started participating here in order to learn J. – Jesse Millikan Apr 4 '11 at 17:59
  • 8
    @Jesse: Am I really the only person here who doesn’t only think of himself? – Timwi Apr 4 '11 at 18:24
  • 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.

  • 13
    Who's the winner when you have a 1 vote / 100 chars answer and a 10 votes / 200 chars answer? No one really, it just gives a weird sensation that the competition is not really codegolf, but instead some weirdo social competition a little like one of those reality TV programmes, except that the rules are even more vague. – aaaaaaaaaaaa Apr 5 '11 at 21:32
  • 11
    @eBusiness: InRe: "Who's the winner" I haven't "won" a codegolf yet excepting a couple on this site where no one else submitted a entry, but all my efforts have been personally rewarding. I do it for fun and therefore win even when I lose/ – dmckee Apr 5 '11 at 21:43
  • 1
    @dmckee - That's just fine, but some of us want to compete. – aaaaaaaaaaaa Apr 5 '11 at 22:09
  • 3
    I’ve already mentioned this multiple times; if I were the one with 200 chars but 10 votes I’d be happy — but so far answers with more than 2 upvotes are really rather rare. – Timwi Apr 6 '11 at 11:04

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.

  • Using a golfing language lets the answerer profit from work that isn't their own, but the language maker's. How is that not true for every other language as well? – Dennis Mar 15 '16 at 2:05
  • 7
    @Dennis I tried rephrasing it -- is that better? What I'm trying to say is, for golfing languages, it's the language writer's skill at making a concise language that makes the answerer look undeservedly impressive for posting such a short solution. – xnor Mar 15 '16 at 2:17
  • the next month there was a pretty interesting code-challenge on handicap system for code golf depending of the language question and the answer – Erwan Mar 15 '16 at 7:27
  • [...] that push has promoted golfing languages to a central position in the site that they should not hold ... Why not? – AdmBorkBork Mar 15 '16 at 14:23
  • 1
    @TimmyD By "should not hold", I meant that they would not have taken such a hold if not for these extra forces. I do think there's issues with having them be so prominent, in particular in attracting new users, but that's a topic for another post. – xnor Mar 15 '16 at 21:08

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

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.

  • 2
    I think you should be allowed to score 1 char = 1 byte, if and only if you are able to produce (not necessarily did produce) a file of the specified byte length that will be executed by an existing interpreter in accordance with the rules of the challenge. – Timwi Mar 10 '14 at 18:30
  • @Timwi This is hard because APL traditionally does not operate on source files! You save programs in a workspace which is a RAM dump of the interpreter with the functions you are interested in loaded. – FUZxxl Apr 11 '15 at 13:00

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.

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.

  • 12
    “Don't bring a sword to a gunfight” is just another phrasing for the same thing hallvabo said, so my response is the same. My choices are not only “learn GolfScript” and “use a language that is destined to lose”; my third option is “leave the site”. I suspect less than 10% of people will want to learn GolfScript just to participate on this site, so your attitude reduces participant count by a factor of 10 or more. It seems that everyone here forgets about this or doesn’t care about it. I find that perplexing — do you really prefer for the site to be that much emptier? – Timwi Apr 5 '11 at 16:10
  • 2
    @Timwi, people who want to compete against others in the same language already have golf.shinh.org to play on. If someone wants to only program in Java or C# that's fine. If they want to win code-golf under the rules of this site, they probably need to learn another language. If they are too lazy to do that, I have my doubts that they have the tenacity to golf very well anyway. I certainly don't want the site diluted with people like that. We had problems with people over on SO arguing that code-golf was something other than shortest code. – gnibbler Apr 5 '11 at 23:26
  • 3
    @gnibbler: Well, to each their opinion, but your bigoted attitude is not only far removed from reality, but also detrimental to the health of the site. I guess it’s time for me to give up, because clearly this site is dominated by people like you who want it to die from lack of participation. – Timwi Apr 6 '11 at 10:59
  • 1
    @Timwi, Many of the code-golf questions that I have asked have not been won by either golfscript or J. When designing the question there can be a balance between making it fun and making it just a little harder got golfscript and J to keep other languages competitive. I can't control how other design their questions though. On SO I've golfed in at least golfscript,perl,ruby,python,C,fortran,cobol. I don't expect all those answers to win but I do it because it is fun. You're asking for special treatment so you can win code-golfs in Java and you think I am bigoted. hmmm – gnibbler Apr 13 '11 at 1:54
  • 2
    @gnibbler: Once again you are only thinking of (and talking about) yourself. Why? — I am not asking for special treatment. I’m not even talking about myself. I’m talking about all the people who will likely never get interested in this site, never settle in and never engage in discussions like this one because of the problems I am mentioning. I don’t get why no-one seems to get this and everyone seems to think only of themselves. You just exclude those people and somehow that seems to make you happy. – Timwi Apr 13 '11 at 17:33
  • Also, to clarify, what I found bigoted about your comment was your claim that anyone who doesn’t happen to like GolfScript as much as you do is automatically a lousy golfer. This attitude is far removed from reality because golfing in languages like Java or C# is just as much fun, and in fact can sometimes be an entirely different type of challenge — one that you probably don’t appreciate. This site doesn’t recognise that and thus excludes a large set of people. – Timwi Apr 13 '11 at 17:33

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.

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

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.
  • 1
    Whoa, this is ironic. I started this thread a long time ago; but I’m also the inventor of Sclipting :) – Timwi Feb 1 '14 at 21:45
  • 2
    BTW it turns out Sclipting doesn’t beat GolfScript very often, not even in number of characters (much less bytes)... – Timwi Feb 1 '14 at 21:49
  • That shows your evolution, @Timwi! :) You felt so frustrated by the situation here that you had no choice than to invent a new language, even more obscure than its predecesors. Just to be able to compete here :). Well, new users are feeling exactly like you have been feeling some time ago, and praise and support your thread! :) – Tomas Feb 1 '14 at 21:52
  • Hehe, thanks, but take a look at the paragraph I just added to the question here; my stance has really changed... – Timwi Feb 1 '14 at 22:05
  • 2
    "Uses non-ASCII characters" doesn't work as a characterisation of esoteric languages, unless you want to consider Java esoteric. However, people do sometimes include in the problem statement a ban on submitted programs using characters other than printable ASCII. – Peter Taylor Feb 1 '14 at 22:11
  • 1
    This answer is almost exactly duplicated at meta.codegolf.stackexchange.com/a/934/194 – Peter Taylor Feb 1 '14 at 22:14
  • I'm pretty sure J wasn't created for code golfing – Cyoce Nov 2 '16 at 16:35

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.

  • One problem with this is that the advantage is non-linear, for example importing a module in python can be a large proportion of a short answer. from itertools import* has very useful things like combinations and product. Then I can also have P=product if I need to use cartesian product in a few places. For a longer answer this gives quite a large advantage – gnibbler Apr 13 '11 at 2:00
  • @dmckee: Thanks, read it by now. – user unknown Apr 13 '11 at 3:50
  • @gnibbler: Is there enough data to show, that it isn't linear? Then it should be possible to map graphs together, and fix the exchange rate by the raw score of the best solution. – user unknown Apr 13 '11 at 3:52

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.

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.

  • 3
    Non-golf contests are on-topic here (note the name of the site), they just haven't attracted a lot of interest. We would, obviously, be pleased if you were to ask a good one (or more). Indeed, I'm am even now agitating for a flood of good questions. On the other hand, splitting the already small and not-very-active user base seems to be a recipe for disaster. – dmckee Apr 23 '11 at 23:15
  • 1
    About splitting a small user base -- you're right, I never thought about that. The problem here right now I think as Timwi noted is that non-golf answers to golf questions aren't really encouraged or rewarded as much as they should be. – Rei Miyasaka Apr 24 '11 at 2:34

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 . Maybe this can be applied to other challenges as well, and we would introduce 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...

  • 1
    See code-bowling – Peter Taylor Feb 21 '14 at 15:57
  • @PeterTaylor: thanks for the tag, but it's not exactly what I want. Look at the accepted answer codegolf.stackexchange.com/a/19230/16901 . This code has not been golfed at all. There are many ways to reduce this code. – Thomas Weller Feb 21 '14 at 16:06
  • 2
    Wouldn't all such challenges reduce to "Who can choose the most verbose Turing-complete language?" Methinks most contests will end in a tie between Shakespeare and Gertrude. I don't see how that is any different than J/Golfscript/APL often winning standard code golf due to their terse syntax. – Jonathan Van Matre Feb 25 '14 at 22:10
  • @JonathanVanMatre: if you choose a verbose language, you still need to solve the given task, for which you should not only name that language but also use it. I could also go the opposite direction for "normal" code-golf and invent a new programming language for each problem, defining a one character keyword to complete the given task. – Thomas Weller Feb 26 '14 at 1:29
  • Agree with @JonathanVanMatre, this will keep J and GolfScript out, but it will gather many other esoteric or specially-built languages that have long syntax. For example, one can invent a new programming language that uses a 10K-character-function-name just to print to STDOUT. – justhalf Aug 22 '14 at 2:47
  • @justhalf: Inventing a new programming language is considered as a standard loophole and therefore discouaged, I would say – Thomas Weller Aug 27 '14 at 9:14

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.

  • 1
    This is basically equivalent to atomic-code-golf although it seems that you want to weight different operators depending on how much they do. You should be able to find several discussions about this or similar scoring mechanisms on meta. The general problem is that it's impossible to define this scoring in a fair and objective way across all possible languages. You'd have to come up with scoring rules for every single language separately which isn't really feasible. Atomic code golf works best if you instead define a toy language for the challenge that everyone has to use. – Martin Ender Apr 18 '17 at 8:11
  • True. I never saw that anywhere. I might try to make a question like that. – user233009 Apr 18 '17 at 20:53

You must log in to answer this question.

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