15
\$\begingroup\$

I'd like to write challenges that encourage people away from golf languages, and into a more competitive space. what are some things that golf languages tend to not do, or do not as well compared to non golf languages?

For all intents and purposes, we'll consider a language a golf language if it has 5 or more one character functions that don't require the use of 'imports', aside from algebraic operators (+,-,/,*, %, etc.).

\$\endgroup\$
9
  • 1
    \$\begingroup\$ It's not usually a good idea to try and restrict the playing field. However, things like GET requests perhaps are less apparent in golfing languages. \$\endgroup\$ Nov 8, 2016 at 19:02
  • 2
    \$\begingroup\$ @ConorO'Brien well, I'm not going to stop you from entering a fish into a tree-climbing contest, but a fish (a golf language) may not be the best creature to climb a tree (solve my challenge). \$\endgroup\$
    – tuskiomi
    Nov 8, 2016 at 19:06
  • 1
    \$\begingroup\$ I can appreciate the want to target non-golfing languages. That said, you aren't going to find tasks that golfing languages can do, but aren't competitive compared to other languages. Many IO tasks, such as network requests, displaying a popup screen, or listening for a mouse movement are pretty impossible in most golfing languages. \$\endgroup\$ Nov 8, 2016 at 19:06
  • 1
    \$\begingroup\$ I highly doubt this will lead to fruitful discussion \$\endgroup\$
    – user45941
    Nov 9, 2016 at 6:58
  • 5
    \$\begingroup\$ @Mego I disagree. As we all know, some users are put off by golfing languages. Something like banning golfing languages is a terrible idea that's been tried before and didn't work, but I think cleverly writing challenges in such a way that it encourages participation in non-golfing languages is a fantastic idea. \$\endgroup\$
    – DJMcMayhem
    Nov 9, 2016 at 17:09
  • \$\begingroup\$ @DrMcMoylex And then golfing languages are made that have all of the features listed here, which makes those answers moot. This is a list post, not Q&A, so it's not good for SE. \$\endgroup\$
    – user45941
    Nov 9, 2016 at 23:14
  • \$\begingroup\$ @Mego that is a good thing, in my opinion. once we have more golf languages than we can name, we'll have no choice but to start disallowing them, or regulating \$\endgroup\$
    – tuskiomi
    Nov 10, 2016 at 16:19
  • 6
    \$\begingroup\$ That will never happen. The community as a whole is against white- or blacklisting programming languages; three of our four moderators have written and regularly use golfing languages. If this is supposed to be a constructive discussion on how to make challenges that appeal to users put off by golfing languages, fine. If this is just part of your crusade against golfing languages, you will be disappointed. \$\endgroup\$
    – Dennis
    Nov 10, 2016 at 21:04
  • \$\begingroup\$ In addition to challenges that suit non-golfing languages better, it might also be interesting to find challenges where it isn't clear cut, so there's a chance of beating some/all of the golfing languages but both sides have to really fight for it. \$\endgroup\$ Nov 14, 2016 at 22:56

5 Answers 5

18
\$\begingroup\$

challenges

Golfing languages are often at a disadvantage in those challenges because:

  • A lot of them are transpiled into another high-level interpreted language.

  • They are created to be short first and foremost, which means that a lot of their 1-byte built-ins are resource expensive operations (e.g. compute all permutations) that are good in a lot of challenges but useless when writing fast code.

  • They are implemented by at most a few people in their free time and are as such not necessarily as optimized as more standard languages.

Note though that they also often use libraries of the languages they are written in for things like math operations, which means they are definitely not that slow either.

challenges

Here, golfing languages are sometimes at a disadvantage because:

  • They can get quite cumbersome to use when programs get long

  • They can get fairly unreadable when programs get long

More simply said, there is often no point in using a golfing language rather than a “normal” one in challenges where the length of the code is not the winning criterion

Final note

