Newest at the top
| 2026-01-08 02:48:27 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-01-08 02:45:50 +0100 | lbseale | (~quassel@user/ep1ctetus) ep1ctetus |
| 2026-01-08 02:45:07 +0100 | lbseale | (~quassel@user/ep1ctetus) (Client Quit) |
| 2026-01-08 02:42:30 +0100 | Googulator14 | (~Googulato@2a01-036d-0106-4994-68db-cf64-05de-a70a.pool6.digikabel.hu) |
| 2026-01-08 02:42:13 +0100 | Googulator14 | (~Googulato@2a01-036d-0106-4994-68db-cf64-05de-a70a.pool6.digikabel.hu) (Quit: Client closed) |
| 2026-01-08 02:42:00 +0100 | lbseale | (~quassel@user/ep1ctetus) ep1ctetus |
| 2026-01-08 02:36:55 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-01-08 02:30:24 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-01-08 02:25:44 +0100 | divlamir_ | divlamir |
| 2026-01-08 02:24:52 +0100 | divlamir_ | (~divlamir@user/divlamir) divlamir |
| 2026-01-08 02:24:48 +0100 | divlamir | (~divlamir@user/divlamir) (Read error: Connection reset by peer) |
| 2026-01-08 02:23:20 +0100 | <newmind> | exactly, the language itself has nothing to do with the inherent safety, that was never my claim. but what it has is a type system that does let you reason where and how IO actually happens. if you need _safety_ you still need sandboxing, vms and whatever else you would use for any other binary |
| 2026-01-08 02:23:15 +0100 | bggd | (~bgg@user/bggd) bggd |
| 2026-01-08 02:22:52 +0100 | Lycurgus | (~juan@user/Lycurgus) Lycurgus |
| 2026-01-08 02:22:22 +0100 | <jreicher> | Nothing in that guarantees safety. |
| 2026-01-08 02:22:03 +0100 | <jreicher> | My understanding of type checking has always been that it's only checking whether the programmer has contradicted themselves. The programmer writes the type assertions, and the programmer writes the code. Type checker checks if that set of assertions is inconsistent according to the type inference rules. |
| 2026-01-08 02:19:19 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2026-01-08 02:18:36 +0100 | <EvanR> | in any language |
| 2026-01-08 02:17:55 +0100 | <EvanR> | haskell itself isn't making code inherently safe, you have whatever layers of stuff and planning for something like an eval bot |
| 2026-01-08 02:15:52 +0100 | <int-e> | EvanR: I'm kind of curious what evoked that picture. |
| 2026-01-08 02:14:36 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-01-08 02:13:43 +0100 | <newmind> | agents are doing |
| 2026-01-08 02:13:42 +0100 | <newmind> | obviously, yes. and i'd never advocate for blindly running untrusted code either. but it's a lot easier to reason about a function with a type signature than just executing a bash script blindly. it's not meant as a airtight sandbox that holds up against adverserial attacks, but it is another layer. and it is quite a bit more than what current |
| 2026-01-08 02:12:27 +0100 | <int-e> | huh |
| 2026-01-08 02:11:34 +0100 | <EvanR> | he's running in the equivalent of that underwater prison in avengers |
| 2026-01-08 02:11:16 +0100 | <EvanR> | the amount of infrastructure required for lambdabot xD |
| 2026-01-08 02:10:35 +0100 | <lambdabot> | why oh why indeed |
| 2026-01-08 02:10:34 +0100 | <int-e> | > text "why oh why indeed" |
| 2026-01-08 02:10:21 +0100 | <EvanR> | and not sure why that's even required |
| 2026-01-08 02:10:13 +0100 | <EvanR> | executing "untrusted" code is still a horrible idea in haskell |
| 2026-01-08 02:10:05 +0100 | <int-e> | You'd need {-# LANGUAGE AdditivePromises #-} for that. |
| 2026-01-08 02:09:40 +0100 | <EvanR> | some of those premises about haskell don't add up ... |
| 2026-01-08 02:08:55 +0100 | <int-e> | discover new ways in which well-typed programs go wrong |
| 2026-01-08 02:08:00 +0100 | prite | (~pritam@user/pritambaral) (Quit: Konversation terminated!) |
| 2026-01-08 02:06:28 +0100 | <newmind> | take your point, i was just generally looking for feedback, viewpoints and ideas |
| 2026-01-08 02:06:27 +0100 | <newmind> | the connection would be that haskell (or strongly typed languages in particular) provide guardrails and constraints to LLM generated code that does not exist in other languages, including that generated haskell code is safer (not absolutely safe) to generate and run than in most other languages (especially with the Safe extension enabled). but i |
| 2026-01-08 02:05:09 +0100 | omidmash5 | omidmash |
| 2026-01-08 02:05:09 +0100 | omidmash | (~omidmash@user/omidmash) (Ping timeout: 244 seconds) |
| 2026-01-08 02:05:09 +0100 | xff0x | (~xff0x@2405:6580:b080:900:4b0b:90a:cd82:2bd2) (Ping timeout: 244 seconds) |
| 2026-01-08 02:03:41 +0100 | <haskellbridge> | <sm> (I'm not excusing rudeness, but I understand it) |
| 2026-01-08 02:03:39 +0100 | <haskellbridge> | <sm> it means that if you come into a space and talk about the ai thing you're building, you need to be ready for all kinds of response |
| 2026-01-08 02:03:35 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2026-01-08 02:03:10 +0100 | omidmash5 | (~omidmash@user/omidmash) omidmash |
| 2026-01-08 02:02:58 +0100 | <jreicher> | Fair |
| 2026-01-08 02:02:08 +0100 | <EvanR> | yeah I don't see the connection to haskell specifically |
| 2026-01-08 02:01:30 +0100 | <ncf> | take it to #haskell-offtopic please, this is not the place to discuss LLMs |
| 2026-01-08 02:01:26 +0100 | <geekosaur> | that was the theory behind UML, I think? |
| 2026-01-08 02:00:56 +0100 | <jreicher> | Never thought about this before, but maybe there's a market for AI /only/ because of informal specification. If the spec was formal non-AI program generation might be possible? |
| 2026-01-08 02:00:55 +0100 | <EvanR> | hopefully that bleeds onto programming at some point |
| 2026-01-08 02:00:03 +0100 | <EvanR> | people with mathematical or engineering maturity are better at specifying what they want or what they have |