3 ms·

There is one tangential thing that I’ve thought about before—it would be nice if there was some way to encode this into the library ecosystem (ie crates.io) I h

There is one tangential thing that I’ve thought about before—it would be nice if there was some way to encode this into the library ecosystem (ie crates.io) I have no idea how this would be realistically possible though—it’s pretty clear that you can rely on categories that are statically verifiable like “no-std/no-alloc”. But what mechanism could be used to allow library consumers to distinguish between things like “laser focus on high perf/low-alloc” vs “prioritizes API over perf-at-all-costs” vs “this package is an experiment/Baby’s First Crate/shitpost” ?? They’re all valid choices for different consumers or usecases.

steveklabnik 4y ago
Yeah, there is something in this space for sure. I think one of the issues is time; code can start off as a fun experiment, but transform into one that's not, which maybe just means that it is metadata associated with a specific release, yadda yadda, but there's a lot here to think about. For sure. I recently have been accepting some PRs to some Ruby code that I wrote ten years ago that ended up being still in-use today. "Shitpost" or "baby's first crate" isn't accurate, but "hey I was very serious about this before but now it's not as high priority for me but that doesn't mean I abandoned it" is a tough thing to encode.
- evntdrvn 4y ago
  Absolutely true re evolution. That's why it would have to probably be crate keywords rather than categories, I'm thinking. This whole space about encoding library non-technical aspects like intent and status seems like it has a lot of possibilities. I wonder if there's prior art in other language ecosystems?
  - lcall 4y ago
    I replied just below, to another comment, with an idea. Not fleshed out well, but oh well.
  - steveklabnik 4y ago
    Perl has the Acme namespace for expressly silly projects, that’s the first thing that comes to mind…
    - lcall 4y ago
      Maybe defining the interesting axes (for each, one for whether it is considered a goal, the other for whether it has in fact prioritized that goal in practice; not saying whether it succeeded in others' eyes), and for each axis give a number 0-10 (or whatever) rating it, in the author's view. Then maybe users of the library can give similar ratings as they compare it with others. Or not.
tialaramex 4y ago
I think documentation is the right layer to express what is or is not a goal for the crate. Whether you met the goal is not something you as author can judge reliably. https://crates.io/crates/misfortunate https://crates.io/crates/misfortunate - is not intended to be used seriously. A redditor pointed out that arguably my Double (a smart pointer where the mutable and immutable references point to separate things and you can swap their places) might actually be useful! But I don't want you to depend on misfortunate::Double in your real software project - if that is useful (and maybe, with careful documentation, it is) you should give it a name suiting its purpose and include it in a crate of stuff that's intended to be used, not as something like a practical joke or thought experiment.

steveklabnik 4y ago

Yeah, there is something in this space for sure. I think one of the issues is time; code can start off as a fun experiment, but transform into one that's not, which maybe just means that it is metadata associated with a specific release, yadda yadda, but there's a lot here to think about. For sure. I recently have been accepting some PRs to some Ruby code that I wrote ten years ago that ended up being still in-use today. "Shitpost" or "baby's first crate" isn't accurate, but "hey I was very serious about this before but now it's not as high priority for me but that doesn't mean I abandoned it" is a tough thing to encode.

evntdrvn 4y ago
Absolutely true re evolution. That's why it would have to probably be crate keywords rather than categories, I'm thinking. This whole space about encoding library non-technical aspects like intent and status seems like it has a lot of possibilities. I wonder if there's prior art in other language ecosystems?
- lcall 4y ago
  I replied just below, to another comment, with an idea. Not fleshed out well, but oh well.
- steveklabnik 4y ago
  Perl has the Acme namespace for expressly silly projects, that’s the first thing that comes to mind…
  - lcall 4y ago
    Maybe defining the interesting axes (for each, one for whether it is considered a goal, the other for whether it has in fact prioritized that goal in practice; not saying whether it succeeded in others' eyes), and for each axis give a number 0-10 (or whatever) rating it, in the author's view. Then maybe users of the library can give similar ratings as they compare it with others. Or not.

tialaramex 4y ago

I think documentation is the right layer to express what is or is not a goal for the crate. Whether you met the goal is not something you as author can judge reliably. https://crates.io/crates/misfortunate https://crates.io/crates/misfortunate - is not intended to be used seriously. A redditor pointed out that arguably my Double (a smart pointer where the mutable and immutable references point to separate things and you can swap their places) might actually be useful! But I don't want you to depend on misfortunate::Double in your real software project - if that is useful (and maybe, with careful documentation, it is) you should give it a name suiting its purpose and include it in a crate of stuff that's intended to be used, not as something like a practical joke or thought experiment.