there isn't too much more you can do with it other than maybe run-length encode things for hyper-optimization and that'll maybe save you a couple nanoseconds here and there
@dzaima It was mostly a joke. If I managed to get a C program to run, it'd probably faster than the Python one, but it's unlikely I can actually get it to work without segfaulting or something
@hyper-neutrino @cairdcoinheringaahing Hyper's interpreter showing the current element is a great addition. Here's the final Bash interpreter with that implemented!
@EliteDaMyth gcc -O3 will do that, but also apply a ton of regular optimizations (i've seen it optimize the fancy BF constant calculations to just mov rax, 85 or whatever)
Searching for burn yields an awful lot of messages posted by me (and that search doesn't seem to include a couple more with the characters "burn" in them)
@pxeger The more interesting thing in that document to me: they've finally caved and are adding (a more powerful version of) a case statement! :^0 I always understood that was something Python was never ever going to do.
Well, it does seem to lack custom extractors, which is another reason Python is bad and everyone should use Scala, which totally doesn't have any weird features
I'm going to post it when I get back, but I just finished a BF answer to this question
The shortest Python and JS as of now are 24 & 22 bytes, respectively. With some answers in those langs going up into the 40s. Does anyone have a guess for how long the BF answer is?