The Nineteenth Byte

« first day (4934 days earlier) ← previous day next day → last day (123 days later) »

lyxal

12:02 AM

@Redz It's why I'm not playing it of a night time :p

Redz

fair

4 hours later…

l4m2

4:07 AM

CMC Map 24h display with 12h display. Both in 7-seg, bi-directional convertion

3 hours later…

RubenVerg

7:31 AM

bidirectional as in i have to detect which one it is, or i can make two functions?

3 hours later…

Themoonisacheese

10:04 AM

maybe this is just me being olympics brained (and i can't imagine this hasn't been proposed before) (and also this is kind of how thing are already informally working currently) but:
the current rules try to encompass all languages in order to write the law for scoring, IO, what's a language in the first place, you name it. I think this is both inefficient and could never correctly be achieved because of the complexities that i'm sure are obvious.

hence, the alternative:
A central "constitution" is written to govern how generally, languages should administer themselves, and to establish so…

lyxal

10:30 AM

Languages already are deemed to only compete with each other

Redz

this feels interesting but also feels a bit like it's going the way of a government

which is not to say it's bad it just seems a bit much complexity

mousetail

Q: New users' guides to golfing rules in specific languages

What are the most important rules a first-time golfer in a given language should know? For instance, how do golfed programs usually take input and output? Each language should have a single CW answer as the go-to explanation of the site rules for golfing in that language. Use code snippet exam...

It's been tried before

In general the site seems to be extremely bad at keeping guidelines up to date or following them

lyxal

10:48 AM

@Themoonisacheese What do you do if there's not enough people involved with a language to create/update/protect a language's rules?

Besides, people can already score however they want

A: Allow answers to be scored in things other than bytes to stop the log byte madness

No change in rules is needed, simply a change in behavior This might not be a complete answer, but I would like to provide what I think is a solution to the issues that doesn't actually require changing any rules. First lets talk about weird and unpleasant formatting. Rydwolf points out that ther...

Bytes is merely a convention

4 hours later…

Unrelated String

2:51 PM

@Redz Yeah, I like the core notion of enshrining the existence of language-specific conventions, but that seems like a far too involved way to do it. They do fine on their own as is!

noodle person

I just had a dumb thought to name a challenge "Go go pow()er range()rs!" but I can't think a task that fits and isn't a dupe and it's not that good a joke anyway

mousetail

It's a good title, maybe for a CMC

Unrelated String

Ahaha

Yeah it's hard to think of something nontrivial that would fit but it feels like there has to be

mousetail

The nontrivial part is solving it in Go

noodle person

I did think of incorporating golang into it yeah

mousetail

3:01 PM

I see a rs too so I guess you need to solve it simultaniously in go and rust

Just need a use for the "er" and we have used all the letters in the phrase

noodle person

could do ReScript

it's a bit backwards though

mousetail

3:17 PM

Erlang maybe?

I don't have a good idea how to make a challenge that involves 3 specific languages though

7 hours later…

noodle person

10:47 PM

In a golflang, is it likely that programs would be dealing with integers outside of the signed 16 bit range? In the language I'm doing these would be expressed as 21 bits = 2.625 bytes each

because it takes 5 bits to declare that it should read the next 16 bits as a 16 bit integer

emanresu A

10:59 PM

If you mean hardcoding those ints: Unlikely to use anything specific beyond 100, and you could always introduce a custom "compressed int" syntax

noodle person

@emanresuA I don't mean hardcoding at all, I mean being able to have them as literals

emanresu A

That's what I meant, phrasing hard :p

noodle person

This is not an SBCS language, it compiles from words to a tightly-packed compiled form based on static typing

emanresu A

If your goal is golfiness I'd suggest limiting literals to numbers <100 (or similar) plus a few useful constants e.g. 128, 256, 1000 and having a separate, longer syntax for anything larger

Storing large integers and performing base conversion on them is generally the golfiest way to compress large amounts of data anyway, so you'll probably want at least some way to do that regardless

noodle person

That's a reasonable idea I guess. Though I wouldn't use 100, I would do 128 or 256

emanresu A

11:04 PM

(and by "syntax" I mean "byte encoding")

noodle person

because they are literally stored as bits in the compiled form, it would be a waste of space

My current plan is to support 4bit, 8bit, and 16bit ints as literals

emanresu A

What I'm saying is:
- You're going to want a way to have arbitrary-size integer literals, at the very least for compressed data
- There aren't that many specific constants actually used in golfing languages (I believe lyxal has a list somewhere) so why not only have short encodings for the more common ones and force using the arbitrary-precision version for everything else?

noodle person

Oh that makes sense

emanresu A

(you can handle this all at the compiler level and just allow regular ints in the actual user-facing syntax)

noodle person

well sure

I guess it makes sense for 100 to be shorter to reference than 37

emanresu A

11:09 PM

A: Tips for Creating/Maintaining a Golfing Language

Useful integer constants Of course your golfing language has syntax that can represent any integer constant, but some integers are more useful than others. You want the useful ones to be available as a single byte. A couple of obstacles to this goal: With a traditional decimal format, only the n...

You could potentially even huffman-code some of these - have 1 encoded as three bits, but 7 as five or something

Oh also from the comments here's a longer version from JS solutions

noodle person

@emanresuA I will have to think about it, I'm not sure if I value a more consistent experience (by some metric) over pure golfiness

emanresu A

Fair enough :p

noodle person

This is also more of a Nibbles-esque language in the sense that there are gonna be way fewer builtins than say Vyxal

Partially because it's sorta a proof of concept for a different project which is more ambitious

emanresu A

Neat :p

Are you bothering with strings or just having charcode lists

noodle person

Probably a string type, since I'm not doing anything finicky with array model stuff or anything

(Hi Maddie, I'm talking about the type-packed stuff we talked about a couple weeks ago)

RubenVerg

11:14 PM

yeah, guessed (:

noodle person

Lately I haven't really had much motivation for programming anything other than like J golf solutions since I'm trying to learn that still, but I'm gonna do a little work on this pretty soon

RubenVerg

i mean i've completely stopped thinking about it for at least two weeks now

i think i'll have way more time after august is done

noodle person

cool