> Vyxal aims to bridge the gap between simplicity and "golfability".
With code golfing languages, there are inherent tradeoffs between code size and usability/fun. IMO the most important features for minimizing length (assuming the only rule is the interpreter must be published before the challenge) are:
* (in Vyxal) Efficient syntax. Not sure what state of the art is anymore but stack-based seems reasonable.
* (in Vyxal) String compression
* (not in Vyxal) Efficient encoding; Huffman coding at a minimum but ideally arithmetic coding using sophisticated machine learning to predict the next command. It's super inefficient to have each command be 1 or 2 bytes regardless of frequency.
* (not in Vyxal) Huge numbers of builtins; Vyxal has "only" ~560. Ideally every past code golf question and every OEIS sequence are their own builtin.
Vyxal might hit a sweet spot, but I'm skeptical that it actually score as well as other languages with more of these features.
With code golfing languages, there are inherent tradeoffs between code size and usability/fun. IMO the most important features for minimizing length (assuming the only rule is the interpreter must be published before the challenge) are:
* (in Vyxal) Efficient syntax. Not sure what state of the art is anymore but stack-based seems reasonable.
* (in Vyxal) String compression
* (not in Vyxal) Efficient encoding; Huffman coding at a minimum but ideally arithmetic coding using sophisticated machine learning to predict the next command. It's super inefficient to have each command be 1 or 2 bytes regardless of frequency.
* (not in Vyxal) Huge numbers of builtins; Vyxal has "only" ~560. Ideally every past code golf question and every OEIS sequence are their own builtin.
Vyxal might hit a sweet spot, but I'm skeptical that it actually score as well as other languages with more of these features.