Don't know what to say about TNB's life, do you?

Does this count as a improper quine? mousetail.github.io/Fish/#eyJ0ZXh0IjoiXCJyZjIrMipyb2w/…

Trying to solve this: codegolf.stackexchange.com/questions/118884/…

how is 36 achieveable in js for prime?

I got 61 only lmao

Is it just me, or does this look wrong?

How is that "+4"‽

erm

@NewPosts we need a do-x-without-y

@DialFrost copy and paste it from cgcc

@DialFrost copy and paste it from cgcc

@Sʨɠɠan Copy and paste from Steggan

SMH @Sʨɠɠan, quit talking to yourself :P

the hivemind had a glitch

At first I legitimately thought one of you had had a conversation with someone else who then deleted their comments

Soon, we'll all be Steggan

there is only one steggan

@DLosc Clearly, the number of Sʨɠɠans is equal to the digit that appears the most, of a minimum of 3 times, in the year, defaulting to 0, if no such digit exists

Every 1011 years, a new Sʨɠɠan comes into existence, before they are all wiped out the next year

@Bubbler whoever adds it to code.golf can add SBCS support

defaulting to UTF-8 if there are chars outside of SBCS

LDQ: Generic<Type> or Generic[Type]?

Generic}Type{

Generic[Type]

Type<Generic>

Or Type<<Generic

First-class types!

Not a fan of <>, it's ugly and my editor doesn't have bracket match highlighting for them

I'd go with [] or ()

Generic Type

or Generic(Type) if you have the misfortune of needing parentheses for function application

@emanresuA JS be like

@emanresuA that's just weird

I know

I was actually considering Generic(Type) for a language I was designing

To me it seems like a sensible place to use parens

I was going to use [Type] for an array of that type so Generic[Type] wasn't really an option

I'm considering trying out my inferred-borrowing idea and making a language that transpiles to Rust as an intermediate language

It'd be slightly higher level, with things like Arcs and Mutexes abstrated away, arrays and Vecs would be merged into a single type, that sort of thing

Maybe I'll make it lean slightly more functional than Rust, since it's already got the potential for that, just with its built-in verbosity getting in the way a lot

Warm take: No language I know of does errors well

Not talking about Result vs. exceptions here, like the actual way errors are represented

In OOP/semi-OOP langs they tend to just be classes which inherit from some sort of base Error type

I don't like that

And some langs let you use any type as an error, which is also bad

Problem with the OOP method is that it makes creating new error types annoying

E.g., in Rust you need to make a whole struct, and add the Display trait to get it to print a useful message

So I think an error should be more like a two-element tuple. The first should be like the error's type name; e.g., in a library called http, you might have http::gzip::InvalidGzip as the first item. The second would be a string description. That's it.

The first item would be for matching, so you can handle certain errors, and not others

The second would be how the error is shown to the user if it ends up turning into a panic/fatal

Like in Rust, since you have the freedom to use any type as a Result's Err field, some things return Strings, but most use types with the Error trait

So if you want to actually handle an error, you need to understand what type it is, and hope that it actually lets you handle things how you wanted to, and if it's an Error and you just want to pass it along, you need a Box<dyn ...> which is annoying

@RadvylfPrograms I also think anything that could return an error should be able to specify either a list of possible error types, or a wildcard, with neither requiring creating a new type or using dynamic dispatch

So like, you could have a function which returns either a successful result, a https::tls::TlsHandshakeFailure, a http::gzip::InvalidGzip, or a net::NetworkUnreachable, and if you use this function in your function, and just pass on any errors that the function you used could return, it'll automatically add those three to the list of possible errors your function could return

So for any function which possibly returns an error, you can see exactly which errors are possible, in a standardized way, and handle them conveniently

what if you want to programmatically get data from the error?

i.e. if its an index error, whats the index and bounds?

parsing strings is a sin

IMO you should not be doing that with an error in the first place

Your function should be returning an enum or some sort of data structure which can represent invalid indices if you expect those to be a possibility

So the only processing you should be doing on errors is deciding whether to ignore them, panic, or pass them on to the calling function

Alternatively if you really wanted to use an error for that situation, but also give additional information, you could return a struct containing the error and information about it

suppose a piece of code catches an error that it would like to pass on, but is lower-level than what the user would expect (e.x. an IndexError). the code wants to rethrow it but as a NoMoreItemsError. what if it needs info from the lower level error?

(ofc in this case it doesnt, but i am certain there are cases when it does)

Hmm, that's a good point. Maybe there'd be a way to include a lower level error in an error, so the user would see a NoMoreItemsError with a brief higher level description of what went wrong, and under that would be the IndexError, with any details which would be needed for debugging

I think the issue would mostly be prevented by not using a single error which can encompass multiple types of failures which, to the end user, might be handled differently.

Also, typically errors wouldn't be shown to the user with the expectation that the user reads them, unless they're the writer/debugger of the program, right?

Errors should just tell you you're a dumbass

I would like it a lot better

If it's an expected error, like a 400 when requesting something from a dodgy API, it should be handled and the user informed through something other than throwing an error (probably just printing a status message, or displaying a popup in a GUI app). If it's an unexpected error, it's fine if it's low-level and verbose, since the user of a program typically isn't expected to learn why the software they're using isn't working, just pass on the error message to whoever maintains it

@Adám I see no errors here :p

Bruh why do I have a blue notification in my chat telling me about some random flag in some random room???

@AidenChow chat flags appear to anyone who has >10k cumulative rep network wide

and you have the option of handling it/marking it valid/invalid

why?

oh

@Sʨɠɠan it ain't in cgcc

And I alr found it lol