Newest at the top
| 2025-03-04 00:44:21 +0100 | <haskellbridge> | <Liamzee> https://en.wikipedia.org/wiki/MUMPS |
| 2025-03-04 00:43:55 +0100 | <haskellbridge> | <Liamzee> /s/wins ahead/comes out ahead/ |
| 2025-03-04 00:43:51 +0100 | <geekosaur> | you want terse? mumps |
| 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:42:52 +0100 | <haskellbridge> | <Liamzee> begin end |
| 2025-03-04 00:42:35 +0100 | <c_wraith> | I think of like apl or julia. |
| 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: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:39:44 +0100 | ystael | (~ystael@user/ystael) (Ping timeout: 252 seconds) |
| 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: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: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:36:32 +0100 | fmira | (~user@user/fmira) fmira |
| 2025-03-04 00:35:48 +0100 | fmira | (~user@user/fmira) (Remote host closed the connection) |
| 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:31:36 +0100 | fp | (~Thunderbi@hof1.kyla.fi) (Ping timeout: 272 seconds) |
| 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:24:59 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-04 00:22:12 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2025-03-04 00:19:34 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 272 seconds) |
| 2025-03-04 00:17:54 +0100 | LainExperiments | (~LainExper@user/LainExperiments) LainExperiments |
| 2025-03-04 00:14:44 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-04 00:14:15 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 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:09:37 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-04 00:02:16 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-03-03 23:58:40 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-03 23:55:23 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2025-03-03 23:54:13 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-03 23:51:30 +0100 | jmcantrell | (~weechat@user/jmcantrell) (Ping timeout: 248 seconds) |
| 2025-03-03 23:49:41 +0100 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2025-03-03 23:49:08 +0100 | myxos | (~myxos@syn-065-028-251-121.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2025-03-03 23:48:10 +0100 | LainExperiments | (~LainExper@user/LainExperiments) (Ping timeout: 240 seconds) |
| 2025-03-03 23:47:41 +0100 | <monochrom> | In Haskell, if you use the async library (https://hackage.haskell.org/package/async), it is actually not too different from the Python version. |
| 2025-03-03 23:45:32 +0100 | ljdarj1 | ljdarj |
| 2025-03-03 23:45:31 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 268 seconds) |
| 2025-03-03 23:44:49 +0100 | <constxd> | i have to defer the application of f with its arguments until the bind operation that unwraps the pure value |
| 2025-03-03 23:43:47 +0100 | <constxd> | and then it's literally just pure |
| 2025-03-03 23:43:39 +0100 | <constxd> | in haskell it doesn't matter i guess because you just apply f immediately, there's no difference |
| 2025-03-03 23:43:12 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-03-03 23:43:08 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-03-03 23:42:49 +0100 | <jackdk> | Liamzee: any chance you can say more about the problem you're modelling? |
| 2025-03-03 23:42:34 +0100 | <jackdk> | Liamzee: I have never found OOP to be a scalable technique. As soon as you work on two types of data, you have to make hard choices about which OOclass "owns" the method, or invent dubious nouns to hold a single function of two arguments. |
| 2025-03-03 23:42:03 +0100 | <monochrom> | jackdk: This is how I teach Haskell type classes. At the end there is also a little discussion about C++ and Java. https://www.cs.utoronto.ca/~trebla/CSCC24-latest/04-haskell-types-2.html |
| 2025-03-03 23:41:57 +0100 | <constxd> | but in a language with colored async functions (python), i have this: def foo(f, *xs): async def g(): return f(*xs); return g |
| 2025-03-03 23:40:32 +0100 | <constxd> | i guess maybe this question doesn't really make sense in haskell |
| 2025-03-03 23:40:08 +0100 | <monochrom> | either that, or at call sites just "pure (f x)" without making a name for it. |
| 2025-03-03 23:39:45 +0100 | <monochrom> | I think I'll just use "pure . f" |
| 2025-03-03 23:39:32 +0100 | <constxd> | wait no |
| 2025-03-03 23:39:22 +0100 | <constxd> | foo f x = pure (f x) |