Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vyxal: A code-golfing language experience

github.com

Post reply on HN
Print view View original

11–20 of 32 posts

Re: Vyxal: A code-golfing language experience

#11

Post by tromp »

mikewarot wrote: post #8
tromp wrote: post #3

> 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 functi…

Does that output a string of bits, or decimal numbers?

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.

Re: Vyxal: A code-golfing language experience

#12

Post by spencerflem »

tromp wrote: post #9
spencerflem wrote: post #7

Earlier quoted context omitted.

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

> 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,…

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

Re: Vyxal: A code-golfing language experience

#13

Post by posix86 »

spencerflem wrote: post #2

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.

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.

Re: Vyxal: A code-golfing language experience

#14

Post by mikewarot »

tromp wrote: post #11
mikewarot wrote: post #8

Earlier quoted context omitted.

Does that output a string of bits, or decimal numbers?

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.

So how long is the code to convert those representations into ASCII or Unicode decimal strings?

Re: Vyxal: A code-golfing language experience

#15

Post by spencerflem »

posix86 wrote: post #13
spencerflem wrote: post #2

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.

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.

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.

Re: Vyxal: A code-golfing language experience

#16

Post by tromp »

mikewarot wrote: post #14
tromp wrote: post #11

Earlier quoted context omitted.

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.

So how long is the code to convert those representations into ASCII or Unicode decimal strings?

The size of https://www.ioccc.org/2012/tromp/oddindices.Blc is 84 bytes.

Re: Vyxal: A code-golfing language experience

#17

Post by tromp »

spencerflem wrote: post #12
tromp wrote: post #9

Earlier quoted context omitted.

> 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,…

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 c…

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/86b3184f852f65bfb814e3ab0987d8...

Re: Vyxal: A code-golfing language experience

#18

Post by MrZander »

spencerflem wrote: post #15
posix86 wrote: post #13

Earlier quoted context omitted.

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.

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.

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.

Re: Vyxal: A code-golfing language experience

#19

Post by spencerflem »

tromp wrote: post #17
spencerflem wrote: post #12

Earlier quoted context omitted.

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 c…

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/86b3184f852f65bfb814e3ab0987d8...

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.

Re: Vyxal: A code-golfing language experience

#20

Post by myhf »

spencerflem wrote: post #2

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.

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.
Post reply on HN