3 ms·

At the risk of sounding like an HN contrarian: I find it fascinating how many projects reinvent the wheel with a complex solution for something that's already e

by imiric 4y ago

At the risk of sounding like an HN contrarian: I find it fascinating how many projects reinvent the wheel with a complex solution for something that's already easily possible, while introducing all sorts of limitations and security issues. This seems like a repository of—hopefully verified—NodeJS scripts, and a standard library of common tasks, presented by a slick graphical launcher. The appeal seems to be that it's cross-platform (yet no Linux?), and that users can write their own scripts. But... Other than the standard library, which might be useful, all of this is already possible. Just write your scripts _in any language_ and launch them via the universal launcher: the command line. Or, if you want to get fancy, use any number of script launchers, like rofi on Linux. I'm curious to know what this tool does differently or better than what's currently out there.

synergy20 4y ago
plus, rust-rewrite-all-your-utilities efforts, what rust really adds is syntax highlighting and esp be .gitignore aware but I now need remember quite a few different option flags. admittedly, the old unix tools(e.g. find,grep,etc) should had .gitignore-awareness etc a few years back, which is still undone.
veidr 4y ago
At the risk of sounding myself like a knee-jerk HN meta-cliché... you absolutely do sound like the famous Dropbox quote from here, or CmdrTaco's comment on the original iPod. Absolutely every single tool in this space is re-inventing the wheel. The entire concept of this kind of system automation scripting is, "do stuff that you could already do — but more conveniently." Now "more convenient" is maybe a slippery concept, but it could mean: - the same scripts work on different platforms - the interface for creating, managing, and executing scripts is good - include a good core library of building blocks to make tedious foundational things quick - generate a lot of user support/enthusiasm, resulting in e.g. lots of scripts, good forum or a lot of blog posts or docs, that make it easier to work with - offer UX or design elegance that somehow warms users' cockles - start with really good defaults You could do any one of those things well and make the world better. I currently use Raycast on Mac and it's cool, but it's Mac-only. On Linux I use Albert, but am still looking around (for years). The built-in commands of these tools are appreciated, but even when they are just invoking scripts I myself wrote, as a user I still want any help I can get in organizing my scripts and commands, syncing them across my machines, restoring them when I set up a new machine, and easily editing them in a convenient way that works well with revision tracking. Plus (in theory) I'd love to see other features, like easy ways to share useful automations with friends/family/whoever, etc. My point is that there is absolutely nothing wrong with reinventing the wheel if you can make a better wheel, especially in the context of day-to-day user interaction automation scripting. (For me personally, the potentially exciting bullet point for this particular system is "cross platform" — even if Linux is still WIP.)
- imiric 4y ago
  Thanks. I don't want to be _that_ guy, so I appreciate the different perspective. I can see the appeal of a standard library of common tasks to make certain workflows more convenient. And this tool is certainly an improvement over existing proprietary tools that are not as easily extensible. My main criticism is that given that it's "made for developers", an audience that technical can already do all of these things. And if the intention is to make things more convenient for them, publishing a NodeJS library would accomplish the same thing, without reinventing the way they already launch scripts. I suppose the difference of opinion boils down to the subjective perception of "convenience". The workflow I use to solve these problems is convenient for _me_, but might not be for someone else. So it's difficult to relate to alternative workflows, but at the same time I shouldn't be dismissive of the fact that it works for others.
lanza 4y ago
> But... Other than the standard library, which might be useful, all of this is already possible. Just write your scripts _in any language_ and launch them via the universal launcher: the command line. How do you not understand why people would want to do something faster than they typically do it?

by imiric 4y ago

synergy20 4y ago

plus, rust-rewrite-all-your-utilities efforts, what rust really adds is syntax highlighting and esp be .gitignore aware but I now need remember quite a few different option flags. admittedly, the old unix tools(e.g. find,grep,etc) should had .gitignore-awareness etc a few years back, which is still undone.

veidr 4y ago

At the risk of sounding myself like a knee-jerk HN meta-cliché... you absolutely do sound like the famous Dropbox quote from here, or CmdrTaco's comment on the original iPod. Absolutely every single tool in this space is re-inventing the wheel. The entire concept of this kind of system automation scripting is, "do stuff that you could already do — but more conveniently." Now "more convenient" is maybe a slippery concept, but it could mean: - the same scripts work on different platforms - the interface for creating, managing, and executing scripts is good - include a good core library of building blocks to make tedious foundational things quick - generate a lot of user support/enthusiasm, resulting in e.g. lots of scripts, good forum or a lot of blog posts or docs, that make it easier to work with - offer UX or design elegance that somehow warms users' cockles - start with really good defaults You could do any one of those things well and make the world better. I currently use Raycast on Mac and it's cool, but it's Mac-only. On Linux I use Albert, but am still looking around (for years). The built-in commands of these tools are appreciated, but even when they are just invoking scripts I myself wrote, as a user I still want any help I can get in organizing my scripts and commands, syncing them across my machines, restoring them when I set up a new machine, and easily editing them in a convenient way that works well with revision tracking. Plus (in theory) I'd love to see other features, like easy ways to share useful automations with friends/family/whoever, etc. My point is that there is absolutely nothing wrong with reinventing the wheel if you can make a better wheel, especially in the context of day-to-day user interaction automation scripting. (For me personally, the potentially exciting bullet point for this particular system is "cross platform" — even if Linux is still WIP.)

imiric 4y ago
Thanks. I don't want to be _that_ guy, so I appreciate the different perspective. I can see the appeal of a standard library of common tasks to make certain workflows more convenient. And this tool is certainly an improvement over existing proprietary tools that are not as easily extensible. My main criticism is that given that it's "made for developers", an audience that technical can already do all of these things. And if the intention is to make things more convenient for them, publishing a NodeJS library would accomplish the same thing, without reinventing the way they already launch scripts. I suppose the difference of opinion boils down to the subjective perception of "convenience". The workflow I use to solve these problems is convenient for _me_, but might not be for someone else. So it's difficult to relate to alternative workflows, but at the same time I shouldn't be dismissive of the fact that it works for others.

lanza 4y ago

> But... Other than the standard library, which might be useful, all of this is already possible. Just write your scripts _in any language_ and launch them via the universal launcher: the command line. How do you not understand why people would want to do something faster than they typically do it?