11
\$\begingroup\$

This question already has an answer here:

My read on the current state of meta.CG opinion is that the use of libraries is acceptable and that the library call should count in the character count:

Use of built-in functions and libraries in Code Golfs

Using libraries in solutions

And from this discussion I conclude that there isn't really a consensus around whether or not languages specifically built for golfing should be allowed (but GolfScript is used to answer questions all the time, so perhaps that's as definitive an answer as one can get):

What programming language should we consider for the code-golf solution ?

Would the use of a code golfing library therefore be acceptable? I'm thinking of a library that:

  • Has a one-letter name (so calling it would require something like library(g) -- 10 characters)
  • Shortens commonly used function names (print to p, etc.)
  • Curries a few functions so that defaults agree with their common usage in golfing
  • Loads a few commonly used libraries (so commonly used that they are pretty much part of the canon in answering questions on SO)
  • Would be a general-purpose library (e.g. it wouldn't be updated just to solve a particular problem)

It seems to me that:

  • You incur a fairly major upfront cost (10 or so characters) and get a benefit down the road. Not unlike the common golfing trick of shortening functions that you use twice (e.g. l=length;l(a);l(b))
  • For short problems this would be at best a slight advantage and for long ones it would be a huge advantage.
  • This may help to even out the cross-language differences in function lengths

Sounds like a reasonable compromise to me, but curious what others think.

\$\endgroup\$

marked as duplicate by Dennis Jul 7 '17 at 17:05

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 1
    \$\begingroup\$ From my R-non-user point of view, this reads like a "R doesn't win often enough, can we devise a library from the ground up, we'll publish it and make it well-known enough so we can reference it and win" from disgruntled R users. But maybe I'm missing some background. \$\endgroup\$ – J B Dec 8 '11 at 21:53
  • \$\begingroup\$ @JB - It's a rather accurate observation. Doesn't diminish the need for such a package though ;-) \$\endgroup\$ – Tommy Dec 8 '11 at 23:09
  • \$\begingroup\$ @JB I'm clearly coming at this from an R perspective since that's what I know, but I don't think the problem is limited to R. \$\endgroup\$ – Ari B. Friedman Dec 9 '11 at 2:58
  • 1
    \$\begingroup\$ The discussion about the legitimacy of GolfScript is actually to be found here \$\endgroup\$ – Peter Taylor Dec 9 '11 at 12:23
8
\$\begingroup\$

It's one thing to use standard libraries and another to roll your own. I think it risks turning into a game of "Who can write the most advantageous library?" rather than "Who can find a devious way to use the language?"

(Which isn't to say I don't understand the desire: I often find myself wishing that GolfScript had w as an alias for while or b as an alias for base, and that digits weren't valid in identifiers - but I stick to muttering about it rather than forking the language).

\$\endgroup\$
  • \$\begingroup\$ +1 I have also muttered about # being wasted as far as golfing goes \$\endgroup\$ – gnibbler Jan 24 '12 at 20:25
  • 8
    \$\begingroup\$ Resurrecting the dead here, but if we allow people to construct their own languages and use those (if the language was created before the question date), then we should certainly allow people to create their own libraries under the same restrictions. \$\endgroup\$ – Nathan Merrill Jun 15 '15 at 18:47
7
\$\begingroup\$

I believe that it shouldn't be a problem, as long as:

  1. using the library does not violate the rules of the question
  2. you are using a version that was released before the question was posted
  3. that version of the library is freely available as of when you are posting your answer (please provide a link in your answer as well)
\$\endgroup\$
6
\$\begingroup\$

It's been many years since this quesion was asked (and was active). Today, I see some users using pretty much personal golfing languages, and besides the rule of not using languages/language features that didn't exist before the question was asked, it seems everyone is fine with it.

I'm fine with it too. However, I think that to be consistent, we should also then allow custom libraries, as long as they too existed before the challenge in question, and as long as they're "declared". For instance, whether you answer with

C with Votrob's Magical Golfing Macro library, 32 bytes

or

VotroC, 32 bytes

shouldn't matter. Here, I imagine "VotroC" as a custom golfing language implemented as a C header file of macro definitions, existing before the challenge question of course.

If submitting as the former, I think you should even be allowed to leave out the #include "votroc.h" or skip it in your byte count, since you could easily work around it by declaring your library a language and submit it as the latter.

Writing macro collections/EDSLs for golfing isn't really against the spirit of golfing more than golfing languages are, IMO. It's really the same thing. So they should "compete" on equal terms.

\$\endgroup\$
  • \$\begingroup\$ I agree with this to an extent. If its a standard library, however, then I'd consider it to be the same language \$\endgroup\$ – Nathan Merrill Nov 15 '16 at 20:16
4
\$\begingroup\$

IMO the point of golfing is perverting existing languages that were not designed with golfing in mind. Designing a golf library is akin to altering the language with golfing in mind. Which defeats the point.

My opinion makes me pro-J and kinda anti-Golfscript. (well, GS is nice...)

\$\endgroup\$
2
\$\begingroup\$

I think it's a great idea. I have given this some thought, and I have some ideas:

1 - Naming. G might be less problematic than g (a more common local variable).

2 - Loading the library:

# Normal way, Not efficient 
library(G) 

# Golfed way, Much more efficient :)
G::.

3 - How do we accomplish that? Well, in the golf package we define "." using an active binding:

makeActiveBinding(".", function(x) require(G), golfEnv)

4 - Functions to put into it: Well, plenty of candidates, but something to get input efficiently and output efficiently seem like good candidates. I'm often annoyed that paste and cat always have sep=" " when I want sep=""...

\$\endgroup\$
1
\$\begingroup\$

I found this question hoping to propose the same thing. Since the [tips] questions are all CW, it seems convenient to have one answer in the [tips] question for each language for a collaborative library. If you keep using the same idiom and abbreviations, add them to the KB, and save yourself X chars next time.

In my PS answers, I find I keep needing a control structure that combines for and forall. I'd love to lose some of the overhead.

To use it in a golf answer, one would have to cite a specific revision dated earlier than the question (no ex-post-facto).

\$\endgroup\$

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