Newest at the top
| 2026-06-30 20:25:06 +0000 | ridcully | (~ridcully@p57b52a2d.dip0.t-ipconnect.de) (Quit: WeeChat 4.9.2) |
| 2026-06-30 20:25:05 +0000 | <monochrom> | I haven't needed to use LLMs. |
| 2026-06-30 20:24:58 +0000 | <monochrom> | OK! |
| 2026-06-30 20:24:50 +0000 | <EvanR> | see |
| 2026-06-30 20:24:44 +0000 | <EvanR> | so they don't have to |
| 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:32 +0000 | <int-e> | monochrom: I see it: Consider who the people who unironically call themselves "elite" are. |
| 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:05 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 20:23:56 +0000 | <monochrom> | I don't see the correlation between elite and vibe coding. |
| 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:22:22 +0000 | <EvanR> | gotta stir the pot! |
| 2026-06-30 20:21:55 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-06-30 20:20:39 +0000 | <tomsmeding> | I grudgingly use LLMs for prototypes when on-the-clock |
| 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:19:54 +0000 | <absentia> | or do you view this as a foolish and astroturfed bubble |
| 2026-06-30 20:19:43 +0000 | <absentia> | are all of you vibecoding now |
| 2026-06-30 20:19:39 +0000 | <absentia> | so this is a pretty elite channel |
| 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:18:59 +0000 | dtman34_ | (~dtman34@c-73-242-68-179.hsd1.mn.comcast.net) dtman34 |
| 2026-06-30 20:16:50 +0000 | polykernel_ | polykernel |
| 2026-06-30 20:16:50 +0000 | polykernel | (~polykerne@user/polykernel) (Ping timeout: 245 seconds) |
| 2026-06-30 20:14:49 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 20:13:53 +0000 | polykernel_ | (~polykerne@user/polykernel) polykernel |
| 2026-06-30 20:13:18 +0000 | <tomsmeding> | (there's still plenty of engineering involved to make it good) |
| 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: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:12:17 +0000 | <monochrom> | (Use rewrite rules for the code optimization? "It's not that hard"? :) ) |
| 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: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:05 +0000 | <monochrom> | I didn't understand APL until that paper! |
| 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: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:08 +0000 | <jaror> | Does accelerate rely on llvm for vectorisation? |
| 2026-06-30 20:10:05 +0000 | <tomsmeding> | (surprisingly, to me) |
| 2026-06-30 20:09:34 +0000 | <tomsmeding> | not massiv, by the way, because iirc that doesn't vectorise |
| 2026-06-30 20:09:16 +0000 | <monochrom> | matlab |
| 2026-06-30 20:09:14 +0000 | <int-e> | monochrom: fair, I was thinking EDSL |
| 2026-06-30 20:09:11 +0000 | <tomsmeding> | accelerate, futhark |
| 2026-06-30 20:09:11 +0000 | <jaror> | Futhark |
| 2026-06-30 20:08:56 +0000 | <tomsmeding> | repa |
| 2026-06-30 20:08:53 +0000 | <monochrom> | APL |
| 2026-06-30 20:08:43 +0000 | <int-e> | jaror: welcome to.... numpy |
| 2026-06-30 20:08:31 +0000 | <monochrom> | Oh, that. |
| 2026-06-30 20:08:28 +0000 | <tomsmeding> | you're kidding, that would never work |
| 2026-06-30 20:08:20 +0000 | <jaror> | :P |
| 2026-06-30 20:08:18 +0000 | <tomsmeding> | O.o |
| 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:04 +0000 | <tomsmeding> | that's not at all obvious any more :) |
| 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) |