2026/01/08

Newest at the top

2026-01-08 02:24:52 +0100divlamir_(~divlamir@user/divlamir) divlamir
2026-01-08 02:24:48 +0100divlamir(~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 +0100bggd(~bgg@user/bggd) bggd
2026-01-08 02:22:52 +0100Lycurgus(~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 +0100merijn(~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 +0100merijn(~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 +0100prite(~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 +0100omidmash5omidmash
2026-01-08 02:05:09 +0100omidmash(~omidmash@user/omidmash) (Ping timeout: 244 seconds)
2026-01-08 02:05:09 +0100xff0x(~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 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds)
2026-01-08 02:03:10 +0100omidmash5(~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
2026-01-08 01:59:30 +0100 <newmind> in the meantime, for _a lot_ of real world software problems, it's a lot more grey: people can specify "what they want" only in very loose terms
2026-01-08 01:59:15 +0100 <EvanR> that part is beyond my paygrade xD
2026-01-08 01:58:49 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-08 01:58:48 +0100 <jreicher> Even if AI could do it, I think the bigger problem is motivating humans to write specs in the first place. That's been possible for half a century and still almost nobody doesit.
2026-01-08 01:58:02 +0100 <newmind> least run code that's checked by a compiler and can't do anything completely nuts
2026-01-08 01:58:01 +0100 <newmind> that would be the dream, yeah: provide a spec, and it spits out a program that fulfills that (and while we're at it, also does proofably terminate and run in limited space).. but current AI agents are doing the exact opposite, little more than running in yolo mode and just executing whatever comes to mind.. what i'm proposing is a middle ground: at
2026-01-08 01:57:36 +0100 <EvanR> not "write me an MMO in haskell"
2026-01-08 01:57:22 +0100 <EvanR> jreicher, correct in the sense that I explicitly specified the theorem
2026-01-08 01:56:39 +0100ryanbooker(uid4340@id-4340.hampstead.irccloud.com) ryanbooker