# How to score the Lego WeDo programming language?

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

• I think if we are counting bytes you have to use the size of the file. If we are counting "score" we can probably come up with a nicer scoring method, like what was done for minecraft. This is sort of another topic, but I don't think we should ever be comparing bytes to these other scores (or that we should really compare between languages at all). – FryAmTheEggman Jul 22 '16 at 18:25
• I think the current policy is that "code-golf" is competition between submissions of the same language rather than between different languages. So, I believe is it fair to use an alternative scoring system based on the blocks instead of the 856-byte file for scoring. We just have to establish a consensus so that all WeDo programmers (of which I might be the only one on the site) use the same scoring system. – PhiNotPi Jul 22 '16 at 18:44
• – Adám Jul 24 '16 at 18:19
• And I thought Pyth was confusing... – George Gibson Aug 1 '16 at 11:30
• does this language use GOTOS!?! – noɥʇʎԀʎzɐɹƆ Aug 3 '16 at 17:31
• Snap is a similar language: codegolf.stackexchange.com/a/48482/34718. Languages like this remind me of Alice. – mbomb007 Aug 3 '16 at 18:36

## 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 score to a challenge.

• While I don't golf in this language, I expect it to be much more accessible to try to minimize blocks, or some other visible feature, than bytes. Imagine if every time you think you have an optimization, you need to view the raw file and read off some totally opaque number. Maybe you can look at the produced source and learn what effect each change makes, but then you're golfing some other clunky not-really-graphical language. I'm skeptical that the optimizations will be the same -- back when Pyth was basically Python commands shortened, it still led to different solutions. – xnor Jul 27 '16 at 9:26
• @xnor But that doesn't mean we should count Python by a short-hand notation like the original Pyth, just because removing tokens ("simplifying the program") might increase the byte count. That's atomic-code-golf. If the extra layer of the file representation is too much trouble for anyone, they can still define their own text-based format and transpile it. – Martin Ender Jul 27 '16 at 9:46

### 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 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.

• Well, we DO use bytes. – user54200 Jul 27 '16 at 6:23
• What you're suggesting is submitting an atomic-code-golf score to a code-golf challenge (plus, if you just count blocks you can store an arbitrary amount of information in the literal blocks for free). I don't think that's a good idea. There's also the issue that everyone using the language would have to know about this post to score their submission correctly. I've posted a separate answer that goes into a bit more detail regarding these problems. – Martin Ender Jul 27 '16 at 7:50
• Minecraft doesn't actually use blocks for scoring anymore. – mbomb007 Aug 3 '16 at 18:35

## 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.

• Is this really representative of the size of the code? If the output file contains redundant information like the Operating System and position of blocks than it might not be fair. For example a golfer on Linux may be getting one less byte than one on windows. Just some food for thought, let me know what you think, – Rohan Jhunjhunwala Jul 23 '16 at 18:01
• @RohanJhunjhunwala If there is redundant information, one could always make a compressed version of the language and use it. – Mego Jul 23 '16 at 19:32
• that is an interesting argument, but personally I do not believe that we should require this to create a competitive entry. Essentially I could write a trivial java derivative which does not have a class declaration or main method signature at all. Personally I feel we should encourage use of the original over trivial deriviatives. However that being said I do understand your view point and will change my vote. It does seem like a viable way of scoring. – Rohan Jhunjhunwala Jul 23 '16 at 19:42
• Well Im locked in to my opinion now. – Rohan Jhunjhunwala Jul 23 '16 at 19:42
• I cant change my vote. :( – Rohan Jhunjhunwala Jul 23 '16 at 19:43
• @RohanJhunjhunwala Another thing to consider about your argument about OS info and position of blocks is, we accept any code, so long as it will run on at least one readily-accessible system. If your code is shorter on Linux than Windows, then post the Linux version. Cross-compatibility is not expected here. Adjusting the positions of the blocks to achieve the optimal byte size would be part of the golfing, in my opinion. – Mego Jul 25 '16 at 5:28
• makes sense (15 char limit) – Rohan Jhunjhunwala Jul 25 '16 at 11:51

# 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.

• 2D position of blocks
• Like I said, if that extraneous data is not required for Lego WeDo to work with the file, the user is free to remove as much of it as possible. There is no requirement to count the file exactly as it is produced by Lego WeDo while exporting, as long as the counted file can be imported. – Martin Ender Aug 3 '16 at 18:21

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.