Newest at the top
| 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 |
| 2025-01-16 02:14:55 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 244 seconds) |
| 2025-01-16 02:14:20 +0100 | <jackdk> | sm: +1, again |
| 2025-01-16 02:14:20 +0100 | <Guest71> | So my theory is that for initial setup my users would pull an umbrella package that re-exports the smaller packages, benchmark their code, pick an implementation (or implementations) and then change their dependencies to only pull the one implementation. |
| 2025-01-16 02:14:04 +0100 | <jackdk> | Knowing little about your problem space, and having tremendous respect for Ed's library design sensibilities, I would lean towards following `ad` as a model over `regex-*` since it sounds closer to what you want to do. Note also that the Kmettverse of category-theory-flavoured packages started as a single `category-extras` package that was split when it became too large |
| 2025-01-16 02:12:52 +0100 | <haskellbridge> | <sm> if you unnecessarily proliferate packages and it's not providing real benefit, I promise some day as maintainer you will rue the day |
| 2025-01-16 02:10:53 +0100 | <jackdk> | Especially if the "experimentation phase" means "add and benchmark them all" and that's something that most users will want to do. |
| 2025-01-16 02:10:42 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2025-01-16 02:10:37 +0100 | <haskellbridge> | <sm> but YMMV and you can always split up the package later as jack says |
| 2025-01-16 02:10:24 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-01-16 02:10:19 +0100 | <haskellbridge> | <sm> especially if they're going to be comparing implementations as you say |
| 2025-01-16 02:10:01 +0100 | <haskellbridge> | <sm> most users will rather pull one simple package than have to think about which variant they need |