being part of an interconnected commons is good actually god forbid we shirk a false sense of independence for even a moment https://mastodon.social/@dabeaz/113318518803522463

d@nny "disc@" mc²

@aud i was literally going to say that but i do think that one is just a teensy bit overused or misapplied (although understandably so). maybe not, actually. but there is value in novel cryptography as long as you're extremely careful about what novelty you introduce and consider changes to be an extensive research project instead of an agile checkbox bc people could die otherwise

d@nny "disc@" mc²

@aud so maybe it's not actually overused but i think people shouldn't be scared to do crypto research and only leave it to "experts" who often have their own ulterior motives like surveillance is all

Asta [AMP]

@[email protected] it's true! It was a bit of a lazy choice on my part, for sure. The blanket statement that every import is a missed chance to learn is easily proven false, though, so I definitely picked the most obvious "there will be blood" example. There's definitely more nuance about when to use code vs. when you should just write it up yourself.

Asta [AMP]

@[email protected] AGREED HOLY SHIT

Asta [AMP]

@[email protected] that's a perfect way to put it. If I'm not actively working on implementing or experimenting with novel crypto and I need something that works... import for the love of fuck. On the other hand, if I AM doing something that is novel or requires atypical usage, well...

But I also think it's wrong to say that importing denies you the opportunity to learn something. Sometimes, I think, there's actually more mental overhead for me for importing because then I have to A. read the documentation to see how it works, which requires... B. understanding the library author's mental model of how this concept can be done in code, which isn't necessarily at odds with how I've considered the problem... but also could be. And translating my own code to fit with their implementation could be a lot of work.

Suffice to say, a lot of learning and thinking is required regardless of whether I import or choose to write my own. I think my experience with using the activitypub federation crate in rust (from the lemmy people) highlights that pretty well: they used a very, very different model for representing AP than how I think of it and I just found it wasn't going to work and I wasn't going to like the code nearly as much, so I bailed on using it.

d@nny "disc@" mc²

@aud reading the source code (often by cloning the repo) is my secret weapon. so often i'll end up forking slightly and then either contribute my changes back if i really need them or often i can figure out how to avoid them and go back to using a published release

d@nny "disc@" mc²

@aud this is how my signal work started lol

Asta [AMP]

@[email protected] ooooh, I should consider doing a fork more often. That's a good idea. I often read the source code, too, to see how they implement things and how the data is moved about and manipulated in their code.

d@nny "disc@" mc²

@aud also making docs changes!! see e.g. https://github.com/rust-lang/regex/pull/861

d@nny "disc@" mc²

@aud but then see how later upon discussion i found regex-automata wouldn't work for my use case! https://github.com/rust-lang/regex/discussions/1167#discussioncomment-8585027

Asta [AMP]

@[email protected] I really need to be more active with the libraries and things I use. I've had a number of bad experiences involving PRs and questions in the tech world to where I tend to just use the software as is and work around it or ditch it, if necessary, without even thinking about the possibility of making fixes/suggestions/etc. I just assume they'll brush me off, which... well.

Still, just because it's happened a lot before (and in a job setting) doesn't mean it's always going to happen or that I should let myself be held back from contributing or becoming involved. Blehhhhh.

Asta [AMP]

@[email protected] I really need to be more active with the libraries and things I use. I've had a number of bad experiences involving PRs and questions in the tech world to where I tend to just use the software as is and work around it or ditch it, if necessary, without even thinking about the possibility of making fixes/suggestions/etc. I just assume they'll brush me off, which... well.

Still, just because it's happened a lot before (and in a job setting) doesn't mean it's always going to happen or that I should let myself be held back from contributing or becoming involved. Blehhhhh. I guess I'm a little shy about it due to PRs sometimes being used as a gatekeeping method. It's like, I just spent weeks on this, and I don't necessarily want to go through the PR process only to find that nothing I do will be good enough for them to accept not because of the work, but because of... well.

d@nny "disc@" mc²

@aud oh yeah i mean worst case i just fork it. nobody mentions that forking is not remotely as difficult as maintaining the base software bc you can pull in their changes except for the parts you need (this again is how i have been doing my signal work, and how i was going to do the zip crate until the new maintainer started accepting my changes)

d@nny "disc@" mc²

@aud my pip PRs have taken many months to get in (multiple years in some cases) but i think they're still good so i'm doing the work and getting community buy-in to accept them but rejection is always a possibility and if it's not worth your time then that's their loss and you make your own fork, or rewrite from scratch, or contribute to a different project. pip maintainers fucking rock and are terribly reasonable (they just have very little free time) so i have no problem continuing to push for stuff to get in

d@nny "disc@" mc²

@aud however i also feel that people often misinterpret maintainers saying "i need these changes to be made" as a rejection instead of a polite request to make the code easier to accept as part of the natural back-and-forth of contributing code that the maintainer will have to maintain unless you have already established yourself as a maintainer who can be trusted to fix issues that come up

Asta [AMP]

@[email protected] I definitely agree. I usually consider those positive PR cases (and have definitely had them, for the record!) and differentiate between when you do everything they ask and... well, I'm also talking in a work context project, where they start "nitpicking" things that you've seen them completely ignore in PRs from other people. Or do themselves. In the code. Or even try and "nitpick" something that pops up in the PR that is literally you emulating the style of code they've had.

Asta [AMP]

@[email protected] (or in one case, literally "nitpick" something they did that happened to show up as visible in the code preview of your PR because they're clearly barely reading it).