00:09:41 <esolangs> [[]] https://esolangs.org/w/index.php?diff=177118&oldid=177045 * InLuaIKnow * (+77)
00:27:52 <esolangs> [[ZecZec]] M https://esolangs.org/w/index.php?diff=177119&oldid=177117 * BODOKE2801e * (+1) /* Syntax */
00:40:09 <esolangs> [[ZecZec]] https://esolangs.org/w/index.php?diff=177120&oldid=177119 * BODOKE2801e * (+76) /* Syntax */
00:51:56 -!- amby has quit (Quit: so long suckers! i rev up my motorcylce and create a huge cloud of smoke. when the cloud dissipates im lying completely dead on the pavement).
01:51:34 <esolangs> [[ZecZec]] https://esolangs.org/w/index.php?diff=177121&oldid=177120 * BODOKE2801e * (+150)
01:55:41 <esolangs> [[ZecZec]] https://esolangs.org/w/index.php?diff=177122&oldid=177121 * BODOKE2801e * (+9)
02:00:49 <esolangs> [[Bbtos]] https://esolangs.org/w/index.php?diff=177123&oldid=175432 * BODOKE2801e * (+169) >|<>|< interpreter
02:19:46 <esolangs> [[Septem Lingua]] https://esolangs.org/w/index.php?diff=177124&oldid=177063 * Yoyolin0409 * (+257) /* Bitwise Statements List */
02:20:20 <esolangs> [[Septem Lingua]] https://esolangs.org/w/index.php?diff=177125&oldid=177124 * Yoyolin0409 * (-3) /* Bitwise Statements List */
02:23:55 <esolangs> [[Septem Lingua]] https://esolangs.org/w/index.php?diff=177126&oldid=177125 * Yoyolin0409 * (+22) /* Syntax */
02:24:33 <esolangs> [[Septem Lingua]] https://esolangs.org/w/index.php?diff=177127&oldid=177126 * Yoyolin0409 * (-13) /* type */
02:24:43 <esolangs> [[Septem Lingua]] https://esolangs.org/w/index.php?diff=177128&oldid=177127 * Yoyolin0409 * (-1) /* type */
02:31:26 <esolangs> [[Septem Lingua]] https://esolangs.org/w/index.php?diff=177129&oldid=177128 * Yoyolin0409 * (+696) /* operator */
02:32:23 <esolangs> [[Septem Lingua]] https://esolangs.org/w/index.php?diff=177130&oldid=177129 * Yoyolin0409 * (+65) /* process */
02:33:30 <esolangs> [[Septem Lingua]] https://esolangs.org/w/index.php?diff=177131&oldid=177130 * Yoyolin0409 * (+228) /* eval */
02:33:59 <esolangs> [[Septem Lingua]] https://esolangs.org/w/index.php?diff=177132&oldid=177131 * Yoyolin0409 * (+64) /* process */
03:58:45 <esolangs> [[Plea]] https://esolangs.org/w/index.php?diff=177133&oldid=175413 * UnavgAustralian * (-94)
04:08:56 <esolangs> [[User:Dragoneater67]] https://esolangs.org/w/index.php?diff=177134&oldid=177099 * Dragoneater67mobile * (+90)
04:17:11 <esolangs> [[User:Dragoneater67]] https://esolangs.org/w/index.php?diff=177135&oldid=177134 * Dragoneater67mobile * (+308)
04:17:24 <esolangs> [[User:Dragoneater67]] https://esolangs.org/w/index.php?diff=177136&oldid=177135 * Dragoneater67mobile * (-17) /* uwu nyaaa :3 rawr */
04:19:27 -!- somefan has quit (Remote host closed the connection).
04:19:39 -!- somefan has joined.
04:41:21 <esolangs> [[User:RaiseAfloppaFan3925]] M https://esolangs.org/w/index.php?diff=177137&oldid=177003 * RaiseAfloppaFan3925 * (+263)
04:44:09 <esolangs> [[User:RaiseAfloppaFan3925]] M https://esolangs.org/w/index.php?diff=177138&oldid=177137 * RaiseAfloppaFan3925 * (+90) /* things I don't like */
05:22:21 <esolangs> [[Text]] https://esolangs.org/w/index.php?diff=177139&oldid=176956 * InLuaIKnow * (+54)
05:24:10 -!- somefan has quit (Remote host closed the connection).
05:24:18 -!- somefan has joined.
05:28:22 <esolangs> [[Text]] M https://esolangs.org/w/index.php?diff=177140&oldid=177139 * InLuaIKnow * (+1)
05:42:13 -!- somefan has quit (Remote host closed the connection).
05:42:20 -!- somefan has joined.
06:09:27 -!- moony has quit (Quit: leaving).
06:09:49 -!- iovoid has quit (Quit: iovoid has quit!).
06:09:49 -!- Bowserinator has quit (Quit: Blame iczero something happened).
06:10:23 -!- Bowserinator has joined.
06:13:16 -!- moony has joined.
06:14:18 -!- iovoid has joined.
06:46:38 -!- somefan has quit (Remote host closed the connection).
06:46:45 -!- somefan has joined.
07:08:04 <esolangs> [[ZecZec]] https://esolangs.org/w/index.php?diff=177141&oldid=177122 * Yayimhere2(school) * (+1) . seems to function exactly as a string!
07:22:56 -!- somefan has quit (Remote host closed the connection).
07:48:00 -!- tromp has joined.
08:06:18 -!- Lord_of_Life has quit (Quit: Laa shay'a waqi'un moutlaq bale kouloun moumkine).
08:08:11 -!- Lord_of_Life has joined.
08:10:45 <esolangs> [[ActionLang]] https://esolangs.org/w/index.php?diff=177142&oldid=176967 * None1 * (+189) Add some examples
08:11:52 <esolangs> [[ActionLang]] M https://esolangs.org/w/index.php?diff=177143&oldid=177142 * None1 * (-4) /* Truth Machine */
09:20:33 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
09:23:02 -!- Sgeo has quit (Read error: Connection reset by peer).
09:42:44 <esolangs> [[User:Dragoneater67/wipwipwip]] https://esolangs.org/w/index.php?diff=177144&oldid=176566 * Dragoneater67mobile * (-67)
09:43:27 <esolangs> [[NO WAY? NO WAY!]] https://esolangs.org/w/index.php?diff=177145&oldid=176183 * Cleverxia * (-8) /* Computational class */
09:49:39 <esolangs> [[Esolang talk:Categorization]] https://esolangs.org/w/index.php?diff=177146&oldid=177073 * Dragoneater67mobile * (+184)
10:27:53 -!- tromp has joined.
10:43:39 <esolangs> [[ActionLang]] https://esolangs.org/w/index.php?diff=177147&oldid=177143 * Cleverxia * (+2520) /* Truth Machine */
10:51:44 <esolangs> [[ActionLang]] M https://esolangs.org/w/index.php?diff=177148&oldid=177147 * Cleverxia * (+272) add hello world
11:30:52 -!- somefan has joined.
11:31:28 <esolangs> [[ActionLang]] M https://esolangs.org/w/index.php?diff=177149&oldid=177148 * Dragoneater67mobile * (+28) /* Hello, World! */ formatting
12:19:42 -!- somefan has quit (Remote host closed the connection).
12:19:49 -!- somefan has joined.
12:25:18 -!- amby has joined.
12:27:44 -!- somefan has quit (Remote host closed the connection).
12:41:07 <esolangs> [[MarkupL]] M https://esolangs.org/w/index.php?diff=177150&oldid=164199 * 47 * (+18)
12:43:33 <esolangs> [[Category:Gaia]] N https://esolangs.org/w/index.php?oldid=177151 * 47 * (+204) Created page with "See also the same category in [https://mockupedia.miraheze.org/wiki/Category:Gaia] for OS/Tech related stuff and [https://dreamfiction.fandom.com/wiki/Category:Gaia Dream Fiction Wiki] for everything else"
12:43:53 <esolangs> [[Category:Gaia]] M https://esolangs.org/w/index.php?diff=177152&oldid=177151 * 47 * (+11)
12:47:28 <esolangs> [[Filename "xxx" doesn't seem to be a valid filename. Please check if the filename your trying to execute is written correctly]] M https://esolangs.org/w/index.php?diff=177153&oldid=168159 * 47 * (-289)
12:48:01 <esolangs> [[Snakel]] M https://esolangs.org/w/index.php?diff=177154&oldid=175651 * 47 * (+18)
12:49:29 <esolangs> [[MarkupL]] M https://esolangs.org/w/index.php?diff=177155&oldid=177150 * 47 * (+0) /* Cat program */
13:23:59 <esolangs> [[Category talk:Gaia]] N https://esolangs.org/w/index.php?oldid=177156 * Dragoneater67mobile * (+140) Created page with "was this discussed?? ~~~~"
13:24:15 <esolangs> [[Special:Log/move]] move * 47 * moved [[Filename "xxx" doesn't seem to be a valid filename. Please check if the filename your trying to execute is written correctly]] to [[Filename "xxx" doesn't seem to be a valid filename/commmand!]]: rename
13:55:50 <esolangs> [[User:RaiseAfloppaFan3925]] M https://esolangs.org/w/index.php?diff=177159&oldid=177138 * RaiseAfloppaFan3925 * (-2283)
14:02:23 <esolangs> [[Category talk:Gaia]] https://esolangs.org/w/index.php?diff=177160&oldid=177156 * Corbin * (+265)
14:04:50 <korvo> ^^^ User:47 is an alt of User:Ractangle.
14:08:47 <int-e> At least the user page mentions this.
14:12:54 <int-e> Oh yeah, people keep creating catgories. https://esolangs.org/wiki/Category:Goto_based is another (at least this one could be a topical fit)
14:14:15 <int-e> (But obviously it hasn't been discussed properly.)
14:17:55 <int-e> The one language in there is https://esolangs.org/wiki/Interpriterlol and it's of course underspecified. But from the example the theme here is having a *computed* goto. And a pretty expressive expression syntax.
14:23:53 <korvo> I don't mind the particular themes, but I greatly dislike normalization of deviance. I think I'm allowed to blame current management for it, too; I think that I've laid out a *comprehensive* approach that engages with problematic users at every level, and I'm only unable to carry it out due to lack of approval and oversight.
14:35:08 <esolangs> [[Bash: foo: No such file or directory]] https://esolangs.org/w/index.php?diff=177161&oldid=144014 * MihaiEso * (+95) /* Batch */
14:43:55 <esolangs> [[Esolang:Introduce yourself/Archive (20-09-2025 to 31-01-2026)]] N https://esolangs.org/w/index.php?oldid=177162 * MihaiEso * (+37557) Created page with "{{Archived|19 September 2025|31 Janurary 2026|[[Esolang:Introduce yourself]]}} Hi. I created this account to fix the definition of R (Robin) on the Combinatory Logic page. [[User:Davidwg|Davi
14:45:14 <esolangs> [[Esolang:Introduce yourself/Archive (20-09-2025 to 31-01-2026)]] https://esolangs.org/w/index.php?diff=177163&oldid=177162 * MihaiEso * (-23) Spelling fix and cleared line-breaks.
14:45:17 <esolangs> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=177164&oldid=176991 * MihaiEso * (-37350) Cleared to just a month of introductions!
14:47:42 <esolangs> [[Special:Log/newusers]] create * ByteTilde * New user account
14:47:59 <esolangs> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=177165&oldid=177164 * MihaiEso * (+0) Fixed date!
14:48:02 <esolangs> [[Esolang:Introduce yourself/Archive (20-09-2025 to 31-01-2026)]] https://esolangs.org/w/index.php?diff=177166&oldid=177163 * MihaiEso * (+0) Fixed date!
14:54:39 <esolangs> [[User talk:MihaiEso]] https://esolangs.org/w/index.php?diff=177167&oldid=169300 * I am islptng * (+248) /* You're Back!? */ new section
14:56:14 <esolangs> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=177168&oldid=177165 * ByteTilde * (+216)
15:08:05 <int-e> LOL. Finishing Trackmania maps is NP-hard.
15:10:28 <b_jonas> int-e: huh, aren't games supposed to be at least PSPACE-complete to solve these days?
15:11:14 <int-e> (Looking at the first track played in https://www.youtube.com/watch?v=kNrj8vMzzkE which encodes a SAT problem in the finished checkpoints (the game allows tracks to have linked checkpoints, only one of which has to be taken) :P)
15:11:48 <int-e> b_jonas: racing games? :-P
15:12:23 <b_jonas> like if there are interactive elements on the course (including vehicles) that can block a path
15:13:23 <b_jonas> of course you won't want those constructions on maps that players are typically playing, because those want to be clearly completable
15:14:22 <int-e> But TM doesn't really have any permanent effects I can think of. No switches, no destructible blocks... just a bunch of state attached to the car and some moving blocks that depend on the current time on the track.
15:14:58 <b_jonas> and you can't unget checkpoints?
15:15:05 <int-e> Anyway. It's one thing to think about this in the abstract... it's another thing entirely to see an actual reduction as a track. :P
15:15:34 <int-e> Yeah, checkpoints, once collected, stay collected, unless you finish a lap in a multi-lap track. But that resets all of them at once.
15:17:03 <int-e> The other thing at play here is that you can reset to the last taken checkpoint. And that might spawn you on a different part of the track that would otherwise be unreachable.
15:18:02 <int-e> Also... this particular track is a bit open so there might be a stupid simulated physics trick that lets your car drop down without using a checkpoint as a portal. But the concept of the reduction looks sound to me.
15:18:10 <b_jonas> I wonder if Mario Kart can remember enough interactive elements (like infinitely bouncing shells) that a reasonable generalization would have their number increase with the size of the track and become PSPACE-complete
15:51:22 <esolangs> [[User talk:MihaiEso]] https://esolangs.org/w/index.php?diff=177169&oldid=177167 * PrySigneToFry * (+605) /* Septem Lingua */ new section
15:54:36 <esolangs> [[Septem Lingua]] https://esolangs.org/w/index.php?diff=177170&oldid=177132 * PrySigneToFry * (+38)
16:36:15 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
16:38:16 -!- impomatic has joined.
16:53:50 <esolangs> [[Special:Log/delete]] delete * Ais523 * deleted "[[Category:Gaia]]": unapproved category (and unclear purpose)
16:58:32 <korvo> FWIW the purpose of that Gaia category appears to be to denote a fictional AU that has alternate versions of companies like Microsoft and presumably an entire alternate culture of computing.
16:58:48 <esolangs> [[Esolang talk:Categorization]] https://esolangs.org/w/index.php?diff=177171&oldid=177146 * Ais523 * (+920) /* Category:goto based */ this is somewhat hard to define (and the name may be wrong)
16:58:54 <esolangs> [[Special:Log/delete]] delete * Ais523 * deleted "[[Category:Goto based]]": undiscussed category; may be a good idea and is being discussed on the categorisation page at the moment, but the name might be wrong and as such I'm deleting it for the time being to prevent it filling up (which would make it hard to rename)
17:00:51 <esolangs> [[Esolang talk:Categorization]] https://esolangs.org/w/index.php?diff=177172&oldid=177171 * Ais523 * (+455) /* Category:Graph-based? */ this seems reasonable if there are enough entries, but there might not be
17:06:52 -!- tromp has joined.
17:11:12 <int-e> b_jonas: LOL: https://forums.factorio.com/viewtopic.php?p=669081#p669081 vs. https://forums.factorio.com/viewtopic.php?p=689061#p689061 (obviously what happened in the meantime is that we have a 100% space age run in under 7h that relies on blocking biter spawns)
17:14:03 -!- impomatic has quit (Quit: Client closed).
17:17:35 <int-e> (TBH, for this particular behavior it's their initial reply that this wasn't a bug that surprised me. Because it is very cheesy.)
17:18:04 <b_jonas> int-e: there's a specific fix that I'd prefer for the biter blocking but it's hard to implement so I don't think it will happen. (1) the biter should be able to spawn in the entire area, even between two adjacent power poles, not just at the center of tile every third row and third column. (2) if the biter can't spawn anywhere then it stays in the spawner such that it carries out its normal melee or
17:18:10 <b_jonas> spitting attacks, and it exits the nest as soon as it has free space, but you can't damage it because shooting at it only damages the spawner. (there would still be a limit that no more biters spawn if there are already eight in the nest.)
17:19:16 <b_jonas> int-e: that it "makes dealing with biters completely trivial" is very much exaggerated
17:19:54 <int-e> That's thedoh being sarcastic.
17:19:57 <b_jonas> it's cheesy in some specific challenge runs, but not in general play
17:20:18 <b_jonas> the most important reason why it's considered cheese is the new "Keeping your hands clean" achievement
17:20:42 <int-e> I believe using Wube's language from the justification for disallowing reduced biter settings for combat related achievements.
17:21:10 <b_jonas> that achievement is hard in the sense that you don't normally get it in normal playthrough, even if you play fast and efficiently, while other achievements you either get naturally or at least they encourage some strategy that is not too unreasonable
17:21:31 <b_jonas> and the biter blocking helps with that one weird achievements and some other voluntary challenges
17:24:54 <b_jonas> that said you probably shouldn't trust me on evaluating this, because I don't care much about achievements and I prefer to play without biters
17:29:19 <int-e> In the end I don't care; I just find the idea of people not playing a sandbox game the intended way funny.
17:33:21 <int-e> Even for speedrunners... 100% may actually die this time as a competitive cateogory (or not, maybe there'll be another surprise on the scale of "what if we make the map one huge island"?) and all other categories are not reliant on achievements or easily adjustible like APA.
17:36:42 <b_jonas> Factorio is good as an open-information puzzle game in that it tells you almost all the rules and lets you figure out their consequences, and when you try that you build something that you think is really good, then show it to other players, and then you find out that there's a much better way to do the same even in the specific metric that you tried to optimize for but that you missed even though it is
17:36:48 <b_jonas> a consequence of the rules that you had known. And even in the cases where it's not open information but you have to experiment to figure out the rules, it can present good puzzles because there aren't many glitches and the rules lead to interesting consequences. So I think blocking nests is very much in the spirit of playing the game as intended, the intent is that you should found out the best
17:36:49 -!- impomatic has joined.
17:36:54 <b_jonas> solutions even if the game designers didn't know what those best solutions are. It helps here that the game doesn't have as many serious glitches as many commercial games do.
17:37:24 <b_jonas> There are some other interesting things where it's debatable if you consider it a cheesy exploit or an interesting strategy that is fun to discover and learn.
17:39:03 <b_jonas> as for the speedrun categories, I hope people will start to play no enemies but other settings on default and random seed, which is an enjoyable middle ground between the two popular categories of any% and default settings random seed
17:40:37 <int-e> so you dislike the rich resources in RSNG+?
17:51:10 <b_jonas> int-e: I wouldn't say I dislike the rich resources as such, but I think the default density with random seed leads to a more interesting challenge. I admit I do dislike no water in map generation, which is what speedrunners do for any%.
17:52:02 <b_jonas> also people play RSNG+ for Space Age, I want this for without Space Age
17:54:57 <b_jonas> ok, admittedly the normal patch density is more interesting with biters, where you can't just bypass it by going far from the starting point and building there soon after early game
17:55:06 <b_jonas> so maybe the speedrun categories do make sense
18:06:01 -!- impomatic has quit (Quit: Client closed).
18:10:22 -!- impomatic has joined.
18:13:24 <korvo> Prepping for vibecoding challenge round 2: https://gist.github.com/MostAwesomeDude/ebb60b9bec53c4795f54606e944fccd7
18:16:40 -!- lisbeths has joined.
18:42:01 <esolangs> [[User talk:Tommyaweosme]] https://esolangs.org/w/index.php?diff=177173&oldid=166818 * Mrtli08 * (+58)
18:42:20 -!- Sgeo has joined.
18:44:10 <esolangs> [[User talk:Tommyaweosme]] https://esolangs.org/w/index.php?diff=177174&oldid=177173 * Yayimhere2(school) * (+185) /* why */
18:50:18 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
18:58:21 -!- ais523 has joined.
18:58:56 <ais523> korvo: aren't many of those tasks asking people to use LLMs to solve problems that may not be possible?
18:59:32 <ais523> in any case I'm not sure that the experiment is likely to produce useful results – in advance, you should probably define what a success (for vibecoding) and a failure (for vibecoding) will look like
19:00:10 <ais523> fwiw I think the "common bytecode" problem is likely to have a vibecodeable solution that technically complies with the spec but is useless
19:00:34 <ais523> which is an outcome you should allow for (especially as arguably, a human-coded solution that complied with the spec and met non-functional requirements well would also be useless)
19:01:22 <korvo> ais523: I think that all of these are possible and they're all on my side plate. This time around, I'm not actually going to do them in real time and I don't think that that will compromise my ability to detect broken submissions.
19:01:40 <korvo> And yeah, I haven't defined the task-specific scoring guides yet.
19:01:52 <ais523> the Zaddy one reminds me of Feather a lot
19:02:18 <ais523> in the sense of "it feels like this should be plausible and that I wouldn't expect anyone else to be able to do it" combined with a lot of difficulty actually doing it in practice
19:03:34 <ais523> fwiw, describing Packrat as "fast" amuses me – from my point of view, most reasonable parsing problems have a fairly simple linear-time solution, and Packrat produces a conceptually simple but practically complicated parser with linear-time performance and a terrible constant factor
19:03:36 -!- tromp has joined.
19:05:03 <ais523> it's not as bad as the algorithm which solves any polynomial-time problem in polynomial time by bruteforcing through all possible algorithms for solving it, but I mentally put it into a similar category
19:05:56 <korvo> Meh. I just want to not mess with parsers. Unrestricted Zaddy should leave parsing to some other language and focus on state-of-the-art tree rewriting.
19:06:31 <ais523> using packrat is reasonable in the context, I was just amused at the adjectives
19:07:12 <ais523> (that said, PEG-based parsers do have a significant problem: It is easy to accidentally write a grammar that doesn't match your intent behind the grammar and, unless you happen across a program that parses incorrectly or not at all, the bug is very hard to spot)
19:08:20 <ais523> fwiw I think the most convincing evidence would be along the lines of "here's a problem that the Internet hasn't seen before, 80% of the humans we tested it on were able to solve it in 10 minutes, LLMs still can't figure out how to solve it"
19:08:45 <ais523> arcprize has been doing a lot of problems of that form, although it's setting reasoning tasks rather than vibecoding tasks
19:09:05 <korvo> I deal with a lot of practical problems. For example, I'm currently writing a Nix evaluator. I need to first parse Nix. Nix's reference implementation uses an LR(k) toolkit, so surely the grammar is LR(k) and I should also use an LR(k) toolkit? I wrongly chose "yes" and had to park the project because it wasn't making progress.
19:09:20 <korvo> Replaced it all with a PEG parser over the course of two days and now the project's back on track.
19:10:14 <korvo> This isn't about being convincing. At this point, it's about immanetizing the AI winter by putting to bed the idea that a senior developer can be replaced by a junior centaur.
19:17:24 <ais523> fwiw I view this as an indictment of the quality of current LR(k) toolkits more than anything
19:17:56 <ais523> I think there might be some LR(k) grammars which can't be expressed in PEG, although I'm not sure (and they might be quite artificial-looking)
19:19:19 <ais523> my viewpoint on parsers is very much "LR-family parsers logically should be 'better' in basically every respect than GLR and PEG and hand-written parsers, so why doesn't that seem to be the case in practice?"
19:19:33 <ais523> although you need to define 'better' quite carefully
19:22:56 <korvo> I don't know why LR would be better than GLR, but I don't know GLR well. PEG has two massive advantages over both LR and LL when packrat'd: recursion just works in all cases, and also there's no shift/shift or shift/reduce conflicts.
19:23:14 <ais523> GLR doesn't catch errors at compile time
19:23:43 <ais523> if you write an ambiguous grammar, it's accepted when generating the parser, but then detected at runtime when it tries to parse something that matches the grammar two different ways
19:24:31 <b_jonas> korvo: "reference implementation uses an LR(k) toolkit, so surely the grammar is LR(k)" => because of how C compilers traditionally use yacc but have to add custom magic code to make it work it's easy to see why that's a fallacy, unless you have actually read the reference implementation parser up close
19:24:36 <ais523> (meanwhile, PEG's alternation operator automatically picks one side if it looks like it could match, even if you want the other)
19:31:31 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
19:38:27 <ais523> many parsers that use LR(k) toolkits are not actually LR(k) in practice
19:38:59 <ais523> (as a simple example, C-INTERCAL uses yacc but has a separate sparkears-matching step in the lexer – I am not currently sure whether that's avoidable or not)
19:39:57 <ais523> I don't think the LR(k) algorithm itself is the last word in parsing, primarily because it doesn't nest well (a regular lexer + an LR(k) parser together may do something that an LR(k) parser couldn't do on its own)
19:40:38 <ais523> but that just mean that it needs to be generalised a bit (e.g. LR(*) is an obvious generalisation that can handle the combination, although I suspect other generalisations may work better in practice)
19:41:01 <ais523> maybe my objection is "why is LR parsing stuck on LR(k)?"
19:44:04 -!- somefan has joined.
19:48:19 -!- Lord_of_Life has quit (Ping timeout: 264 seconds).
19:48:26 -!- Lord_of_Life_ has joined.
19:50:41 -!- tromp has joined.
19:51:21 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
19:59:46 <esolangs> [[Crazy J]] https://esolangs.org/w/index.php?diff=177175&oldid=176797 * Blashyrkh * (+576) Elaborate syntax, give short syntactic examples
20:01:46 <esolangs> [[Deadfish+]] https://esolangs.org/w/index.php?diff=177176&oldid=160633 * Kaveh Yousefi * (+1138) Introduced an examples section tallying a trisulc membership, added a hyperlink to my interpreter implementation on GitHub, and supplemented several page category tags.
20:01:57 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
20:04:00 -!- tromp has joined.
20:14:34 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
20:16:42 -!- tromp has joined.
20:18:15 <esolangs> [[Special:Log/newusers]] create * Oak lod * New user account
20:24:38 <korvo> ais523: Thanks for pushing back and forcing me to clarify my thoughts. I've added 10-point rubrics to each task.
20:25:32 <korvo> I need to write that intro. One thing I should emphasize is that yes, starting around Task 3, part of why I haven't just done these yet is because these are some of the hardest and most abstract topics in all of computer science. I'm not some coding wizard; I work hard like any other blockhead.
20:25:51 -!- lisbeths has quit (Quit: Connection closed for inactivity).
20:44:58 <korvo> ais523: Oh, also, I trust you (and y'all in channel) to not spoil Task 5. I did it a couple *years* ago and part of the test is whether the bot can do technical writing in their own voice without plagiarizing me. https://ncatlab.org/nlab/show/Conway's+law
20:45:36 <korvo> (If they don't copy me, and they don't copy Conway, who else can they copy? AFAICT *nobody else* wants to notice the mathematical formalism *and* the formal-to-informal bridge simultaneously; it's just the two of us.)
20:57:54 <ais523> korvo: do you trust the channel logs to not spoil it? they're probably in LLM training data
20:57:58 <ais523> or will be at some point
20:58:30 <korvo> ais523: That's not enough for spoilers. It will show up in a Web search too. I just would prefer that people not post it in the lobste.rs challenge thread or as a comment on the gist.
20:58:30 <ais523> fwiw I thought you were talking about the Conway's law which is about organizations designing things that have the same structure as the organization
20:58:33 <ais523> you might want to clarify that
20:58:55 <korvo> Yep, it's that same law.
21:00:48 <ais523> there's an article about it on Wikipedia
21:02:18 <ais523> I would expect that to be a very likely source for bots to copy from
21:10:39 <int-e> fungot: long time no see
21:12:12 <korvo> ais523: I guess it's not obvious? The English WP article is *wrong*. Like, wrong at the seams. Straight-up copied from cliffnotes, did not do the reading, F tier, see me after class.
21:13:15 <ais523> it clearly has a very different point of view from your article
21:13:24 <ais523> I think it's covering the subject more generally
21:13:47 <ais523> I note that the last paragraph of the lede isn't cited, and it's also the paragraph I'm most suspicious of
21:14:10 <esolangs> [[Stuley]] M https://esolangs.org/w/index.php?diff=177177&oldid=163255 * Ractangle * (+18)
21:14:53 <ais523> after the lede, pretty much the entire article is cited opinions, so it can in a sense only be wrong if the cited persons don't hold the stated opinions
21:15:33 <ais523> (fwiw, at a previous job I worked on a project that was consciously designed based on Conway's law – we worked out the program structure we needed and designed the organisational structure to match)
21:28:30 <korvo> ais523: The given quote is from the paper Conway 1968, but it's the first sentence of the conclusion; it isn't the "proof" that Conway gives on p2-3.
21:29:37 <ais523> <Melvin Conway's website> Author's note 42 years after publication: Perhaps this paper's most remarkable feature is that it made it to publication with its thesis statement in the third-last paragraph. To save you the trouble of wading through 45 paragraphs to find the thesis, I'll give an informal version of it to you now: Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose
21:29:39 <ais523> structure is a copy of the organization's communication structure.
21:30:16 <ais523> specifically https://www.melconway.com/Home/Committees_Paper.html
21:30:29 <esolangs> [[Ooh]] M https://esolangs.org/w/index.php?diff=177178&oldid=167692 * Ractangle * (-4) /* Python implementation */ golfed it a bit now
21:31:16 <korvo> ais523: Sure, and you might also be misled by Conway's wording here: "Is there any predictable relationship between the graph structure of a design organization and the graph structure of the system it designs? The answer is: Yes, the relationship is so simple that in some cases it is an identity. Consider the following "proof.""
21:31:52 <korvo> However, what he shows is adjacency preservation: "If there is a branch, then the two (not necessarily distinct) design groups X and Y which designed the two nodes must have negotiated and agreed upon an interface specification to permit communication between the two corresponding nodes of the design organization. If, on the other hand, there is no branch between x and y, then the subsystems do not communicate with each other, there was nothing fo
21:31:52 <korvo> r the two corresponding design groups to negotiate, and therefore there is no branch between X and Y."
21:32:26 <ais523> korvo: I think it makes sense for Wikipedia to consider the relevant part of the paper to be the part that Conway thinks is relevant
21:32:27 <korvo> Similarly, later, he says "image" but means "preimage" formally: "If we believe our homomorphism, then we must agree that it does. To the extent that an organization is not completely flexible in its communication structure, that organization will stamp out an image of itself in every design it produces."
21:32:30 <ais523> rather than the part which was proved
21:33:03 <korvo> ais523: I think that, in either case, WP clearly misses the mark in the next section: "The law is, in a strict sense, only about correspondence; it does not state that communication structure is the cause of system structure, merely describes the connection." Wrong!
21:34:34 <korvo> ais523: BTW sociologists generally misuse the concepts of similarity, as in their use of "isomorphism": https://en.wikipedia.org/wiki/Isomorphism_(sociology)
21:34:35 <ais523> korvo: so I think what happened is, Conway thinks there's a particular direction of causation, other people disagree, and the article is trying to explain that the sources disagree on the direction and has worded it a little badly
21:35:36 <korvo> ais523: I think that most people don't understand graph homomorphisms. With the right background, Conway's message shines through brightly and it becomes obvious that the metaphors he is using were not precise enough to convey it otherwise.
21:36:43 <ais523> I think the result is vague because "organisation's communication structure" is not well-defined (and not immutable)
21:36:45 <korvo> The advantage of my interpretation is that I can compute whether a given team, with a given way of organizing and communicating, is able to produce a system based on its design doc.
21:37:08 <korvo> You've never had an employer with rules about who can join which Slack channels?
21:37:24 <esolangs> [[ZecZec]] https://esolangs.org/w/index.php?diff=177179&oldid=177141 * BODOKE2801e * (+1002)
21:37:28 <ais523> I've never been in a team large enough to need them
21:37:31 <esolangs> [[Brainfuck Assembly Language]] M https://esolangs.org/w/index.php?diff=177180&oldid=162250 * Ractangle * (-30) BAL is not cannon anymore
21:37:44 <ais523> but, I imagine that in such employers, it would be possible to get the rules changed if they were in the way
21:38:00 <korvo> And yeah, Conway's logic allows for evolution over time. Indeed it can be generalized to causets, which are like DAGs for spacetime events. This is part of what lets us imagine anachronisms, for example.
21:38:06 <ais523> or use a different form of communcation that wasn't banned
21:38:52 <ais523> this sort of thing works better if you consider it working across multiple organisations – there are plenty of instances where, e.g., software developers develop to particular pieces of hardware under the assumption they can't change the spec, and vice versa
21:39:38 <korvo> Specifications are communicable documents.
21:39:39 <ais523> this has lead to weirdnesses like the ARM instruction that does float-to-int (or vice versa, I can't remember which) conversions in a way that matches the JavaScript spec rather than the IEEE one
21:40:19 <ais523> korvo: OK, but you're now claiming a result which might be true, but is entirely useless – that a program can't interface with something that it has no mechanism at all of gaining any information about
21:40:31 <ais523> I don't think this was the point that Conway was trying to make
21:41:44 <ais523> in practice there's normally a gradation of difficulty – some communication is harder than others, some parts of a project are coupled more tightly than others
21:41:55 <ais523> there is almost certainly a correlation there, but due to the fuzziness it is hard to prove
21:43:12 <korvo> ais523: Well, of course, we can learn a theory from observed data. There's programs out there where you feed them a sequence of flashing GPIOs and they'll construct a (small, efficient) Prolog database which can reproduce the sequence.
21:44:20 <korvo> But no, that's not what either of us are saying. We're saying that the physical components of systems (and I suppose the software interfaces, by extended reasoning) only fit together because they were designed to fit together. The odds of randomly fitting aren't super-great and we see lots of mismatches in nature, so the banana really looks like it was designed, y'know?
21:45:18 <korvo> Conway's saying, as a sociologist, that as we walk through our modern jungle we see plenty of components that fit together. Each time something fits together it's because of communication between the designers; it's just too unlikely otherwise.
21:45:32 <ais523> I disagree that that is what Conway is saying
21:46:07 <ais523> that is a true statement, but it's not a very interesting one and I don't think it's the point that Conway was getting at
21:47:00 <ais523> I think Conway's point is more along the lines of "the tightness of coupling between two parts of a software system is correlated to the extent/amount of communication between the people who produced them"
21:47:19 <korvo> Quoting from two adjacent paragraphs: "Dropping down one level, an airplane, for example. may possess subsystems for structure, propulsion, power distribution, communication, and payload packaging. The propulsion subsystem has fuel, ignition, and starting subsystems, to name a few."
21:47:30 <korvo> "For example, the investigation of an airplane crash attempts to produce a theory explaining a complex event. It can consist of subtheories describing the path of the aircraft, its radio communications, the manner of its damage, and its relationship to nearby objects at the time of the event."
21:48:16 <ais523> I'm not sure what point those quotes are supposed to support
21:48:51 <korvo> I'm not sure where tight and loose coupling come in. For Conway's examples, the physical objects *are* coupled; the nature of the coupling isn't really investigated.
21:49:36 <ais523> Conway is viewing system design as a nested hierarchy
21:50:21 <ais523> in that view, tighter coupling is being grouped together near the branches of the hierarchy, whereas looser coupling is communicating nearer the root (e.g. separate branches off the root)
21:50:33 <korvo> Yeah. But his view of graphs can be un-nested. It's easy to verify that graph homomorphisms are preserved for any sort of sub- or super-nodes.
21:53:18 <ais523> korvo: I think you're arguing that part of a project cannot at all depend on an internal detail of another part – and that's clearly a false statement (it's true in general that parts of a project *try to avoid* depending on internals of other parts, in order to avoid being excessively fragile or breaking from what people expected to be non-breaking changes, but it does happen, both intentionally and accidentally)
21:54:25 <ais523> huh, Conway's article cites one of Parkinson's laws
21:54:44 <ais523> which I'm pretty sure were intended as jokes with a grain of truth in them, rather than as actual theorems
21:56:13 <ais523> Conway's footnote 3 is a pretty good summary of the whole discussion, I think: "This claim may be viewed several ways. It may be trivial, hinging on the definition of meaningful negotiation. Or, it may be the result of the observation that one design group almost never will compromise its own design to meet the needs of another group unless [doing so is] absolutely imperative."
21:57:45 <ais523> Conway is viewing communication as a negotiation – there are other possible forms of communication, such as experimentation or reading a specification or reading source code, and that complicates matters
21:59:40 <korvo> Oh! I just realized. So, I only started copy-pasting because you linked the HTML, but before that, I was reading the PDF. Have you *seen* Fig. 2? I know you've seen Fig. 3, because it's the one that's always reposted, but there's a clear version at https://www.melconway.com/Home/pdf/committees.pdf
22:00:35 <korvo> The mapping of zeta-prime to zed shows that this isn't an isomorphism or identity mapping. It's the more general case: homomorphism.
22:02:00 <korvo> Anyway, it's quite fun to know that this is such a contentious claim. The admins over at nLab were also irritated, but mostly because they'd never heard of Conway's Law at all and thought I'd invented it.
22:02:48 <ais523> figure 2 is also in the HTML
22:03:02 <korvo> It's itty-bitty. I can't read it. My eyes are not super-great.
22:03:36 <ais523> there's a commutative diagram which has two nodes x and y connected by an "interface x-y", which commutes with two designers X and Y and a "Coordinator X-Y"
22:04:18 <ais523> I think this is a contentious point in three different respects (definitions, direction of causality, and whether the diagram actually needs to commute in practice)
22:04:43 <ais523> fwiw I think that whether or not the design inherently commutes depends on which definitions you use!
22:09:13 <korvo> I guess. But I still think that I have a computational justification for claims made from it, whereas the typical C-suite is operating wholly on vibes, and I think that the main difference is our willingness to do maths.
22:09:26 <ais523> the relevant sentence about Conway's view is "If there is a branch, then the two (not necessarily distinct) design groups X and Y which designed the two nodes must have negotiated and agreed upon an interface specification to permit communication between the two corresponding nodes of the design organization." which is unfortunately ambiguous and makes it hard to work out Conway's viewpoint (specifically, the concept of "negotiate and agree" has multiple
22:09:27 <ais523> reasonable definitions)
22:10:09 <ais523> and footnote 3 implies that Conway also understands it to be ambiguous / definition-dependent
22:10:23 <ais523> as such I don't think this is a mathematical result, there is relevant fuzziness that Conway was aware of
22:13:09 <korvo> I mean, in distributed systems, we take it fairly seriously when we can rule out whether two machines were communicating. (I think we've talked about the four tenses before.)
22:13:31 <korvo> But sure, I'll grant that humans magically absorb information from their ambient environment.
22:13:50 <ais523> …and I just noticed that Conway's statement doesn't imply a direction of causality either, "if x communicates with y then X must have negotiated with Y" could happen either because x and y needed to communicate and that forced X and Y to negotiate, or because X and Y were negotiating already and so they allowed their x and y to communicate with each other
22:15:29 <korvo> Negotiation is sometimes implicit or low-level, below our focus. Am I negotiating with Doug Crockford when I read the JSON spec from json.org? What's relevant is Crockford's presence in my past lightcone, not the specifics of our HTTP messages.
22:16:28 <ais523> indeed – I think this is the point that lead to the more nuanced versions of Conway's Law
22:16:52 <ais523> implicit and low-level negotiation is different in a sense from explicit / high-level negotiation
22:17:14 <ais523> the more actively you can negotiate and agree, the more tightly you can couple
22:17:58 <ais523> (that said, this doesn't mean that tight coupling is necessarily a good idea – the consensus project management for designing large systems involves a preference for loose coupling even between two things designed by the same person)
22:19:56 <ais523> now I'm reminded of one of the biggest ongoing project-management-style disagreements about designing Rust programs: in Rust, if an item in a module is used by other modules in the same crate, but not outside the crate, you can define it either as pub or as pub(crate) and the two are equivalent
22:20:14 <ais523> (assuming the module itself isn't visible outside the crate)
22:21:20 <ais523> many people have strong views on which you should use – for me, "pub" is correct because a module shouldn't care what's going on in the crate around it, only about the interface it itself presents
22:23:17 <b_jonas> yeah, I don't like the pub(crate) annotation either. mod, use, and plain pub are expressive enough that you shouldn't need qualified pub to express visibilities.
22:24:54 <ais523> I use pub(crate) on rare occasions but it's like friend in C++ – it's there to intentionally make holes in the visibility system when you're doing something that's locally unsound but globally sound
22:25:33 <b_jonas> though I don't know if this still applies if you can have the restrictions that the modern impl type return values add, where rust doesn't have a decltype and a crate may export a function that returns a type but not export the type so users of the crate aren't allowed to name it
22:26:46 <ais523> I don't think pub(crate) helps in that situation but might be wrong
22:27:07 <b_jonas> oh, I don't like C++ friend. it may have made sense in ancient C++, but today with all the modern features like templates, the friend feature just makes the name lookup rules of C++ extra complicated without adding much expressivity to the language, so it's a load that isn't worth its cost
22:27:08 <ais523> there are two cases: a) where the return value is specifically "impl Trait", b) where the return value is a specific concrete type that the user can't name
22:27:57 <ais523> (the latter can happen if the type is a public type in a private module – those can be returned from functions that are siblings of the module, but can't be named by their callers)
22:28:13 <ais523> and they appear unlinked in the docs, just the name but you can't click on it for more details
22:29:11 <ais523> (impl Trait is also a specific concrete type, but one that at present *nobody* can name – although there are proposals for a return type notation to allow you to name them by saying "the return type of T::method")
22:29:25 <ais523> (not with that syntax of course)
22:40:03 <int-e> nightly can sort of do it with impl_trait_in_assoc_type: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024 (seen here: https://github.com/embassy-rs/embassy/blob/ac1d8719b64cba62a132d12ba1cba107ce88afa8/embassy-executor-macros/src/macros/task.rs#L198-L208 )
22:40:36 <int-e> The corresponding tracking issue is from 2019 though :P https://github.com/rust-lang/rust/issues/63063
22:41:52 <b_jonas> as far as I understand you can't just add decltype to rust. currently if a crate exports a function that returns an impl Trait then the users aren't allowed to depend on the specific type that the function returns, so later versions of the crate can change it without that causing an incompatibility. if you allowed the user of the crate to name that type with decltype then this would no longer be true.
22:41:58 <b_jonas> but decltype might still work for when the return type is a specific type, it just can't be named directly because it refers to a name that isn't exported.
22:42:18 <int-e> (the future becomes namable as <() as Foo)::Fut )
22:42:35 <int-e> ...modulo obvious syntax errors
22:45:13 <b_jonas> I wonder if an impl Trait return looks as if the function returned a newtype used only in this function and the field of the newtype is private to the crate, but inside the crate that newtype is transparently constructed and deconstructed
22:45:42 <b_jonas> and of course that newtype implements Trait by forwarding it to its field
22:47:55 <b_jonas> int-e: that link to the playground doesn't link to any code by the way
22:48:03 <ais523> part of the motivation for return type notation was so you could say "where the return type of this method is Send"
22:48:18 <ais523> that does break current impl Trait information hiding principles
22:48:18 <int-e> IIUC it's a completely opaque type to you as a user, but the compiler knows the representation even in other crates.
22:48:56 <int-e> (well, sorry, I'm stuck on the particular case of async/Future)
22:49:07 <ais523> int-e: yes, that's intentional for it to be able to optimise around the specific type
22:49:19 <int-e> (Rather than the generic impl Trait, which is still opaque but the compiler isn't likely to poke around in it.)
22:49:26 <ais523> the difference is that some of the new features are making aspects of the type observable, such as its size, alignment and sendiness
22:49:30 <b_jonas> sure, the compiler has to know the actual type to be able to generate code at all
22:49:59 <ais523> (although, you can't *specialise* on the sendiness, so the observation of the sendiness only affects whether or not the program compiles)
22:50:26 <ais523> I guess "sendability" is a better word than "sendiness" for this
22:53:20 <b_jonas> ais523: is that new features? surely you could always observe the size of a value even in old rust
22:53:51 <ais523> b_jonas: size_of_val works even in current Rust, but not at compile time
22:54:41 <b_jonas> oh, you can observe it in runtime only? I see
22:54:43 <ais523> actually, I think you could probably call a function that takes the impl-Trait as a generic argument and have it do the size_of for you?
22:55:31 <b_jonas> there's offset_of!((function_with_secret_return_type(), ()), 1) but that macro is somewhat new to Rust
22:56:02 <ais523> and isn't guaranteed to give the right result
22:56:21 <ais523> because (T, U) doesn't have a stable layout
22:57:17 <ais523> also offset_of! also takes a type, not a value
22:57:36 <ais523> OK, I think current Rust can't check the size of an impl Trait at compile time
22:57:49 <ais523> it's possible at runtime using multiple methods (with size_of_val being provided for the purpose)
22:57:57 <b_jonas> Rust tuples don't guarantee their representation, and for a good reason
22:59:53 <b_jonas> you need a #[repr(C)] struct for that, and you can't define one without naming the type; and yes, offset_of! needs a type
23:02:34 <esolangs> [[Esolang:Introduce yourself]] M https://esolangs.org/w/index.php?diff=177181&oldid=177168 * Oak lod * (+202) Added introduction
23:02:47 <b_jonas> and I think you would need to be able to name the type to do the compile time pointer subtraction trick
23:03:06 <esolangs> [[User:Oak lod]] N https://esolangs.org/w/index.php?oldid=177182 * Oak lod * (+10) Created page with "Wadup gng."
23:03:16 <esolangs> [[CAESAR\]] https://esolangs.org/w/index.php?diff=177183&oldid=106928 * Oak lod * (+440) Fixed multiple spelling errors and updated code snippets
23:07:37 <esolangs> [[CAESAR\]] M https://esolangs.org/w/index.php?diff=177184&oldid=177183 * Ais523 * (-30) the first letter of a page name is case-insensitive, so you don't need to pipe a link purely to change the case of that letter
23:08:04 <b_jonas> I still hate how C doesn't clearly specify whether offsetof(struct { int p }, p) is valid to write, because while most syntactic constructs like sizeof get formal grammars with pages of standardese describing what exactly is allowed, offsetof is just a macro so it doesn't get such a detailed description.
23:08:22 <b_jonas> it's clearly invalid in C++, but that doesn't solve the problem
23:08:41 <b_jonas> at some point C compilers disagreed about this
23:08:54 <esolangs> [[CAESAR\]] https://esolangs.org/w/index.php?diff=177185&oldid=177184 * Aadenboy * (-404) convert lists to wikitext
23:08:54 <b_jonas> I should check if they fixed this in later C standards
23:10:36 <ais523> does offsetof work on unions?
23:10:57 <ais523> I guess it isn't ever useful, which makes it unclear whether it would be allowed or not
23:11:25 <b_jonas> I think it does, it pretty much has to because of anonymous unions in structs
23:15:32 <b_jonas> as in struct f { int p; union { int m; float n; }; }; ... int main() { return offsetof(f, m); }
23:15:42 <esolangs> [[CAESAR\]] https://esolangs.org/w/index.php?diff=177186&oldid=177185 * Oak lod * (+49) Added interpreter link
23:17:29 <esolangs> [[Special:Log/move]] move * Oak lod * moved [[CAESAR\]] to [[CAESAR]]: Misspelled title
23:22:29 <esolangs> [[CAESAR/]] N https://esolangs.org/w/index.php?oldid=177189 * Oak lod * (+20) Added re-direct for old page title
23:25:00 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
23:51:34 <esolangs> [[Deadfish+]] https://esolangs.org/w/index.php?diff=177190&oldid=177176 * Kaveh Yousefi * (+0) Rectified the page category tag expressing the year from 2024 to the correct 2025.