Newest at the top
| 2025-01-16 03:34:34 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-16 03:30:18 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-16 03:24:06 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) chexum |
| 2025-01-16 03:23:35 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2025-01-16 03:23:20 +0100 | smalltalkman | (uid545680@id-545680.hampstead.irccloud.com) smalltalkman |
| 2025-01-16 03:21:04 +0100 | user363627 | (~user@user/user363627) (Remote host closed the connection) |
| 2025-01-16 03:19:27 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-16 03:19:11 +0100 | mulk | (~mulk@pd9514590.dip0.t-ipconnect.de) mulk |
| 2025-01-16 03:17:50 +0100 | Jeanne-Kamikaze | (~Jeanne-Ka@79.127.217.40) (Quit: Leaving) |
| 2025-01-16 03:14:55 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-16 03:13:22 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 265 seconds) |
| 2025-01-16 03:04:18 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2025-01-16 03:04:15 +0100 | mulk | (~mulk@p5b112493.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2025-01-16 03:03:07 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f246994c33ea14f59d4.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2025-01-16 02:55:02 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-16 02:53:12 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-01-16 02:50:01 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2025-01-16 02:49:30 +0100 | <Guest71> | geekosaur, ColinRobinson, thanks for your input as well |
| 2025-01-16 02:47:01 +0100 | <haskellbridge> | <sm> 👍 |
| 2025-01-16 02:45:02 +0100 | <Guest71> | sm: Thanks to you as well, you were very helpful! |
| 2025-01-16 02:44:19 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-16 02:43:25 +0100 | califax | (~califax@user/califx) califx |
| 2025-01-16 02:39:40 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-16 02:38:56 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2025-01-16 02:34:29 +0100 | otto_s | (~user@p4ff27909.dip0.t-ipconnect.de) |
| 2025-01-16 02:32:44 +0100 | otto_s | (~user@p5b044c54.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2025-01-16 02:32:23 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2025-01-16 02:30:59 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 260 seconds) |
| 2025-01-16 02:28:49 +0100 | <jackdk> | I still don't understand (but would like to, once it's in a public repo) what numeric algorithms you're implementing and whether 4× the LoC of `lens` indicates opportunities for simplification or for library splitting. Best of luck Guest71, I hope you figure out something that works for you and your users. |
| 2025-01-16 02:28:39 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2025-01-16 02:27:54 +0100 | <Guest71> | jackdk: Oh, sorry to keep you busy. Thank you so much! |
| 2025-01-16 02:27:02 +0100 | <jackdk> | This conversation has gone on for nearly 90 minutes without a clear resolution, and I'm sorry but I have to tap out and focus on work. I think you should soft-launch a monopackage to a git forge and try and drum up some users. That would give you more information about what your real users need from your library, and how to split it up; and give us something to look at so we're making recommendations based on something that we can see. |
| 2025-01-16 02:26:46 +0100 | <Guest71> | Making the monopackage from the microrepos would probably just entail using git submodules and crafting a .cabal file for the purpose. So basically easy. |
| 2025-01-16 02:26:30 +0100 | ColinRobinson | (~juan@user/JuanDaugherty) (Quit: ColinRobinson) |
| 2025-01-16 02:24:36 +0100 | <jackdk> | Beware that Haddocks' rendering of module re-exports is not the clearest, especially for new users. I still think I'd do the simplest thing that could possibly work, which still sounds like a single package. |
| 2025-01-16 02:24:35 +0100 | <Guest71> | That would for sure be more conservative |
| 2025-01-16 02:24:25 +0100 | <Guest71> | Then again, as you say, semantic equivalence means that I can split off at any time in the future and not even break API |
| 2025-01-16 02:23:40 +0100 | <Guest71> | (Portable Haskell too, if that matters) |
| 2025-01-16 02:23:26 +0100 | <Guest71> | No FFI though, pure Haskell. |
| 2025-01-16 02:23:10 +0100 | <Guest71> | jackdk: the different implementations have different data requirements so they do handle special purpose data structures. Hence the interface (a type class) and not just a single type. |
| 2025-01-16 02:22:09 +0100 | <Guest71> | (Ideally you'd use it a little at first and then commit to one of the implementations) |
| 2025-01-16 02:21:49 +0100 | <Guest71> | Because the plan was to have an umbrella project that reexports all the other smaller packages. Semantically, it would look exactly like the monopackage. |
| 2025-01-16 02:21:49 +0100 | <Guest71> | I am now realizing I made no emphasis on the umbrella package and it might address many of the concerns you raise. |
| 2025-01-16 02:21:37 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-16 02:21:06 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f246994c33ea14f59d4.dip0.t-ipconnect.de) acidjnk |
| 2025-01-16 02:20:30 +0100 | <jackdk> | Also, I would expect numeric code to be pure, and the "interface" to be "all these functions have the same type, so I can apply the one I want". If FFI or complex data structures are involved, perhaps that's not the case, but it's an ideal. I consider https://hackage.haskell.org/package/search-algorithms a beautiful package, because its interface is just functions. |
| 2025-01-16 02:18:31 +0100 | <jackdk> | The risk is that you do all this work and people bounce off your library because they don't understand your abstraction over all the implementations. I have seen it many times with `regex-*`: beginners come in with a problem and know that regexen are _a_ solution to that problem, and get completely lost. If your target audience includes people dipping into Haskell from other languages, there's a lot to be said for simple packages. |
| 2025-01-16 02:17:58 +0100 | Jeanne-Kamikaze | (~Jeanne-Ka@79.127.217.40) Jeanne-Kamikaze |
| 2025-01-16 02:16:20 +0100 | <jackdk> | I think it is easier to add that engineering later, should it prove necessary, than it will be to remove it should it prove unnecessary. It also won't leave a trail of obsolete packages on Hackage. YAGNI is a great rule of thumb, particularly if you can get your code into users' hands (via a soft-launch on a public repo) and find out whether you are really GNI. |
| 2025-01-16 02:16:20 +0100 | <Guest71> | That ad package does look like the class of problem that my library tries to solve, though |