5 ms·

> We replaced it with our own argument parsing once we noticed that adopting clap was taking more code than doing it ourselves. I feel like it's obvious that t

> We replaced it with our own argument parsing once we noticed that adopting clap was taking more code than doing it ourselves. I feel like it's obvious that there are two sides to this echoed throughout the "programming" community: 1. Don't pull a package in for what you can do yourself because it might have 500 dependenices for no good reason 2. Don't roll your own, use something off-the-shelf third-party that is actively maintained, open-source, well written/easily usable/fleshed out, etc. They conflict...

cryptos 3y ago
Yeah, but that is what makes engineering interesting. You always have to find the right balance with your trade-offs.
steveklabnik 3y ago
It is true that you cannot simply repeat maxims others have declared and expect that the job gets done well. Our profession (like many, many others, if not all!) requires judgement to do the best job. Different situations may call for different decisions.
- MuffinFlavored 3y ago
  > Our profession (like many, many others, if not all!) requires judgement to do the best job. And is almost permanently open to retrospect + disagreement of "you shouldn't have done that this way and followed maxim A, you should've followed maxim B instead" and vice versa... :)
  - steveklabnik 3y ago
    Yeah, time is one of those factors that can change, and tip the scales one way or the other.
jbverschoor 3y ago
They don't conflict: 1+2 -> Pull a package that is well maintained and doesn't use a ton of packages. The problem is the language platform / "culture", for example js
- MuffinFlavored 3y ago
  But in this post we're seeing this "mindset" trickle to the Rust ecosystem, for something as "complicated" as command-line argument parsing
  - ekidd 3y ago
    Clap is a really fantastic command-line argument parser, especially using the "derive macro" they now include. Once you start dealing with git-like subcommands, and other complex cases, it Just Works. You get help, short and long options, defaults, repeated arguments, deserialization to custom types, etc. Essentially everything is accessible with a couple of lines of code. Life's too short to build all of this each time. I'm perfectly happy to ship 2-5 MB zip archives, which is where a lot of my more complicated Rust tools wind up.
    - epage 3y ago
      (maintainer of clap) In this situation, if they were truly concerned about clap, I think they should have gone down to lexopt (https://docs.rs/lexopt/ https://docs.rs/lexopt/) rather than roll their own
    - cozzyd 3y ago
      If every odd utility is several megabytes, good luck fitting an OS in a meager eMMC.
  - mort96 3y ago
    I believe it actually has a lot more to do with the tools than some "mindset" in the community. You don't see this sort of thing in C++ really, because deep trees of transitive dependencies are painful. While Rust... has pretty much the exact same package management style as Node, so it doesn't surprise me that it has similar results.
arp242 3y ago
I don't think they necessarily conflict, and good programmers will pick what's appropriate for the context. The problems start when either path 1 or 2 gets followed dogmatically. I do have to say I'm closer to 2 than 1. Most code really isn't that hard to write, and just solving just your own problems instead of the general case can simplify things a lot. And the code is 100% under your control, which can also have its advantages. Some programmers seem afraid to write code. The amount of contortions I've seen folks pull just to re-use some package that wasn't really a good fit (or just wasn't a good package to start with) has at times been bewildering. In the most extreme case I replaced a badly working solution someone spent half a year on with something that worked well in just a week, just writing it from scratch (add another week or two for bugfixes, so that's 3 weeks). On the other hand I've also seen people NIH the silliest of things. In the most extreme case here they had done their own templating, i18n, database layer – the works. That would have been okay if it worked well, but all of it was ad-hoc junk. For example they did their own flag parsing for $reasons, and only "--flag=value" worked and not "--flag value". I spent quite some time being confused by this because it also didn't error on the wrong usage (it just did the wrong thing...) They gave me shit for nOt REadINg tHe dOCumENtAtiOn. Like, mate, I've never seen any tool where "--a=b" works but not "--a b" before or since, and I just used the space-variant out of habit without thinking. They didn't fix the flag parser, and I wasn't allowed to either. Didn't work long with these spanners. Nothing wrong with doing your own flag parsing necessarily; I did my own flag parsing for Go because I don't like the stdlib package and others I could find. Waste of time? Maybe. But it's my time to waste and at least it works well. The problem with NIH usually isn't the NIH part, but shitty programmers writing shitty code part.
deleted 3y ago
[deleted]

cryptos 3y ago

Yeah, but that is what makes engineering interesting. You always have to find the right balance with your trade-offs.

steveklabnik 3y ago

It is true that you cannot simply repeat maxims others have declared and expect that the job gets done well. Our profession (like many, many others, if not all!) requires judgement to do the best job. Different situations may call for different decisions.

MuffinFlavored 3y ago
> Our profession (like many, many others, if not all!) requires judgement to do the best job. And is almost permanently open to retrospect + disagreement of "you shouldn't have done that this way and followed maxim A, you should've followed maxim B instead" and vice versa... :)
- steveklabnik 3y ago
  Yeah, time is one of those factors that can change, and tip the scales one way or the other.

jbverschoor 3y ago

They don't conflict: 1+2 -> Pull a package that is well maintained and doesn't use a ton of packages. The problem is the language platform / "culture", for example js

MuffinFlavored 3y ago
But in this post we're seeing this "mindset" trickle to the Rust ecosystem, for something as "complicated" as command-line argument parsing
- ekidd 3y ago
  Clap is a really fantastic command-line argument parser, especially using the "derive macro" they now include. Once you start dealing with git-like subcommands, and other complex cases, it Just Works. You get help, short and long options, defaults, repeated arguments, deserialization to custom types, etc. Essentially everything is accessible with a couple of lines of code. Life's too short to build all of this each time. I'm perfectly happy to ship 2-5 MB zip archives, which is where a lot of my more complicated Rust tools wind up.
  - epage 3y ago
    (maintainer of clap) In this situation, if they were truly concerned about clap, I think they should have gone down to lexopt (https://docs.rs/lexopt/ https://docs.rs/lexopt/) rather than roll their own
  - cozzyd 3y ago
    If every odd utility is several megabytes, good luck fitting an OS in a meager eMMC.
- mort96 3y ago
  I believe it actually has a lot more to do with the tools than some "mindset" in the community. You don't see this sort of thing in C++ really, because deep trees of transitive dependencies are painful. While Rust... has pretty much the exact same package management style as Node, so it doesn't surprise me that it has similar results.

arp242 3y ago

I don't think they necessarily conflict, and good programmers will pick what's appropriate for the context. The problems start when either path 1 or 2 gets followed dogmatically. I do have to say I'm closer to 2 than 1. Most code really isn't that hard to write, and just solving just your own problems instead of the general case can simplify things a lot. And the code is 100% under your control, which can also have its advantages. Some programmers seem afraid to write code. The amount of contortions I've seen folks pull just to re-use some package that wasn't really a good fit (or just wasn't a good package to start with) has at times been bewildering. In the most extreme case I replaced a badly working solution someone spent half a year on with something that worked well in just a week, just writing it from scratch (add another week or two for bugfixes, so that's 3 weeks). On the other hand I've also seen people NIH the silliest of things. In the most extreme case here they had done their own templating, i18n, database layer – the works. That would have been okay if it worked well, but all of it was ad-hoc junk. For example they did their own flag parsing for $reasons, and only "--flag=value" worked and not "--flag value". I spent quite some time being confused by this because it also didn't error on the wrong usage (it just did the wrong thing...) They gave me shit for nOt REadINg tHe dOCumENtAtiOn. Like, mate, I've never seen any tool where "--a=b" works but not "--a b" before or since, and I just used the space-variant out of habit without thinking. They didn't fix the flag parser, and I wasn't allowed to either. Didn't work long with these spanners. Nothing wrong with doing your own flag parsing necessarily; I did my own flag parsing for Go because I don't like the stdlib package and others I could find. Waste of time? Maybe. But it's my time to waste and at least it works well. The problem with NIH usually isn't the NIH part, but shitty programmers writing shitty code part.

deleted 3y ago

[deleted]