Newest at the top
| 2024-10-06 18:56:59 +0200 | alp_ | (~alp@2001:861:e3d6:8f80:f5b0:cd1b:e895:cf8a) |
| 2024-10-06 18:56:27 +0200 | <Inst> | that said (,,) <$> foo <*> bar <*> baz >>= qux probably goes too far |
| 2024-10-06 18:53:49 +0200 | <lambdabot> | Monad m => (a -> m b) -> (b -> m c) -> a -> m c |
| 2024-10-06 18:53:48 +0200 | <Rembane> | :t (>=>) |
| 2024-10-06 18:53:42 +0200 | <Rembane> | I'm quite fond of (>=>) |
| 2024-10-06 18:53:34 +0200 | <Rembane> | That seems reasonable |
| 2024-10-06 18:53:20 +0200 | <Inst> | i'm more foo >>= bar when it's simpler, or foo; >>= bar; >>= baz when it better expresses the flow of your computation / program structure |
| 2024-10-06 18:53:19 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-06 18:52:49 +0200 | <Inst> | yeah |
| 2024-10-06 18:52:31 +0200 | <Rembane> | Inst: Are they all in on do-notation? |
| 2024-10-06 18:51:59 +0200 | <Inst> | there's folks on discourse who are fundamentalist in "fake python" style |
| 2024-10-06 18:51:15 +0200 | <davean> | I find I do both, depending on the details |
| 2024-10-06 18:50:20 +0200 | <Inst> | there's a trade-off in expressivity for familiarity, there's tons of cases where using >>= directly can be more expressive |
| 2024-10-06 18:49:54 +0200 | <Inst> | if you're not reusing the term, why bother with do; bar <- foo; baz bar when you can just foo >>= baz and be done with it? |
| 2024-10-06 18:49:02 +0200 | <Inst> | monochrom: the reason I worry about >>= leaking when it's explicitly used is because I love >>= |
| 2024-10-06 18:48:45 +0200 | <Inst> | thanks tomsmeding, and thanks for being unerringly helpful and a strong contributor to the community |
| 2024-10-06 18:48:42 +0200 | <davean> | There *are* ways to deal with it, but you have to deal with a lot of things you don't in others. |
| 2024-10-06 18:48:26 +0200 | <davean> | Franciman: Honestly though, this is a problem I think Haskell makes legitimately harder than other languages do though. |
| 2024-10-06 18:47:01 +0200 | <davean> | That has limited pause time though |
| 2024-10-06 18:46:15 +0200 | <davean> | This predates the non-moving GC |
| 2024-10-06 18:46:00 +0200 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 252 seconds) |
| 2024-10-06 18:45:39 +0200 | <Franciman> | ty |
| 2024-10-06 18:45:29 +0200 | <Franciman> | cool |
| 2024-10-06 18:44:43 +0200 | <geekosaur> | IIRC House specifically did sound drivers in Haskell |
| 2024-10-06 18:43:41 +0200 | <davean> | Franciman: https://metasepi.org/en/posts/2014-09-04-haskell-symposium.html sound drivers are soft realtime. (I remembered this existed, I don't remember the contense at all) |
| 2024-10-06 18:43:14 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) raehik |
| 2024-10-06 18:42:59 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-10-06 18:42:41 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-10-06 18:39:47 +0200 | <Rembane> | davean: That's true. |
| 2024-10-06 18:39:32 +0200 | <davean> | hard sometihng is |
| 2024-10-06 18:39:29 +0200 | <davean> | Rembane: I mean ... its always the product of the two that sets how rthi |
| 2024-10-06 18:38:56 +0200 | <Rembane> | davean: Way harder because of Haskell or because of the domain? |
| 2024-10-06 18:38:36 +0200 | <davean> | There have been a few OS projects in Haskell, while they've managed, I tihnk they've all ended with "This is way harder than we like" |
| 2024-10-06 18:38:02 +0200 | rvalue | (~rvalue@user/rvalue) rvalue |
| 2024-10-06 18:37:47 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
| 2024-10-06 18:37:35 +0200 | <Franciman> | nice |
| 2024-10-06 18:37:10 +0200 | <davean> | I wouldn't call it great at it thoguh. |
| 2024-10-06 18:36:15 +0200 | <davean> | Franciman: Sure. Particularly tight realtime its not great at. Soft is pretty easy with the realtime GC though. |
| 2024-10-06 18:35:40 +0200 | <Franciman> | can haskell do real time programming? |
| 2024-10-06 18:35:22 +0200 | <Franciman> | i'm not sure it's easy to change the status quo of a GCed lang like haskell |
| 2024-10-06 18:34:53 +0200 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 252 seconds) |
| 2024-10-06 18:32:49 +0200 | <Franciman> | the status quo of physics laws is impossible to change |
| 2024-10-06 18:32:33 +0200 | <Franciman> | the status quo of a society is very difficult to change, because of what you said |
| 2024-10-06 18:32:03 +0200 | <Franciman> | monochrom: the status quo of what? |
| 2024-10-06 18:31:00 +0200 | <Rembane> | That's how brains work to use very little glucose |
| 2024-10-06 18:30:34 +0200 | <monochrom> | But people wouldn't like that, eh? People are more comfortable with camps, paradigms, stereotypes, stigmas, over-simplifications. |
| 2024-10-06 18:30:18 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-10-06 18:28:49 +0200 | <monochrom> | It's why I don't put any weight on that notion unless in the context of "we need to get it done yesterday". |
| 2024-10-06 18:27:26 +0200 | <monochrom> | More seriously, the status quo is always changeable. Nothing blocks adding a task X library to any ecosystem. |
| 2024-10-06 18:27:00 +0200 | michalz | (~michalz@185.246.207.200) |