Interesting how the obfuscated code is explained by slowly unobfuscating it step by step. This is the reverse of how obfuscated code is normally created: by starting with understandable code, and then slowly obfuscating it bit by bit (as I explained for this IOCCC submission [1]).
I say normally because one could also have a superoptimizer search for a minimal program that achieves some desired behaviour, and then one has to understand it by slowly unraveling the generated code.
I’ve used reverse Polish notation as an interview question many times. It works well because if someone’s never seen it you can learn a lot about their basic understanding of algorithms. But if they are aware of how easy it is you can extend it forever by adding symbols, improving the algo they build, or doing something like this.
Such is the result of delving into languages such as Forth[0].
Can you make programs with it smaller than assembly language? Sure.
Will you come out the other side a mad hatter speaking of things such as words, dictionaries, and washing machine firmware? Well, I can only speak for myself...
It would be interesting to see the performance difference from a wasm version, but in the end I found the human(ish) readable expression to be quite useful too.
Originally I created an interpreter for a code as a texture maker for code golfed javascripted games. https://github.com/Lerc/stackie
There's potential for a WASM implementation to be both smaller than the small version and Faster than the fast version.
yes, it has always been an influence for me, in fact 9 years ago I implemented a Forth interpreter in plain WAT[2] by de-obfuscating a IOCCC Forth implementation[3] and reimplementing it in Wasm and JS[4]
WASM is cool; I've started implemented a CPU that runs unmodified WASM in Verilog, but I'm finding the feature creep on the instruction set (SIMD, GC) to take away from the initial values behind WASM (simple, small)
You can ignore SIMD and GC (for now). SIMD explodes the complexity level of Wasm, esp when there is WebGPU. I am curious how you are handling layout and how you are handling all the irregular sizes.
Oh, I don't think so either, but if you think back to the asm.js times, there was a clear goal of "simple and higher perf", but now it's going in a direction for maximum compatibility with existing stacks (GC, WASI, etc) at "any" cost
I have never used Twitter so I might be mistaken but I believe the limit has been 280 for a while now, which is why the first one at 269 bytes would also have fit.
Interesting how the obfuscated code is explained by slowly unobfuscating it step by step. This is the reverse of how obfuscated code is normally created: by starting with understandable code, and then slowly obfuscating it bit by bit (as I explained for this IOCCC submission [1]).
I say normally because one could also have a superoptimizer search for a minimal program that achieves some desired behaviour, and then one has to understand it by slowly unraveling the generated code.
[1] https://tromp.github.io/maze.html
I prefer to learn more about it first by having understandable code, that way there is less brainfuck.
But cool stuff anyways
this one started pretty obfuscated :)
https://x.com/warianoguerra/status/1576166873296941056
I’ve used reverse Polish notation as an interview question many times. It works well because if someone’s never seen it you can learn a lot about their basic understanding of algorithms. But if they are aware of how easy it is you can extend it forever by adding symbols, improving the algo they build, or doing something like this.
You are a crazy sadic bastard
Such is the result of delving into languages such as Forth[0].
Can you make programs with it smaller than assembly language? Sure.
Will you come out the other side a mad hatter speaking of things such as words, dictionaries, and washing machine firmware? Well, I can only speak for myself...
:-D
0 - https://forth-standard.org/
> if you take the time to understand what this code does, you’ll learn a surprising amount about WebAssembly!
It's a shame the article mostly teaches about codegolf tricks, and the actual wasm info is left to a single commented code block.
Nonetheless an interesting article about JavaScript quirks though!
“Fits in a tweet” can be safely assumed to mean lots and lots of code golf.
Really interesting. I considered having a go at a RPN to WASM converter when I was making https://c50.fingswotidun.com/
I ended up converting the RPN style notation into a JavaScript string and creating a new function, which lets the JIT sort it out.
https://c50.fingswotidun.com/show/?code=xy!2*!2y!*6%2Bo2%2Fv...
which has the code
becomes
It would be interesting to see the performance difference from a wasm version, but in the end I found the human(ish) readable expression to be quite useful too.
Originally I created an interpreter for a code as a texture maker for code golfed javascripted games. https://github.com/Lerc/stackie
There's potential for a WASM implementation to be both smaller than the small version and Faster than the fast version.
post co-author here, let me know if you have any questions :)
Have you or the other co-author ever worked with/in Forth[0]?
0 - https://forth-standard.org/
yes, it has always been an influence for me, in fact 9 years ago I implemented a Forth interpreter in plain WAT[2] by de-obfuscating a IOCCC Forth implementation[3] and reimplementing it in Wasm and JS[4]
[1] https://github.com/marianoguerra/ricardo-forth
[2] https://github.com/marianoguerra/ricardo-forth/blob/master/s...
[3] https://www.ioccc.org/1992/buzzard.2/
[4] https://github.com/marianoguerra/ricardo-forth/blob/master/s...
WASM is cool; I've started implemented a CPU that runs unmodified WASM in Verilog, but I'm finding the feature creep on the instruction set (SIMD, GC) to take away from the initial values behind WASM (simple, small)
You can ignore SIMD and GC (for now). SIMD explodes the complexity level of Wasm, esp when there is WebGPU. I am curious how you are handling layout and how you are handling all the irregular sizes.
I don't think WASM's value was ever in a hardware instantiation of the actual instruction set.
Oh, I don't think so either, but if you think back to the asm.js times, there was a clear goal of "simple and higher perf", but now it's going in a direction for maximum compatibility with existing stacks (GC, WASI, etc) at "any" cost
This is really impressive. It is over 140 characters, but I guess "a tweet" can be any length now.
Co-author of the post here — we had 280 characters in mind. :-)
I have never used Twitter so I might be mistaken but I believe the limit has been 280 for a while now, which is why the first one at 269 bytes would also have fit.
Twitter was based on sms, the standard SMS character limit is 160. They used 140 so they could use the remained 20 chars for other purposes.
4 replies →
Yeah it was changed to 280 for all users in 2017. That's still the default limit, but paying users can exceed it now.
Is this a Tweet or a Xit (zit)? ha.
This is cool though, i love these programs that exist in these constraints, like Dwitter does with the demoscene.
I call them Xeets now.
[flagged]
I prefer calling it an x-cretion.
Xitter, with the X pronounced as a soft Sh