-3
\$\begingroup\$

This question already has an answer here:

BBC micro:bit is a piece of hardware wich allows to to run code, such as Python or Javascript, that is custom made for the micro:bit chip. However, it in itself is not a programming language.

Instead, it allows people to use 4 different coding languages to manipulate it:

Obviously, as all of these languages are Turing complete, they can compete here. But how should we count the bytes of their programs?

This will be a long post, so buckle down and get reading.

Lets take a look at each language that can be used, and the issues with them.

Python

Python in micro:bit (also known as microPython), uses a separate, custom module called microbit that has to be imported to be used:

import microbit
microbit.display.scroll("text")

I see three different ways of counting bytes in Python micro:bit

1) We count bytes as the text in the actual program. So the example above would be 47 bytes long

2) All Python microbit answers must import is as from microbit import * as to exclude the microbit. from it's functions. The import statement doesn't count as part of the code as it would be like having to import Jelly to run a Jelly program. The above would be changed to display.scroll("text") and would be 22 bytes long.

3) We count the size of the .hex file returned by the website when you click "Download".

Issues

1) It means that a lengthy import call has to made at the start of each program in order for the program to be run successfully

2) We aren't counting the whole piece of code. The code on its own would be a snippet and wouldn't work.

3) The .hex file for the Hello, World! program is 597,968 bytes long! This would automatically disqualify microPython from winning and would mean that any basic would be won hands down.

JavaScript Block Editor

This is close to a combination of JavaScript and Scratch. A Hello, World! program looks like this

JavaScript example

The ways that code could be counted here are similar to the Microsoft Touch method.

1) Count the blocks as 1 byte each and user info as 1 byte for each part ("Hello, World!" => 15). The above example would be 18 bytes

2) Count the blocks as 1 byte each and user info as 1 byte for each part, except the function onStart() { and its closing brace. The above example would be 16 bytes.

3) Count the size of the .hex file. Again, this would lead to incredibly high scores.

Microsoft Block Editor

This is quite similar to Scratch and so I think that it should be scored in the same way, with one addition.

In Microsoft Block Editor, there is a feature that Scratch doesn't have that turns on various LEDs on this display. The block looks like

Extra Feature

I believe that this should be scored as follows:

  • 1 byte for the block
  • 1 byte for every tick in the grid

The above would score 10 bytes (1 for the block and 9 ticks).

And, as usual, there is the "size of the resulting file" argument, which, as explained before, won't work.

Microsoft Touch Editor

This seems to work in the same way as TI-Basic, in that chunks of code are stored as tokens. If you check out the editor and hover over the tokens, you will notice that it groups things together. A Hello, World! program looks like this

program

which groups the code into tokens. This is what the tokenized code looks like ([] is a single token, {} means that each letter in it is a token)

