How to score the Lego WeDo programming language?

Question

Lego WeDo is a programming language meant for children, used to play with some simple Lego robotics. It's a visual drag-and-drop language. Here is a screenshot of a divisibility tester written in the language:

There's a lot of "blocks" that can do various things, like writing a number to the screen and performing some super-basic arithmetic with that number. Language quirks include non-nestable loops and support for multi-threading.

How I/O is handled

The only way to handle I/O effectively, as far as I can tell, is to manually type the input numbers into specific text boxes on the screen. For example, "15" and "5" are the inputs to the divisibility program above. Output is simple: it's the number that's on the screen after the program is finished. Above, the output is 1 because 15 is divisible by 5.

A secondary question I have is, since there's not a formal distinction between input values (the 15 and 5) and other hardwired numbers (the -1 and 1), does this actually count as "taking input"?

Scoring?

This language is almost entirely visual with the exception of the extra parameters that can be assigned to a block (the numbers in the program above). So the question is, how should I score it?

I think there's a couple options...

• Come up with some terse description to represent a program... like each block counts as X bytes with literal numbers/text counting 1 byte per character.

• Look at the raw file size. The above program, when saved to a file, counts as 856 bytes. It contains a lot of additional information, like 2D position of the blocks, what operating system I'm using, etc.

Here is the source file:

   x   d  L     Â  }      Start                               Display      Display   GlowBot    Text Plug      Text   15   Number   1   IsNumber   False   Platform   
Windows NT                   While      Count   Inf   Snippet   1   Display Plug                       Display Divide      Display   GlowBot   Display Plug                       Display Multiply      Display   GlowBot       Text Plug      Number   -1   Number   1   IsNumber   False   Platform   
Windows NT                   Display Add      Display   GlowBot     Text Plug      Text   1   Number   1   IsNumber   False   Platform   
Windows NT                   X  }      Display Subtract      Display   GlowBot      Text Plug      Number   5   Number   1   IsNumber   False   Platform   
Windows NT                        

Answer 1

TL;DR: You don't use "bytes" at all.

Some languages, such as Minecraft, require special units. The answer should be scored:

Lego WeDo, 7 blocks

As @Mego has said, making comparisons between languages' scores does not make sense due to the natural differences between languages. As long as you optimize the code, it is still in the spirit of code-golf even if it doesn't use the same unit.

A notable exception is where a question uses a Stack Snippet leaderboard, in which case one should replace blocks with bytes and specify in the answer 1 block = 1 byte.

Answer 2

Count bytes of the file

Okay, this is the same policy as advocated by Mego's answer, but let me make another case for it.

First of all, what's the motivation for using different scoring? The language's scores won't be comparable with other languages with or without a special scoring mechanism. They'll be smaller, but what does that number actually mean? I don't think a different scoring is actually going to change the order of multiple submissions in this language substantially if at all. So it doesn't really matter. If it's just because the score is larger than it needs to be, then we should also discuss different scoring methods for Java and Brainfuck (and pretty much every other language that doesn't use all 256 characters of a code page).

Counting bytes is the easiest. You just look at the file and you'll know how many bytes it has. If scoring is based on something like blocks and then with special rules for literals (and how do you even account for the information contained in the relative placement of blocks, and should jump targets be a byte as well?), then people are bound to get it wrong, and there won't be enough people to double-check every score. Having to count by hand is just going to lead to problems.

Most importantly, new users of the language would have to know about this post to score their language correctly. I think that's a huge disadvantage. We already have way too many implicit rules scattered around on meta. Let's not add even more to come up with language-specific scoring mechanisms that don't even serve any real purpose.

As for the extraneous/unnecessary information in the saved file: you're free to remove as much of that information as you like as long as the file still works when fed to Lego WeDo. You can view that as an additional component to golfing in this language.

If you still don't like that, like Mego said, you're always free to define a new language with less redundant syntax and write a transpiler to the Lego WeDo file format.

Code golf at the root is defined as the task of solving a problem with the smallest-possible source file. Lego WeDo uses source files under the hood, so I don't see why we should make any exception for this. Like trichoplax said over here anything else means you're submitting an atomic-code-golf score to a code-golf challenge.

Answer 3

Count bytes in the file

This is the standard method of scoring programs. Special methods to count bytes are only needed if there is not a simple way to count the bytes of the program's file (like Minecraft not having a native file format until recently).

If you feel that the file format is not representative of the actual program size, you can always create a compressed/golfed version of the language. Also keep in mind that comparisons across languages are mostly meaningless - don't be upset if your language's programs aren't shorter than another language's programs.

Answer 4

Count the bytes of the file after all data unrelated to the execution* of the code after the file is compressed

This would give a more accurate idea of the amount of information stored in the program than simply counting raw bytes

*e.g.

• Metadata (date, time)
• 2D position of blocks

Answer 5

Use Blocks + Bytes in constants(except input)

Block based programming languages use too much bytes in the file, thus making unfair to score with the file itself.

So we can use a concept, which is also used in other block based programming languages.

We would score like this:

Lego WeDo, 15 Blytes (9 + 6)

(yes, this concept is similarly used in scratch)

Alternatively, We can swap each block with functions so that we can use the unit that is usually used.