| 2025-03-04 00:02:16 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-03-04 00:09:37 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-04 00:12:59 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds) |
| 2025-03-04 00:14:15 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-03-04 00:14:44 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-04 00:17:54 +0100 | LainExperiments | (~LainExper@user/LainExperiments) LainExperiments |
| 2025-03-04 00:19:34 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 272 seconds) |
| 2025-03-04 00:22:12 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2025-03-04 00:24:59 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-04 00:28:19 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Read error: Connection reset by peer) |
| 2025-03-04 00:31:36 +0100 | fp | (~Thunderbi@hof1.kyla.fi) (Ping timeout: 272 seconds) |
| 2025-03-04 00:35:25 +0100 | <haskellbridge> | <Liamzee> jackdk: I'm just doing a simple tetris game in Rust, turned out to have taken much longer until I went to datatypes -> functions (in this case methods) approach |
| 2025-03-04 00:35:48 +0100 | fmira | (~user@user/fmira) (Remote host closed the connection) |
| 2025-03-04 00:36:32 +0100 | fmira | (~user@user/fmira) fmira |
| 2025-03-04 00:38:00 +0100 | <haskellbridge> | <Liamzee> i guess none of what i'm saying is new; people with orders of magnitude more experience than me have compared OOP vs FP approaches; OOP has very nice things about how it organizes code (I've always found FP libs to be disorganized) |
| 2025-03-04 00:38:28 +0100 | <haskellbridge> | <Liamzee> for instance, someone told me that Haskellers just tend to define datatypes anywhere instead of using specialized modules |
| 2025-03-04 00:39:10 +0100 | <haskellbridge> | <Liamzee> also, a very nice thing about playing with Rust is that it's so freaking verbose |
| 2025-03-04 00:39:44 +0100 | ystael | (~ystael@user/ystael) (Ping timeout: 252 seconds) |
| 2025-03-04 00:40:04 +0100 | <haskellbridge> | <Liamzee> you know me as the guy (Inst) who likes to complain about minor syntax issues with Haskell, when Haskell is tied with Python for terseness (monad accounting cancels out FP terseness) |
| 2025-03-04 00:42:24 +0100 | <c_wraith> | python is not what I think of when I think of a terse language. |
| 2025-03-04 00:42:35 +0100 | <c_wraith> | I think of like apl or julia. |
| 2025-03-04 00:42:52 +0100 | <haskellbridge> | <Liamzee> begin end |
| 2025-03-04 00:43:38 +0100 | <haskellbridge> | <Liamzee> although obv apl wins ahead, and it's all classical chinese to me (modern Chinese has tons of digraphs, classical Chinese, the older you get, the more single character words) :) |
| 2025-03-04 00:43:51 +0100 | <geekosaur> | you want terse? mumps |
| 2025-03-04 00:43:55 +0100 | <haskellbridge> | <Liamzee> /s/wins ahead/comes out ahead/ |
| 2025-03-04 00:44:21 +0100 | <haskellbridge> | <Liamzee> https://en.wikipedia.org/wiki/MUMPS |
| 2025-03-04 00:55:20 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds) |
| 2025-03-04 00:58:19 +0100 | prasad | (~Thunderbi@c-73-246-138-70.hsd1.in.comcast.net) |
| 2025-03-04 01:01:45 +0100 | dudek | (~dudek@2a02:a312:c9df:bf80:dd97:ea4a:fd09:4598) |
| 2025-03-04 01:01:53 +0100 | <haskellbridge> | <Liamzee> dumb jokes: Maybe is a comonad in the pseudo-category Hask; just error "Maybe is a comonad in the pseudo-category Hask" on Nothing. |
| 2025-03-04 01:03:09 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-04 01:03:40 +0100 | LainExperiments | (~LainExper@user/LainExperiments) (Ping timeout: 240 seconds) |
| 2025-03-04 01:05:59 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2025-03-04 01:07:36 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-03-04 01:11:55 +0100 | LainExperiments | (~LainExper@user/LainExperiments) LainExperiments |
| 2025-03-04 01:22:09 +0100 | Googulator93 | (~Googulato@2a01-036d-0106-14b2-c443-5a96-b49d-1dd5.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-03-04 01:22:21 +0100 | Googulator93 | (~Googulato@2a01-036d-0106-14b2-c443-5a96-b49d-1dd5.pool6.digikabel.hu) |
| 2025-03-04 01:23:21 +0100 | Square | (~Square@user/square) Square |
| 2025-03-04 01:37:54 +0100 | myxos | (~myxos@syn-065-028-251-121.res.spectrum.com) myxokephale |
| 2025-03-04 01:40:59 +0100 | yegorc | (~yegorc@user/yegorc) yegorc |
| 2025-03-04 01:43:28 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f05ac853a078363741e.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2025-03-04 01:45:19 +0100 | sprotte24 | (~sprotte24@p200300d16f02be0071e2e7b150ab479e.dip0.t-ipconnect.de) (Quit: Leaving) |
| 2025-03-04 01:49:19 +0100 | xff0x | (~xff0x@2405:6580:b080:900:9bc7:c2e3:e40a:e335) (Ping timeout: 244 seconds) |
| 2025-03-04 01:50:33 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-04 01:54:51 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2025-03-04 01:55:01 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 268 seconds) |
| 2025-03-04 01:55:35 +0100 | dudek | (~dudek@2a02:a312:c9df:bf80:dd97:ea4a:fd09:4598) (Quit: Leaving) |
| 2025-03-04 01:56:58 +0100 | <monochrom> | Up to a first-order approximation, OOP is more well-organized than FP, yes. But there is a blindspot in OOP advocacy based on that. |
| 2025-03-04 01:58:46 +0100 | <monochrom> | Ever heard of mutilple dispatch? Everything is not single dispatch. Only Common Lisp Object System does justice in this regard. C++ comes close, acknowledging that for binary operators such as (+), both a.add(b) and b.add(a) are wrong, you are supposed to have "friend-of-C add(C a, C b)". |
| 2025-03-04 01:59:07 +0100 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 265 seconds) |
| 2025-03-04 01:59:51 +0100 | <monochrom> | This means that with most OOP languages that understand only single dispatch, some of your organization is artificially biased, which means, if you think about it, poor and clumsy organization, worse than FP's free form. |
| 2025-03-04 02:00:46 +0100 | Jonno_FTW | (~come@user/jonno-ftw/x-0835346) (Ping timeout: 252 seconds) |
| 2025-03-04 02:01:20 +0100 | <monochrom> | I forgot what OCaml does for binary operators like that, but ISTR it is at least decent. |
| 2025-03-04 02:02:34 +0100 | Jonno_FTW | (~come@user/jonno-ftw/x-0835346) Jonno_FTW |
| 2025-03-04 02:05:04 +0100 | <constxd> | My toy language has proper multiple-dispatch for binary operators, glad to know it's only _partially_ wrong :) |
| 2025-03-04 02:05:38 +0100 | <monochrom> | Well yeah you need multiple dispatch for n-ary operations for all n to claim completeness. :) |
| 2025-03-04 02:06:10 +0100 | <monochrom> | But I wouldn't say "wrong" I just say "has a limit". |
| 2025-03-04 02:07:51 +0100 | <constxd> | Wait actually I guess it has n-ary except only when you have like `fn f(x: A, y: B, z: C) { ... } fn f(x: D, y: E, z: F) { ... }` defined together lexically. Whereas defining a new binary operator somewhere else doesn't shadow anything, it just updates the dispatch rules for that operator |
| 2025-03-04 02:08:17 +0100 | <monochrom> | Actually, I forgot Julia. It's also multiple dispatch. |
| 2025-03-04 02:08:40 +0100 | <monochrom> | Although, I heard that it's very slow when you actually use that in anger. |