[script]{a}[newline]
[function main{}][newline]
[tab][basic][-> show string]{(}["Hello, World!]{,1)}[newline]
[end function]

which would result in 15 bytes. However, despite it grouping "Hello, World!" as 1 token, I believe that it should be split into a byte per character, as it can be edited. Therefore, the final score of this would be 30 bytes.

A different way could be to exclude script, function main() and end function from the scoring as they are unable to be removed.

Finally, again, there is the "count the bytes in the file" option that Dennis seems to love. And, again, this won't work because, like the microPython code, it complies into a massive .hex file, this time 583,482 bytes long and just isn't an accurate representation of the code.

Conclusion

This is how I believe each version should be scored. If you disagree with me, feel free to post an answer below explaining why we should use your way.

  • Python: Length of the complete code given to the online compiler, in UTF-8 bytes
  • JavaScript Block Editor: Count the blocks as 1 byte each and user info as 1 byte for each part
  • Microsoft Block Editor: Scored in the same way as Scratch, with the addition.
  • Microsoft Touch Developer: The token grouping they give, with user information counting as 1 byte per part

And now it is up to you. What do you think?

\$\endgroup\$

marked as duplicate by Okx, user62131, Shaggy, Laikoni, Mr. Xcoder Jun 19 '17 at 11:02

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.

  • 7
    \$\begingroup\$ The .hex file for the Hello, World! program is 597,968 bytes long! Then the score is 597,968 bytes as far as I'm concerned. \$\endgroup\$ – Dennis Jun 18 '17 at 15:25
  • \$\begingroup\$ @Dennis other languages such as Scratch must compile into a file similar to this and yet we don't count them by the size of their files. Or Minecraft, which we count in blytes, compiles as code, but uses a custom scoring system. \$\endgroup\$ – caird coinheringaahing Jun 18 '17 at 15:27
  • 11
    \$\begingroup\$ And I'm very much in favor for counting all of these languages by the size of their files. We should stop making up new scoring schemes for programming languages. \$\endgroup\$ – Dennis Jun 18 '17 at 15:31
  • \$\begingroup\$ @Dennis and I don't agree with that. It unnecessarily punishes languages that think outside the box. If it weren't for Jelly, I'm pretty sure that you'd advocate all languages using UTF-8 as their encoding. \$\endgroup\$ – caird coinheringaahing Jun 18 '17 at 15:33
  • 8
    \$\begingroup\$ I'm not sure why this suddenly became ad hominem, but I'll bite. Requiring a specific encoding is the exact opposite of scoring programs by their actual size in bytes. Some languages aren't even character-based; UTF-8 makes no sense here. Also, programming languages existed long before Unicode did, and some of the older ones have no interpreter that would even understand UTF-8. \$\endgroup\$ – Dennis Jun 18 '17 at 15:39
  • \$\begingroup\$ @Dennis this isn't ad hominem. I simply used Jelly as an example, I could have used 05AB1E or Ohm etc. I just believe that forcing a language to count their score in bytes can punish innovative and interesting languages such as Piet. It seems as though you're encouraging people to make simple text based languages, which is just destroying creativity. \$\endgroup\$ – caird coinheringaahing Jun 18 '17 at 15:58
  • 6
    \$\begingroup\$ I'm not talking about Jelly, I'm talking about I'm pretty sure that you'd advocate. Anyway, Piet is a perfect example to illustrate how "obvious" choices for scoring systems can go bad. It's commonplace to score Piet programs by the number of codels, yet that loses some information about how all the codels are arranged. \$\endgroup\$ – Dennis Jun 18 '17 at 16:12
  • \$\begingroup\$ Your scoring for the 'box' makes no sense. 1 byte for each tick? Each tick-box has to be stored as either ON or OFF, which would take up the same number of space - there's no point in adding more bytes for more ticks. It should be constant. \$\endgroup\$ – FlipTack Nov 2 '17 at 20:42
10
\$\begingroup\$

The length in bytes of a program is the number of bytes in its source file. If this means that Hello World is 600000 bytes, that's a problem with the language, not with the scoring system. If the language has lots of boilerplate, that's a problem with the language, not with the scoring system.


Although the above is really all that needs to be said (and has been said many times before), I do additionally want to address one remark OP made in a comment:

I just believe that forcing a language to count their score in bytes can punish innovative and interesting languages such as Piet. It seems as though you're encouraging people to make simple text based languages, which is just destroying creativity.

The purpose of PPCG is not to encourage people to make languages of any kind. If people really want to make languages for use on PPCG then that's their privilege, but it is entirely optional and at their own risk. I think the site was at least a couple of years old before the first language was created specifically for it (GolfScript being created before PPCG, and I think by an Anarchy Golf competitor).

But we do need to keep things like scoring systems as simple and consistent as possible. I'm sure I'm not the only person who's fed up with people claiming that their language deserves special treatment. Creativity can be a good thing, but IMO it's a bad thing when it's channelled into coming up with creative reasons for making pointless exceptions to the rules which waste the time of other members of the community who have to argue against them.

\$\endgroup\$
  • 1
    \$\begingroup\$ How on Earth do you interpret "the number of bytes in its source file" as "their compiled file size"??! \$\endgroup\$ – Peter Taylor Jun 19 '17 at 10:04
2
\$\begingroup\$

For the languages you mention, see Peter Taylor's answer - I agree with all points.

A new language

I also wanted to add that if you really want to have a shorter representation in bytes for a particular language, you could write your own language that compiles to the target language. You'd write a compiler that takes source code in your new language as input and outputs the standard representation in the language you are targeting. I don't generally see the point in a language that exists solely to produce shorter versions of the code of its parent language, but occasionally a language starts off that way and then goes on to develop interesting features in its own right. I'm sure people here can give several examples if you're interested in seeing how this has happened in the past.

Readability leads to golfability

It might be particularly useful for the languages you mention since they seem to have such long "source code" that it clearly isn't human readable in its raw form, so it may be difficult to guess whether a particular change will make the source code shorter or longer. One advantage of a new language that takes condensed source code that compiles to the long standard source code is that after getting used to it, it may be nearer to human readable. Even more so if you make this a design consideration.

Golf is not the only sport

Note that your concerns about destroying creativity only apply to code golf, as the other challenge types do not require unambiguously measurable length of source code. If it is specifically code golf that you wish to compete in, understand that a big part of its success and appeal is that it is trivially simple to score, giving a very low barrier to entry but almost endless opportunity for improvement. Making up an arbitrary "equivalent" scoring mechanism detracts from this simple appeal.

Note that if you implement your desired scoring mechanism in the form of a new language as described, and it meets our site definition of a programming language, then you won't need a meta post to validate the scoring mechanism - you'll just be scoring in bytes like everyone else. If you haven't done this, then the scoring mechanism is arbitrary and will tend to lead to disagreements over the correct score where people have an incentive to interpret the wording to suit their particular answer. A compiler removes that potential for subjectivity and restores the beautiful simplicity of code golf.

\$\endgroup\$

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