Newest at the top
| 2026-03-09 14:54:05 +0100 | comerijn | (~merijn@77.242.116.146) merijn |
| 2026-03-09 14:35:59 +0100 | st_aldini | (~Betterbir@136.48.46.187) (Quit: st_aldini) |
| 2026-03-09 14:26:07 +0100 | oskarw | (~user@user/oskarw) oskarw |
| 2026-03-09 14:16:17 +0100 | Fischmiep | (~Fischmiep@user/Fischmiep) (Remote host closed the connection) |
| 2026-03-09 14:13:34 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2026-03-09 13:58:29 +0100 | prdak1 | prdak |
| 2026-03-09 13:54:17 +0100 | prdak1 | (~Thunderbi@user/prdak) prdak |
| 2026-03-09 13:54:06 +0100 | prdak | (~Thunderbi@user/prdak) (Read error: Connection reset by peer) |
| 2026-03-09 13:46:32 +0100 | Square2 | (~Square4@user/square) Square |
| 2026-03-09 13:32:41 +0100 | YoungFrog | (~youngfrog@2a02:a03f:ca07:f900:1032:66d2:1281:f541) youngfrog |
| 2026-03-09 13:31:24 +0100 | YoungFrog | (~youngfrog@39.129-180-91.adsl-dyn.isp.belgacom.be) (Quit: ZNC 1.7.x-git-3-96481995 - https://znc.in) |
| 2026-03-09 13:25:46 +0100 | <ski> | EvanR : yea, the point of that respone was to provide perhaps a more mathematical/logical aspect to the FD semantics. but yes, neither of the mentioned two effects have anything to do with actually selecting an instance, but rather to constrain the usage (merging used instances (demanded constraints)) and definition (disallowing instances violating the FD) of instances |
| 2026-03-09 13:24:29 +0100 | xff0x | (~xff0x@2405:6580:b080:900:3f2f:c15f:718f:76d4) |
| 2026-03-09 13:09:56 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2026-03-09 13:06:12 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2026-03-09 13:05:24 +0100 | czan | (~czan@user/mange) (Ping timeout: 246 seconds) |
| 2026-03-09 12:57:17 +0100 | target_i | (~target_i@user/target-i/x-6023099) target_i |
| 2026-03-09 12:56:18 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2026-03-09 12:54:20 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 245 seconds) |
| 2026-03-09 12:52:02 +0100 | danza | (~danza@user/danza) (Remote host closed the connection) |
| 2026-03-09 12:51:12 +0100 | danza | (~danza@user/danza) danza |
| 2026-03-09 12:50:58 +0100 | danza | (~danza@user/danza) (Read error: Connection reset by peer) |
| 2026-03-09 12:45:01 +0100 | oskarw | (~user@user/oskarw) (Ping timeout: 276 seconds) |
| 2026-03-09 12:42:20 +0100 | _d0t | (~{-d0t-}@user/-d0t-/x-7915216) {-d0t-} |
| 2026-03-09 12:37:13 +0100 | _d0t | (~{-d0t-}@user/-d0t-/x-7915216) (Ping timeout: 276 seconds) |
| 2026-03-09 12:29:11 +0100 | danza | (~danza@user/danza) danza |
| 2026-03-09 12:28:07 +0100 | prdak | (~Thunderbi@user/prdak) prdak |
| 2026-03-09 12:21:50 +0100 | dhil | (~dhil@5.151.29.139) dhil |
| 2026-03-09 12:21:14 +0100 | dutchie | (~dutchie@user/dutchie) dutchie |
| 2026-03-09 12:20:33 +0100 | prdak | (~Thunderbi@user/prdak) (Ping timeout: 265 seconds) |
| 2026-03-09 12:20:30 +0100 | int-e | runs |
| 2026-03-09 12:20:28 +0100 | <int-e> | mauke: with Haskell you can have both! |
| 2026-03-09 12:20:14 +0100 | dutchie | (~dutchie@user/dutchie) (Remote host closed the connection) |
| 2026-03-09 12:20:02 +0100 | <mauke> | I strongly prefer code to be typed, not generated |
| 2026-03-09 12:19:57 +0100 | <newmind> | int-e: more or less, yes :) still more successful than just inventing code that then just crashes at runtime |
| 2026-03-09 12:18:47 +0100 | <int-e> | "but it compiles" -- yeah because they throw the code at the compiler until it does |
| 2026-03-09 12:00:19 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2026-03-09 11:59:05 +0100 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2026-03-09 11:48:42 +0100 | arthurvl | (~arthurvl@2a02-a469-f5e2-1-83d2-ca43-57a2-dc81.fixed6.kpn.net) earthy |
| 2026-03-09 11:42:41 +0100 | dutchie | (~dutchie@user/dutchie) dutchie |
| 2026-03-09 11:41:58 +0100 | dutchie | (~dutchie@user/dutchie) (Remote host closed the connection) |
| 2026-03-09 11:35:18 +0100 | <newmind> | at least the claude models are.. usable? they still get a lot of it wrong, and often get stuck in trivial sections, and the code they produce is... quite bad... but it compiles, and once it's working, refactoring it in a strongly typed language is so much more reliable than without |
| 2026-03-09 11:34:03 +0100 | <merijn> | mesaoptimizer: I mean, that's just reinventing Epigram but unprincipled :p\ |
| 2026-03-09 11:33:45 +0100 | <merijn> | newmind: I've mostly been using it with Scala, so not entirely sure how it does for HAskell |
| 2026-03-09 11:32:10 +0100 | <newmind> | merijn: i feel like it is quite a bit worse at generation, it one-shots less reliably, and often falls back to imperative patterns which don't quite fit wit haskell... but at least most of the time it then doesn't compile and it can fix that, rather than relying just on unit tests or the user catching it |
| 2026-03-09 11:29:07 +0100 | <merijn> | [exa]: tbh, chatgpt seems to do much better with strongly typed code than other stuff imo |
| 2026-03-09 11:28:49 +0100 | vgtw | (~vgtw@user/vgtw) vgtw |
| 2026-03-09 11:25:45 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 248 seconds) |
| 2026-03-09 10:54:59 +0100 | <mesaoptimizer> | (question is whether they will stay intuitive enough for programmers) |
| 2026-03-09 10:54:19 +0100 | <mesaoptimizer> | perhaps if you model the syntax-semantics space, you can essentially sample from regions that are adverserially optimized to be incoherent and counter-intuitive to the model |