It was pointed out on chat- and I agree- that scoring Golfical programs as 1 byte per pixel (as has been done with other graphical languages) would probably not be entirely fair.

Therefore, let's discuss how to do it. Here are some possibilities:

1 byte for each pixel
3 bytes for each pixel
3 bytes for each non-white pixel (1)
19 bits for each pixel (2)
1 byte for each pixel, excluding red values 00-09, which are 2 bytes each (3)
1 byte for each pixel, excluding red values 00-09, which are 3 bytes each (3) (4)
1 byte for each non-white pixel, excluding red values 00-09, which are 3 bytes each (1) (3)
Other (5)

(1) White is a no-op

(2) Based on the approximate number of colors that actually do something at present

(3)The reason red values 00-09 are singled out for these is that they can encode a 16-bit integer argument in their blue and green values, and therefore all blue/green combinations for those red values are functional as opposed to just a very small subset (less than 1/1000)

(4) I personally think this is the most reasonable

(5) Please specify.

  • 17
    \$\begingroup\$ I suggest that you add a switch that makes Golfical read a binary file (or write an codec that turns images into that format and viceversa), and that the score of that file is your actual score. This frees you from requiring a meta consensus to score your language and everyone else from the doubt if the scoring is actually fair. \$\endgroup\$
    – Dennis
    Commented Dec 12, 2015 at 18:00
  • \$\begingroup\$ @Dennis I'll see what I can do. \$\endgroup\$ Commented Dec 12, 2015 at 18:05
  • \$\begingroup\$ @Dennis And... done. \$\endgroup\$ Commented Dec 12, 2015 at 19:39

2 Answers 2


Score the number of bytes by the number of bytes

This really seems pretty straightforward. If your program is run as

$ mylang somefile

then the score of your answer should be the output of

$ wc -c somefile

that is, the number of bytes in the file.

If your language requires a command line switch to read raw bytes (RGBRGBRGB...), count that as an extra byte, just like any other language. (Or, if you make the default "detect filetype and interpret as raw RGB if nothing else is detected," you don't need a switch so there's no penalty.)

apparently I was ninja'd by Peter by 16 seconds...

  • \$\begingroup\$ But then can't everyone just post binary compiled code of their language of choice? I.e. the gcc output of any C program will be smaller than the source code size; same goes for Java, etc. \$\endgroup\$
    – Ruslan
    Commented Dec 16, 2015 at 23:42
  • 9
    \$\begingroup\$ @Ruslan This is false. A simple hello world program I wrote in c was 70 bytes. The compiled binary was 8548 bytes. \$\endgroup\$
    – isaacg
    Commented Dec 17, 2015 at 1:18

Score by transpiling into a suitable raw binary encoding

The github repo now provides an Encoder class for doing this. To encode a program, give the letter e as the first argument, the program filename as the second, and the name of a text file as the third. To decode a program, change the first argument to a d and reverse the second and third arguments.

It assumes that the width and the height of the image are both smaller than 4096 pixels.

  • 3
    \$\begingroup\$ I don't understand why this has a negative score when it's implementing @Dennis' suggestion, which got 15 upvotes/helpful flags \$\endgroup\$
    – cat
    Commented Dec 18, 2015 at 19:53

You must log in to answer this question.

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