Newest at the top
| 2025-12-02 19:05:54 +0100 | yin | (~zero@user/zero) (Ping timeout: 260 seconds) |
| 2025-12-02 19:03:33 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Remote host closed the connection) |
| 2025-12-02 19:02:47 +0100 | tromp | (~textual@2001:1c00:3487:1b00:40c9:191b:e4f:324a) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-12-02 18:59:01 +0100 | ttybitnik | (~ttybitnik@user/wolper) ttybitnik |
| 2025-12-02 18:54:47 +0100 | weary-traveler | (~user@user/user363627) (Ping timeout: 250 seconds) |
| 2025-12-02 18:54:03 +0100 | <mauke> | gotta be quick when looking for the future |
| 2025-12-02 18:53:16 +0100 | user363627 | (~user@user/user363627) user363627 |
| 2025-12-02 18:51:56 +0100 | <absentia> | he's definitely a zoomer |
| 2025-12-02 18:51:47 +0100 | <absentia> | LooksForFuture: patience |
| 2025-12-02 18:51:36 +0100 | target_i | (~target_i@user/target-i/x-6023099) target_i |
| 2025-12-02 18:51:17 +0100 | ttybitnik | (~ttybitnik@user/wolper) (Remote host closed the connection) |
| 2025-12-02 18:43:47 +0100 | gawen | (~gawen@user/gawen) gawen |
| 2025-12-02 18:42:34 +0100 | Enrico63 | (~Enrico63@host-212-171-79-170.pool212171.interbusiness.it) (Quit: Client closed) |
| 2025-12-02 18:40:59 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-12-02 18:39:33 +0100 | LooksForFuture | (~LooksForF@5.74.168.135) (Client Quit) |
| 2025-12-02 18:38:36 +0100 | <LooksForFuture> | Good resources for learning Haskell for a C programmer? |
| 2025-12-02 18:37:55 +0100 | gawen | (~gawen@user/gawen) (Quit: cya) |
| 2025-12-02 18:37:49 +0100 | LooksForFuture | (~LooksForF@5.74.168.135) |
| 2025-12-02 18:33:08 +0100 | peterbecich | (~Thunderbi@172.222.148.214) peterbecich |
| 2025-12-02 18:29:17 +0100 | <fgarcia> | yes i think work has gone into compilers to get them to detect and optimize for emberassingly parallel operations. some things are difficult to do that for so there will still be a longer wait for some tasks |
| 2025-12-02 18:20:01 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-12-02 18:19:54 +0100 | tromp | (~textual@2001:1c00:3487:1b00:40c9:191b:e4f:324a) |
| 2025-12-02 18:18:58 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 255 seconds) |
| 2025-12-02 18:18:18 +0100 | Inline | (~inlinE@2001-4dd3-7fc8-0-434a-a4b1-7362-b14b.ipv6dyn.netcologne.de) Inline |
| 2025-12-02 18:17:20 +0100 | <dutchie> | ( https://downloads.haskell.org/ghc/9.12.1/docs/users_guide/9.12.1-notes.html#included-libraries ) |
| 2025-12-02 18:17:12 +0100 | <dutchie> | containers is a dependency of the ghc library so I guess it's pretty much everywhere |
| 2025-12-02 18:13:38 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Remote host closed the connection) |
| 2025-12-02 18:12:55 +0100 | <__monty__> | (I'm a base minimalist.) |
| 2025-12-02 18:12:26 +0100 | <haskellbridge> | <loonycyborg> You can have small transitive footprint only if most widely used things (like containers and unordered-containers) are in base |
| 2025-12-02 18:12:24 +0100 | <__monty__> | We're limited in our footprints by the unique dependency constraint at least. |
| 2025-12-02 18:11:26 +0100 | <merijn> | __monty__: No, we should have "tiny dependency with minimal transitive footprint" unlike JS which is "tiny dependency with massive transitive footprint" :p |
| 2025-12-02 18:11:06 +0100 | <haskellbridge> | <loonycyborg> Like modern cpus have lot of redundant execution units but not all code ends up using them to the full. |
| 2025-12-02 18:10:26 +0100 | <__monty__> | Clearly we need to approach JavaScript's tiny dependency culture. |
| 2025-12-02 18:09:07 +0100 | <haskellbridge> | <loonycyborg> in some cases things might be even free but you'd need to know details very well to take advantage of that |
| 2025-12-02 18:09:06 +0100 | <haskellbridge> | <loonycyborg> cpu adds lots of own optimizations too |
| 2025-12-02 18:09:05 +0100 | <haskellbridge> | <loonycyborg> Though it can be hard to picture everything that happens at low level |
| 2025-12-02 18:06:58 +0100 | <c_wraith> | (we're still pretending we have infinite memory) |
| 2025-12-02 18:06:43 +0100 | <c_wraith> | because that's when it actually is possible for n to go to infinity anyway |
| 2025-12-02 18:06:17 +0100 | <c_wraith> | Which is why I usually talk about strings instead of integers |
| 2025-12-02 18:06:03 +0100 | <merijn> | It's also not true, since integers aren't compared 1 bit at a time :p |
| 2025-12-02 18:05:24 +0100 | <haskellbridge> | <loonycyborg> I'm not sure why it matters what they share, they all had to be compared anyway for things to be correct :P |
| 2025-12-02 18:05:21 +0100 | <merijn> | 2^63 share a 1 bit prefix :p |
| 2025-12-02 18:05:18 +0100 | <c_wraith> | I think you're right. But it does mean *some* comparison will take time has a lower bound determined by the number of distinct keys. that's the part I was looking for. |
| 2025-12-02 18:05:15 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2025-12-02 18:04:44 +0100 | Enrico63 | (~Enrico63@host-212-171-79-170.pool212171.interbusiness.it) Enrico63 |
| 2025-12-02 18:04:40 +0100 | <merijn> | c_wraith: The one where the last bit is 0 and the one where the last bit is 1? |
| 2025-12-02 18:04:25 +0100 | <merijn> | c_wraith: Logically speaking only 2 keys will share a 2^63 prefix, no? |
| 2025-12-02 18:04:11 +0100 | <merijn> | It's way to late to trust mine :p |
| 2025-12-02 18:04:02 +0100 | <c_wraith> | Actually it's way too early for me to trust my ability to do numbers. |
| 2025-12-02 18:03:54 +0100 | <merijn> | Wait, I guess that's the same? |