These are generalities; it is definitely possible to answer challenges with either of those tags with golfing languages. It is just generally less likely that people will compared to challenges.

\$\endgroup\$
2
  • 11
    \$\begingroup\$ TL;DR: Golfing languages aren't as good at challenges that aren't code golf. \$\endgroup\$
    – DLosc
    Nov 14, 2016 at 7:10
  • 1
    \$\begingroup\$ Also [king-of-the-hill]. Although I'd love to see a language specific KotH using a golfing language... \$\endgroup\$ Nov 14, 2016 at 22:52
8
\$\begingroup\$

Domain specific functionality

Want to perform image processing? Audio processing? Simple machine learning? Many high level languages, like Python, Mathematica, etc., will have those sorts of packages already built in, while golfing languages rarely will. While it's not a good idea to directly use a built-in, they can make challenges much, much easier without making them trivial.

Anything you'd like to import a package for is probably easier in a non-golfing language.

\$\endgroup\$
7
\$\begingroup\$

Questions tagged with are mainly answered with non-golfing languages. You can browse those questions here.

Addressing your intention to discourage the use of golfing languages:
I primarily view code-golf challenges as a contest between submissions in the same language and not as contest between languages. If you prefer the between languages competition, you could use your definition of golfing languages and non-golfing languages to get two distinct competitive spaces where golfing languages compete with other golfing languages and non-golfing languages with other non-golfing languages. For your own challenges you could then maintain two distinct leader boards, not accept a winner ect.

However I don't think this will work as a general site practice as it's hard to clearly define golfing languages.

\$\endgroup\$
4
  • \$\begingroup\$ did I not define them clearly in my post? \$\endgroup\$
    – tuskiomi
    Nov 15, 2016 at 16:59
  • 2
    \$\begingroup\$ @tuskiomi You gave a (in my opinion) quite reasonable definition, but if you were to ask for a community consensus on a definition of a golfing language, I'm sure some people would come up with edge cases, eg. some esoteric languages which have more than 5 one character build-ins but other restrictions which make the code longer than Java for most questions. \$\endgroup\$
    – Laikoni
    Nov 15, 2016 at 17:25
  • \$\begingroup\$ EG: brainfuck?? \$\endgroup\$
    – tuskiomi
    Nov 15, 2016 at 17:26
  • \$\begingroup\$ I'm not familiar enough with brainfuck to now whether some of it's operands would fall under the default operand (+,-,/,*, %, etc.) rule, but yes, something like that. \$\endgroup\$
    – Laikoni
    Nov 15, 2016 at 17:31
7
\$\begingroup\$

Full systems

This immediately reminds me of: Given a list of Tetris moves, return the number of completed lines

That code-golf question gathered 2 PHP answers, a C answer and a Ruby answer. No golfing languages appeared (although I for one would love to see a golfing language entry).

The main reason appears to be that it required multiple related but distinct stages: compression of piece shapes, simulation of game physics, and recognition of completed lines. This is what regular languages were built for, but golfing languages struggle to combine multiple parts; they're optimised for solving individual problems.

An important note is that the tetris challenge was coherent and fun. Just gluing challenges together to put golfing languages at a disadvantage is no fun for anybody. It was also flexible in its input and output format, and didn't require specialist functionality (e.g. there was no need to output images, and no need to handle interactivity).

Nothing about the challenge did anything to exclude or even discourage golfing languages; it simply didn't appeal to them.


Or: non-code golf challenges

The obvious one, as already pointed out by Fatalize, and emphasised by DLosc:

Golfing languages aren't as good at challenges that aren't code golf.


As a side-note, I really like seeing golfing language answers to any question. They often take a much higher-level approach to problems and there's a lot to learn from reading them. And I say this as somebody who answers here almost exclusively in C. Whoever "wins" the challenge doesn't matter one bit; it's just about having a target to aim for.

