3
\$\begingroup\$

This question already has an answer here:

Recently, I have been thinking about creating golflang assemblers. Like assemblers, they just substitute a mnemonic(or a word) with the actual symbol. Since many golflangs aren't much more comprehensible than binary, it could use assembly-like programs to ease the coding. I know this makes golflangs easier to use and might make code golf more pointless for some non-golflang golfers. However, there have been tons of previous discussions on how meaningful using a golflang is, and I think using "assemblers" doesn't change that, because it's the logic that makes good answers, not the effort you put in the mundane process of finding the right functions. However, I'd still like to see what the community says. What do you think, guys?

Edit: In case the question's not clear enough, it's sort of like asking whether using assemblers is acceptable in a competition that asks you to submit machine code.

\$\endgroup\$

marked as duplicate by Mego, NoOneIsHere, Paul Schmitz, Michael Klein, manatwork Sep 20 '16 at 7:59

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\$ Sesos already does that. It's definitely legitimate if the binary version can actually be run by your interpreter, but I can't say how interesting or popular it will be. \$\endgroup\$ – Martin Ender Sep 18 '16 at 15:40
  • \$\begingroup\$ @Mego I don't seek to post an answer in a new language, I seek to generate an answer in an existing from a new language \$\endgroup\$ – busukxuan Sep 18 '16 at 18:49
  • \$\begingroup\$ @busukxuan I'm not really seeing the difference. \$\endgroup\$ – Mego Sep 18 '16 at 18:49
  • \$\begingroup\$ @Mego my answer is generated by a program. The linked question's OP's answer is handwritten. Plus these two processes are almost the reverse of each other. \$\endgroup\$ – busukxuan Sep 18 '16 at 18:54
  • \$\begingroup\$ @Mego no, the program doesn't auto-solve the problem. It just assembles the code. \$\endgroup\$ – busukxuan Sep 18 '16 at 18:58
  • \$\begingroup\$ Sorry, misunderstood the question. I still think it's a dupe of the first one I linked - you're asking about creating a language that compiles to an existing language, just like the linked question. \$\endgroup\$ – Mego Sep 18 '16 at 19:02
  • 1
    \$\begingroup\$ @Mego The linked question's point was if it was okay to create languages designed for golfing. Mine is if it's okay to create a tool that essentially removes a significant difficulty in writing golflang answers. I I'm not sure how the community thinks about first writing a long program then assembling it into a short program and then posting as answer. \$\endgroup\$ – busukxuan Sep 18 '16 at 19:09
  • \$\begingroup\$ I'm not sure what the actual question is here. \$\endgroup\$ – Peter Taylor Sep 19 '16 at 7:25
  • \$\begingroup\$ @PeterTaylor Sort of like asking whether using assemblers is acceptable when most people write machine code in a competition. \$\endgroup\$ – busukxuan Sep 19 '16 at 7:28
  • 1
    \$\begingroup\$ You might point out in the question that the difference is in which code your submitting. In devising your own language mapping another you submit/score your code. In devising a assembler-inspired tool, you write in your code but submit/score your output. As long as your open about how your code is produced I don't see a problem. \$\endgroup\$ – Linus Sep 20 '16 at 2:29
5
\$\begingroup\$

To put the clarified question in my own words:

May I use a source-to-source compiler to generate my submission?

Yes, by all means. There are already answers on this site which have been generated by meta-golfing programs, and there's no controversy about that.

\$\endgroup\$
2
\$\begingroup\$

Yes.

I don't see much difference in a program that converts one representation of a program into another and the (manual) process people use to score LabVIEW programs as it applies to the score an entry receives. In fact, it is possibly more fair than the latter, since we can be sure that a fully-executable program is representable in that many bytes.

As to the question of whether it is okay to "remove a significant difficult in writing golflang answers", I think most people find that whole "look through lists of symbols to find the one that means the thing you want to do" the least interesting part of golfing. The fun part is writing the simplest program that performs the required task, and I feel that most people would embrace the opportunity to forgo the boring/annoying part.

In fact, since this may not add much to an opinion about whether entries in one language may be compiled to from another, I will generalize this:

If a language allows its programs to be represented in multiple different forms, you may score the most compact form while posting as an explanation the expanded/mnemonic form. This is what is done with LabVIEW, for instance. In the case of an assembler from one language to another, you can score the language you've assembled to, while posting as an explanation the (presumably easier-to-understand) one you've assembled from.

\$\endgroup\$

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