| 2026-02-16 00:06:54 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 00:07:46 +0100 | tremon | (~tremon@83.80.159.219) (Quit: getting boxed in) |
| 2026-02-16 00:08:36 +0100 | tromp | (~textual@2001:1c00:3487:1b00:4c61:e2e8:1826:9093) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2026-02-16 00:12:01 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-02-16 00:12:41 +0100 | emmanuelux | (~em@user/emmanuelux) emmanuelux |
| 2026-02-16 00:22:39 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 00:27:53 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-02-16 00:36:33 +0100 | emmanuelux | (~em@user/emmanuelux) (Read error: Connection reset by peer) |
| 2026-02-16 00:38:42 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 00:39:54 +0100 | emmanuelux | (~em@user/emmanuelux) emmanuelux |
| 2026-02-16 00:41:11 +0100 | michalz | (~michalz@185.246.207.205) (Read error: Connection reset by peer) |
| 2026-02-16 00:41:37 +0100 | michalz | (~michalz@185.246.207.201) |
| 2026-02-16 00:43:38 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2026-02-16 00:45:25 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh |
| 2026-02-16 00:50:00 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) lisbeths |
| 2026-02-16 00:54:44 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 00:59:04 +0100 | troydm | (~troydm@user/troydm) (Quit: What is Hope? That all of your wishes and all of your dreams come true? To turn back time because things were not supposed to happen like that (C) Rau Le Creuset) |
| 2026-02-16 00:59:58 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2026-02-16 01:08:49 +0100 | <EvanR> | so you want to subtract a number by 1 let me first introduce you to some category theory |
| 2026-02-16 01:10:30 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 01:15:20 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-02-16 01:21:22 +0100 | <monochrom> | :) |
| 2026-02-16 01:26:19 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 01:33:20 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-02-16 01:35:20 +0100 | <jreicher> | EvanR: TBH I'm comfortable with not pinning down terms. I'm more interested in finding good ways to think about stuff, and I think it's worth treating encapsulation of mutable behaviour differently from encapsulation of (immutable) data representation, if that makes sense? |
| 2026-02-16 01:35:54 +0100 | <jreicher> | Particularly since the mainstream OO languages seem to be converging on the functional way of doing the latter. |
| 2026-02-16 01:37:25 +0100 | <EvanR> | I think just being precise is a fine path to getting there. OOP isn't a priori precise unfortunately. mutable behavior? |
| 2026-02-16 01:39:57 +0100 | <jreicher> | For myself I try to make it precise something like following. All program execution requires mutation of state in the sense that the computer's memory is mutating. But the HUGE difference between a pure functional language and not is that the semantics of that are present in the latter and not at all in the former. Meaning you have language constructs that say "mutate this". The programmer can control it. So to me it doesn't matter the |
| 2026-02-16 01:39:58 +0100 | <jreicher> | exact form those constructs take; it only matters whether they are present. |
| 2026-02-16 01:41:08 +0100 | <EvanR> | if we're going to make a distinction between syntax and (different choices of) semantics, then mutable memory doesn't have to factor in either way |
| 2026-02-16 01:41:59 +0100 | <EvanR> | e.g. in one version of imperative programming, or even concurrent programming, the programs can have access to the history of messages which stands in for mutable state |
| 2026-02-16 01:42:12 +0100 | <EvanR> | for semantics |
| 2026-02-16 01:42:33 +0100 | <EvanR> | they even lean into this seriously in immutable databases |
| 2026-02-16 01:43:50 +0100 | <EvanR> | but yeah certain narrow presentations of OOP dwell heavily on "this is OOP. We mutate things" |
| 2026-02-16 01:44:21 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 01:44:23 +0100 | <EvanR> | and in that case I'd be surprised if they even distinguish semantics |
| 2026-02-16 01:46:30 +0100 | <jreicher> | EvanR: ah, fair point with the messages. There's an extra bit I have in mind but I struggle to put it into words. It's something like an observer getting a mutation they didn't ask for, which I think is equivalent to referential transparency failing. |
| 2026-02-16 01:47:02 +0100 | <jreicher> | I did see this discussed precisely many years ago, as something that mutation can actually be useful for, using it as a notification mechanism for a "distant" part of the program. |
| 2026-02-16 01:49:38 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2026-02-16 01:49:44 +0100 | <EvanR> | I still think mutable heap memory is implementation specific, and struggles to be a semantic thing, much less a paradigm-defining thing |
| 2026-02-16 01:50:07 +0100 | xff0x | (~xff0x@2405:6580:b080:900:9c89:4c9f:731a:2a84) (Ping timeout: 264 seconds) |
| 2026-02-16 01:51:18 +0100 | <jreicher> | Not sure what you mean by that. If in an imperative language I say a[42] = "Don't panic", aren't I assured of mutating something in heap even though I might not know exactly where? |
| 2026-02-16 01:54:26 +0100 | <EvanR> | typically they don't define it that way formally, or give particularly clear semantics |
| 2026-02-16 01:54:41 +0100 | <EvanR> | e.g. there's no heap in C, called that |
| 2026-02-16 01:54:44 +0100 | <EvanR> | at least |
| 2026-02-16 01:54:58 +0100 | <jreicher> | Understood, but why is that a problem? |
| 2026-02-16 01:55:07 +0100 | <jreicher> | I mean, if it allowed for no mutation at all, it would be... |
| 2026-02-16 01:55:11 +0100 | <EvanR> | *squint* |
| 2026-02-16 01:56:19 +0100 | <EvanR> | why is what a problem, what problem |
| 2026-02-16 01:57:06 +0100 | <jreicher> | Not having the heap mutation defined formally. |
| 2026-02-16 01:57:35 +0100 | <geekosaur> | in C if it's a local definition `char *a[43]` you'd be modifying stack, not heap |
| 2026-02-16 01:59:38 +0100 | <jreicher> | Well again I'm not sure if those specifics would bother me. It's a mutation that causes referential transparency to fail, and is under the programmer's control. That's what I think (but am not sure) sets these languages apart. |
| 2026-02-16 02:00:08 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-16 02:00:08 +0100 | karenw | (~karenw@user/karenw) (Ping timeout: 260 seconds) |