31–40 of 62 posts
1. Appeal to some of the crowd here 2. Potentially run in the background as meta layer for llm ( as crazy as that sounds, the annoying reality is that it is happening already, but in the most annoying way possible 'worst of all worlds' version )
CLI is cool but this won't work in real life, focus your energy building something else.
The text-based software that would eat work management is one that embraces the incumbents rather than avoid them. I want a bidirectional SaaS YAML/JSON adapter. So that I can push and pull our CRM (and other SaaS utilities like project management) into a common (schematized) YAML format. The YAML then can be analyzed and modified using LLMs and/or stored in git. And then use the bidirectional sync to reconcile confl…
Agreed, this is on my mind as well. Thinking of Terraform, you have data blocks that can grab data from an external source. Still trying to grok what would be a convenient way of doing something like this - whether that gets generated to DSL, or if data pulled in dynamically as you build the org graph... Having your plain-text workspace as a unified structural source where you pull in data from external systems would…
Spent ages building my own work management system only to realise I was just taking the scenic route to eMacs.
Getting people to use the terminal to do things instead of the bloatware produced by Google/Microsoft tools is almost impossible... I live in the terminal, but most people in my company, including developers rather stay away from it
Earlier quoted context omitted.
To state the obvious (sorry): (1) Command lines lack the discoverability element of GUIs (and TUIs), where the available choices are typically laid out in front of you. Just look at the command "firm -c list contact" in the screenshot in the linked readme - no doubt it's sensible, but you wouldn't just type it in out of nowhere. You could argue that good docs fix this, but they'll never be a substitute. (Silly analog…
I don't disagree with you at all, but my biggest hangup with GUI-based software is twofold: 1. It tends to be bloated, with developers slapping framework upon framework, creating a mess of background wiring that is prone to a dictionary's worth of issues that will either frustrate the user or confound the person maintaining it. 2. UX Designers approach their jobs incorrectly; they assume they are smarter than the use…
This is just as true for CLIs.
Getting people to use the terminal to do things instead of the bloatware produced by Google/Microsoft tools is almost impossible... I live in the terminal, but most people in my company, including developers rather stay away from it
To state the obvious (sorry): (1) Command lines lack the discoverability element of GUIs (and TUIs), where the available choices are typically laid out in front of you. Just look at the command "firm -c list contact" in the screenshot in the linked readme - no doubt it's sensible, but you wouldn't just type it in out of nowhere. You could argue that good docs fix this, but they'll never be a substitute. (Silly analog…
Allows for a GUI for tasks that need that better context or hand holding. But then the CLI is there when there is a workflow the GUI doesn't support comes up. Bonus of scripting being possible with the CLI too.
Challenges this approach has is that you have to have a test suite that exercises both workflows or due diligence to make sure they both work as development continues.
Also not all programs can be done acceptably with a CLI. Real time 3d games are an easy example of a GUI only task.
Which is well timed because I've been increasingly leaning more into Tana but also being like "it would really suck if this tool goes away". Having something that has the same ergonomics of Tana but is more open is really interesting.
I love little CLI tools for managing productivity