2026/02/09

Newest at the top

2026-02-09 22:20:46 +0100 <EvanR> functional
2026-02-09 22:20:43 +0100 <EvanR> see also ocaml for a function language that happens to also support OOP
2026-02-09 22:20:01 +0100 <EvanR> jreicher, cardelli theory of objects shows two simplistic OOP "calculi" one with mutable, one without. Both are superficially similar to LC. So yeah
2026-02-09 22:20:00 +0100 <ski> the point is that *one* way to construe "OO" is that the main idea is to structure your program around records with delayed (possibly parameterized) fields. with or without subtyping. with or without implementation inheritance and late binding, open recursion
2026-02-09 22:18:39 +0100 <ski> but they don't have message-dispatching definition syntax (called "copatterns" in Agda. also used, years before that, by e.g. Erik Poll)
2026-02-09 22:18:10 +0100 <KindFoxo> oh, I'm sorry... I don't read while writing...
2026-02-09 22:17:22 +0100 <KindFoxo> also, all the ML-like FP languages have record types, why should it be not an FP thing... I've seen some formalization of classes as coinductive types. In curry or Coq, not sure, sounds interesting to me... As for right now, I don't understand "the idea" behind OOP...
2026-02-09 22:16:23 +0100 <ski> (that's why i used quotes)
2026-02-09 22:16:13 +0100 <ski> yea, those two are very restricted, and highly stylized, alternatives, for the purpose of showing a duality
2026-02-09 22:15:26 +0100 <KindFoxo> ski: you've made Lisps not functional... and I guess the language FP does not fit in the definition being obviously a functional programming language
2026-02-09 22:13:57 +0100 <ski> KindFoxo : you can store data in processes in Erlang, e.g. in its dict, or simply by having it wait for requests to set and access the state (which is immutably passed around in a tail-recursive loop)
2026-02-09 22:13:30 +0100 <KindFoxo> For example, Reader is such an extraction of the fact that a functional arrow is a monad
2026-02-09 22:13:02 +0100 <KindFoxo> Haskell seems to me like a structural programming language, in a sense category theory is a reborn of structuralism in mathematics. In Haskell it allows to extract the structure emerging in relations into some sort of a pattern.
2026-02-09 22:12:40 +0100 <ski> "OO" : programming with record/product types and message-dispatching
2026-02-09 22:12:24 +0100 <ski> "FP" : programming with variant/sum types and pattern-matching
2026-02-09 22:12:01 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds)
2026-02-09 22:10:46 +0100Square2(~Square@user/square) (Ping timeout: 265 seconds)
2026-02-09 22:09:22 +0100Square(~Square4@user/square) Square
2026-02-09 22:08:55 +0100 <KindFoxo> actor seem pretty close to objects for me. I guess originally, in Smalltalk's era, they were the same thing
2026-02-09 22:08:20 +0100 <KindFoxo> What is immutability tho? Is Erlang/Elixir a language with immutable state?
2026-02-09 22:07:38 +0100trickard__trickard
2026-02-09 22:07:08 +0100 <jreicher> If you're using an OO language and everything really is immutable, I think you're doing FP in an inappropriate language.
2026-02-09 22:06:56 +0100 <EvanR> (in fact it messes up some classic inheritance relationships)
2026-02-09 22:06:45 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-02-09 22:06:42 +0100 <EvanR> I don't think mutability is universally critical
2026-02-09 22:06:32 +0100 <EvanR> that gets into what OOP even is
2026-02-09 22:06:11 +0100 <EvanR> immutable objects is kind of fashionable these days
2026-02-09 22:06:10 +0100 <jreicher> I would suggest you're not really doing OO in that case. It's an opinion I'm not even sure I believe, but I just don't see OO offering anything special if its state mutation facilities aren't being used.
2026-02-09 22:05:35 +0100 <EvanR> you can get pretty far in OOP without mutability
2026-02-09 22:05:30 +0100 <jreicher> Is it what?
2026-02-09 22:05:15 +0100 <EvanR> is it?
2026-02-09 22:04:30 +0100KindFoxo(~KindFoxo@user/KindoFoxo) KindoFoxo
2026-02-09 22:04:25 +0100 <jreicher> Yes the mutability of objects is a key point, because the representation of state and the way it's mutated is exactly the kind of implementation detail that clients don't want to know. So I don't think an FP equivalent (if there is one) would just be passing parameters.
2026-02-09 22:04:14 +0100pavonia(~user@user/siracusa) siracusa
2026-02-09 22:03:54 +0100KindFoxo(~KindFoxo@user/KindoFoxo) (Remote host closed the connection)
2026-02-09 22:03:36 +0100 <geekosaur> or monads
2026-02-09 22:03:23 +0100 <geekosaur> OOP smuggles parameters in objects. Haskell can smuggle them in contexts. ☺
2026-02-09 22:02:41 +0100 <geekosaur> note however that it's controlled not by actual need but by perceived need, and perceptions can be slower to change
2026-02-09 22:01:42 +0100 <EvanR> in FP
2026-02-09 22:01:32 +0100 <EvanR> it's one of several OOP things which boils down to "pass a parameter"
2026-02-09 22:00:12 +0100 <jreicher> I've never tried to transplant it to FP. There are certainly people who believe it's very, very important in OO.
2026-02-09 21:59:20 +0100 <EvanR> dependency injection sounds verbose and redundant on the face of it, but maybe that's important xD
2026-02-09 21:59:09 +0100 <geekosaur> it certainly changes over time
2026-02-09 21:58:39 +0100 <EvanR> is jargon darwinistic, i.e. does it persist and expire based on fitness for its purpose, recognized or not xD
2026-02-09 21:56:51 +0100 <EvanR> a couple lines of code is worth N full months of arguing
2026-02-09 21:56:09 +0100 <jreicher> ...a full month...
2026-02-09 21:56:01 +0100 <jreicher> I spent probably full months arguing with some friends about exactly what "dependency injection" meant, and more than half of that was trying to figure out what a "dependency" is.
2026-02-09 21:55:36 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2026-02-09 21:50:58 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-02-09 21:50:47 +0100 <c_wraith> I did some funny stuff faking dependent instances using a Reifies constraint. It works, but actual dependent types would be a lot easier to use.