9
\$\begingroup\$

Some programming languages, like Scratch, have an option to change the underlying human language of the program. Thus code such as

define say(direction

can be compressed by changing the language into, say, Esperanto, saving a byte, becoming

difini diri(direkto

code example
yes, scratchblocks apparently does support different human languages

The question then is, are these to be marked as separate languages when using this trick in answers?

\$\endgroup\$
3
  • \$\begingroup\$ Answer in question: codegolf.stackexchange.com/a/130073/110681 \$\endgroup\$ Commented Aug 26 at 14:07
  • 1
    \$\begingroup\$ My highest scoring answer uses this language trick ;) codegolf.stackexchange.com/questions/121056/… \$\endgroup\$ Commented Sep 3 at 9:59
  • \$\begingroup\$ TIL Excel apparently has different human languages too - I only picked Scratch because that was the first thing that came to mind \$\endgroup\$ Commented Sep 3 at 11:42

1 Answer 1

Reset to default
5
\$\begingroup\$

tl;dr: Not separate languages, but, if you absolutely want scratchblock bytes, separate categories of bytes.

So this is interesting because while there's consensus on topics like how to handle answers using languages with command line flags, I don't believe there's a consensus on how to handle byte saves resulting from "website settings".

After doing some experimenting with the Scratch website, it turns out language selection persists between all Scratch pages, including the home page, profile pages, project view pages, and project editor pages. Therefore, I don't believe it would be accurate to blindly compare chosen human language to command line flags.

Similarly, I also wouldn't say that changing the human language counts as making "new interpreters", as (presumably [hopefully]) the underlying interpreter is still the same, it's just how the code input is rendered in the front-end.

Therefore, I believe that Scratch in different human languages is still the same language. This is kind of reflected by the fact that if you score by block count instead of bytes (i.e. scratchblocks syntax), human language makes no difference. In fact, both the English and Esperanto screenshots have 3 blocks.

The only time a distinction would be required is if using the scratchblocks representation for scoring. In this case, I would say it would be more accurate to use phrases like "English bytes" or "Esperanto bytes" than to use different languages. It's fundamentally the same program, just "encoded" differently. In this case, it's no different to, say, using a range coder to encode programs as bitstrings and specifying "bits" in the answer header.

\$\endgroup\$
9
  • 1
    \$\begingroup\$ The "website settings" situation reminds me of PHP's config file, where AFAICT the consensus was that solutions should all use the default settings. Then again, that post is over 10 years old and maybe should be revisited. Also, is there a default language on the Scratch website, or is it based on the user's browser language? \$\endgroup\$ Commented Aug 26 at 17:32
  • 1
    \$\begingroup\$ @DLosc it seems the PHP config file is more like CLI flags. The scratch language option is more akin to, say, cookie settings or a profile setting. It has no direct impact on the interpreter, only the representation of code in a code golf answer (if Scratchblocks syntax is used as a scoring method) \$\endgroup\$ Commented Aug 27 at 1:41
  • \$\begingroup\$ The difference between "separate languages" and "separate categories of bytes" seems like a distinction without substance. Could you explain what the difference is? \$\endgroup\$ Commented Sep 3 at 19:23
  • 1
    \$\begingroup\$ @WheatWizard it's like how choosing to score golflangs as utf8 instead of SBCS doesn't make it a different language. It's still the same programming language, just encoded differently for code golf scoring purposes. In the same way, changing the human language on Scratch does not change the underlying program - it still has the same blocks in the same order. The only difference is the way it is "encoded" for code golf scoring purposes. Especially given that it seems the interpreter is literally the same with different languages, it's only the display of programs that is changed on scratch. \$\endgroup\$ Commented Sep 4 at 3:53
  • \$\begingroup\$ @lyxal But what is the substance here? Why do we care to make this distinction? It doesn't seem to have any impact on anything. \$\endgroup\$ Commented Oct 29 at 13:46
  • \$\begingroup\$ @WheatWizard the difference is important because while Scratch in English is fundamentally the same programming language as Scratch in Spanish, the "bytes unit" isn't the same. It's like trying to compare a Vyncoded Vyxal answer to a non-Vyncoded Vyxal answer. Yes, they're both Vyxal 2, but one is scored in bits while the other is in bytes. And yes, Scratch English uses the same UTF-8 encoding Scratch Spanish does, but there needs to be some answer level distinction to make it clear that something is different. \$\endgroup\$ Commented Oct 29 at 14:03
  • \$\begingroup\$ If the language change option was an actual compiler/interpreter option, this would be a non-issue, as Scratch English could be considered different to Scratch Spanish. However, the language change option is not an interpreter option. Changing the language on scratch.mit.edu does not change the underlying sb2 (or sb3/whatever file extension they use for scratch 3), it only changes the byte count. \$\endgroup\$ Commented Oct 29 at 14:05
  • \$\begingroup\$ I understand that you are making a distinction here, repeating that doesn't answer the question. The question is why are you making a distinction. It's in the title of your answer and this answer stresses it, but it seems to have zero impact on anything. What is the implication of this distinction? \$\endgroup\$ Commented Oct 29 at 21:56
  • \$\begingroup\$ @WheatWizard The implication is about byte count fairness. When there's byte savings from flags or imports or other language configurations, we require it to be part of the answer heading. Changing the spoken language of the ScratchBlocks representation is a byte save that, really, should be accounted for as part of the answer. Any other method of saving a byte through external means would potentially be seen as cheating, so why should this be excluded? \$\endgroup\$ Commented Oct 29 at 22:59

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.