I disagree. It’s futurism, so it could be wrong, but the idea that the easiest to use UI for apps has switched from a GUI to a command line is interesting. It had been observed for some time that Google is like a CLI but this takes it to a new level. Will it actually work out? Time will tell. But if you’re thinking about where the business opportunities are for programmers, it would be silly to not at least examine if LLMs could help your project.
It misses the key thing that drove GUI adoption in the first place: discoverability. In early CLIs, it was easy to list the full set of commands available in an OS and then full set of options for each one. In DOS, I think it took two screens to list every single command available in the default install. As CLIs get bigger, this become harder because their designs were verb-noun. GUIs make it easy to show the set of verbs that are possible to apply to a specific object, which lets the user discover what the tool can do much more easily. It’s possible to design noun-verb CLIs (PowerShell has enough type info to do this, but decided to make some very poor choices from the perspective of usability). A natural-language prompt is the absolute worst thing here because it gives the user no information about what is possible and relies on their ability to scope queries to something that might work.
I think LLMs change the calculus here because it’s feasible to say, “I’m trying to get the average total value of all the monthly reports” and the LLM can shoot back “Use this code AVG(C5:X5) SUM(B5:B18)”. You don’t have to know that getting the average is AVG and getting the total is SUM. You also don’t have to preprogram in all the synonyms for the functions. Just write a bunch of documentation for one shot learning (and that can also be AI assisted) and let it go.
Typing is still tedious and time-consuming for an average user. It might be more convenient combined with voice, but that depends on user preferences and environment (e.g. open-plan office).
So I’d expect basic operations to still use classic buttons. Instructions may be useful for learning (“show me how…”) or tasks big and complicated enough that it’s easier to describe and delegate them than to do them yourself. However, the AI needs to be really good at this, so that checking the results and correcting it isn’t worse than doing it yourself.
Humans are terrible at writing instructions for others to do, AI included. Usually, they can’t break down a task into atomic units of completion. I suspect this will make making an AI do something harder, because at best, it’s a delegation problem.
The point of the current LLM tools is that it is possible to iterate. So there can be some back and forth between the user and the AI. The AI can even do the breaking down of a task for the user.
This is most likely not faster than a power user that knows how to click the right buttons or type in the right commands. But it is probably a lot faster and definitely a lot nicer experience for everyone else.
And we’re just witnessing the early beginnings of this kind of human machine interfaces. Imagine that the AI that’s assisting you has a personal profile of you where it remembers years of context about who you are and what you work on and what your current task is. Add on top of this the addition of voice and even body language through the web cam and then imagine what kind of interactions are possible.
I had a thought the other day wondering if it would be useful to generate loose GUI wrappers alongside CLIs.
For instance you could hook into a CLAP struct (Rust) and have it render some minimalist buttons. I think ideally it would also show you the cli command it generates and then it would also teach the user to be more comfortable with the CLIs.
I wrote something you might find interesting in my blog just a couple months ago: http://dpldocs.info/this-week-in-d/Blog.Posted_2023_01_16.html#some-thoughts-on-uis basically i think for a lot of cases if you make your code api usable then you can reflect over it to make a variety of different uis to express it with a few declarative annotation helpers. I’ve done similar things in isolation already but never fully integrated them… and i think if they were it could be quite interesting. My blog post has a few illustrations for a web/gui/cli thing generated from a function.
This is a puff piece with no relevant content.
I disagree. It’s futurism, so it could be wrong, but the idea that the easiest to use UI for apps has switched from a GUI to a command line is interesting. It had been observed for some time that Google is like a CLI but this takes it to a new level. Will it actually work out? Time will tell. But if you’re thinking about where the business opportunities are for programmers, it would be silly to not at least examine if LLMs could help your project.
It misses the key thing that drove GUI adoption in the first place: discoverability. In early CLIs, it was easy to list the full set of commands available in an OS and then full set of options for each one. In DOS, I think it took two screens to list every single command available in the default install. As CLIs get bigger, this become harder because their designs were verb-noun. GUIs make it easy to show the set of verbs that are possible to apply to a specific object, which lets the user discover what the tool can do much more easily. It’s possible to design noun-verb CLIs (PowerShell has enough type info to do this, but decided to make some very poor choices from the perspective of usability). A natural-language prompt is the absolute worst thing here because it gives the user no information about what is possible and relies on their ability to scope queries to something that might work.
I think LLMs change the calculus here because it’s feasible to say, “I’m trying to get the average total value of all the monthly reports” and the LLM can shoot back “Use this code AVG(C5:X5) SUM(B5:B18)”. You don’t have to know that getting the average is AVG and getting the total is SUM. You also don’t have to preprogram in all the synonyms for the functions. Just write a bunch of documentation for one shot learning (and that can also be AI assisted) and let it go.
Typing is still tedious and time-consuming for an average user. It might be more convenient combined with voice, but that depends on user preferences and environment (e.g. open-plan office).
So I’d expect basic operations to still use classic buttons. Instructions may be useful for learning (“show me how…”) or tasks big and complicated enough that it’s easier to describe and delegate them than to do them yourself. However, the AI needs to be really good at this, so that checking the results and correcting it isn’t worse than doing it yourself.
Humans are terrible at writing instructions for others to do, AI included. Usually, they can’t break down a task into atomic units of completion. I suspect this will make making an AI do something harder, because at best, it’s a delegation problem.
The point of the current LLM tools is that it is possible to iterate. So there can be some back and forth between the user and the AI. The AI can even do the breaking down of a task for the user.
This is most likely not faster than a power user that knows how to click the right buttons or type in the right commands. But it is probably a lot faster and definitely a lot nicer experience for everyone else.
And we’re just witnessing the early beginnings of this kind of human machine interfaces. Imagine that the AI that’s assisting you has a personal profile of you where it remembers years of context about who you are and what you work on and what your current task is. Add on top of this the addition of voice and even body language through the web cam and then imagine what kind of interactions are possible.
Agreed.
I had a thought the other day wondering if it would be useful to generate loose GUI wrappers alongside CLIs.
For instance you could hook into a CLAP struct (Rust) and have it render some minimalist buttons. I think ideally it would also show you the cli command it generates and then it would also teach the user to be more comfortable with the CLIs.
I wrote something you might find interesting in my blog just a couple months ago: http://dpldocs.info/this-week-in-d/Blog.Posted_2023_01_16.html#some-thoughts-on-uis basically i think for a lot of cases if you make your code api usable then you can reflect over it to make a variety of different uis to express it with a few declarative annotation helpers. I’ve done similar things in isolation already but never fully integrated them… and i think if they were it could be quite interesting. My blog post has a few illustrations for a web/gui/cli thing generated from a function.