Newest at the top
| 2025-05-07 08:40:19 +0200 | <dminuoso> | Bowuigi: Yes. and I only like it for NixOS modules |
| 2025-05-07 08:39:59 +0200 | <dminuoso> | I recently decided to do munihac and zurihac in a biennial rotation. :) |
| 2025-05-07 08:39:39 +0200 | <haskellbridge> | <Bowuigi> The declarative nature of Nix is great for everyone. The rest sometimes feels annoying |
| 2025-05-07 08:39:24 +0200 | <haskellbridge> | <maerwald> there'll probably be endless nix debates on the grass, lmao |
| 2025-05-07 08:39:02 +0200 | <dminuoso> | Probably yes. |
| 2025-05-07 08:38:54 +0200 | <haskellbridge> | <maerwald> will you be at ZuriHac? |
| 2025-05-07 08:38:43 +0200 | <dminuoso> | maerwald: Which question? |
| 2025-05-07 08:38:39 +0200 | <dminuoso> | At work we have some rigorous discipline to have minimal code logic. |
| 2025-05-07 08:38:35 +0200 | <haskellbridge> | <maerwald> dminuoso: anyway, you didn't answer my question above ;) |
| 2025-05-07 08:38:30 +0200 | <dminuoso> | Yeah, though Im fine with the lack of that boundary. |
| 2025-05-07 08:36:52 +0200 | <haskellbridge> | <maerwald> so there goes your ergonomics |
| 2025-05-07 08:36:48 +0200 | <haskellbridge> | <maerwald> well, nix has no boundaries between code and configuration |
| 2025-05-07 08:36:43 +0200 | <dminuoso> | Unless we can agree expressivity to mean code ergonomics. |
| 2025-05-07 08:36:22 +0200 | <dminuoso> | I mean there's code ergonomics and tool ergonomics. |
| 2025-05-07 08:36:17 +0200 | <haskellbridge> | <maerwald> You mean lack of ergenomics? |
| 2025-05-07 08:36:04 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2025-05-07 08:36:04 +0200 | <dminuoso> | In nix they kind of go hand in hand. |
| 2025-05-07 08:35:18 +0200 | <haskellbridge> | <maerwald> ergonomics > expressivity :) |
| 2025-05-07 08:33:53 +0200 | <dminuoso> | Now nix tosses away all kinds of diagnostics, and plenty of performance, but you get expressivity. |
| 2025-05-07 08:33:43 +0200 | <haskellbridge> | <sm> Bowuigi I'm in the same boat as you |
| 2025-05-07 08:33:39 +0200 | <dminuoso> | But honestly, the main pain point for us with other solutions is not reproducability, its *expressivity* and *diagnostics*. |
| 2025-05-07 08:33:30 +0200 | <haskellbridge> | <maerwald> well, as I said... I don't use effects systems. Mainly because whenever I looked at heavy effects system code... I realized it's impossible to reason what it will do _operationally_ ...don't denotational semantics me... I have to run my program in the end |
| 2025-05-07 08:33:15 +0200 | <dminuoso> | And as with nix, there may be odd cases where reproducability has been an issue. |
| 2025-05-07 08:33:15 +0200 | <haskellbridge> | <Bowuigi> sm np lol, I don't see much of a discussion though |
| 2025-05-07 08:32:00 +0200 | <dminuoso> | They help in some situations where you have developers with less-than-ideal discipline |
| 2025-05-07 08:31:34 +0200 | <dminuoso> | That is, effect systems dont fix bad libraries. |
| 2025-05-07 08:31:17 +0200 | emmanuelux | (~emmanuelu@user/emmanuelux) (Quit: au revoir) |
| 2025-05-07 08:31:13 +0200 | <haskellbridge> | <maerwald> lmao |
| 2025-05-07 08:31:03 +0200 | <dminuoso> | Just dont use piss poor libraries that do network calls in the middle ofyour $(makeFromJSON) ? |
| 2025-05-07 08:30:52 +0200 | <haskellbridge> | <maerwald> writing Haskell code like in the 90s |
| 2025-05-07 08:30:48 +0200 | <dminuoso> | maerwald: ultimately, if you are suggesting you have a library that induces 90% reproducability in TH splices, then effect systems are not the right choice |
| 2025-05-07 08:30:38 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-07 08:30:33 +0200 | <haskellbridge> | <maerwald> dminuoso: So you're an IO maximalist |
| 2025-05-07 08:30:33 +0200 | <haskellbridge> | <sm> oops did I say that out loud. Sorry Bowuigi :) |
| 2025-05-07 08:30:07 +0200 | <haskellbridge> | <sm> we're arguing about what's best, you fool! |
| 2025-05-07 08:30:00 +0200 | <dminuoso> | Much like PHp. |
| 2025-05-07 08:29:58 +0200 | <dminuoso> | Transformer stacks are, in my opinion, just an experiment gone wild and spread around. |
| 2025-05-07 08:29:47 +0200 | <haskellbridge> | <Bowuigi> I don't have enough computers to worry about reproducibility, or enough effects to worry about effect systems, but if you do, why not use the best tools available? |
| 2025-05-07 08:29:35 +0200 | <dminuoso> | Well I wouldn't use mtl/transformers except for some local tricks |
| 2025-05-07 08:29:30 +0200 | <haskellbridge> | <maerwald> where in mtl/transformers you have to consciously think about the different stacks all the time |
| 2025-05-07 08:29:10 +0200 | <haskellbridge> | <maerwald> yes, if you compare it to e.g. mtl/transformers, then it's clear that it's more composable |
| 2025-05-07 08:28:43 +0200 | <haskellbridge> | <sm> the goal is usually controlled composability, not a big ball of mud |
| 2025-05-07 08:28:27 +0200 | <haskellbridge> | <maerwald> dminuoso: Yes, bluefin is just IO under the hood |
| 2025-05-07 08:28:09 +0200 | <dminuoso> | But it begs the question if the number of bad programs filtered out if worth the pain. |
| 2025-05-07 08:27:40 +0200 | <dminuoso> | In hopes of filtering out more bad programs than it filters out good programs. |
| 2025-05-07 08:27:18 +0200 | <dminuoso> | effect systems exist *precisely* because they reduce composability. |
| 2025-05-07 08:27:01 +0200 | <dminuoso> | If that was true IO would be the ideal solution as it is maximally composable. |
| 2025-05-07 08:26:48 +0200 | <haskellbridge> | <maerwald> not that I use any |
| 2025-05-07 08:26:28 +0200 | <haskellbridge> | <maerwald> it's composability |
| 2025-05-07 08:26:22 +0200 | <haskellbridge> | <maerwald> the main selling points of effects systems isn't even avoiding bugs |