\$\endgroup\$
8
  • 1
    \$\begingroup\$ "golfing languages struggle to combine multiple parts" is nonsense. I suspect that the J-inspired languages are better at combining multiple parts than the Algol family. It may be true that a majority of people who golf in golfing languages can't be bothered with challenges which they expect to take more than 30 chars, but if so then that's not a defect of the languages. Or it may just be that that challenge was posted when a lot of people were on holiday and there were other challenges posted on the same day which drew more attention. \$\endgroup\$ Nov 21, 2016 at 16:51
  • 1
    \$\begingroup\$ @PeterTaylor yup, could be other factors at play — I just wrote what I think is most likely. Whatever the reason, there's certainly a few full-system questions which didn't appeal much to golfing languages (i.e. unlikely to be just a timing thing / holidays): codegolf.stackexchange.com/questions/221/… codegolf.stackexchange.com/questions/3088/… codegolf.stackexchange.com/questions/54301/… codegolf.stackexchange.com/questions/1864/… \$\endgroup\$
    – Dave
    Nov 21, 2016 at 21:21
  • 1
    \$\begingroup\$ Three of those questions are from 2011 and predate all of the current commonly used golfing languages. IIRC the only one which was in common use on the site back then was GolfScript (and Perl, which does show up in answers to both of them). The other one is another August question. \$\endgroup\$ Nov 21, 2016 at 22:09
  • \$\begingroup\$ @PeterTaylor limiting to the past year (and before August) turns up codegolf.stackexchange.com/questions/65958/… codegolf.stackexchange.com/questions/66707/dd-skill-challenges codegolf.stackexchange.com/questions/83371/… codegolf.stackexchange.com/questions/65459/hexagonal-maze-time codegolf.stackexchange.com/questions/69442/… (not quite a full system but does require more than a usual ascii-art challenge). Of course, now I'm at risk of confirmation bias. \$\endgroup\$
    – Dave
    Nov 21, 2016 at 23:32
  • \$\begingroup\$ (I'm not too sure about including that hexagonal maze one; it doesn't quite seem like the sort of multiple-component system I'm referring to. The first 3 are much better examples) \$\endgroup\$
    – Dave
    Nov 21, 2016 at 23:34
  • \$\begingroup\$ If nothing else, I encourage anybody who likes using golfing languages to have a go at the challenges I linked to. It'd be great to see dedicated golfing languages among the answers. \$\endgroup\$
    – Dave
    Nov 21, 2016 at 23:52
  • 1
    \$\begingroup\$ @Dave Your challenge is accepted. :^D \$\endgroup\$
    – DLosc
    Dec 23, 2016 at 4:06
  • \$\begingroup\$ @DLosc neat; upvoted both! (the 0815 answer especially is amazing) \$\endgroup\$
    – Dave
    Dec 24, 2016 at 1:22
2
\$\begingroup\$

At the time of this post, there was not a single golfing language answer to any challenge with such a tag. It is not for lack of popularity though, as this challenge had about ten thousand views, 63 upvotes, and 37 answers.

A lot of golfing languages seem to have a hard time with such challenges.

\$\endgroup\$
4
  • \$\begingroup\$ iirc, APL can spin up threads no problem. \$\endgroup\$
    – tuskiomi
    Nov 29, 2016 at 15:49
  • \$\begingroup\$ @tuskiomi Correct. APL is not a golfing language. \$\endgroup\$
    – Adám
    Nov 29, 2016 at 16:02
  • \$\begingroup\$ I'm pretty sure it has more than 5 one-character functions. \$\endgroup\$
    – tuskiomi
    Nov 29, 2016 at 16:04
  • 2
    \$\begingroup\$ @tuskiomi They are all "operators" (+,-,÷,×,| etc.) More complex built-in functionality is provided by multi-character system functions (e.g. ⎕UCS to convert to/from Unicode code points). \$\endgroup\$
    – Adám
    Nov 29, 2016 at 16:07

You must log in to answer this question.

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