[HN Gopher] Vyxal: A code-golfing language experience
___________________________________________________________________
Vyxal: A code-golfing language experience
Author : tosh
Score : 46 points
Date : 2024-02-28 16:23 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| spencerflem wrote:
| Huh, once you add a compiler step to turn normal code into
| "golfed" code, it feels like a different thing, with the goal
| being to write a compact bytecode format.
|
| This one seems mostly like a workaround for having to type weird
| Unicode characters, so it still seem "fair" to me whatever that
| means.
|
| But I wonder how much a normal java program can be auto golfed by
| playing with the bytecode output.
| posix86 wrote:
| Isn't the whole purpose of golfing to write compact in higher
| level languages? If writing the lower level is too hard, it's
| no different to jars, pyc, or x86 files.
| spencerflem wrote:
| Yeah, totally. I guess really the way to think about it is
| that any code golfing problem is a separate competition
| between each language. What's the shortest you can get in JS,
| in Java, in Pyth etc.
|
| Languages made just for golfing, and how many of them there
| are, seem a little silly, but theyre cute to look at and fun
| to make i'm sure. Its art :p Not complaining.
| MrZander wrote:
| I agree. I used to frequent codegolf.stackexchange.com but
| nowadays it's just a bunch of 2 character solutions in 50
| different home-grown golfing languages.
|
| Golfing languages can be fun, but they do feel like
| something totally different than trying to make a 200 line
| C program run in 200 bytes.
| myhf wrote:
| There are still different approaches within the same language,
| and having a broad consensus about which constants and
| abbreviations are part of the standard library puts more
| competitive focus on the algorithm instead of the encoding.
| recursive wrote:
| In _my_ golf language, called stax, each program expressible in
| plain ASCII has a corresponding representation in a single byte
| character set. [0] The only reason a program wouldn 't start in
| plain ASCII is the contents of string literals.
|
| The alternate representation generally saves ~15%, as measured
| in bytes. However, I totally understand the argument about
| human-unreadable "golfed" code, which is why you can always use
| the plain ASCII representation if you want.
|
| For instance, you can print fibonacci numbers in an infinite
| loop using this program. [1] 10Wb+Q
|
| It pushes one and zero to the stack. Then `W` repeats the rest
| of the program forever. `b+` copies the top 2 elements from the
| stack and adds them. `Q` peeks from the stack and prints to
| output. This program packs down to `+C>+0` for a savings of 1
| byte (using the languages own impractical character encoding).
|
| [0]
| https://github.com/tomtheisen/stax/blob/master/docs/packed.m...
|
| [1] https://staxlang.xyz/#c=10Wb%2BQ&i=
| tromp wrote:
| > Vyxal is an stack-based esoteric array language that is
| dedicated to dominating competition in code golf challenges. This
| means that it strips away all need for boilerplate, long function
| names and impractical source layouts.
|
| > Functions are a core part of Vyxal. They are first class
| objects, meaning that you can have functions on the stack,
| functions can take functions as arguments, and functions can
| return functions.
|
| This is actually all you need for writing very compact code. If
| you were to strip away all other features of Vyxal, namely
| variables, stacks, numbers, strings, lists, and all control flow,
| and have only functions from functions to functions, plus some
| way to use these for input and output, then you have Binary
| Lambda Calculus [1].
|
| The Vyxal code for the infinite list of Fibonacci numbers is 13
| bytes long. In comparison, the BLC code is only 78 bits, or just
| under 10 bytes: 0101010001101000000000010110110010101111101111011
| 10000111110011110100000100010.
|
| Or graphically [2]: +-+ ----+-+-------- - +
| +-+ ----+-+-+-+---- + | | --+-+-+-+-+-+-- | |
| | +-+-+-+-+-+-+-- | | | +-+ +-+ | +-+-+ | | |
| | +-+ | +-+ | | | | | +-+ | | | |
| +-+ | | | +-----+ | | +---+
| | | +-------------+ |
| +-+
|
| [1] https://www.ioccc.org/2012/tromp/hint.html
|
| [2] https://tromp.github.io/cl/diagrams.html
| mikewarot wrote:
| Does that output a string of bits, or decimal numbers?
| tromp wrote:
| It computes a list (as nested pairs in the standard lambda
| calculus representation) of Church numerals (the standard
| representation of natural numbers). See also the discussion
| of the 167-bit primes program output in the first link, which
| gives an impression of the overhead needed for output in
| decimals.
| mikewarot wrote:
| So how long is the code to convert those representations
| into ASCII or Unicode decimal strings?
| tromp wrote:
| The size of
| https://www.ioccc.org/2012/tromp/oddindices.Blc is 84
| bytes.
| omoikane wrote:
| > strips away all need for boilerplate
|
| Looks like this includes special optimizations for common
| problems including hello world (kh) and fizzbuzz (kF), but not
| 99 bottles of beer.
|
| https://vyxapedia.hyper-neutrino.xyz/elements
| mikewarot wrote:
| I think the size of the interpreter for Vyxal should be included
| in the scoring, if we're going to be really consistent about
| this.
|
| On the other hand, if you're going to allow plaintext to be
| compressed into bytecode, why not include a Huffman encoder as
| part of the flow? The FizzBuzz example has a string splitter in
| it (apparently, I haven't read ALL the docs), just to get around
| quoting some strings, but quotes might be less than a byte if you
| do them enough, etc.
|
| Lastly, who can make the smallest Vyxal executable? _Let 's use
| Jart's excellent Acutally Portable Executable[1] format as a
| kicking off point._ That seems like the best way to make it work
| for almost anyone. If not, then maybe
| DOS/Windows/Arm/VAX/PDP-11/Z80 categories might be needed?
|
| A Vyxal compliance suite of tests is required to enable all of
| the above. Who can make it the smallest? ;-)
|
| [1] https://justine.lol/ape.html
| tromp wrote:
| > the size of the interpreter for vyval should be included in
| the scoring
|
| But an interpreter in what language?
| spencerflem wrote:
| the demoscene version is assembly on a specific machine,
| which seems very fair to me.
|
| Compared to code golfing, where finding a language with the
| closest built ins for the task is a good bit of the strategy
| tromp wrote:
| > assembly on a specific machine, which seems very fair to
| me.
|
| It seems a little biased toward imperative languages. The
| earliest models of computation, namely combinatory logic
| with S & K, and the lambda calculus, date back to 1920s,
| and being exceedingly simple, can easily be implemented in
| any modern functional language. But not so easily in an
| imperative one, which have no support for closures.
|
| On the other hand, implementing an imperative language in a
| functional one is relatively straightforward.
| spencerflem wrote:
| Any defined runtime seems fair, though a real computer
| will always seem more canonical.
|
| The two parts that seem unfair to me:
|
| 1. There's hidden bits of information based on choosing
| one language over another that can't be counted. Imagine
| a family of 26 languages that are the same except the
| first letter is different etc.
|
| 2. Some of the golfing is in how good the language you
| picked is in their bytecode and not how clever your
| solution is
|
| Standardizing on one format would fix those, but you
| would lose the cuteness compared to demoscene of turning
| on your phyaical computer and trying it out, and you
| would lose compared to current code golf the fun of
| finding and playing with new cool languages
|
| Or I guess just treat each language as a separate
| category and not compare between them
| tromp wrote:
| My motivation in defining BLC was to have the simplest
| measure of the complexity of things. That includes binary
| strings, natural numbers, tuples, lists, sets, and
| functions of those, as well as languages (according to
| their interpreter) and formal systems (according to their
| theorem enumerator) [1].
|
| [1] https://gist.github.com/tromp/86b3184f852f65bfb814e3a
| b0987d8...
| spencerflem wrote:
| Oh, is BLC yours? I saw the link posted earlier in the
| thread, its beautiful.
|
| Still trying to understand it but yeah, there's
| definitely a mathematical purity to it that some random
| ASM language doesn't have.
| creatonez wrote:
| Since version 3 was rewritten from Python to Scala, does that
| mean it drops support for Python FFI? Does it replace it with
| Java FFI?
|
| Python FFI in Vyxal was neat because you could trivially import
| python libraries like sockets, or start doing FFI to C libraries
| with calls to Python's ctypes. It was a mess but it's satisfying
| just how many different cross-cutting concerns you could glue
| together with very little code, when most other esolangs don't
| provide much of a standard library.
| Nuzzerino wrote:
| Reminds me of this, which I used back in the day when I was
| competitive on that site https://www.hacker.org/hvm/
| tkwa wrote:
| > 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.
___________________________________________________________________
(page generated 2024-02-28 23:00 UTC)