Wrong tool for the job
Repost from 2018, 2021, 2022, but rephrased significantly
Technically, every Turing-complete language should be able to solve every problem. In practice though, some problems are really hard in particular languages, and thus those languages are rarely used. While you can, for example, invent multiplication in a language that doesn't have it, it's a lot of effort for little benefit.
However, some brave souls are not afraid of a challenge. They'll solve array challenges in languages that lack arrays. They'll solve random challenges in languages lacking an easy-to-use RNG. This category is for them. Those who don't care about spending a whole day solving a challenge that would be <100 bytes of Python.
In short, this answer is for answers that:
- Solve a challenge in a language that's lacking the basic features that would normally be used for this type of challenge
- This could be because the language has a specific weakness or because it's just really hard to use for all problems
- Still make a good attempt to improve the score, within the limits of the language
This challenge is about substituting a specific word with a different set at random.
There are two things that ><> is really bad at: working with arrays and randomness. The stack in ><> can hold only single numbers so trying to store something like a list of strings that can be conveniently accessed with the very primitive set of stack manipulation operators. Instead, this answer uses the code itself as storage but this has it's own problems as you need leave space near the top of the code box to store data. If you need more data, in this case you need a list of list of strings it's tricky to make sure you can store them all while still being convenient to access.
The most important part to make that a bit golfy is to make sure the base of every array is below 15 so you can access it with f+ instead of a much longer expression for every single access. That means your main code needs to be limited to at most 15 - amount of data lines, in this case 13, very little for such a complex challenge.
Randomness is also very hard. The only random operator in ><> is the x which just moves in a random direction. Turning this into a uniform random number between 0 and n, a basic builtin in most languages, is not trivial, especially when you have a tight limit on the number of vertical lines used.
Nomination by Aiden Chow
Edit: Bubbler has recently golfed his answer even further to 29 bytes, due to an improvement to the second loop. It is now under 30 bytes... just insane!
An easy challenge like converting a base-10 number to its binary form can be done with the use of a builtin or two in most languages. However, in Piet, it is difficult to create a functioning answer to even the most simplistic challenges, let alone golf them.
For Piet specifically, it is not only difficult to decide which instructions need to be used in which order, but also to construct a concise structure of the code and control the path of the instruction pointer as it makes its way throughout said structure.
In Piet, there are also two different registers which influence the path of the instruction pointer that also need to be considered to properly control the instruction pointer in a way that you want it to: the Codel Chooser (CC) and the Direction Pointer (DP). The instruction pointer is heavily influenced by the shape of the various "islands" of colors, called codels, so not only do you need to manipulate the CC and the DP in an efficient way, but to also fit together the codels in the most concise way possible.
Going back to the Number to Binary challenge, Bubbler's Piet answer comes in as the third Piet answer to that challenge. The first Piet answer posted was by Parcly Taxel, at 73 bytes, and it showcases an interesting looping structure and a great start as Piet answers go. Then I, Aiden Chow, decided to give it a shot with a 42 bytes answer. While this was an improvement to Parcly Taxel's structure, this still used a naive structure, with two loops right next to each other in a two-high grid. But then Bubbler posted a mind blowing 33(!!!) bytes answer, blowing the previous two answers out of the water.
The main improvements that Bubbler's answer had over both Parcly Taxel's and my answer was the insightful and elegant structure of the code. Although the fundamental logic of using two loops, one to set up the stack with bits and the other to print out all the bits on the stack, was the same as the previous two answers, Bubbler's choice of placing the DP+ instruction at A1A2, which helped save space in the first loop, was what set apart his answer from the previous two answers and saved around 10 bytes over the previous best Piet answer to the challenge (which was my, Aiden Chow, 42 bytes answer).
The basic reason why Bubbler's A1A2 DP+ instruction saves so many bytes is because this placement of the DP+ instruction allows more flexibility as to how the loop is constructed afterwards. With the technique of putting the two loops right next to each other, you are limited to placing the DP+ instruction at the rightmost edge of the loop in order for the instruction pointer to be able to easily transition from first loop to the second loop. But for this to work you need to place the check to exit the loop on the top half of the loop, while putting the actual logic of converting a base-10 number to its binary form on the bottom half of the loop. This wasted space along the top half of the loop.
This problem is bypassed with Bubbler's DP+ instruction placement because instead of being limited to having to exit the loop on the rightmost edge of the loop, it is instead possible to transition to the second loop through the bottom of the first loop. This essentially removes the limitation of having the place the exiting check on the top half of the loop and the actual logic on the bottom half of the loop as I did in my 42 bytes answer, but instead it is now possible to do both the actual logic and the check without any limitations as to where the codels are.
If you are interested in learning more about the A1A2 DP+ structure, you can check out Bubbler's tip, where he goes over when to apply this kind of structure and provides specific examples of how this structure is applied.
Overall, because of the ingenious structure of Bubbler's Piet answer resulting in a surprisingly golfy 33 bytes answer, along with the sheer difficulty of creating a Piet answer for even the simplest of challenges due to the amount of things you need to keep track of when creating a Piet answer, I nominate Bubbler's Piet answer to the Number to Binary challenge.
