@Razetime Flagging just causes the message to be deleted if others determine the message to be offensive. IIRC ROs can do that anyway, or just move the message to trash. FWIW handling things as a RO is normally better than sending a notification to the entire network.
I should be here throughout the day today (8/20), during the afternoon tomorrow (8/21), and during the afternoon the day after (8/22), which is the last day.
you've got 6 hours before it starts, so use that time to get at least an idea of who's doing what, and what "roles" people have (even if that means people need more than one role)
@PyGamer0 I mean team management wise
you can't really decide on language specifics until the theme is revealed
I don't really have any details in mind, but I was thinking something along the lines of comments being able to override stuff in the program, for example maybe being able to do stuff like Vyxal's r or D flags and change how stuff works, but be able to change those during runtime.
@Razetime you should probably add everyone on the team as collaborators on the fork so we can contribute easier
Since comments are "first-class" and therefore objectively the best, everything is a comment, and the commands, structure, flow, etc. of the program are all determined by the types, size, contents, etc. of the comments.
This is brainstorming, so we should all put down any random ideas that come to us, and we can develop the ones we like the best together.
It doesn't have to be TC, so we could just have each comment either do some string transformations or do nothing and then pass it on to the next comment to process, resulting in a different string at the end
Another idea: the comments consist of some subset of English that is parsable, and the comments are the actual code ("this function takes a number a and a number b and adds a and b" -> (a, b) => a + b
