3 ms·

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

by 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.

by veidr 4y ago

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.