To this point when we do anything on the web it will start purely as a CLI at m3o.com/cli and replicate the existing terminal experience, but maybe with some messaging like component so you can have nice emojis, rendering screenshots for graphs, etc.
When it comes to cheque signing (6-9 figure deals) from the people with the money, I'm sure at that point we'll have to do something to win them over but we're a long ways from it right now.
But do you have plans to release libraries for your API in major languages? Stringing together a bunch of shell commands in a bash script is also a little bit annoying... or at least much less friendly than doing the same thing with, say, a Python lib...
When I started in computing, CLI was the only option, and I don't miss those days.
Good luck with your endevours.
That's terrible - especially the part about the boss who cares more about toys than productivity and delivery. I hope you can find a way to demonstrate your skills to a talented team who in turn can offer sane working conditions.
It is terrible, but very common in my experience. It is the success recipe for Apple to a large degree.
Software houses are something different, but if you change to another industry as inhouse dev, the priorities change drastically. It has advantages and disadvantages, but in industry jobs outside of software people just cannot really evaluate the quality of your work. It just needs to look shiny to a degree.
You can, actually, but few companies bother to do it.
There are quite a few apps with macro functionality, where each GUI option is also a command and you can record those commands.
I imagine they have too few users who use that functionality so that's why they're so rare.
Xerox Computing / Lisp Machines >>>> UNIX CLI
My affinity for CLI boils down to Powershell capabilities over classical UNIX shells, including having a REPL and debugger.
the "only" really does imply that for me.
That's weird to me, but I'm in the embedded space. GUIs aren't scriptable (or aren't easily scriptable) which, for me and the teams I've been in, has basically been a no-go. If we can't script it, we can't automate it (easily), so we don't want to use it. A GUI + (good) CLI is a reasonable compromise. GUI helps us do some things, explore the tools/space, and then the CLI for all our automation.
> Finally for those pointy hair bosses a CLI only service is hard to sign a check for, since they can't really "see it" even if you send a great invoice.
Again, weird to me. But also still the embedded space. We buy tools with no GUI (or an awful one, but a decent CLI) all the time.
> If we can't script it, we can't automate it
That's the point! In my team in Amazon, a candidate unfamiliar (or hostile to) CLI would be a strong no hire.
As a CLI only cloud storage provider, I can tell you that the upside to this is dramatically reduced technical support requests.
Further, attack surface is also reduced. I sleep very soundly at night knowing that nothing but TCP22 can come into our cloud platform.
"90% of the developers and IT staff I work with are GUI only"
Please don't tell them about rsync.net. They'd hate it.
For example, while I am fairly proficient with the git cli and everything, I would never renounce to the comfort of gitk.
It's just simpler, faster and more intuitive.
I'm a cli junkie, but if I'm only going to do something every 6 months, it's not worth the mental effort to remember. I could be using that mental energy for learning obscure git subcommands and trying to shoehorn them into random situations I find myself in.