Newest at the top
| 2025-05-07 08:46:58 +0200 | <haskellbridge> | <sm> we all know its badness :) |
| 2025-05-07 08:46:55 +0200 | <haskellbridge> | <Bowuigi> At some things, yes |
| 2025-05-07 08:46:25 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-07 08:46:23 +0200 | <haskellbridge> | <maerwald> So now Haskell is bad? |
| 2025-05-07 08:45:45 +0200 | <haskellbridge> | <Bowuigi> Because when something is good, everyone wants to use it for everything, thus making it bad |
| 2025-05-07 08:44:57 +0200 | euleritian | (~euleritia@77.23.248.100) |
| 2025-05-07 08:44:57 +0200 | <haskellbridge> | <sm> and also not enough (only one shake file / process per directory) |
| 2025-05-07 08:44:37 +0200 | <haskellbridge> | <maerwald> sm: Too powerful, imo |
| 2025-05-07 08:44:28 +0200 | <haskellbridge> | <sm> Shake is quite powerful |
| 2025-05-07 08:44:08 +0200 | <dminuoso> | Just to replace them with a different kind of bad. |
| 2025-05-07 08:44:07 +0200 | euleritian | (~euleritia@77.23.248.100) (Remote host closed the connection) |
| 2025-05-07 08:44:05 +0200 | <haskellbridge> | <maerwald> premake, SCons? xD |
| 2025-05-07 08:44:01 +0200 | <dminuoso> | There's certainly a plethora of build systems that claim they finally solved all the bad parts... |
| 2025-05-07 08:43:47 +0200 | <haskellbridge> | <sm> hmmm |
| 2025-05-07 08:43:45 +0200 | euleritian | (~euleritia@77.23.248.100) |
| 2025-05-07 08:43:39 +0200 | <haskellbridge> | <Bowuigi> No |
| 2025-05-07 08:43:36 +0200 | euleritian | (~euleritia@77.23.248.100) (Read error: Connection reset by peer) |
| 2025-05-07 08:43:27 +0200 | <dminuoso> | Has there ever been a build system that isnt just bad? |
| 2025-05-07 08:42:44 +0200 | <haskellbridge> | <maerwald> the best thing is when your configure has some syntax errors, but carries on anyway... uhm, bro |
| 2025-05-07 08:42:17 +0200 | <haskellbridge> | <sm> hey I depend on m4, sometimes nothing else gets it done |
| 2025-05-07 08:42:02 +0200 | <haskellbridge> | <Bowuigi> Reproducibility was annoying sometimes because it actively nerfed some programs |
| 2025-05-07 08:41:52 +0200 | <haskellbridge> | <maerwald> m4 is th the worst macro system in existence |
| 2025-05-07 08:41:50 +0200 | <dminuoso> | Oh and you cant even inspect any of it. |
| 2025-05-07 08:41:32 +0200 | <haskellbridge> | <maerwald> autotools, lmao |
| 2025-05-07 08:41:21 +0200 | <dminuoso> | Declarative autotools sans documentation. |
| 2025-05-07 08:41:19 +0200 | <haskellbridge> | <maerwald> MuniHac at in September, which is bad weather... and I can't be bothered to fly twice from Asia to Europe |
| 2025-05-07 08:41:02 +0200 | <dminuoso> | You're essentially writing autotools parts but without any documentation how or in what order they execute, and what it done when. |
| 2025-05-07 08:40:30 +0200 | <dminuoso> | For nix derivation it is a hopelessly horrible excercise. |
| 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 |