On "interactive" answers and other special conditions

Question

Interactive languages (and related issues) have afflicted me with a bunch of gripes regarding character count and program testing. Clarifying these should help coders in other languages like Mathematica and dc with similar issues. (And will also shut me up about it!)

1. How much action on the user's part (to invoke the program)? For instance, does it count if you, as in this example, make the user paste in each line?
2. How are character counted in interactive solutions? How is it counted if you, as in this example, make the user paste in each line? In that example, Eelvex counts just the characters in each row, no newlines.
3. How are special invocations counted? E.g. specifying perl command line options or using an external program like tr to filter input for dc or J. Example (Sorry, Eelvex, you're an easy target :)
4. Where a function is requested, should it be assigned a name? For instance, in this question.

Answer 1

My basic guideline would be "as the problem statement says". Which is mostly to mean it's allowed to explicitly override anything it wants from what I'm about to say next.

Actions to invoke

For test-case/IO programs, I like it better when the whole invocation is possible as a single line, through redirection or bash herestrings (<<<).

$ interpreter script.ext < input_file
$ program <<< 'input line'
$ echo -n 'sensitive input' | ...

If for justifiable reasons input can't be redirected in (e.g. has to be terminal input, and the problem statement didn't forbid that—and I don't think it should), it should be with minimal hassle. Line by line would likely be too much for my personal level of acceptable laziness.

(kinda OT: I haven't tried the Eelvex example you linked to, but the data-pasting requirement seems more like an overhasty copy-paste from his live demo session than an actual requirement of his program)

Character count in interactive solutions

Only the characters part of the code are counted in. That includes newlines, if they're needed for the code to be well-formed. Unless overruled by problem statement, input is not counted in. That includes newlines part of the input. I trust the problem statements to be clear enough in this regard, and the answerers to be fast enough to request clarifications when needed.

Digressing from there, I don't think input data should be allowed to be mixed with code. Separate file, input stream, prepended, appended, both? (J again), stuck in parentheses for a function call, ok, but this is too much.

Special invocations

This one is more subtle than the question makes it. I make a difference between:

• options to bring the language level to a specific point. This has mostly been observed with Perl 5.10+, but I feel it might pop up again with Haskell Prime. It was kept a bit more hidden for compiled languages anyway (C99, C++0x) The consensus up to now on SO and here was "the -M5.010, when needed, is free".
• options to request different behaviors from the interpreter. This is the n/p/l/a/f family of options in perl/sed/awk/ruby. I count those as a difference in character count to the shortest equivalent invocation without them. This can be a bit tricky at times
  perl -nle 'stuff' is 2 characters more than perl -e 'stuff', so it counts for 2 more characters than the contents of stuff. This supposes stuff needs no quoting to go in single quotes, or it would need more characters to escape. If not, either the escape characters are counted in as well, or you put the script in a file, and count the difference to perl -nl file.pl, which now includes the hyphen as well as one of the spaces.
• OT: the shebang follows the same rules (it's free, except for the behavior-modifying parts of it)
• external filtering: IMO this kicks the submission out of single language league, and it should be evaluated as a standalone bash (or other) script. That shoudln't prohibit it from using multiple script files, named with a single letter if the interpreter allows it; it makes the submission less readable anyway and that should be enough to discourage. We might want to devise a tolerance for a single interpreter name (jconsole seems a bit arbitrarily handicapped compared to dc).

Named functions?

If the problem statement asks for a statement, answer with a function. If the language allows/supports anonymous functions, use them at will. If not, well you don't really have a choice, do you?

For languages without functions... I don't know.

Compute this!

You didn't ask for it, but I'm mentioning it en passant as it's related. For problems that just ask "compute this" (usually with such and such constraints), I'm very tolerant on the I/O.

• The interpreter's interactive output is good to me.
• Requiring the code to be pasted in is ok, as long as it can be done in a single shot and the newline is counted in if needed.
• Requiring a bit of environment tweaking to prevent long answers from being truncated is ok and free.
• Environment tweaking that alters the calculations is not ok. (I'm thinking of bc's precision and base)

Answer 2

On the scoring of PHP and Perl

J B's post is commonly linked back to in defense of a particular scoring, most often for Perl. Although I agree with his post in large part, there are a couple points that I am not in complete agreement with, or that I believe were not adequately addressed.

As a foreword, I consider myself a fairly active member of this site, and the majority of my submissions have been in either PHP or Perl. At the time of writing, I have 92 submissions in Perl (20 accepted, 72 unaccepted), and 66 in PHP (11 accepted, 55 unaccepted). As far as I can tell, I am the most prolific contributor of either language. I therefore have a vested interest in a fair and consistent scoring of these two languages in particular.

---

1. Programs are Programs

This is a point that I believe J B failed to adequately address. Both PHP and Perl support saving code to a file and executing it, and this is in fact the primary usage. The shortest invocation of each is php program.php and perl program.pl respectively. If the question specifically asks for a program, as most do, it is my opinion that the supplied code must be executable in this manner. If the code cannot be run in this way (e.g. it can only be run from the command line), it is, in my opinion, not a program.

To be clear, this would restrict the Perl options -e and -E, and the PHP options -r and -R from any challenges requiring a program.

---

2. Every Additional Command Line Byte Counts

"I count those as a difference in character count to the shortest equivalent invocation without them."
- J B

I am in complete agreement with this, although I have not to this point been following it (and instead counting only "functional" bytes, i.e. [^- ]). This would mean, for example, that -p as in perl -p program.pl should be counted 3 bytes heavier than its shortest invocation perl program.pl, and -pl as 4 bytes, etc. This is entirely consistent with the "Unofficial Official" Perl Golf Rules, and all entries in the Perl Golf History Book were scored in this way.

For challenges where a program is not required, the same rule should apply: every additional byte is counted. For example, the difference between shortest invocation perl -e'code' and perl -pe'code' is only one, and therefore -p should be counted as one in this instance.

I also believe that -M5.01 (and it's more verbose equivalent -M5.010) should be scored in the same way, just as one would score -Mbigint or -Mntheory. Of course, if a program isn't required, -E is no longer than -e, and therefore should be "free" in this sense. J B argues that this option falls under "options to bring the language level to a specific point", as would, for example gcc -std=c99. I disagree. The closest equivalent I can think of is Python's from __future__ import, which I also don't think should be free. If you're writing code for Python 2, you should be writing for Python 2, taking the good with the bad, and not picking and choosing Python 3 features that could make your code shorter. As an example, this solution could be one byte shorter with a "free" from __future__ import division, so that x could be initialized to 1, rather than 1..

I feel the same way for Perl. use 5.10 is short-hand for use feature qw(say state switch), all of which were back-ported from Perl 6.

---

3. Assume Default Settings

Content Moved

---

4. Default Encoding

Some online interpreters, for example ideone.com, will silently convert any input to UTF-8, potentially invalidating an otherwise valid solution. In PHP, for example, ~õ is a common shortcut for "\n". It is my suggestion that the encoding be assumed as ISO-8859-1, unless otherwise specified. Solutions using multibyte encodings should be counted in bytes, and not characters.

---

5. Prefer Shebangs

This is more of a suggestion for style rather than scoring. For interpreters that allow post-hoc command line options via shebang (e.g. Perl and Ruby), this should be the preferred way to convey this information. There are two primary advantages. For users unfamiliar with the language, and its available command line options, when copy-pasted the code will still work "as is." For others, it will allow them to immediately see what the program does and how it works, even when scanning quickly, without having to stop and read the accompanying description.