Newest at the top
| 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 |
| 2025-05-07 08:25:11 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: praxis.meansofproduction.biz (juan@acm.org)) |
| 2025-05-07 08:24:16 +0200 | <haskellbridge> | <sm> soo.. don't rewrite TH with bluefin/effectful then ? Too much ? |
| 2025-05-07 08:24:16 +0200 | <dminuoso> | And Haskell is great as a playground to do these experiments. |
| 2025-05-07 08:23:55 +0200 | <dminuoso> | And honestly, Ive been on that side. I had a phase where I made loads of type tricks to solve contrived bugs that I never had, and then felt good about how I had code provably absent of bugs (that I never had) |
| 2025-05-07 08:23:38 +0200 | <haskellbridge> | <maerwald> dminuoso: sounds like you're ok if my libraries work correctly 90% of the time. So I guess you don't mind if you get broken filepaths now and then |
| 2025-05-07 08:23:01 +0200 | euleritian | (~euleritia@77.23.248.100) |
| 2025-05-07 08:23:00 +0200 | <dminuoso> | Or they introduce anecdotes.. |
| 2025-05-07 08:22:55 +0200 | <JuanDaugherty> | inventory isn even cattle |
| 2025-05-07 08:22:43 +0200 | euleritian | (~euleritia@dynamic-176-006-137-036.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2025-05-07 08:22:27 +0200 | <haskellbridge> | <sm> yup.. with bash.. (I feel like a cave man, but so be it 😂) |