| 2026-06-30 00:08:31 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 00:15:09 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-06-30 00:26:37 +0000 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-06-30 00:28:00 +0000 | robobub | (uid248673@id-248673.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2026-06-30 00:30:44 +0000 | merijn | (~merijn@62.45.136.136) (Ping timeout: 245 seconds) |
| 2026-06-30 00:36:50 +0000 | acidjnk_new | (~acidjnk@p200300d6e74def672da110570be53229.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 2026-06-30 00:36:59 +0000 | acidjnk | (~acidjnk@p200300d6e74def672da110570be53229.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 2026-06-30 00:41:55 +0000 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-06-30 00:46:53 +0000 | merijn | (~merijn@62.45.136.136) (Ping timeout: 268 seconds) |
| 2026-06-30 00:57:16 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 01:01:50 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-06-30 01:06:50 +0000 | xff0x | (~xff0x@2405:6580:b080:900:e4cf:554c:fb5:7866) (Ping timeout: 245 seconds) |
| 2026-06-30 01:08:26 +0000 | polykernel_ | (~polykerne@user/polykernel) polykernel |
| 2026-06-30 01:10:58 +0000 | polykernel | (~polykerne@user/polykernel) (Ping timeout: 276 seconds) |
| 2026-06-30 01:10:58 +0000 | polykernel_ | polykernel |
| 2026-06-30 01:12:38 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 01:16:59 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-06-30 01:26:43 +0000 | ft | (~ft@p3e9bc5ec.dip0.t-ipconnect.de) (Ping timeout: 264 seconds) |
| 2026-06-30 01:27:22 +0000 | Digit | (~user@user/digit) Digit |
| 2026-06-30 01:28:01 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 01:31:53 +0000 | jrm | (~jrm@user/jrm) (Quit: ciao) |
| 2026-06-30 01:32:31 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds) |
| 2026-06-30 01:32:36 +0000 | absentia | (~henricus@user/absentia) absentia |
| 2026-06-30 01:32:57 +0000 | <absentia> | i appear to be struggling with haskell text parsing |
| 2026-06-30 01:33:07 +0000 | <absentia> | it's not much, 300k lines and 25MB of UTF8 |
| 2026-06-30 01:33:14 +0000 | jrm | (~jrm@user/jrm) jrm |
| 2026-06-30 01:33:23 +0000 | <absentia> | but it is stateful, i need to thread a cache through the parse, updated by each line |
| 2026-06-30 01:33:40 +0000 | <absentia> | attoparsec.text still chokes, takes several minutes |
| 2026-06-30 01:34:11 +0000 | <absentia> | accumulating into a vector for each line |
| 2026-06-30 01:35:11 +0000 | <jreicher> | Parsing is not stateful. |
| 2026-06-30 01:35:25 +0000 | <jreicher> | Sorry, I should say it's not side-effecting |
| 2026-06-30 01:35:36 +0000 | <jreicher> | You can write it with a state monad if you want |
| 2026-06-30 01:35:40 +0000 | <absentia> | jreicher: they're weechat logs |
| 2026-06-30 01:35:43 +0000 | <absentia> | i manually implemented a state monad |
| 2026-06-30 01:35:59 +0000 | <absentia> | the idea is when you see a PRIVMSG log line, you look up the hostname associated with that nick in a cache |
| 2026-06-30 01:36:02 +0000 | <jreicher> | You mean you didn't use the state monad supplied by Haskell? |
| 2026-06-30 01:36:06 +0000 | <absentia> | the cache is populated by earlier JOIN/PART/QUIT messages |
| 2026-06-30 01:36:19 +0000 | <absentia> | jreicher: so what do i do, do i stack StateT on top of Parser? |
| 2026-06-30 01:36:34 +0000 | <absentia> | some LLM actually advised not to do this, it will be slow |
| 2026-06-30 01:36:53 +0000 | <absentia> | instead my parser just returns (s, a) |
| 2026-06-30 01:36:53 +0000 | <jreicher> | Would you prefer something that's fast and broken, or slow and works? |
| 2026-06-30 01:36:56 +0000 | <mauke> | StateT Parser feels wrong |
| 2026-06-30 01:37:01 +0000 | <absentia> | it's already slow and works |
| 2026-06-30 01:37:03 +0000 | <absentia> | but thank you for presuming |
| 2026-06-30 01:37:11 +0000 | <jreicher> | Oh I thought you said it was broken |
| 2026-06-30 01:37:11 +0000 | <absentia> | my issue is i want it to be fast and working |
| 2026-06-30 01:37:13 +0000 | <EvanR> | when you are parsing and have a state, you have to decide when the state is reset if ever |
| 2026-06-30 01:37:17 +0000 | <absentia> | jreicher: where did i say that |
| 2026-06-30 01:37:17 +0000 | <mauke> | wouldn't that give you stateful construction of a (pure) parser? |
| 2026-06-30 01:37:22 +0000 | <absentia> | jreicher: maybe you should work on your reading comprehension |
| 2026-06-30 01:37:32 +0000 | <absentia> | jreicher: instead of projecting whatever wh*te nonsense you have going on up there |
| 2026-06-30 01:37:52 +0000 | <monochrom> | I think they mean StateT Foo Parser but they don't tell you what's Foo. |
| 2026-06-30 01:37:53 +0000 | <EvanR> | this is no longer serious! |
| 2026-06-30 01:38:00 +0000 | <mauke> | er, yes |
| 2026-06-30 01:38:03 +0000 | <jreicher> | absentia: it's what I thought you meant by "I appear to be struggling" and also "chokes". It's a simple misunderstanding, and you don't need to be so harsh about it. |
| 2026-06-30 01:38:10 +0000 | <mauke> | StateT s Parser |
| 2026-06-30 01:38:13 +0000 | <absentia> | anyway |
| 2026-06-30 01:38:22 +0000 | <absentia> | mauke: Parser does not instance MonadState or whatever |
| 2026-06-30 01:38:40 +0000 | <absentia> | attoparsec explicitly diverges from parsec and megaparsec in this way, supposedly for performance |
| 2026-06-30 01:38:51 +0000 | <mauke> | ?? |
| 2026-06-30 01:38:55 +0000 | <monochrom> | But crucially whether this is fast or slow depends on Foo, along with a hundred other "details" not revealed. |
| 2026-06-30 01:39:07 +0000 | <absentia> | https://hackage.haskell.org/package/attoparsec-0.14.4/docs/Data-Attoparsec-Internal-Types.html#t:P… |
| 2026-06-30 01:39:20 +0000 | <mauke> | my concern was the layering |
| 2026-06-30 01:39:26 +0000 | <absentia> | https://hackage.haskell.org/package/parsec-3.1.18.0/docs/Text-Parsec.html#t:ParsecT |
| 2026-06-30 01:39:34 +0000 | <mauke> | specifically StateT-around-Parser vs ParserT-around-State |
| 2026-06-30 01:39:37 +0000 | <absentia> | mauke: i'm saying, there is no other possible layering |
| 2026-06-30 01:39:40 +0000 | <monochrom> | But really the moment I saw "LLM said ..." I turned off. |
| 2026-06-30 01:39:52 +0000 | <absentia> | and the only possible layering is nonsensical for the reason you pointed out |
| 2026-06-30 01:40:09 +0000 | <absentia> | because there is no ParsecT in Attoparsec instancing MonadState |
| 2026-06-30 01:40:14 +0000 | <absentia> | there is in Parsec |
| 2026-06-30 01:40:41 +0000 | <absentia> | so actually what i have are s -> Parser (s, a) |
| 2026-06-30 01:40:42 +0000 | <mauke> | why do you keep talking about instances |
| 2026-06-30 01:40:47 +0000 | <monochrom> | The 3 times I took a look at what Google AI said, they were all wrong. In fact in one case, it said "X is true" where the very references it cited said "X is false". |
| 2026-06-30 01:40:49 +0000 | <absentia> | mauke: where do the stateful effects come from |
| 2026-06-30 01:41:02 +0000 | <absentia> | without a monad instance |
| 2026-06-30 01:41:30 +0000 | <mauke> | wait, now it's about Monad? |
| 2026-06-30 01:41:54 +0000 | <absentia> | the hell... all i'm saying is there is no MonadState instance for Attoparsec.Text.Parser |
| 2026-06-30 01:41:56 +0000 | <mauke> | I do assume there is a Monad instance, yes |
| 2026-06-30 01:42:02 +0000 | <mauke> | I don't care about MonadState |
| 2026-06-30 01:42:05 +0000 | <absentia> | therefore i thread my own state through |
| 2026-06-30 01:42:19 +0000 | jrm | (~jrm@user/jrm) (Quit: ciao) |
| 2026-06-30 01:42:33 +0000 | <absentia> | i should really just profile it at this point |
| 2026-06-30 01:42:40 +0000 | <absentia> | instead of guessing |
| 2026-06-30 01:42:48 +0000 | <absentia> | but it's aggravating that something as simple as text parsing is so damn slow |
| 2026-06-30 01:42:52 +0000 | <mauke> | IIRC all MonadState gives you is the ability to write 'put x' instead of 'lift (put x)' |
| 2026-06-30 01:43:23 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 01:43:25 +0000 | <absentia> | mauke: so what is it that gives you the ability to lift |
| 2026-06-30 01:43:29 +0000 | ft | (~ft@p3e9bccb7.dip0.t-ipconnect.de) ft |
| 2026-06-30 01:43:31 +0000 | jrm | (~jrm@user/jrm) jrm |
| 2026-06-30 01:43:36 +0000 | <mauke> | monad transformer |
| 2026-06-30 01:43:41 +0000 | <absentia> | yeah. it doesn't instance that either. |
| 2026-06-30 01:43:48 +0000 | <absentia> | maybe that's closer to what i meant |
| 2026-06-30 01:44:13 +0000 | <EvanR> | there are ways to parse really fast, and break things |
| 2026-06-30 01:44:21 +0000 | <geekosaur> | if it claims to be ParsecT then it ought to be (that's what the trailing T by convention means) |
| 2026-06-30 01:44:32 +0000 | <absentia> | there is only ParsecT in Parsec |
| 2026-06-30 01:44:37 +0000 | <absentia> | there is no transformer in Attoparsec |
| 2026-06-30 01:44:40 +0000 | <absentia> | it only instances monad |
| 2026-06-30 01:44:47 +0000 | <absentia> | in fact monadplus and monadfail |
| 2026-06-30 01:44:58 +0000 | <geekosaur> | maybe that's the wrong way to go then. |
| 2026-06-30 01:45:21 +0000 | <absentia> | well attoparsec is allegedly "faster" without the ability to lift stateful computations |
| 2026-06-30 01:45:31 +0000 | <absentia> | but it still takes like 10 minutes to parse 25MB |
| 2026-06-30 01:45:40 +0000 | <geekosaur> | also if you want really fast you probably want flatparse, but the price you pay is inconvenience |
| 2026-06-30 01:45:51 +0000 | <absentia> | sometimes i wonder why i didn't write this in python or C or something |
| 2026-06-30 01:46:01 +0000 | <absentia> | it's just shocking to me because i've written minimax engines in haskell |
| 2026-06-30 01:46:08 +0000 | <absentia> | but it just absolutely shits the bed on plaintext processing |
| 2026-06-30 01:46:10 +0000 | <EvanR> | python, that blazing fast language |
| 2026-06-30 01:46:20 +0000 | <absentia> | yeah but do you think it would take 10 minutes to parse 25MB? |
| 2026-06-30 01:46:31 +0000 | <absentia> | i even tried the naive caveman approach |
| 2026-06-30 01:46:33 +0000 | <absentia> | T.splitOn |
| 2026-06-30 01:46:34 +0000 | <EvanR> | you sound like you don't know what you're doing honestly |
| 2026-06-30 01:46:35 +0000 | <absentia> | etc |
| 2026-06-30 01:46:43 +0000 | <geekosaur> | that sounds bad enough that I wonder if you're doing something really wrong |
| 2026-06-30 01:46:46 +0000 | <absentia> | should i just poste the goddamn code |
| 2026-06-30 01:47:02 +0000 | <mauke> | that usually helps :-) |
| 2026-06-30 01:47:07 +0000 | <EvanR> | messing up basic haskell fundamentals |
| 2026-06-30 01:47:13 +0000 | <mauke> | EvanR: ? |
| 2026-06-30 01:47:14 +0000 | <absentia> | https://bpa.st/V2MQ |
| 2026-06-30 01:47:26 +0000 | <EvanR> | in the old days that would cause an early exit for too much stack used |
| 2026-06-30 01:47:30 +0000 | <monochrom> | This is known as "information hiding". |
| 2026-06-30 01:47:33 +0000 | <absentia> | go and audit the code |
| 2026-06-30 01:47:37 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) (Remote host closed the connection) |
| 2026-06-30 01:47:40 +0000 | <absentia> | i seriously don't see why this should be non performant |
| 2026-06-30 01:47:54 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2026-06-30 01:48:11 +0000 | Digit | (~user@user/digit) (Remote host closed the connection) |
| 2026-06-30 01:48:41 +0000 | <absentia> | like you have to be fucking kidding me if this performs so poorly |
| 2026-06-30 01:48:52 +0000 | <absentia> | there aren't even any explicit lists |
| 2026-06-30 01:49:03 +0000 | <absentia> | yes Vector.snoc is O(n) but spatial locality and cache lines etc |
| 2026-06-30 01:49:19 +0000 | <absentia> | rather shit asymptotics than shotgun random accessing memory and cache missing all the time |
| 2026-06-30 01:49:21 +0000 | <monochrom> | Well that does it. |
| 2026-06-30 01:49:32 +0000 | <absentia> | monochrom: seen this talk by Stroustrup? |
| 2026-06-30 01:49:38 +0000 | <absentia> | https://www.youtube.com/watch?v=OB-bdWKwXsU&t=44m38s |
| 2026-06-30 01:49:39 +0000 | <monochrom> | No. |
| 2026-06-30 01:49:43 +0000 | <absentia> | he says caches beat asymptotics |
| 2026-06-30 01:49:45 +0000 | <absentia> | every time |
| 2026-06-30 01:49:59 +0000 | <absentia> | vectors >>> linked lists |
| 2026-06-30 01:50:00 +0000 | <monochrom> | Well he hasn't seen your example. |
| 2026-06-30 01:50:06 +0000 | <EvanR> | lol |
| 2026-06-30 01:50:10 +0000 | <absentia> | there must be something quite unique about GHC.... |
| 2026-06-30 01:50:17 +0000 | <monochrom> | Also he is not using immutable vectors. |
| 2026-06-30 01:50:21 +0000 | <EvanR> | are you thinking Vector is C++ vector |
| 2026-06-30 01:50:27 +0000 | <absentia> | is it the linalg vector |
| 2026-06-30 01:50:34 +0000 | <absentia> | what am i supposed to use then |
| 2026-06-30 01:50:37 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2026-06-30 01:50:38 +0000 | schuelermine | (~Thunderbi@user/schuelermine) (Ping timeout: 244 seconds) |
| 2026-06-30 01:50:58 +0000 | <EvanR> | some humility |
| 2026-06-30 01:51:11 +0000 | <absentia> | i think liberians love to project all their own flaws unto everyone else.... |
| 2026-06-30 01:51:22 +0000 | Digit | (~user@user/digit) Digit |
| 2026-06-30 01:51:35 +0000 | <absentia> | can you point out the "basic haskell fundamentals" that are obviously absent from my code EvanR |
| 2026-06-30 01:51:58 +0000 | <EvanR> | e.g. trying to do the equivalent of repeatedly appending an item to the end of a list |
| 2026-06-30 01:52:07 +0000 | <absentia> | i literally came out the gate with that |
| 2026-06-30 01:52:17 +0000 | <monochrom> | Stroustrup is working with, say, "after every 1000 snocs, move to a new location". But Haskell Vector's is after every 1 snoc, move to a new location. |
| 2026-06-30 01:52:17 +0000 | <absentia> | and acknowledged the poor asymptotics, but cited Stroustrup's pragmatics |
| 2026-06-30 01:52:27 +0000 | <absentia> | ok. let's try with plain lists |
| 2026-06-30 01:52:31 +0000 | <EvanR> | quadratic, sure |
| 2026-06-30 01:52:42 +0000 | <EvanR> | but you sounded surprised that it was slow |
| 2026-06-30 01:52:50 +0000 | <absentia> | because i also tried it with lists |
| 2026-06-30 01:52:52 +0000 | <absentia> | it was still pitiful |
| 2026-06-30 01:52:59 +0000 | <absentia> | something like 3000 lines a minute |
| 2026-06-30 01:53:05 +0000 | <absentia> | i am importing 21M |
| 2026-06-30 01:53:18 +0000 | <EvanR> | lists are pretty bad for a lot of things but now we're talking hypotheticals again |
| 2026-06-30 01:53:19 +0000 | <absentia> | then again it was not a controlled experiment |
| 2026-06-30 01:53:23 +0000 | <absentia> | i will try this exact code with lists |
| 2026-06-30 01:55:09 +0000 | <monochrom> | You should go back to C++. Because even when you attempt Haskell, you're just translating C++ to Haskell word by word. That is doomed to make slow programs. There are ways to write fast Haskell programs, but first you must not presume that C++ best practices become Haskell best practices. Some do, some others are the exact opposite. You have to start from scratch. Or just go back to the C++ comfort zone. |
| 2026-06-30 01:55:44 +0000 | <absentia> | why are liberians content to make assuming gender a hate crime |
| 2026-06-30 01:55:50 +0000 | <absentia> | but go on to assume all sorts of other intangible things about you |
| 2026-06-30 01:56:02 +0000 | <absentia> | i've written a naive bayesian filter in haskell |
| 2026-06-30 01:56:06 +0000 | <absentia> | half the functions are pointfree |
| 2026-06-30 01:56:20 +0000 | <absentia> | i've even written a chess engine in haskell |
| 2026-06-30 01:56:31 +0000 | <absentia> | it will go up to 4ply within 2 minutes on a $5 VPS |
| 2026-06-30 01:56:55 +0000 | <EvanR> | C++ in any language |
| 2026-06-30 01:57:03 +0000 | <EvanR> | just as bad as haskell in any language |
| 2026-06-30 01:57:23 +0000 | <jreicher> | Hmm. I would have thought all the takes in the do blocks would be OK... |
| 2026-06-30 01:59:51 +0000 | <monochrom> | Haskell's Vector snoc performs a relocation (really a copy --- the old version still exists) every time. You lose cache locality already. It never benefits from what Stroustrup hoped for. |
| 2026-06-30 02:00:01 +0000 | <absentia> | is this because of immutability |
| 2026-06-30 02:00:05 +0000 | <absentia> | is it literally a malloc per snoc |
| 2026-06-30 02:00:13 +0000 | <monochrom> | Yes and yes. |
| 2026-06-30 02:00:20 +0000 | <absentia> | maybe my friend's intuition was right after all... |
| 2026-06-30 02:00:25 +0000 | <absentia> | he was sniffing out excessive memory allocation |
| 2026-06-30 02:00:51 +0000 | <absentia> | hm |
| 2026-06-30 02:01:25 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 02:01:37 +0000 | dibblego | (~dibblego@157.211.3.209) |
| 2026-06-30 02:01:37 +0000 | dibblego | (~dibblego@157.211.3.209) (Changing host) |
| 2026-06-30 02:01:37 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) dibblego |
| 2026-06-30 02:01:42 +0000 | <absentia> | accumulating into a list and then V.fromList'ing doesn't seem to yield much improvement either |
| 2026-06-30 02:01:55 +0000 | <absentia> | ok |
| 2026-06-30 02:01:59 +0000 | <monochrom> | Becasue xs ++ [x] is even worse. |
| 2026-06-30 02:02:01 +0000 | <absentia> | well maybe it only took two minutes that time |
| 2026-06-30 02:02:18 +0000 | <absentia> | i mean V.fromList after the final iteration |
| 2026-06-30 02:02:24 +0000 | <absentia> | or recursive call |
| 2026-06-30 02:02:52 +0000 | luke | (~luke@user/luke) (Remote host closed the connection) |
| 2026-06-30 02:03:06 +0000 | luke | (~luke@user/luke) luke |
| 2026-06-30 02:04:31 +0000 | <mauke> | ok, I've watched the stroustrup thing. he's talking about std::vector vs std::list |
| 2026-06-30 02:04:56 +0000 | <mauke> | i.e. a mutable, resizable (dynamic) array vs. a mutable, doubly-linked list |
| 2026-06-30 02:05:10 +0000 | <mauke> | neither of those map to haskell Vector and [] |
| 2026-06-30 02:06:01 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 248 seconds) |
| 2026-06-30 02:06:01 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-06-30 02:06:34 +0000 | <absentia> | well thanks for this then |
| 2026-06-30 02:06:35 +0000 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2026-06-30 02:06:41 +0000 | <absentia> | a list yields non-negligible improvement |
| 2026-06-30 02:07:24 +0000 | Digit | (~user@user/digit) (Ping timeout: 245 seconds) |
| 2026-06-30 02:08:53 +0000 | emilym | (~Thunderbi@user/emilym) emilym |
| 2026-06-30 02:09:14 +0000 | <absentia> | https://arxiv.org/abs/1808.08329 |
| 2026-06-30 02:09:17 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) dibblego |
| 2026-06-30 02:09:22 +0000 | <absentia> | sensational paper headlines considered harmful |
| 2026-06-30 02:10:10 +0000 | <monochrom> | I use lazy lists all the time. But as loops, not data. |
| 2026-06-30 02:10:20 +0000 | <absentia> | [1..] is great sure |
| 2026-06-30 02:10:28 +0000 | <absentia> | i find lazy eval extremely difficult to reason about |
| 2026-06-30 02:10:33 +0000 | <monochrom> | Add line numbers: zip [1..] myLines |
| 2026-06-30 02:10:51 +0000 | <absentia> | in terms of performance |
| 2026-06-30 02:11:22 +0000 | <monochrom> | But everyone agrees that lists are terrible for data, lazy or not, Haskell or C. |
| 2026-06-30 02:12:00 +0000 | <mauke> | I don't! |
| 2026-06-30 02:12:10 +0000 | <monochrom> | The world is not a boolean question like "should you use lists or not". |
| 2026-06-30 02:12:57 +0000 | emilym | (~Thunderbi@user/emilym) (Ping timeout: 248 seconds) |
| 2026-06-30 02:13:08 +0000 | <mauke> | the snoc thing reminds me of Larry Wall's "Doing linear scans over an associatvie array is like clubbing someone to death with a loaded Uzi" |
| 2026-06-30 02:13:21 +0000 | <jreicher> | absentia: I believe the computation time of lazy should be no worse than strict. Only the memory use is a bit unpredictable. |
| 2026-06-30 02:14:29 +0000 | <jreicher> | So if you are seeing worse times, I don't think laziness is the reason. |
| 2026-06-30 02:15:24 +0000 | <absentia> | i should have just profiled this from the very beginning |
| 2026-06-30 02:15:24 +0000 | <mauke> | memory has a time all of its own |
| 2026-06-30 02:15:26 +0000 | <absentia> | and it would have been obvious |
| 2026-06-30 02:15:34 +0000 | <mauke> | particularly if your space leak runs into swap :-( |
| 2026-06-30 02:15:54 +0000 | <jreicher> | mauke: yeah, well, thrashing is completely its own thing. |
| 2026-06-30 02:16:47 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 02:16:52 +0000 | <jreicher> | absentia: why didn't you profile it earlier? Just curious |
| 2026-06-30 02:16:56 +0000 | <monochrom> | Well GC takes time too. And it shows up asymptotically too. If you use linear space, GC time is at least quadratic in total. |
| 2026-06-30 02:17:59 +0000 | <absentia> | jreicher: because i was fed up doing all this other auxiliary work just to get this parser going |
| 2026-06-30 02:18:16 +0000 | <absentia> | i already had to replatform the project on top of debian trixie because bullseye is being EOL'd, all packages out of date |
| 2026-06-30 02:18:19 +0000 | <absentia> | can't update stack resolver |
| 2026-06-30 02:18:29 +0000 | <absentia> | so ok, vacate the VPS, move the platform over, upgrade stack, upgrade libs |
| 2026-06-30 02:18:44 +0000 | <absentia> | then before i can write any code, now i have to set up a profiling harness and benchmark |
| 2026-06-30 02:18:50 +0000 | <absentia> | which probably means installing and setting up hspec |
| 2026-06-30 02:18:54 +0000 | <absentia> | and this just feels like an actual job now |
| 2026-06-30 02:19:02 +0000 | <absentia> | but it's just me being stubborn |
| 2026-06-30 02:19:08 +0000 | <absentia> | i knew from the get-go the first move is always to profile |
| 2026-06-30 02:19:15 +0000 | <absentia> | just wanted to fuck around i guess, idk |
| 2026-06-30 02:19:25 +0000 | <jreicher> | Only if performance is a requirement, and the runtime behaviour is opaque. |
| 2026-06-30 02:19:36 +0000 | <absentia> | based on the old numbers it would have taken 117 hours |
| 2026-06-30 02:19:39 +0000 | <absentia> | not really acceptable |
| 2026-06-30 02:20:00 +0000 | <jreicher> | I wouldn't expect to need a profiler for a simple assembler program, but I would (potentially) for an apparently simple SQL query. (For example) |
| 2026-06-30 02:20:11 +0000 | <monochrom> | I have my share of not even reading the error message. |
| 2026-06-30 02:20:20 +0000 | <jreicher> | Naughty boy |
| 2026-06-30 02:20:25 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 248 seconds) |
| 2026-06-30 02:20:33 +0000 | davidlbowman | (~davidlbow@user/davidlbowman) davidlbowman |
| 2026-06-30 02:20:39 +0000 | <jreicher> | ^boy^person. Very sorry |
| 2026-06-30 02:20:48 +0000 | <monochrom> | No worries. :) |
| 2026-06-30 02:21:36 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2026-06-30 02:26:09 +0000 | finsternis | (~X@23.226.237.192) (Remote host closed the connection) |
| 2026-06-30 02:26:23 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) dibblego |
| 2026-06-30 02:28:22 +0000 | td_ | (~td@i53870922.versanet.de) (Ping timeout: 265 seconds) |
| 2026-06-30 02:29:45 +0000 | td_ | (~td@i53870912.versanet.de) |
| 2026-06-30 02:32:08 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 02:37:25 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2026-06-30 02:47:33 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 02:50:36 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 265 seconds) |
| 2026-06-30 02:51:50 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-06-30 02:56:53 +0000 | dibblego | (~dibblego@157.211.3.209) |
| 2026-06-30 02:56:53 +0000 | dibblego | (~dibblego@157.211.3.209) (Changing host) |
| 2026-06-30 02:56:53 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) dibblego |
| 2026-06-30 03:02:53 +0000 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-06-30 03:07:21 +0000 | merijn | (~merijn@62.45.136.136) (Ping timeout: 245 seconds) |
| 2026-06-30 03:26:45 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 03:30:06 +0000 | ft | (~ft@p3e9bccb7.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2026-06-30 03:33:38 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-06-30 03:41:54 +0000 | ft | (~ft@p3e9bc446.dip0.t-ipconnect.de) ft |
| 2026-06-30 03:44:43 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 03:49:00 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-06-30 04:00:03 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 04:04:29 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-06-30 04:10:04 +0000 | johna321 | (~johna321@c-76-110-10-66.hsd1.fl.comcast.net) |
| 2026-06-30 04:15:27 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 04:19:45 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-06-30 04:28:34 +0000 | machinedgod | (~machinedg@d108-173-95-19.abhsia.telus.net) (Ping timeout: 276 seconds) |
| 2026-06-30 04:46:10 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 04:50:57 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2026-06-30 04:57:24 +0000 | takuan | (~takuan@d8D86B9E9.access.telenet.be) |
| 2026-06-30 04:59:14 +0000 | Axman6 | (~Axman6@user/axman6) Axman6 |
| 2026-06-30 05:01:32 +0000 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-06-30 05:08:27 +0000 | merijn | (~merijn@62.45.136.136) (Ping timeout: 252 seconds) |
| 2026-06-30 05:12:21 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 05:16:59 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2026-06-30 05:27:44 +0000 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-06-30 05:31:59 +0000 | merijn | (~merijn@62.45.136.136) (Ping timeout: 245 seconds) |
| 2026-06-30 05:32:31 +0000 | johna321 | (~johna321@c-76-110-10-66.hsd1.fl.comcast.net) (Ping timeout: 265 seconds) |
| 2026-06-30 05:38:56 +0000 | divlamir | (~divlamir@user/divlamir) (Remote host closed the connection) |
| 2026-06-30 05:39:08 +0000 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2026-06-30 05:43:02 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 05:47:15 +0000 | haritz | (~hrtz@user/haritz) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 2026-06-30 05:47:18 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-06-30 05:54:00 +0000 | marinelli | (~weechat@gateway/tor-sasl/marinelli) (Quit: marinelli) |
| 2026-06-30 06:10:13 +0000 | peterbecich | (~Thunderbi@71.84.33.135) (Quit: peterbecich) |
| 2026-06-30 06:10:44 +0000 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2026-06-30 06:13:18 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 06:15:10 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 245 seconds) |
| 2026-06-30 06:17:40 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-06-30 06:26:47 +0000 | dibblego | (~dibblego@157.211.3.209) |
| 2026-06-30 06:26:47 +0000 | dibblego | (~dibblego@157.211.3.209) (Changing host) |
| 2026-06-30 06:26:47 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) dibblego |
| 2026-06-30 06:28:41 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 06:35:27 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 261 seconds) |
| 2026-06-30 06:39:08 +0000 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2026-06-30 06:44:20 +0000 | czan | (~czan@user/mange) (Quit: Quittin' time!) |
| 2026-06-30 06:46:06 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 06:49:04 +0000 | peterbecich | (~Thunderbi@71.84.33.135) (Ping timeout: 245 seconds) |
| 2026-06-30 06:52:57 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-06-30 06:53:43 +0000 | emmanuelux | (~em@user/emmanuelux) emmanuelux |
| 2026-06-30 07:02:31 +0000 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2026-06-30 07:10:08 +0000 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2026-06-30 07:11:36 +0000 | ft | (~ft@p3e9bc446.dip0.t-ipconnect.de) (Ping timeout: 265 seconds) |
| 2026-06-30 07:13:01 +0000 | ft | (~ft@p3e9bca38.dip0.t-ipconnect.de) ft |
| 2026-06-30 07:14:18 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 07:15:22 +0000 | rainbyte | (~rainbyte@181.47.219.31) (Remote host closed the connection) |
| 2026-06-30 07:15:41 +0000 | rainbyte | (~rainbyte@181.47.219.31) rainbyte |
| 2026-06-30 07:18:43 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2026-06-30 07:20:17 +0000 | michalz | (~michalz@185.246.207.193) |
| 2026-06-30 07:26:01 +0000 | tromp | (~textual@2001:1c00:340e:2700:39b7:4dd7:ef94:da89) |
| 2026-06-30 07:32:47 +0000 | tromp | (~textual@2001:1c00:340e:2700:39b7:4dd7:ef94:da89) (Read error: No route to host) |
| 2026-06-30 07:36:35 +0000 | jaror | (~jaror@user/jaror) (Quit: The Lounge - https://thelounge.chat) |
| 2026-06-30 07:37:00 +0000 | jaror | (~jaror@user/jaror) jaror |
| 2026-06-30 07:38:17 +0000 | schuelermine | (~Thunderbi@user/schuelermine) schuelermine |
| 2026-06-30 07:45:26 +0000 | chele | (~chele@user/chele) chele |
| 2026-06-30 07:51:14 +0000 | schuelermine | (~Thunderbi@user/schuelermine) (Ping timeout: 248 seconds) |
| 2026-06-30 07:51:52 +0000 | schuelermine | (~Thunderbi@user/schuelermine) schuelermine |
| 2026-06-30 07:58:00 +0000 | fp | (~Thunderbi@130.233.70.229) fp |
| 2026-06-30 07:58:42 +0000 | schuelermine | (~Thunderbi@user/schuelermine) (Ping timeout: 256 seconds) |
| 2026-06-30 08:04:57 +0000 | merijn | (~merijn@77.242.116.146) merijn |
| 2026-06-30 08:09:31 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 08:12:44 +0000 | terrorjack | (~terrorjac@2a01:4f8:271:2d98::2) (Quit: The Lounge - https://thelounge.chat) |
| 2026-06-30 08:16:51 +0000 | terrorjack | (~terrorjac@2a01:4f8:271:2d98::2) terrorjack |
| 2026-06-30 08:23:40 +0000 | ft | (~ft@p3e9bca38.dip0.t-ipconnect.de) (Quit: leaving) |
| 2026-06-30 08:34:42 +0000 | CiaoSen | (~Jura@2a02:3100:661d:600:4e50:ddff:fe9b:8922) CiaoSen |
| 2026-06-30 08:36:54 +0000 | merijn | (~merijn@77.242.116.146) (Ping timeout: 252 seconds) |
| 2026-06-30 08:40:52 +0000 | jaror6 | (~jaror@user/jaror) jaror |
| 2026-06-30 08:42:32 +0000 | jaror | (~jaror@user/jaror) (Ping timeout: 262 seconds) |
| 2026-06-30 08:42:32 +0000 | jaror6 | jaror |
| 2026-06-30 08:42:45 +0000 | Ranhir | (~Ranhir@157.97.53.139) (Ping timeout: 272 seconds) |
| 2026-06-30 08:45:34 +0000 | merijn | (~merijn@77.242.116.146) merijn |
| 2026-06-30 08:46:41 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 08:47:22 +0000 | Ranhir | (~Ranhir@157.97.53.139) Ranhir |
| 2026-06-30 08:49:10 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 08:50:37 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 08:53:16 +0000 | merijn | (~merijn@77.242.116.146) (Ping timeout: 244 seconds) |
| 2026-06-30 08:54:08 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 08:55:11 +0000 | CiaoSen | (~Jura@2a02:3100:661d:600:4e50:ddff:fe9b:8922) (Ping timeout: 252 seconds) |
| 2026-06-30 08:57:43 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 08:58:21 +0000 | fp | (~Thunderbi@130.233.70.229) (Ping timeout: 252 seconds) |
| 2026-06-30 09:01:51 +0000 | acidjnk_new | (~acidjnk@p200300d6e74def67cefedba3bc5cab81.dip0.t-ipconnect.de) |
| 2026-06-30 09:02:01 +0000 | acidjnk | (~acidjnk@p200300d6e74def67cefedba3bc5cab81.dip0.t-ipconnect.de) acidjnk |
| 2026-06-30 09:03:01 +0000 | merijn | (~merijn@77.242.116.146) merijn |
| 2026-06-30 09:05:07 +0000 | danza | (~danza@user/danza) danza |
| 2026-06-30 09:08:26 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 09:21:07 +0000 | fp | (~Thunderbi@130.233.70.229) fp |
| 2026-06-30 09:32:17 +0000 | <probie> | monochrom: Are lists always bad for data? A single list is bad, but if you have many (singly-linked) lists and a lot of sharing going on I'm not willing to immediately write it off as "bad" |
| 2026-06-30 09:42:39 +0000 | karenw | (~karenw@user/karenw) karenw |
| 2026-06-30 09:46:03 +0000 | Digit | (~user@user/digit) Digit |
| 2026-06-30 09:46:45 +0000 | merijn | (~merijn@77.242.116.146) (Ping timeout: 265 seconds) |
| 2026-06-30 09:47:19 +0000 | jreicher | (~joelr@user/jreicher) (Killed (manganese.libera.chat (Nickname regained by services))) |
| 2026-06-30 09:47:50 +0000 | jreicher | (~joelr@user/jreicher) jreicher |
| 2026-06-30 09:48:21 +0000 | merijn | (~merijn@77.242.116.146) merijn |
| 2026-06-30 09:52:18 +0000 | Digit | digitteknohippie |
| 2026-06-30 09:52:18 +0000 | digitteknohippie | (~user@user/digit) (Remote host closed the connection) |
| 2026-06-30 09:55:50 +0000 | Digit | (~user@user/digit) Digit |
| 2026-06-30 10:03:30 +0000 | Digit | (~user@user/digit) (Ping timeout: 248 seconds) |
| 2026-06-30 10:04:13 +0000 | fp2 | (~Thunderbi@130.233.70.229) fp |
| 2026-06-30 10:04:26 +0000 | __monty__ | (~toonn@user/toonn) toonn |
| 2026-06-30 10:04:39 +0000 | fp | (~Thunderbi@130.233.70.229) (Read error: Connection reset by peer) |
| 2026-06-30 10:04:39 +0000 | fp2 | fp |
| 2026-06-30 10:08:32 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 10:10:21 +0000 | kuribas | (~user@2a02-1810-2825-6000-bae0-9ec9-ef49-8ccc.ip6.access.telenet.be) |
| 2026-06-30 10:10:53 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 10:12:25 +0000 | Digitteknohippie | (~user@user/digit) Digit |
| 2026-06-30 10:16:48 +0000 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 246 seconds) |
| 2026-06-30 10:16:51 +0000 | Digitteknohippie | Digit |
| 2026-06-30 10:22:36 +0000 | poscat | (~poscat@user/poscat) (Remote host closed the connection) |
| 2026-06-30 10:23:00 +0000 | merijn | (~merijn@77.242.116.146) (Ping timeout: 265 seconds) |
| 2026-06-30 10:25:40 +0000 | poscat | (~poscat@user/poscat) poscat |
| 2026-06-30 10:27:32 +0000 | <tomsmeding> | that sounds like a tree :p |
| 2026-06-30 10:27:47 +0000 | <tomsmeding> | I guess an inverted tree |
| 2026-06-30 10:30:45 +0000 | emmanuelux_ | (~em@168.104.204.77.rev.sfr.net) |
| 2026-06-30 10:31:42 +0000 | emmanuelux | (~em@user/emmanuelux) (Ping timeout: 256 seconds) |
| 2026-06-30 10:31:52 +0000 | <fp> | When one says that some T :: * -> * is Co/Contra/Invariant over a -> b, what is "varying"? I understand that it means you can turn a -> b into T a -> T b or T b -> T a or not, but to me that follows only from the Co/Contra/In, not the variant |
| 2026-06-30 10:36:56 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 10:37:26 +0000 | <fp> | Like I'm familiar with invariance in the sense of like a physical energy system where it's behavior is invariant wrt the total energy of the system, i.e. no energy is lost or destroyed regardless of the evolution of the system. So you can understand the invariance as "the total energy can't vary" |
| 2026-06-30 10:41:08 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Read error: Connection reset by peer) |
| 2026-06-30 10:41:32 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 10:44:12 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 10:45:33 +0000 | <tomsmeding> | fp: I think there are two different notions of co(ntra)variant here: one is that of a co(ntra) variant functor, and the other is that of co(ntra)variance in type systems |
| 2026-06-30 10:46:00 +0000 | <tomsmeding> | a covariant functor has fmap : (a -> b) -> T a -> T b; a contravariant functor has fmap : (a -> b) -> T b -> T a |
| 2026-06-30 10:46:17 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 10:46:49 +0000 | <tomsmeding> | co(ntra)variance in type systems relates to subtyping, where the idea is that a subtype A' of A is to be accepted wherever A is |
| 2026-06-30 10:47:20 +0000 | <tomsmeding> | but then if you think about it, B -> A' should be a subtype of B -> A, but A -> B should be a subtype of A' -> B |
| 2026-06-30 10:47:29 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 10:47:45 +0000 | <tomsmeding> | because whenever B -> A works, getting a more precise A out (i.e. an A') would be acceptable |
| 2026-06-30 10:48:25 +0000 | <tomsmeding> | but if you're expecting a function A' -> B, then a function A -> B also works, as passing an A' to that is fine by subtyping |
| 2026-06-30 10:49:23 +0000 | <fp> | Mm I see |
| 2026-06-30 10:49:25 +0000 | <tomsmeding> | hence 'a -> b' is said to be covariant in b (because b' <= b ==> a -> b' <= a -> b), and contravariant in a (because a' <= a ==> a -> b <= a' -> b) |
| 2026-06-30 10:49:52 +0000 | <tomsmeding> | with the type systems one, the thing that varies is the specificity along the subtyping relation ("making something more 'sub'") |
| 2026-06-30 10:50:16 +0000 | <tomsmeding> | with the category theory one, the thing that "varies" is the direction of movement along the arrow, I guess? I'm not a category theorist |
| 2026-06-30 10:50:45 +0000 | <fp> | Ok interesting thank you |
| 2026-06-30 10:51:40 +0000 | <fp> | I'v fallen down a bit of a rabbit hole of people talking about wacky algebras and type-level programming, and stuff like this comes up |
| 2026-06-30 10:52:12 +0000 | <tomsmeding> | you can see the subtyping version in Haskell too, even though Haskell does not, by the usual terminology, have subtyping: polymorphism has similar behaviour |
| 2026-06-30 10:52:34 +0000 | merijn | (~merijn@77.242.116.146) merijn |
| 2026-06-30 10:53:00 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 10:53:21 +0000 | <tomsmeding> | Int <= (forall a. Num a => a) [here '<=' is "more specific"], hence (Bool -> Int) <= (Bool -> forall a. Num a => a) = (forall a. Num a => Bool -> a) |
| 2026-06-30 10:53:49 +0000 | <tomsmeding> | but ((forall a. Num a => a) -> Bool) <= (Int -> Bool) |
| 2026-06-30 10:54:51 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 10:55:12 +0000 | <tomsmeding> | there are fewer Ints than "arbitrary Num values", but if you have to _take_ an arbitrary Num value, there's less you can do than if you know you're getting an Int |
| 2026-06-30 10:57:19 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 10:57:48 +0000 | merijn | (~merijn@77.242.116.146) (Ping timeout: 265 seconds) |
| 2026-06-30 10:59:24 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 11:00:25 +0000 | merijn | (~merijn@77.242.116.146) merijn |
| 2026-06-30 11:02:17 +0000 | fun-safe-math | (~fun-safe-@97-120-35-225.ptld.qwest.net) () |
| 2026-06-30 11:02:45 +0000 | <fp> | does `forall a. Num a` mean that a single monomorphization of a function will polymorphically accept any Num a => a ? |
| 2026-06-30 11:04:05 +0000 | tremon | (~tremon@83-80-159-219.cable.dynamic.v4.ziggo.nl) tremon |
| 2026-06-30 11:04:12 +0000 | fun-safe-math | (~fun-safe-@97-120-35-225.ptld.qwest.net) fun-safe-math |
| 2026-06-30 11:06:39 +0000 | <tomsmeding> | fp: "a function" -- which function? It matters on which side the forall stands :) |
| 2026-06-30 11:07:51 +0000 | <fp> | Mm, then could it be `f :: forall a. Num a => a -> Bool` is what I said and `g:: forall a. Num a => Bool -> a` is type erasure? |
| 2026-06-30 11:08:26 +0000 | <tomsmeding> | those two functions are just the other way round, I'm not sure where type erasure comes in |
| 2026-06-30 11:09:07 +0000 | <tomsmeding> | I'm not sure where your thoughts are / where you're stuck (if you are), but in case you're not familiar with that view, you can see "forall" as just another argument |
| 2026-06-30 11:09:27 +0000 | <fp> | I guess in my head, forall is a thing that creates dynamic dispatch on the backend |
| 2026-06-30 11:09:32 +0000 | <tomsmeding> | f :: forall a. Num a => Bool -> a takes 3 arguments: a type 'a', a dictionary 'Num a', and a 'Bool' |
| 2026-06-30 11:10:03 +0000 | <tomsmeding> | as such (f1 :: forall a. Num a => a -> Bool) and (f2 :: (forall a. Num a => a) -> Bool) are very different: f1 takes 3 arguments, f2 takes 1 |
| 2026-06-30 11:10:43 +0000 | <fp> | You know, there's probably a manual page I should read about this |
| 2026-06-30 11:10:43 +0000 | <tomsmeding> | on the other hand, (g1 :: forall a. Num a => Bool -> a) and (g2 :: Bool -> (forall a. Num a => a)) are the same up to argument ordering: they both take 3 arguments, just in a different order |
| 2026-06-30 11:11:26 +0000 | <tomsmeding> | now, when you actually want to execute this stuff and be fast-ish, you indeed start thinking about dynamic dispatch and polymorphic code and stuff |
| 2026-06-30 11:11:51 +0000 | <tomsmeding> | but when thinking about meaning and behaviour in the type system, I think this perspective is much more precise |
| 2026-06-30 11:17:58 +0000 | <tomsmeding> | fp: re manual, I don't think the GHC manual explains any of this since it generally assumes you know the underlying theory |
| 2026-06-30 11:18:11 +0000 | xff0x | (~xff0x@2405:6580:b080:900:f8e0:a6ee:fc93:d765) |
| 2026-06-30 11:18:33 +0000 | <tomsmeding> | there may well be resources that explain this in more detail for haskell specifically, but I don't know them |
| 2026-06-30 11:19:21 +0000 | <tomsmeding> | oh I guess this is just system F |
| 2026-06-30 11:19:25 +0000 | <tomsmeding> | https://en.wikipedia.org/wiki/System_F |
| 2026-06-30 11:20:07 +0000 | <tomsmeding> | both simply typed lambda calculus and dependently-typed calculi (type theory) have much theory and literature devoted to them; system F and Haskell are a bit in the middle |
| 2026-06-30 11:20:40 +0000 | <tomsmeding> | and the terminology when you read about this stuff tends to assume some knowledge about basic type theory |
| 2026-06-30 11:21:02 +0000 | <fp> | Interesting, I'll have to read |
| 2026-06-30 11:39:19 +0000 | <gentauro> | tomsmeding: -> https://sdiehl.github.io/typechecker-zoo/system-f-omega/system-f-omega.html ;) |
| 2026-06-30 11:39:55 +0000 | <tomsmeding> | > System Fω stands as one of the most type systems in the theoretical foundations of programming languages |
| 2026-06-30 11:40:15 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 11:40:51 +0000 | <tomsmeding> | now I want to know the most _what_ type system System Fω is lol |
| 2026-06-30 11:42:34 +0000 | <tomsmeding> | fp: ^ another resource |
| 2026-06-30 11:42:57 +0000 | <tomsmeding> | depending on how deep you want to dive into this :p |
| 2026-06-30 11:43:25 +0000 | weary-traveler | (~user@user/user363627) user363627 |
| 2026-06-30 11:44:09 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 11:55:01 +0000 | lynxx_ | (~lynxx_@2001:9e8:3bcd:2200:997c:8365:c7f6:f178) |
| 2026-06-30 11:55:35 +0000 | fgarcia | (~lei@user/fgarcia) (Ping timeout: 252 seconds) |
| 2026-06-30 11:57:45 +0000 | fgarcia | (~lei@user/fgarcia) fgarcia |
| 2026-06-30 12:08:06 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 12:08:49 +0000 | <jreicher> | Coincidentally I've just been looking at his Prism language today. |
| 2026-06-30 12:10:56 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 12:13:25 +0000 | <__monty__> | tomsmeding: Just read, system Fω is the most type. |
| 2026-06-30 12:14:37 +0000 | danza | (~danza@user/danza) (Read error: Connection reset by peer) |
| 2026-06-30 12:14:40 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 12:19:31 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 264 seconds) |
| 2026-06-30 12:24:51 +0000 | haritz | (~hrtz@140.228.70.141) |
| 2026-06-30 12:24:52 +0000 | haritz | (~hrtz@140.228.70.141) (Changing host) |
| 2026-06-30 12:24:52 +0000 | haritz | (~hrtz@user/haritz) haritz |
| 2026-06-30 12:28:27 +0000 | potatoes_ | (~quassel@130.44.145.181) (Ping timeout: 252 seconds) |
| 2026-06-30 12:34:17 +0000 | lynxx_ | (~lynxx_@2001:9e8:3bcd:2200:997c:8365:c7f6:f178) (Ping timeout: 248 seconds) |
| 2026-06-30 12:34:36 +0000 | lynxx | (~lynxx_@2001:9e8:3bcd:2200:997c:8365:c7f6:f178) |
| 2026-06-30 12:55:04 +0000 | Alex_delenda_est | (~al_test@178.34.151.183) (Quit: ;-) |
| 2026-06-30 12:55:33 +0000 | AlexZenon | (~alzenon@178.34.151.183) (Quit: ;-) |
| 2026-06-30 12:55:35 +0000 | lynxx | (~lynxx_@2001:9e8:3bcd:2200:997c:8365:c7f6:f178) (Quit: lynxx) |
| 2026-06-30 12:55:48 +0000 | AlexNoo | (~AlexNoo@178.34.151.183) (Quit: Leaving) |
| 2026-06-30 12:56:03 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 13:00:36 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 246 seconds) |
| 2026-06-30 13:04:19 +0000 | lynxx | (~lynxx@i59F6675C.versanet.de) |
| 2026-06-30 13:06:56 +0000 | AlexNoo | (~AlexNoo@178.34.151.183) |
| 2026-06-30 13:11:14 +0000 | AlexNoo | (~AlexNoo@178.34.151.183) (Ping timeout: 248 seconds) |
| 2026-06-30 13:11:56 +0000 | AlexNoo | (~AlexNoo@178.34.151.183) |
| 2026-06-30 13:12:56 +0000 | AlexNoo_ | (~AlexNoo@178.34.151.183) |
| 2026-06-30 13:13:01 +0000 | AlexZenon | (~alzenon@178.34.151.183) |
| 2026-06-30 13:13:40 +0000 | AlexNoo__ | (~AlexNoo@178.34.151.183) |
| 2026-06-30 13:13:54 +0000 | lynxx6 | (~lynxx@i59F6675C.versanet.de) |
| 2026-06-30 13:15:52 +0000 | <tomsmeding> | __monty__: clearly! |
| 2026-06-30 13:16:34 +0000 | AlexNoo | (~AlexNoo@178.34.151.183) (Ping timeout: 248 seconds) |
| 2026-06-30 13:16:34 +0000 | lynxx | (~lynxx@i59F6675C.versanet.de) (Ping timeout: 248 seconds) |
| 2026-06-30 13:16:34 +0000 | lynxx6 | lynxx |
| 2026-06-30 13:17:06 +0000 | AlexNoo_ | (~AlexNoo@178.34.151.183) (Ping timeout: 248 seconds) |
| 2026-06-30 13:18:10 +0000 | AlexNoo__ | (~AlexNoo@178.34.151.183) (Ping timeout: 248 seconds) |
| 2026-06-30 13:19:45 +0000 | lynxx | lynxx_ |
| 2026-06-30 13:21:07 +0000 | Alex_delenda_est | (~al_test@178.34.151.183) |
| 2026-06-30 13:25:37 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 13:26:39 +0000 | lynxx_ | (~lynxx@i59F6675C.versanet.de) (Quit: The Lounge - https://thelounge.chat) |
| 2026-06-30 13:26:53 +0000 | lynxx_ | (~lynxx@i59F6675C.versanet.de) |
| 2026-06-30 13:28:45 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 13:32:03 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 13:34:01 +0000 | merijn | (~merijn@77.242.116.146) (Ping timeout: 268 seconds) |
| 2026-06-30 13:36:27 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Read error: Connection reset by peer) |
| 2026-06-30 13:38:21 +0000 | xff0x | (~xff0x@2405:6580:b080:900:f8e0:a6ee:fc93:d765) (Remote host closed the connection) |
| 2026-06-30 13:39:00 +0000 | xff0x | (~xff0x@2405:6580:b080:900:c0c7:fc31:efb5:5c54) |
| 2026-06-30 13:45:00 +0000 | merijn | (~merijn@77.242.116.146) merijn |
| 2026-06-30 13:55:56 +0000 | lynxx_ | (~lynxx@i59F6675C.versanet.de) (Quit: The Lounge - https://thelounge.chat) |
| 2026-06-30 14:04:14 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 14:07:42 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 14:09:32 +0000 | lynxx_ | (~lynxx@i59F6675C.versanet.de) |
| 2026-06-30 14:10:50 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 14:28:28 +0000 | machinedgod | (~machinedg@d108-173-95-19.abhsia.telus.net) machinedgod |
| 2026-06-30 14:33:14 +0000 | fp | (~Thunderbi@130.233.70.229) (Ping timeout: 245 seconds) |
| 2026-06-30 14:35:35 +0000 | lynxx_ | (~lynxx@i59F6675C.versanet.de) (Remote host closed the connection) |
| 2026-06-30 14:36:38 +0000 | lynxx_ | (~lynxx@i59F6675C.versanet.de) |
| 2026-06-30 14:37:04 +0000 | lynxx_ | (~lynxx@i59F6675C.versanet.de) (Remote host closed the connection) |
| 2026-06-30 14:38:45 +0000 | lynxx_ | (~lynxx@i59F6675C.versanet.de) |
| 2026-06-30 14:48:33 +0000 | s00pcan | (~s00pcan@71.214.104.207) (Remote host closed the connection) |
| 2026-06-30 14:52:57 +0000 | s00pcan | (~s00pcan@71.214.104.207) s00pcan |
| 2026-06-30 14:53:01 +0000 | davidlbowman | (~davidlbow@user/davidlbowman) (Quit: WeeChat 4.9.1) |
| 2026-06-30 14:56:46 +0000 | davidlbowman | (~davidlbow@user/davidlbowman) davidlbowman |
| 2026-06-30 15:11:11 +0000 | davidlbowman | (~davidlbow@user/davidlbowman) (Quit: WeeChat 4.9.1) |
| 2026-06-30 15:11:48 +0000 | davidlbowman | (~davidlbow@user/davidlbowman) davidlbowman |
| 2026-06-30 15:16:30 +0000 | Googulator | (~Googulato@80-95-87-76.pool.digikabel.hu) (Quit: Client closed) |
| 2026-06-30 15:16:43 +0000 | Googulator | (~Googulato@80-95-87-76.pool.digikabel.hu) |
| 2026-06-30 15:18:34 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) (Ping timeout: 276 seconds) |
| 2026-06-30 15:19:15 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2026-06-30 15:27:41 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) (Read error: Connection reset by peer) |
| 2026-06-30 15:28:07 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2026-06-30 15:39:55 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) (Ping timeout: 264 seconds) |
| 2026-06-30 15:45:22 +0000 | s00pcan | (~s00pcan@71.214.104.207) (Remote host closed the connection) |
| 2026-06-30 15:50:45 +0000 | s00pcan | (~s00pcan@71.214.104.207) s00pcan |
| 2026-06-30 15:58:09 +0000 | m | (~travltux@user/travltux) (Quit: WeeChat 4.7.2) |
| 2026-06-30 15:59:50 +0000 | xintron | (~xintron@user/xintron) (Quit: Lurker 1.0.5 (the truth is out there) https://lurker.chat) |
| 2026-06-30 16:00:06 +0000 | xintron | (~xintron@user/xintron) xintron |
| 2026-06-30 16:01:10 +0000 | mvk | (~mvk@2607:fea8:5c9d:ee00::f8a8) mvk |
| 2026-06-30 16:01:21 +0000 | mvk | (~mvk@2607:fea8:5c9d:ee00::f8a8) (Client Quit) |
| 2026-06-30 16:04:26 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2026-06-30 16:04:51 +0000 | mangoiv | (~mangoiv@static.148.35.181.135.clients.your-server.de) (Changing host) |
| 2026-06-30 16:04:51 +0000 | mangoiv | (~mangoiv@user/mangoiv) mangoiv |
| 2026-06-30 16:10:44 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) (Ping timeout: 245 seconds) |
| 2026-06-30 16:11:05 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2026-06-30 16:14:23 +0000 | gmg | (~user@user/gehmehgeh) (Ping timeout: 252 seconds) |
| 2026-06-30 16:14:45 +0000 | tusko | (~uwu@user/tusko) (Ping timeout: 252 seconds) |
| 2026-06-30 16:14:55 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) (Read error: Connection reset by peer) |
| 2026-06-30 16:15:07 +0000 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Ping timeout: 252 seconds) |
| 2026-06-30 16:15:07 +0000 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 252 seconds) |
| 2026-06-30 16:15:07 +0000 | chexum | (~quassel@gateway/tor-sasl/chexum) (Ping timeout: 252 seconds) |
| 2026-06-30 16:15:20 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2026-06-30 16:17:13 +0000 | s00pcan | (~s00pcan@71.214.104.207) (Remote host closed the connection) |
| 2026-06-30 16:23:00 +0000 | s00pcan | (~s00pcan@71.214.104.207) s00pcan |
| 2026-06-30 16:27:09 +0000 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
| 2026-06-30 16:27:38 +0000 | chexum | (~quassel@gateway/tor-sasl/chexum) chexum |
| 2026-06-30 16:29:33 +0000 | tusko | (~uwu@user/tusko) tusko |
| 2026-06-30 16:29:54 +0000 | merijn | (~merijn@77.242.116.146) (Ping timeout: 252 seconds) |
| 2026-06-30 16:31:21 +0000 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2026-06-30 16:33:05 +0000 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Client Quit) |
| 2026-06-30 16:33:20 +0000 | Guest64 | (~Guest64@dyn-157-190.public.tut.fi) |
| 2026-06-30 16:35:04 +0000 | gabiruh | (~gabiruh@vps19177.publiccloud.com.br) gabiruh |
| 2026-06-30 16:35:40 +0000 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2026-06-30 16:35:50 +0000 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2026-06-30 16:36:09 +0000 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2026-06-30 16:36:28 +0000 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
| 2026-06-30 16:42:15 +0000 | s00pcan | (~s00pcan@71.214.104.207) (Remote host closed the connection) |
| 2026-06-30 16:47:37 +0000 | s00pcan | (~s00pcan@71.214.104.207) s00pcan |
| 2026-06-30 16:51:01 +0000 | divlamir | (~divlamir@user/divlamir) divlamir |
| 2026-06-30 16:54:28 +0000 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) lisbeths |
| 2026-06-30 17:08:00 +0000 | gentauro | #haskell on libera is the most irc |
| 2026-06-30 17:08:15 +0000 | <absentia> | irc is dead |
| 2026-06-30 17:09:47 +0000 | polykernel_ | (~polykerne@user/polykernel) polykernel |
| 2026-06-30 17:10:44 +0000 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2026-06-30 17:12:48 +0000 | califax | (~califax@user/califx) califx |
| 2026-06-30 17:12:52 +0000 | polykernel | (~polykerne@user/polykernel) (Ping timeout: 265 seconds) |
| 2026-06-30 17:12:53 +0000 | polykernel_ | polykernel |
| 2026-06-30 17:13:02 +0000 | Guest64 | (~Guest64@dyn-157-190.public.tut.fi) (Quit: Client closed) |
| 2026-06-30 17:13:39 +0000 | <EvanR> | of all the irc it's one of them |
| 2026-06-30 17:21:59 +0000 | gabiruh | (~gabiruh@vps19177.publiccloud.com.br) (Read error: Connection reset by peer) |
| 2026-06-30 17:22:15 +0000 | gabiruh | (~gabiruh@vps19177.publiccloud.com.br) gabiruh |
| 2026-06-30 17:22:21 +0000 | ephapticpulse | (~user@user/ephapticpulse) ephapticpulse |
| 2026-06-30 17:25:38 +0000 | davidlbowman | (~davidlbow@user/davidlbowman) (Quit: WeeChat 4.9.1) |
| 2026-06-30 17:25:59 +0000 | davidlbowman | (~davidlbow@user/davidlbowman) davidlbowman |
| 2026-06-30 17:27:47 +0000 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 2026-06-30 17:30:42 +0000 | <monochrom> | probie: Yeah OK every principle has exceptions! |
| 2026-06-30 17:33:15 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 17:35:53 +0000 | ft | (~ft@p3e9bca38.dip0.t-ipconnect.de) ft |
| 2026-06-30 17:37:49 +0000 | <monochrom> | There are a ton of "___ is dead" statements that are true but irrelevant. |
| 2026-06-30 17:38:06 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-06-30 17:38:29 +0000 | <monochrom> | Like, Latin is dead, sure. Has never stopped people from coining new names and slogans from it. |
| 2026-06-30 17:39:28 +0000 | <monochrom> | Example: https://en.wikipedia.org/wiki/Lucent_Technologies#Name |
| 2026-06-30 17:41:28 +0000 | <tomsmeding> | also those statements are generally very relative |
| 2026-06-30 17:41:44 +0000 | <tomsmeding> | IRC is dead except it isn't, look at this channel |
| 2026-06-30 17:42:01 +0000 | <monochrom> | gentauro: Thanks for the typecheck zoo link! I will find it super useful too. |
| 2026-06-30 17:42:11 +0000 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2026-06-30 17:42:19 +0000 | <tomsmeding> | Latin is dead except there are small pockets of people still learning and speaking it https://en.wikipedia.org/wiki/Accademia_Vivarium_Novum |
| 2026-06-30 17:43:02 +0000 | <monochrom> | Haha "Type classes are the answer to a question that ordinary Hindley-Milner cannot phrase." Reminds me of "a solution looking for a problem" and "this paper/book fills a much-needed gap". >:) |
| 2026-06-30 17:43:30 +0000 | <tomsmeding> | "a much-needed gap" lol |
| 2026-06-30 17:43:58 +0000 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2026-06-30 17:44:17 +0000 | <monochrom> | Very handy next time someone makes you peer-review something and it's really bad but you want to be polite. >:) |
| 2026-06-30 17:44:53 +0000 | <tomsmeding> | I'm not sure that's particularly polite :p |
| 2026-06-30 17:46:05 +0000 | <monochrom> | Wait why is their code written in Rust?!! This hurts my eyes... |
| 2026-06-30 17:47:35 +0000 | <monochrom> | I like Rust too. But if your code is full of Box::new, just go back to Haskell or Java... |
| 2026-06-30 17:48:39 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 17:49:30 +0000 | polykernel_ | (~polykerne@user/polykernel) polykernel |
| 2026-06-30 17:50:35 +0000 | <EvanR> | I had no idea people outside haskell loved boxing so much |
| 2026-06-30 17:50:52 +0000 | <EvanR> | unboxed or bust |
| 2026-06-30 17:51:01 +0000 | <monochrom> | :) |
| 2026-06-30 17:51:19 +0000 | polykernel | (~polykerne@user/polykernel) (Ping timeout: 276 seconds) |
| 2026-06-30 17:51:19 +0000 | polykernel_ | polykernel |
| 2026-06-30 17:53:26 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 266 seconds) |
| 2026-06-30 17:55:59 +0000 | <gentauro> | monochrom: yeah. I'm glad Stephen Diehl returned to write nice stuff instead of "blob chain is bad, bla, bla, bla, …" (I guess the irony is that he now works for quantitative trading firm) :| |
| 2026-06-30 17:56:18 +0000 | <monochrom> | hahaha |
| 2026-06-30 17:56:27 +0000 | <monochrom> | "if you can't beat them, join them" |
| 2026-06-30 17:56:58 +0000 | <gentauro> | monochrom: in Denmark we have a saying: "Moral s good, double moral is twice as good" xD |
| 2026-06-30 17:57:05 +0000 | <monochrom> | hahaha |
| 2026-06-30 17:57:47 +0000 | sp1ff | (~user@2601:1c2:4080:14c0:5df2:f2f4:8a07:70ec) (Remote host closed the connection) |
| 2026-06-30 18:04:02 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 18:08:43 +0000 | polykernel_ | (~polykerne@user/polykernel) polykernel |
| 2026-06-30 18:08:43 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-06-30 18:10:02 +0000 | <absentia> | is using `for` to traverse through a vector also slow? :/ |
| 2026-06-30 18:10:19 +0000 | polykernel | (~polykerne@user/polykernel) (Ping timeout: 245 seconds) |
| 2026-06-30 18:10:19 +0000 | polykernel_ | polykernel |
| 2026-06-30 18:11:50 +0000 | ephapticpulse | (~user@user/ephapticpulse) (ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.3)) |
| 2026-06-30 18:11:59 +0000 | enzo | (~enzo@re-byods-146-50-208-227.wireless.uva.nl) |
| 2026-06-30 18:12:05 +0000 | <monochrom> | That is not very meaningful in isolation. |
| 2026-06-30 18:13:20 +0000 | enzo | (~enzo@re-byods-146-50-208-227.wireless.uva.nl) (Client Quit) |
| 2026-06-30 18:13:31 +0000 | enzo | (~enzo@re-byods-146-50-208-227.wireless.uva.nl) |
| 2026-06-30 18:13:53 +0000 | enzo | (~enzo@re-byods-146-50-208-227.wireless.uva.nl) (Client Quit) |
| 2026-06-30 18:14:03 +0000 | emilym | (~Thunderbi@user/emilym) emilym |
| 2026-06-30 18:14:04 +0000 | enzo | (~enzo@re-byods-146-50-208-227.wireless.uva.nl) |
| 2026-06-30 18:14:49 +0000 | enzo | (~enzo@re-byods-146-50-208-227.wireless.uva.nl) (Client Quit) |
| 2026-06-30 18:15:00 +0000 | enzo | (~enzo@re-byods-146-50-208-227.wireless.uva.nl) |
| 2026-06-30 18:15:27 +0000 | enzo | (~enzo@re-byods-146-50-208-227.wireless.uva.nl) (Client Quit) |
| 2026-06-30 18:15:38 +0000 | enzo | (~enzo@re-byods-146-50-208-227.wireless.uva.nl) |
| 2026-06-30 18:16:00 +0000 | enzo | (~enzo@re-byods-146-50-208-227.wireless.uva.nl) (Client Quit) |
| 2026-06-30 18:16:07 +0000 | tusko | (~uwu@user/tusko) (Ping timeout: 252 seconds) |
| 2026-06-30 18:16:11 +0000 | enzo | (~enzo@re-byods-146-50-208-227.wireless.uva.nl) |
| 2026-06-30 18:16:16 +0000 | kuribas | (~user@2a02-1810-2825-6000-bae0-9ec9-ef49-8ccc.ip6.access.telenet.be) (Remote host closed the connection) |
| 2026-06-30 18:16:52 +0000 | tusko | (~uwu@user/tusko) tusko |
| 2026-06-30 18:16:57 +0000 | dtman34 | (~dtman34@2601:447:d17d:eaf2:8123:c1ff:6dae:d26b) (Ping timeout: 244 seconds) |
| 2026-06-30 18:18:50 +0000 | enzo | (~enzo@re-byods-146-50-208-227.wireless.uva.nl) (Client Quit) |
| 2026-06-30 18:19:16 +0000 | emilym | (~Thunderbi@user/emilym) (Ping timeout: 276 seconds) |
| 2026-06-30 18:19:33 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 18:20:13 +0000 | ezno__ | (~enzo@re-byods-146-50-208-227.wireless.uva.nl) |
| 2026-06-30 18:21:01 +0000 | ezno__ | enzo |
| 2026-06-30 18:21:05 +0000 | enzo | ezno__ |
| 2026-06-30 18:21:14 +0000 | ezno__ | enzo_ |
| 2026-06-30 18:21:18 +0000 | enzo_ | ezno |
| 2026-06-30 18:21:20 +0000 | ezno | enzo_ |
| 2026-06-30 18:22:34 +0000 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2026-06-30 18:23:19 +0000 | <Leary> | absentia: Maybe; compare against `forM`. |
| 2026-06-30 18:24:24 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2026-06-30 18:26:23 +0000 | <Leary> | Err, 'vector's native `forM`s that is, not `Data.Traversable.forM`. |
| 2026-06-30 18:27:50 +0000 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-06-30 18:31:59 +0000 | merijn | (~merijn@62.45.136.136) (Ping timeout: 245 seconds) |
| 2026-06-30 18:32:27 +0000 | ft | (~ft@p3e9bca38.dip0.t-ipconnect.de) (Ping timeout: 244 seconds) |
| 2026-06-30 18:34:49 +0000 | ft | (~ft@p3e9bca53.dip0.t-ipconnect.de) ft |
| 2026-06-30 18:35:25 +0000 | dtman34 | (~dtman34@2601:447:d17d:eaf2:8123:c1ff:6dae:d26b) dtman34 |
| 2026-06-30 18:39:08 +0000 | enzo_ | (~enzo@re-byods-146-50-208-227.wireless.uva.nl) (Quit: Konversation terminated!) |
| 2026-06-30 18:39:09 +0000 | ft | (~ft@p3e9bca53.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2026-06-30 18:39:17 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 18:39:22 +0000 | enzo_ | (~enzo@re-byods-146-50-208-227.wireless.uva.nl) |
| 2026-06-30 18:39:31 +0000 | enzo_ | (~enzo@re-byods-146-50-208-227.wireless.uva.nl) (Client Quit) |
| 2026-06-30 18:39:44 +0000 | enzo_ | (~enzo@re-byods-146-50-208-227.wireless.uva.nl) |
| 2026-06-30 18:40:39 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 18:41:33 +0000 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2026-06-30 18:42:52 +0000 | dtman34 | (~dtman34@2601:447:d17d:eaf2:8123:c1ff:6dae:d26b) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 2026-06-30 18:43:07 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 18:43:19 +0000 | dtman34 | (~dtman34@c-73-242-68-179.hsd1.mn.comcast.net) dtman34 |
| 2026-06-30 18:43:50 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 18:44:52 +0000 | enzo_ | (~enzo@re-byods-146-50-208-227.wireless.uva.nl) (Quit: Konversation terminated!) |
| 2026-06-30 18:45:06 +0000 | enzo_ | (~enzo@re-byods-146-50-208-227.wireless.uva.nl) |
| 2026-06-30 18:47:26 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2026-06-30 18:49:55 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 18:50:17 +0000 | ft | (~ft@p3e9bc928.dip0.t-ipconnect.de) ft |
| 2026-06-30 18:54:27 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 18:55:15 +0000 | enzo_ | (~enzo@re-byods-146-50-208-227.wireless.uva.nl) (Quit: Konversation terminated!) |
| 2026-06-30 18:55:49 +0000 | ft | (~ft@p3e9bc928.dip0.t-ipconnect.de) (Ping timeout: 265 seconds) |
| 2026-06-30 18:56:46 +0000 | ft | (~ft@p3e9bc956.dip0.t-ipconnect.de) ft |
| 2026-06-30 18:58:06 +0000 | <absentia> | Leary: i don't have a monad instance though |
| 2026-06-30 18:58:08 +0000 | <absentia> | merely applicative |
| 2026-06-30 18:58:26 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 19:01:38 +0000 | <EvanR> | traverse :: Applicative f => (a -> f b) -> Vector a -> f (Vector b) |
| 2026-06-30 19:02:10 +0000 | ft | (~ft@p3e9bc956.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2026-06-30 19:02:38 +0000 | weary-traveler | (~user@user/user363627) user363627 |
| 2026-06-30 19:03:05 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-06-30 19:10:15 +0000 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2026-06-30 19:12:35 +0000 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2026-06-30 19:13:49 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 19:18:14 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-06-30 19:18:33 +0000 | polykernel_ | (~polykerne@user/polykernel) polykernel |
| 2026-06-30 19:20:22 +0000 | polykernel | (~polykerne@user/polykernel) (Ping timeout: 276 seconds) |
| 2026-06-30 19:20:22 +0000 | polykernel_ | polykernel |
| 2026-06-30 19:21:43 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 19:22:05 +0000 | <absentia> | yes EvanR i am giving that a shot now |
| 2026-06-30 19:22:22 +0000 | <absentia> | but uhhh the implementation of traverse in Data.Vector gives me pause |
| 2026-06-30 19:22:24 +0000 | <absentia> | https://hackage-content.haskell.org/package/vector-0.13.2.0/docs/src/Data.Vector.html#line-455 |
| 2026-06-30 19:22:33 +0000 | <absentia> | > in Data.Vector.fromListN n Applicative.<$> Traversable.traverse f (toList xs) |
| 2026-06-30 19:22:34 +0000 | <lambdabot> | <hint>:1:1: error: parse error on input `in' |
| 2026-06-30 19:22:43 +0000 | <absentia> | "fromListN," "toList" |
| 2026-06-30 19:23:29 +0000 | <jaror> | Yeah, traversing over vectors is slow unless you use IO or ST |
| 2026-06-30 19:23:38 +0000 | m | (~travltux@user/travltux) travltux |
| 2026-06-30 19:24:02 +0000 | <jaror> | Think about what it would mean to construct a vector in the list monad |
| 2026-06-30 19:24:28 +0000 | <jaror> | hint: you could end up needing to make an arbitrary number of vectors |
| 2026-06-30 19:24:39 +0000 | <absentia> | sigh... what collection should i use for plain traversal then |
| 2026-06-30 19:24:59 +0000 | <absentia> | like this can't be an obscure use case..... execute some request (DB, REST, whatever) for every element in a collection |
| 2026-06-30 19:25:00 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 19:25:11 +0000 | <jaror> | That sounds like IO |
| 2026-06-30 19:25:24 +0000 | <absentia> | ok but where do i store the data |
| 2026-06-30 19:25:27 +0000 | <absentia> | like the tuples |
| 2026-06-30 19:25:38 +0000 | <jaror> | I mean traversing over a vector with IO is fine |
| 2026-06-30 19:25:47 +0000 | <absentia> | how does that work |
| 2026-06-30 19:25:49 +0000 | <absentia> | V.!? |
| 2026-06-30 19:25:50 +0000 | <jaror> | There's a special rewrite rule for that |
| 2026-06-30 19:26:02 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 19:26:02 +0000 | <absentia> | what |
| 2026-06-30 19:26:29 +0000 | <jaror> | Like Data.Vector.mapM |
| 2026-06-30 19:26:34 +0000 | <absentia> | i don't have a monad |
| 2026-06-30 19:26:36 +0000 | <absentia> | only an applicative |
| 2026-06-30 19:27:37 +0000 | <jaror> | ah |
| 2026-06-30 19:28:40 +0000 | <absentia> | it's very unusual to me |
| 2026-06-30 19:28:42 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 19:28:51 +0000 | <absentia> | that something utterly trivial is utterly non-performant |
| 2026-06-30 19:28:58 +0000 | <absentia> | unless you go through all these weird contortions in haskell |
| 2026-06-30 19:29:17 +0000 | <absentia> | rather disturbing actually |
| 2026-06-30 19:29:19 +0000 | <tomsmeding> | absentia: what implementation would you want? |
| 2026-06-30 19:29:29 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 19:29:38 +0000 | <absentia> | tomsmeding: literally anything that just lets me execute an action for about 5000 elements in a collection |
| 2026-06-30 19:29:53 +0000 | <absentia> | without spending 30 minutes in allocation or something else silly like that |
| 2026-06-30 19:30:07 +0000 | peterbecich | (~Thunderbi@71.84.33.135) (Ping timeout: 276 seconds) |
| 2026-06-30 19:30:12 +0000 | <absentia> | like... attoparsec can crunch 150,000 lines, 10MB a second |
| 2026-06-30 19:30:20 +0000 | <tomsmeding> | for 5000 elements even a linked list wouldn't take more than 1ms |
| 2026-06-30 19:30:22 +0000 | <jaror> | But your action is pretty special, what kind of applicative do you have |
| 2026-06-30 19:30:27 +0000 | <absentia> | it's Hasql.Pipeline |
| 2026-06-30 19:30:35 +0000 | <absentia> | https://hackage-content.haskell.org/package/hasql-1.10.3.5/docs/Hasql-Pipeline.html |
| 2026-06-30 19:30:58 +0000 | <absentia> | ns <- Pool.use pool . Session.pipeline . (flip traverse) nicks $ (\(t, nick) -> |
| 2026-06-30 19:31:00 +0000 | <absentia> | (nick ,) <$> Pipeline.statement (nick, t) createNickRecord) |
| 2026-06-30 19:31:08 +0000 | <absentia> | that's it. what's what's taking so long. |
| 2026-06-30 19:31:15 +0000 | <tomsmeding> | what part of it is taking long? |
| 2026-06-30 19:31:18 +0000 | <absentia> | here, `nicks :: Vector (UTCTime, SomePlainRecord)` |
| 2026-06-30 19:31:29 +0000 | <absentia> | tomsmeding: well honestly i'm not sure. been too lazy to profile |
| 2026-06-30 19:31:47 +0000 | <absentia> | i doubt it is the DB, which is seeing nothing, and why would postgres be slow |
| 2026-06-30 19:31:50 +0000 | <tomsmeding> | could it be that collecting 5000 statements in a Hasql pipeline is just slow, regardless of how you do it? |
| 2026-06-30 19:32:00 +0000 | <absentia> | it's possible, but it's expressly designed for insert of bulk data |
| 2026-06-30 19:32:09 +0000 | <absentia> | the lib is otherwise high quality, but sure, who knows |
| 2026-06-30 19:32:26 +0000 | <absentia> | > You can use pipeline to turn a single-row insert query into an efficient multi-row insertion session. In effect this should be comparable in performance to issuing a single multi-row insert statement. |
| 2026-06-30 19:32:28 +0000 | <lambdabot> | <hint>:1:139: error: parse error on input `in' |
| 2026-06-30 19:32:42 +0000 | <absentia> | like... that's exactly what i'm doing. multi-row insert. |
| 2026-06-30 19:32:46 +0000 | <tomsmeding> | I see |
| 2026-06-30 19:32:52 +0000 | <absentia> | 2000 records is not a lot, it is a high school textbook example |
| 2026-06-30 19:33:19 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-06-30 19:33:19 +0000 | <absentia> | god forbid because some of these pipelines are actually |
| 2026-06-30 19:33:21 +0000 | <absentia> | 300k! |
| 2026-06-30 19:33:27 +0000 | <absentia> | and yes that also took an eternity |
| 2026-06-30 19:33:37 +0000 | <absentia> | this is very frustrating, people in the other IRC channel are laughing at me |
| 2026-06-30 19:33:42 +0000 | <absentia> | for struggling with such a basic task |
| 2026-06-30 19:33:50 +0000 | <absentia> | i don't know why haskell performance is so opaque |
| 2026-06-30 19:33:52 +0000 | <tomsmeding> | I would try to see if you can figure out where the slowness is |
| 2026-06-30 19:34:02 +0000 | <absentia> | hnngnhgngnhgnghnghn i don't want to profile |
| 2026-06-30 19:34:03 +0000 | <absentia> | reeeeeeeeeee |
| 2026-06-30 19:34:15 +0000 | <tomsmeding> | "I don't know why performance is so opaque" "I don't want to profile" |
| 2026-06-30 19:34:22 +0000 | <tomsmeding> | well then you'll never no |
| 2026-06-30 19:34:24 +0000 | <tomsmeding> | *know |
| 2026-06-30 19:34:28 +0000 | <absentia> | sigh |
| 2026-06-30 19:36:05 +0000 | <tomsmeding> | cabal run --enable-profiling --profiling-detail=late your-app -- ...args... +RTS -pj |
| 2026-06-30 19:36:14 +0000 | <monochrom> | OTOH it is not like profiling results are actually transparent and interpreting them is easy either. |
| 2026-06-30 19:36:18 +0000 | <tomsmeding> | and then give the resulting json file to https://www.speedscope.app/ |
| 2026-06-30 19:36:26 +0000 | <tomsmeding> | start there, then if that doesn't give enough info, come back |
| 2026-06-30 19:36:30 +0000 | <absentia> | it's uhh |
| 2026-06-30 19:36:40 +0000 | <absentia> | not so trivial, because it's one piece of a concurrent system with all sorts of other shit running |
| 2026-06-30 19:36:47 +0000 | <tomsmeding> | monochrom: actually, in all fairness, profiling haskell code can be a nightmare because of laziness and costs being attributed in places you don't expect |
| 2026-06-30 19:36:49 +0000 | <absentia> | that will probably muddle the waters in the profile |
| 2026-06-30 19:36:53 +0000 | <monochrom> | If you have a broken mental model of Haskell execution, profiling results are misleading. (Or rather, your broken model is misleading.) |
| 2026-06-30 19:37:06 +0000 | <absentia> | i HAVE profiled haskell code before |
| 2026-06-30 19:37:14 +0000 | <absentia> | but that is where i had a test suite and a mate-in-2 chess problem |
| 2026-06-30 19:37:23 +0000 | <absentia> | that i could easily isolate and zero in on outside of an actual deployment |
| 2026-06-30 19:37:27 +0000 | <absentia> | but it's a pain to set all that shit up |
| 2026-06-30 19:37:27 +0000 | <tomsmeding> | right |
| 2026-06-30 19:37:39 +0000 | <absentia> | anyway i can do it |
| 2026-06-30 19:37:41 +0000 | <absentia> | i'm just lazy |
| 2026-06-30 19:37:43 +0000 | <absentia> | sigh |
| 2026-06-30 19:37:46 +0000 | <absentia> | self-created problems |
| 2026-06-30 19:38:07 +0000 | <absentia> | it's actually that exact optimization quest |
| 2026-06-30 19:38:11 +0000 | <absentia> | that turned me off linked lists and onto vectors |
| 2026-06-30 19:38:16 +0000 | <tomsmeding> | did it help? |
| 2026-06-30 19:38:22 +0000 | <absentia> | quite substantially i believe |
| 2026-06-30 19:38:28 +0000 | <tomsmeding> | in this bit of code, or elsewhere? |
| 2026-06-30 19:38:29 +0000 | <absentia> | that's also where i learned about attoparsec incidentally |
| 2026-06-30 19:38:35 +0000 | <absentia> | i wrote a small alpha beta pruning engine |
| 2026-06-30 19:38:36 +0000 | polykernel_ | (~polykerne@user/polykernel) polykernel |
| 2026-06-30 19:38:40 +0000 | <int-e> | wait, we're building and running 5k SQL queries and it's slow so we're looking for faster way to *checks notes* iterate over a list with 5k elements? |
| 2026-06-30 19:38:40 +0000 | <absentia> | elsewhere |
| 2026-06-30 19:38:48 +0000 | <tomsmeding> | because yes, vectors can make a tremendous difference over lists depending on what you're doing |
| 2026-06-30 19:38:53 +0000 | <absentia> | int-e: the alternative is i steal some code i wrote elsewhere to build SQL strings |
| 2026-06-30 19:38:57 +0000 | <tomsmeding> | int-e: the lib is supposed to bundle them into 1 query I THINK |
| 2026-06-30 19:39:00 +0000 | <absentia> | and just bang in VALUES (?, ?, ?), (?, ?, ?) |
| 2026-06-30 19:39:10 +0000 | <absentia> | but at that point why am i using a damn SQL library |
| 2026-06-30 19:39:22 +0000 | <tomsmeding> | but yes, I've been trying to say that a list of 5000 elements is not going to take 30 minutes; it's not even going to take 1ms |
| 2026-06-30 19:39:42 +0000 | <absentia> | it's neither exactly 5k SQL queries nor one query |
| 2026-06-30 19:39:45 +0000 | <int-e> | tomsmeding: that's fine, it can still be expensive regardless ;-) |
| 2026-06-30 19:39:49 +0000 | <absentia> | it's a series of statements issued in postgresql pipeline mode |
| 2026-06-30 19:39:51 +0000 | <absentia> | in one network roundtrip |
| 2026-06-30 19:39:59 +0000 | <tomsmeding> | ok |
| 2026-06-30 19:40:02 +0000 | <monochrom> | What I do is I don't profile a completed project first. That's too late. If I have a hypothesis "I'm using State, I'm blaming State [denying that I'm also using a hundred other things so why am I singling out State]", I write 5 lines of code benchmarking State itself and nothing else. |
| 2026-06-30 19:40:02 +0000 | <absentia> | ik weird shit |
| 2026-06-30 19:40:07 +0000 | ski | (~ski@31-208-30-244.cust.bredband2.com) (Read error: Connection reset by peer) |
| 2026-06-30 19:40:15 +0000 | <tomsmeding> | even apart from haskell profiling, have you checked whether that 30 minutes is spent in haskell or in postgres |
| 2026-06-30 19:40:51 +0000 | <tomsmeding> | like, open your favourite process monitor and look at what's using CPU |
| 2026-06-30 19:40:55 +0000 | <absentia> | i mean pg_stat_activity |
| 2026-06-30 19:40:57 +0000 | <tomsmeding> | if it's 30 minutes, that ought to be obvious |
| 2026-06-30 19:40:57 +0000 | <absentia> | says everything is idle |
| 2026-06-30 19:41:01 +0000 | <absentia> | i don't see any rows being inserted |
| 2026-06-30 19:41:10 +0000 | polykernel | (~polykerne@user/polykernel) (Ping timeout: 276 seconds) |
| 2026-06-30 19:41:10 +0000 | polykernel_ | polykernel |
| 2026-06-30 19:41:12 +0000 | <absentia> | so my presumption is the app layer is burning cycles building up some massive collection |
| 2026-06-30 19:41:14 +0000 | <tomsmeding> | and your haskell process is pegged all that time? |
| 2026-06-30 19:41:15 +0000 | <absentia> | or intermediate result |
| 2026-06-30 19:41:18 +0000 | <absentia> | yeah |
| 2026-06-30 19:41:26 +0000 | <tomsmeding> | 5000 is _not_ massive |
| 2026-06-30 19:41:27 +0000 | <absentia> | like max CPU |
| 2026-06-30 19:41:32 +0000 | <absentia> | it's not, which is why this is so frustrating |
| 2026-06-30 19:41:38 +0000 | <tomsmeding> | if there is something massive, it's in hasql's internals here |
| 2026-06-30 19:41:42 +0000 | <tomsmeding> | not in traverse over a vector |
| 2026-06-30 19:41:47 +0000 | <absentia> | good grief |
| 2026-06-30 19:41:54 +0000 | <absentia> | maybe i SHOULD just compile my own SQL |
| 2026-06-30 19:41:56 +0000 | <absentia> | i've even done it before |
| 2026-06-30 19:42:00 +0000 | <absentia> | for this exact use case - ETL |
| 2026-06-30 19:42:29 +0000 | <int-e> | tomsmeding: It's just, of all the bottlenecks I can imagine that isn't one of them. I suppose if it's a list that's populated lazily *that* can take a while too, and make it look as if iteration is slow... |
| 2026-06-30 19:42:49 +0000 | <tomsmeding> | int-e: I've been saying this about 10 times throughout this conversation, in various phrasings |
| 2026-06-30 19:42:51 +0000 | <absentia> | i think the vector is strict |
| 2026-06-30 19:43:09 +0000 | <EvanR> | if it wasn't obvious what would happen, I'd be temped to make minimal test cases to disprove all your claims, like it's impossible to quickly traverse 5000 items with a vector, etc |
| 2026-06-30 19:43:14 +0000 | <int-e> | Anyway. Profile, or read the library code trying to understand where the time might be spent. I'd think that profiling will be far less effort for starters. |
| 2026-06-30 19:43:27 +0000 | <absentia> | yes it's always "profile first" isn't it |
| 2026-06-30 19:43:27 +0000 | <EvanR> | so you can get some more targeted claims more likely to be the problem |
| 2026-06-30 19:43:29 +0000 | <absentia> | hnnngh |
| 2026-06-30 19:43:37 +0000 | <int-e> | tomsmeding: Yes I have little constructive things to add ;) |
| 2026-06-30 19:43:48 +0000 | <monochrom> | Yeah we need more "falsify your own hypotheses" attitudes. |
| 2026-06-30 19:43:48 +0000 | <EvanR> | instead of guessing, blaming random things, and try to spread FUD |
| 2026-06-30 19:43:49 +0000 | <int-e> | Or few. |
| 2026-06-30 19:44:02 +0000 | <tomsmeding> | int-e: both can be true at the same time |
| 2026-06-30 19:44:05 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 19:45:03 +0000 | <int-e> | absentia: If you have no idea where the time is spent, profile first unless your code base *including* dependencies, except the ones whose performancy characteristics you understand perfectly is very small. |
| 2026-06-30 19:45:23 +0000 | <int-e> | Hmm, "performancy" is cute. |
| 2026-06-30 19:45:39 +0000 | <int-e> | sounds more magical that way, like necromancy |
| 2026-06-30 19:46:14 +0000 | <monochrom> | Danse Macabre is a necromancy performance. >:) |
| 2026-06-30 19:48:33 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2026-06-30 19:54:15 +0000 | <tomsmeding> | absentia: https://paste.tomsmeding.com/tjiAWaX1 |
| 2026-06-30 19:54:20 +0000 | ski | (~ski@31-208-30-244.cust.bredband2.com) ski |
| 2026-06-30 19:54:47 +0000 | <tomsmeding> | I can sum 1 million ints in a vector using traverse in IO in 820 ms in the interpreter, 344 ms compiled -O0, and 204ms compiled -O1 |
| 2026-06-30 19:55:12 +0000 | <tomsmeding> | and actually that is not only the traverse, also a separate Data.Foldable.sum of the results afterwards |
| 2026-06-30 19:55:25 +0000 | <tomsmeding> | I did for you what EvanR suggested |
| 2026-06-30 19:56:32 +0000 | <tomsmeding> | doing 1 million individual insert queries in postgres is going to take longer than 200ms |
| 2026-06-30 19:56:47 +0000 | <tomsmeding> | even if pipelined |
| 2026-06-30 19:56:59 +0000 | <int-e> | (you still have to marshal the data at least) |
| 2026-06-30 19:57:08 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 19:57:36 +0000 | <int-e> | meanwhile, maybe each of the 5k things has a 1GB blob :) |
| 2026-06-30 19:58:14 +0000 | <EvanR> | 1 million boxed ints? |
| 2026-06-30 19:58:40 +0000 | <int-e> | EvanR: apparently! |
| 2026-06-30 19:58:55 +0000 | <EvanR> | so chonky |
| 2026-06-30 19:59:27 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 19:59:47 +0000 | <jaror> | tomsmeding: You can speed it up a bit with mapM and enumFromTo :) |
| 2026-06-30 20:00:55 +0000 | <tomsmeding> | jaror: this is purposefully written this way to be the thing that absentia complained about :p |
| 2026-06-30 20:01:20 +0000 | <int-e> | > let n = 1000000 in fromInteger (n*(n+1) `div` 2) :: Int |
| 2026-06-30 20:01:22 +0000 | <lambdabot> | 500000500000 |
| 2026-06-30 20:01:41 +0000 | <tomsmeding> | I mean, yes, you can optimise this to nothingness but that's not the point :p |
| 2026-06-30 20:02:05 +0000 | <int-e> | I'm just jumping to the end of jaror's road. |
| 2026-06-30 20:02:14 +0000 | <int-e> | I know that it's missing the point entirely ;) |
| 2026-06-30 20:02:25 +0000 | <tomsmeding> | once you get into number crunching and unboxed arrays, very quickly discover that GHC does not vectorise array loops, and you shall cry in performance |
| 2026-06-30 20:02:28 +0000 | <int-e> | But this middle of the road approach really didn't agree with me :P |
| 2026-06-30 20:02:44 +0000 | <tomsmeding> | now that's actually worth complaining about |
| 2026-06-30 20:02:53 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 20:02:55 +0000 | <jaror> | Just use -fllvm :P |
| 2026-06-30 20:03:03 +0000 | <tomsmeding> | I suppose |
| 2026-06-30 20:03:11 +0000 | <int-e> | Nah just don't use Haskell. |
| 2026-06-30 20:03:15 +0000 | <tomsmeding> | ^ |
| 2026-06-30 20:03:17 +0000 | <int-e> | For the number crunching parts |
| 2026-06-30 20:03:30 +0000 | <tomsmeding> | yes, so I wrote some C code and linked that into haskell |
| 2026-06-30 20:03:34 +0000 | <tomsmeding> | 8x speedup |
| 2026-06-30 20:04:03 +0000 | <EvanR> | according to legend that formula was invented by carl friedrich gauss when he was in 3rd grade |
| 2026-06-30 20:04:17 +0000 | <int-e> | Maybe prototype in Haskell... it's often more fun to tinker with algorithms in a higher level language. |
| 2026-06-30 20:04:27 +0000 | <EvanR> | I wonder if the teacher accused him of cheating |
| 2026-06-30 20:04:31 +0000 | <int-e> | EvanR: But he only used it for 100! |
| 2026-06-30 20:04:34 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2026-06-30 20:04:36 +0000 | <jaror> | We now have SIMD in the NCG, so it can't be that hard to add loop vectorisation |
| 2026-06-30 20:04:59 +0000 | <tomsmeding> | well it's still tricky, because you have to write the vector operations yourself, right? |
| 2026-06-30 20:05:14 +0000 | <jaror> | I mean add a vectorisation optimization to the compiler |
| 2026-06-30 20:05:38 +0000 | <tomsmeding> | loop vectorisation is like the largest and most complicated optimisation in all of LLVM iirc |
| 2026-06-30 20:05:53 +0000 | <tomsmeding> | "it can't be that hard" is underselling it a bit :p |
| 2026-06-30 20:06:28 +0000 | <jaror> | Also, the vector library was built to do loop vectorisation with its bundles, but somehow it was never finished |
| 2026-06-30 20:06:30 +0000 | <monochrom> | To it to Lean instead. It can't be that hard. And it's Dependent Haskell here and now. |
| 2026-06-30 20:06:31 +0000 | <tomsmeding> | it is certainly not impossible! And maybe easy cases are not too hard |
| 2026-06-30 20:06:40 +0000 | <monochrom> | s/To it/Do it/ |
| 2026-06-30 20:07:06 +0000 | <tomsmeding> | jaror: right, doing it in user code, e.g. in vector's Bundle stuff, is probably much lower fruit |
| 2026-06-30 20:07:07 +0000 | <monochrom> | Um "easy casses not too hard" is a tautology :) |
| 2026-06-30 20:07:50 +0000 | <tomsmeding> | monochrom: okay, the relatively easy cases (as compared to loop vectorisation as understood by gcc/llvm) are not too hard (as compared to other optimisations GHC does) |
| 2026-06-30 20:08:04 +0000 | <tomsmeding> | that's not at all obvious any more :) |
| 2026-06-30 20:08:11 +0000 | <jaror> | or, here's a wild idea: a DSL which is specialized to array operations. |
| 2026-06-30 20:08:18 +0000 | <tomsmeding> | O.o |
| 2026-06-30 20:08:20 +0000 | <jaror> | :P |
| 2026-06-30 20:08:28 +0000 | <tomsmeding> | you're kidding, that would never work |
| 2026-06-30 20:08:31 +0000 | <monochrom> | Oh, that. |
| 2026-06-30 20:08:43 +0000 | <int-e> | jaror: welcome to.... numpy |
| 2026-06-30 20:08:53 +0000 | <monochrom> | APL |
| 2026-06-30 20:08:56 +0000 | <tomsmeding> | repa |
| 2026-06-30 20:09:11 +0000 | <jaror> | Futhark |
| 2026-06-30 20:09:11 +0000 | <tomsmeding> | accelerate, futhark |
| 2026-06-30 20:09:14 +0000 | <int-e> | monochrom: fair, I was thinking EDSL |
| 2026-06-30 20:09:16 +0000 | <monochrom> | matlab |
| 2026-06-30 20:09:34 +0000 | <tomsmeding> | not massiv, by the way, because iirc that doesn't vectorise |
| 2026-06-30 20:10:05 +0000 | <tomsmeding> | (surprisingly, to me) |
| 2026-06-30 20:10:08 +0000 | <jaror> | Does accelerate rely on llvm for vectorisation? |
| 2026-06-30 20:10:45 +0000 | <monochrom> | Ooohhh Jeremy Gibbons did APL as EDSL into Haskell: https://www.cs.ox.ac.uk/publications/publication10857-abstract.html |
| 2026-06-30 20:10:45 +0000 | <tomsmeding> | currently, yes, but just this evening Ivo messaged me that a student would be looking at doing some vectorisation in accelerate already, because LLVM isn't doing a very good job with the generated code for reductions and especially scans and permutes |
| 2026-06-30 20:11:05 +0000 | <monochrom> | I didn't understand APL until that paper! |
| 2026-06-30 20:11:22 +0000 | <tomsmeding> | (for GPU, naturally "vectorisation" is a thing already because if not then what are you doing) |
| 2026-06-30 20:11:36 +0000 | <monochrom> | He didn't generate optimized code, but he spec'ed out the EDSL itself. |
| 2026-06-30 20:12:17 +0000 | <monochrom> | (Use rewrite rules for the code optimization? "It's not that hard"? :) ) |
| 2026-06-30 20:12:46 +0000 | <tomsmeding> | well once you have a high-level _array language_, at that level of abstraction it's much more doable, conceptually, to generate good code |
| 2026-06-30 20:13:02 +0000 | <tomsmeding> | it's the recognition of vectorisable structure from imperative loop code that's such a nightmare |
| 2026-06-30 20:13:18 +0000 | <tomsmeding> | (there's still plenty of engineering involved to make it good) |
| 2026-06-30 20:13:53 +0000 | polykernel_ | (~polykerne@user/polykernel) polykernel |
| 2026-06-30 20:14:49 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 20:16:50 +0000 | polykernel | (~polykerne@user/polykernel) (Ping timeout: 245 seconds) |
| 2026-06-30 20:16:50 +0000 | polykernel_ | polykernel |
| 2026-06-30 20:18:59 +0000 | dtman34_ | (~dtman34@c-73-242-68-179.hsd1.mn.comcast.net) dtman34 |
| 2026-06-30 20:19:26 +0000 | dtman34 | (~dtman34@c-73-242-68-179.hsd1.mn.comcast.net) (Ping timeout: 265 seconds) |
| 2026-06-30 20:19:39 +0000 | <absentia> | so this is a pretty elite channel |
| 2026-06-30 20:19:43 +0000 | <absentia> | are all of you vibecoding now |
| 2026-06-30 20:19:54 +0000 | <absentia> | or do you view this as a foolish and astroturfed bubble |
| 2026-06-30 20:20:16 +0000 | <absentia> | i can't really believe all the LLM hype if it is plausibly generated and hallucinated by LLMs themselves |
| 2026-06-30 20:20:39 +0000 | <tomsmeding> | I grudgingly use LLMs for prototypes when on-the-clock |
| 2026-06-30 20:21:55 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-06-30 20:22:22 +0000 | <EvanR> | gotta stir the pot! |
| 2026-06-30 20:23:12 +0000 | <probie> | My hatred for LLMs doesn't come from their capacity, but the fact that they were trained on copyrighted works without permission |
| 2026-06-30 20:23:56 +0000 | <monochrom> | I don't see the correlation between elite and vibe coding. |
| 2026-06-30 20:24:05 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 20:24:19 +0000 | <dcb> | I'd try to minimize the number of tools needed to write code |
| 2026-06-30 20:24:32 +0000 | <int-e> | monochrom: I see it: Consider who the people who unironically call themselves "elite" are. |
| 2026-06-30 20:24:40 +0000 | <EvanR> | it's like when elite golfers hire robots to play golf for them |
| 2026-06-30 20:24:44 +0000 | <EvanR> | so they don't have to |
| 2026-06-30 20:24:50 +0000 | <EvanR> | see |
| 2026-06-30 20:24:58 +0000 | <monochrom> | OK! |
| 2026-06-30 20:25:05 +0000 | <monochrom> | I haven't needed to use LLMs. |
| 2026-06-30 20:25:06 +0000 | ridcully | (~ridcully@p57b52a2d.dip0.t-ipconnect.de) (Quit: WeeChat 4.9.2) |
| 2026-06-30 20:25:29 +0000 | <monochrom> | And like I said last night, the 3 times I took a look at what Google AI said, it's all wrong. |
| 2026-06-30 20:25:43 +0000 | <monochrom> | I wanted to give it a chance! Disillusioned. |
| 2026-06-30 20:26:12 +0000 | <probie> | [Google AI] did you know that the concept of "Supplemental Material" simply didn't exist until digital storage? |
| 2026-06-30 20:26:34 +0000 | ridcully | (~ridcully@p57b52a2d.dip0.t-ipconnect.de) ridcully |
| 2026-06-30 20:27:03 +0000 | <jaror> | it always reminds me of the "Great Galactic Grid" from the Zogg from Betelgeuse video on mathematics |
| 2026-06-30 20:27:35 +0000 | <monochrom> | In one case it said "X is true" where the reference it cited said "X is false". |
| 2026-06-30 20:27:37 +0000 | <tomsmeding> | monochrom: they generate predictable text, that's all they do. If you ask them to generate boilerplate for you, they'll be mostly successful. The "higher-quality" the model, the more the boundaries of "boilerplate" shift, but fundamentally that's still what's happening |
| 2026-06-30 20:27:42 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 20:27:52 +0000 | <monochrom> | This is what you get when you believe in "express in your own words to show you understand". |
| 2026-06-30 20:28:33 +0000 | <mauke> | I don't use LLMs, but how are they advertised nowadays? is it just code generation, or do they also offer to explain existing code to you? |
| 2026-06-30 20:28:35 +0000 | <tomsmeding> | if you don't write any boilerplate, I'm not surprised you don't find them useful :) |
| 2026-06-30 20:28:48 +0000 | <monochrom> | LLMs will make great politicians and management types. Just needing to mince words. |
| 2026-06-30 20:28:49 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 20:29:23 +0000 | <monochrom> | It's advertised as artificial intelligence. |
| 2026-06-30 20:29:25 +0000 | <jaror> | Some GHC developers seem to just be able to say "fix this bug" and have Claude churn away at it for them... |
| 2026-06-30 20:29:38 +0000 | Katarushisu6 | (~Katarushi@finc-20-b2-v4wan-169598-cust1799.vm7.cable.virginm.net) (Ping timeout: 248 seconds) |
| 2026-06-30 20:29:51 +0000 | <tomsmeding> | if it's not too conceptually difficult, I'm not surprised |
| 2026-06-30 20:31:07 +0000 | <tomsmeding> | and it's quite impressive how "harness engineering" (translation: writing code that practices the socratic method on the LLM, in addition to providing it a (textual) "API" for calling external tools) can increase their abilities |
| 2026-06-30 20:31:31 +0000 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2026-06-30 20:32:11 +0000 | <tomsmeding> | but if you do use them, you have to make sure you know _why_ you're using them, and if you actually think that's a good idea |
| 2026-06-30 20:32:24 +0000 | <tomsmeding> | (the precise interpretation of that latter statement is personal, so I'll leave that to the reader) |
| 2026-06-30 20:32:50 +0000 | <monochrom> | I admit that it does something right, OK? For example, academically it shows that some linguists are right about semantics of a word containing a large factor of correlating with other words, much larger than most people want to believe. |
| 2026-06-30 20:32:53 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 20:33:01 +0000 | califax | (~califax@user/califx) califx |
| 2026-06-30 20:33:03 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 20:33:05 +0000 | <tomsmeding> | mind, compared to even the middle-of-the-road programmer these days, my experience using these tools amounts to a rounding error |
| 2026-06-30 20:33:40 +0000 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2026-06-30 20:33:54 +0000 | <monochrom> | Oh harness engineering is going to be another of those meaningless "meaningful" words coined by programmers. |
| 2026-06-30 20:34:04 +0000 | <monochrom> | after bus factors and test pollution. |
| 2026-06-30 20:34:14 +0000 | <tomsmeding> | (that's why I offered a translation -- I didn't know its definition until a few weeks ago :p) |
| 2026-06-30 20:34:22 +0000 | <jaror> | Yeah, I was talking to Ed Kmett at Zurihac and he is spending like 3-4 times my salary on tokens... |
| 2026-06-30 20:34:37 +0000 | <monochrom> | or rather s/meaningless/unguessable/ |
| 2026-06-30 20:34:43 +0000 | hc | (~hc@user/hc) (Remote host closed the connection) |
| 2026-06-30 20:35:44 +0000 | hc | (~hc@user/hc) hc |
| 2026-06-30 20:35:50 +0000 | <tomsmeding> | monochrom: actually, the first time I heard someone describe what they were doing (which turned out to be harness engineering), I made the mistake of asking (because I genuinely didn't understand at first) how it was different from prompt engineering |
| 2026-06-30 20:36:13 +0000 | polykernel_ | (~polykerne@user/polykernel) polykernel |
| 2026-06-30 20:36:18 +0000 | <tomsmeding> | unstated: why they were doing so at an academic institution |
| 2026-06-30 20:36:34 +0000 | <tomsmeding> | (I'm still unsure about the latter, but don't tell them that) |
| 2026-06-30 20:37:47 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2026-06-30 20:38:10 +0000 | polykernel | (~polykerne@user/polykernel) (Ping timeout: 248 seconds) |
| 2026-06-30 20:38:10 +0000 | polykernel_ | polykernel |
| 2026-06-30 20:39:04 +0000 | machinedgod | (~machinedg@d108-173-95-19.abhsia.telus.net) (Ping timeout: 245 seconds) |
| 2026-06-30 20:39:13 +0000 | Katarushisu6 | (~Katarushi@finc-20-b2-v4wan-169598-cust1799.vm7.cable.virginm.net) |
| 2026-06-30 20:40:44 +0000 | <tomsmeding> | mauke: they do offer that, and the success rate (of good models) is high enough that it's tempting to use it. But it's very dangerous, because it's often very hard to check that they're right (indeed, otherwise you would likely not have asked the LLM) |
| 2026-06-30 20:41:53 +0000 | <tomsmeding> | the more falsifiable the output, the less risky it is. :p |
| 2026-06-30 20:42:50 +0000 | <monochrom> | It's why I don't call it AI when talking to people who know. I'm sure LLM is a great component of AI, but just one component, it's lacking f**king fact-checking. |
| 2026-06-30 20:43:02 +0000 | <tomsmeding> | (and I'm not even talking about the inevitable skill atrophy if you replace too much of your work) |
| 2026-06-30 20:43:16 +0000 | <tomsmeding> | I hate the word "AI" for LLMs |
| 2026-06-30 20:43:40 +0000 | <tomsmeding> | it's a language model, and if you understand what it does, it's not so surprising what it's good at and what it isn't good at |
| 2026-06-30 20:44:11 +0000 | <newmind> | following and detecting patterns... just like humans :P |
| 2026-06-30 20:44:27 +0000 | <tomsmeding> | it's a "concisely" represented markov chain with a very long history dependence |
| 2026-06-30 20:44:55 +0000 | <monochrom> | Deep Think is closer to what I can call AI. It uses a proof checker to check LLM attempts. That's what I can call fact-checking. |
| 2026-06-30 20:45:12 +0000 | <int-e> | tomsmeding: Hmm, would that make it a "C"LM? |
| 2026-06-30 20:45:32 +0000 | <tomsmeding> | int-e: what is the C for? |
| 2026-06-30 20:45:39 +0000 | <int-e> | tomsmeding: "C" for "concise" |
| 2026-06-30 20:45:40 +0000 | <tomsmeding> | oh |
| 2026-06-30 20:46:21 +0000 | <monochrom> | It's also how I do math! I think up an attempt by experience of seeing tons of previous proofs by others or me (LLM), but I still have to check it with very rigid rules (proof checker). |
| 2026-06-30 20:46:30 +0000 | <tomsmeding> | well, the quotes are because the things are hundreds of gigabytes large these days; the word "concise" is because naively, a probability distribution of the next token conditioned on the previous 100k tokens would require super-galactic storage |
| 2026-06-30 20:46:42 +0000 | <monochrom> | or at least test with test cases. |
| 2026-06-30 20:46:53 +0000 | acidjnk_new3 | (~acidjnk@p200300d6e74def37a5af64098d23bd41.dip0.t-ipconnect.de) acidjnk |
| 2026-06-30 20:48:00 +0000 | <tomsmeding> | monochrom: having an LLM generate proofs is actually the cleanest application of them that I've found yet |
| 2026-06-30 20:48:16 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 20:49:04 +0000 | <tomsmeding> | (theoretically, in any case; not by personal experience) |
| 2026-06-30 20:49:07 +0000 | <int-e> | It's a million monkeys with a dictionary (LLM) on typewriters, but with a lector (harness) that rejects the most obvious bullshit. You may get a Dan Brown but not Shakespeare? (too harsh?) |
| 2026-06-30 20:49:39 +0000 | <monochrom> | That may be too harsh on Dan Brown. :) |
| 2026-06-30 20:49:40 +0000 | <int-e> | (I'm not covering prompts part.) |
| 2026-06-30 20:49:45 +0000 | <tomsmeding> | what monochrom said |
| 2026-06-30 20:50:12 +0000 | <int-e> | monochrom: I'm stealing an old Colbert bit |
| 2026-06-30 20:50:27 +0000 | acidjnk | (~acidjnk@p200300d6e74def67cefedba3bc5cab81.dip0.t-ipconnect.de) (Ping timeout: 272 seconds) |
| 2026-06-30 20:50:27 +0000 | acidjnk_new | (~acidjnk@p200300d6e74def67cefedba3bc5cab81.dip0.t-ipconnect.de) (Ping timeout: 272 seconds) |
| 2026-06-30 20:51:06 +0000 | acidjnk | (~acidjnk@p200300d6e74def37a5af64098d23bd41.dip0.t-ipconnect.de) acidjnk |
| 2026-06-30 20:51:34 +0000 | <int-e> | monochrom: Though his punchline (as I recall it) was very different: "And a single monkey typing away over Columbus Day weekend will give you a Dan Brown." |
| 2026-06-30 20:52:10 +0000 | <tomsmeding> | That's certainly too harsh on Dan Brown :p |
| 2026-06-30 20:52:28 +0000 | juri_ | (~juri@217-114-215-140.pool.ovpn.com) (Ping timeout: 268 seconds) |
| 2026-06-30 20:52:33 +0000 | <monochrom> | heh |
| 2026-06-30 20:53:04 +0000 | <int-e> | tomsmeding: Or maybe he just called a human a monkey. Which... eh we're not that far apart, biologically speaking. |
| 2026-06-30 20:53:07 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-06-30 20:53:20 +0000 | <tomsmeding> | fair |
| 2026-06-30 20:54:26 +0000 | <EvanR> | a human and a banana |
| 2026-06-30 20:54:58 +0000 | <tomsmeding> | don't make fun of bananas, bananas are nice |
| 2026-06-30 20:55:16 +0000 | <EvanR> | how many infinities would it take a banana to write Shakespeare |
| 2026-06-30 20:55:43 +0000 | <Clint> | depends how radioactive it is |
| 2026-06-30 20:55:50 +0000 | <tomsmeding> | lol |
| 2026-06-30 20:56:14 +0000 | <int-e> | Anyway. The point was that as I understand it, the harness is a kind of lector. It'll catch the most obvious bullshit (code that fails to compile, test suites don't pass, linter outputs etc.) and reject stuff, and I suppose add it to the prompt (call it "refining the prompt" if you want to be fancy) |
| 2026-06-30 20:56:29 +0000 | <int-e> | So the poor humans have to do less of that. |
| 2026-06-30 20:56:51 +0000 | int-e | shrugs |
| 2026-06-30 20:57:14 +0000 | <tomsmeding> | int-e: supposedly, the fancy ones also do some kind of socratic method stuff: have another instance of the LLM (with a different prompt) judge the output, feeding that back, etc |
| 2026-06-30 20:57:26 +0000 | <tomsmeding> | which, perhaps surprisingly, apparently works |
| 2026-06-30 20:59:06 +0000 | Katarushisu6 | (~Katarushi@finc-20-b2-v4wan-169598-cust1799.vm7.cable.virginm.net) (Quit: The Lounge - https://thelounge.chat) |
| 2026-06-30 20:59:37 +0000 | polykernel_ | (~polykerne@user/polykernel) polykernel |
| 2026-06-30 20:59:54 +0000 | <int-e> | I dislike the word "works" in this context, it's too unspecific |
| 2026-06-30 21:00:13 +0000 | <tomsmeding> | subjectively improves output quality |
| 2026-06-30 21:01:09 +0000 | polykernel | (~polykerne@user/polykernel) (Ping timeout: 245 seconds) |
| 2026-06-30 21:01:09 +0000 | polykernel_ | polykernel |
| 2026-06-30 21:01:15 +0000 | <int-e> | So... it feels better by an unspecified margin. |
| 2026-06-30 21:01:31 +0000 | <tomsmeding> | yes |
| 2026-06-30 21:02:12 +0000 | <int-e> | Well, it's not calle vibe coping for nothing |
| 2026-06-30 21:02:41 +0000 | <int-e> | (unfortunately that's not a plausible typo. :) ) |
| 2026-06-30 21:02:44 +0000 | juri_ | (~juri@217-114-215-140.pool.ovpn.com) juri_ |
| 2026-06-30 21:03:26 +0000 | <int-e> | ('p' for 'd' that is) |
| 2026-06-30 21:03:38 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 21:05:16 +0000 | Katarushisu6 | (~Katarushi@finc-20-b2-v4wan-169598-cust1799.vm7.cable.virginm.net) |
| 2026-06-30 21:08:55 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2026-06-30 21:18:59 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 21:23:36 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |