5 ms·

Asdf is a good idea in theory and pretty okay considering it's in Bash, but the execution is quite lackluster. I'm glad the maintainer is focusing on performanc

Asdf is a good idea in theory and pretty okay considering it's in Bash, but the execution is quite lackluster. I'm glad the maintainer is focusing on performance, but there are other areas that prevent me from using the tool: - asdf uses way more commands than it needs to. Instead of glob pattern matching for files, it reads the output of `ls` (and _many_ very similar mistakes) - When running functions, the output tends to be collected using $(). Since this is done so much, this realllyyyy slows down execution since subshell invocations are slowwww in bash. Better is to set the global variable `REPLY` and use that directly from the callee - The command line interface is kind of verbise and clunky and a little unintuitive - There are too many separate plugins to use and download. Too much code duplication between plugins I hope this doesn't sound like a laundry list of gripes, but just things to improve upon for the maintainers - I understand how hard it is to write Bash that works everywhere. Personally, I've opted to build my own (partial) solution that implements these suggestions at https://github.com/hyperupcall/woof https://github.com/hyperupcall/woof, but my hope is that asdf will become substantially better over the years

lapser 4y ago
Plugins are a trade off. It's either code duplication, or put it all inside core, in which case people will complain that it contains things they don't care about ("it's bloated"). Rest are valid, I guess. But wouldn't your efforts be better spent helping improve asdf, instead of creating a whole new system?
- hyperupcall 4y ago
  Your point about plugins is valid, but I believe a good middleground is having the plugins in core, but disabling them by default. Having an interface to enable particular plugins or plugin groups would be useful in this scenario too. I thought about contributing to asdf, but unfortunately many of my pain points are deeply integrated within the design and architecture of the code itself. For example, since there is a lot of code duplication within plugins, it would be good to create a "plugin API" (I think that has recently been proposed). But that would be very time consuming to implement not just because of the already-existing code, but also because essentially every plugin is its own separate repository, usually maintained by different people. So I'd think it's not too hard to imagine how difficult making broad improvements or changes will be. There's also the fact that writing (decently) fast and cross-platform Bash codes necessitates an essentially orthogonal coding style, which would be at odds with asdf's coding style. Even though the `REPLY` and `$()` is probably 80% of it, I would also like to take advantage of my `bash-core` and `bash-term` Bash libraries, which really wouldn't be possible in asdf (implementation-wise, that would necessitate the use of my Bash package manager)

lapser 4y ago

Plugins are a trade off. It's either code duplication, or put it all inside core, in which case people will complain that it contains things they don't care about ("it's bloated"). Rest are valid, I guess. But wouldn't your efforts be better spent helping improve asdf, instead of creating a whole new system?

hyperupcall 4y ago
Your point about plugins is valid, but I believe a good middleground is having the plugins in core, but disabling them by default. Having an interface to enable particular plugins or plugin groups would be useful in this scenario too. I thought about contributing to asdf, but unfortunately many of my pain points are deeply integrated within the design and architecture of the code itself. For example, since there is a lot of code duplication within plugins, it would be good to create a "plugin API" (I think that has recently been proposed). But that would be very time consuming to implement not just because of the already-existing code, but also because essentially every plugin is its own separate repository, usually maintained by different people. So I'd think it's not too hard to imagine how difficult making broad improvements or changes will be. There's also the fact that writing (decently) fast and cross-platform Bash codes necessitates an essentially orthogonal coding style, which would be at odds with asdf's coding style. Even though the `REPLY` and `$()` is probably 80% of it, I would also like to take advantage of my `bash-core` and `bash-term` Bash libraries, which really wouldn't be possible in asdf (implementation-wise, that would necessitate the use of my Bash package manager)