Confession: I mostly hate command lines and I think the obsession with them in the tech world is basically a cultural signifier and little else.
-
@kevin GUIs are harder to write and that's its own problem. i was really into electron back when it was called atom-shell for this reason. we do not need to accept the externalities of electron to improve the situation
@kevin "i guess GUIs are too hard for you" can be an appropriately biting response to someone who cba and acts tuff bc they don't know how to write better user interfaces
-
@kevin also you just deleted a post presumably to edit it and before i forget i wanted to let you know the term for the phenomenon you described is "concern trolling"
@hipsterelectron yeah I just deleted because I try to not be too antagonistic.
-
@hipsterelectron yeah I just deleted because I try to not be too antagonistic.
@kevin you are more patient than me at this time
-
@kevin have i shown you https://codeberg.org/cosmicexplorer/corporeal yet
@hipsterelectron oh! This is fascinating work. I’m going to dig into this very soon, this is of direct interest for me!
-
@hipsterelectron oh! This is fascinating work. I’m going to dig into this very soon, this is of direct interest for me!
@kevin working on this right now. i have a bibliography and some criticism of the ziv-lempel approach here https://codeberg.org/cosmicexplorer/corporeal/src/branch/main/literature i've been told ziv has some good work on error correction but i'm not a fan of their stream compression at all
-
@kevin working on this right now. i have a bibliography and some criticism of the ziv-lempel approach here https://codeberg.org/cosmicexplorer/corporeal/src/branch/main/literature i've been told ziv has some good work on error correction but i'm not a fan of their stream compression at all
@kevin i'm doing a C implementation not rust for complicated ideological reasons (spent a decade on rust, i need this to work in many build environments, rust is not portable) and i'm not using zstd because the format is weird and possibly enables certain backdoors but i'm using the compression techniques it employs
-
@kevin i'm doing a C implementation not rust for complicated ideological reasons (spent a decade on rust, i need this to work in many build environments, rust is not portable) and i'm not using zstd because the format is weird and possibly enables certain backdoors but i'm using the compression techniques it employs
@hipsterelectron I’m sure you have looked at it, but I’d be very curious to see comparisons with SCSU and BOCU. By the way, as a fun fact, Symbian stored all strings as SCSU
-
@hipsterelectron I’m sure you have looked at it, but I’d be very curious to see comparisons with SCSU and BOCU. By the way, as a fun fact, Symbian stored all strings as SCSU
@kevin not at all, looking those up now
-
@kevin not at all, looking those up now
@hipsterelectron let me know what you think!
-
@kevin GUIs are harder to write and that's its own problem. i was really into electron back when it was called atom-shell for this reason. we do not need to accept the externalities of electron to improve the situation
@hipsterelectron @kevin guis and clis fit two different spaces and i don't think saying "cli bad gui good", nor the opposite, is any productive tbh
they function differently, present information differently, guis are reactive, have more options to express complex information, but are very limited in non-interactive, or learnt, usage (as usage is often reactive too, clicking buttons isn't exactly great for power usage)
clis are predictable, scriptable, once you know their interface you can very easily use them with your eyes closed -- but they're often static and one dimensional, great for scripting, not as good for displaying live/changing or complex info
imo a good system has to have both good guis and good clis -- note that tui programs fall into guis mostly and don't share much with clis except by being ran in a terminal, i don't like tuis as a concept very much -
@hipsterelectron @kevin guis and clis fit two different spaces and i don't think saying "cli bad gui good", nor the opposite, is any productive tbh
they function differently, present information differently, guis are reactive, have more options to express complex information, but are very limited in non-interactive, or learnt, usage (as usage is often reactive too, clicking buttons isn't exactly great for power usage)
clis are predictable, scriptable, once you know their interface you can very easily use them with your eyes closed -- but they're often static and one dimensional, great for scripting, not as good for displaying live/changing or complex info
imo a good system has to have both good guis and good clis -- note that tui programs fall into guis mostly and don't share much with clis except by being ran in a terminal, i don't like tuis as a concept very much@navi @kevin clis being scriptable is important too as that can (and generally should) serve the purpose of a versioned API. this allows emacs to build interfaces out of text and in the absence of electron emacs is what i have reverted to. more on text as an interface in my emacsconf 2024 talk https://emacsconf.org/2024/talks/regex/
-
@hipsterelectron @kevin guis and clis fit two different spaces and i don't think saying "cli bad gui good", nor the opposite, is any productive tbh
they function differently, present information differently, guis are reactive, have more options to express complex information, but are very limited in non-interactive, or learnt, usage (as usage is often reactive too, clicking buttons isn't exactly great for power usage)
clis are predictable, scriptable, once you know their interface you can very easily use them with your eyes closed -- but they're often static and one dimensional, great for scripting, not as good for displaying live/changing or complex info
imo a good system has to have both good guis and good clis -- note that tui programs fall into guis mostly and don't share much with clis except by being ran in a terminal, i don't like tuis as a concept very much@navi @hipsterelectron @kevin i dont mind tui's except from an accessibility standpoint. prompt-based would be better -
@hipsterelectron @kevin guis and clis fit two different spaces and i don't think saying "cli bad gui good", nor the opposite, is any productive tbh
they function differently, present information differently, guis are reactive, have more options to express complex information, but are very limited in non-interactive, or learnt, usage (as usage is often reactive too, clicking buttons isn't exactly great for power usage)
clis are predictable, scriptable, once you know their interface you can very easily use them with your eyes closed -- but they're often static and one dimensional, great for scripting, not as good for displaying live/changing or complex info
imo a good system has to have both good guis and good clis -- note that tui programs fall into guis mostly and don't share much with clis except by being ran in a terminal, i don't like tuis as a concept very much@navi @hipsterelectron @kevin I largely agree but guis are also keyboard driven. hitting key combos or sequences can easily be as fast or faster than typing for a power user. the sequences can then themselves be scripted, although quality of tools for this varies a lot more than good command lines
-
Confession: I mostly hate command lines and I think the obsession with them in the tech world is basically a cultural signifier and little else. I constantly see obtuse command line interfaces that are worse in every way than simple GUI would be, but are preferred, I guess, on the grounds that that’s what the epic bigshot “coders” use.
@kevin thank you, hanging out on fedi was making me think I'm the only one on the planet lol. CLIs stink for beginners but also for occasional use tools where I can't be bothered to learn the syntax for something I use once in 3 months. I only use it when there's nothing else or when the investment of time will look worth it in the long run
-
@atsuzaki this is a really important point. I do think I know of something which addresses this. You might check out the form driven interfaces of IBM OS/400. Basically, the entire UI is form/menu driven *but* forms always have an isomorphism between a CL (its shell language) and a form. So you can send someone a CL command but this is basically a sort of descriptor for a sort of GUI. I also think a lot of work here has unwittingly conflated text based and command line based UIs.
The unique property of a mature command line is that it enables conveniently stringing (pun intended) a series of commands to each other by way of | and &&. Many command lines do not, but those are irredeemably bad. This capability is very difficult to reproduce in a GUI. That said, I've never experienced OS/400.
@kevin @atsuzaki -
@navi @hipsterelectron @kevin I largely agree but guis are also keyboard driven. hitting key combos or sequences can easily be as fast or faster than typing for a power user. the sequences can then themselves be scripted, although quality of tools for this varies a lot more than good command lines
GUIs used to be keyboard drivable. Increasingly that's impossible - shortcuts don't exist, menu activations are forgotten, and tab-navigation is broken. Today's PMs have never done anything but mouse or touch navigation.
@tibi2 @navi @hipsterelectron @kevin -
@kevin thank you, hanging out on fedi was making me think I'm the only one on the planet lol. CLIs stink for beginners but also for occasional use tools where I can't be bothered to learn the syntax for something I use once in 3 months. I only use it when there's nothing else or when the investment of time will look worth it in the long run
CLIs stink for beginners
That, too, depends. Once I understood the fundamentals (word splitting, quoting) of the shell, I knew how to run any command with any argument(s). When I didn't know a command or its options, the
manpage was right there. When I didn't know which command to use for a task,man -k KEYWORDgave me useful hints.But in the GUI environment there was no simple search. I had to rummage through nested application menus to find (sometimes misleadingly named) programs and hope they did something useful. Something similar would repeat inside the application: Some functions are hidden behind toolbar buttons, some are in the menu at the top, others in a context menu, etc. Even if the buttons have tooltips, you can't easily see them unless you manually mouse over them one by one. There usually are certain conventions that most applications follow, but they're not intuitive: A beginner still has to learn them.
(Of course the issue of obscure commands and inconsistent interfaces also exists in command line tools, but the difference is that I can easily automate that one weird set of options or sequence of tool invocations with a shell script. That was true even when I was just learning how to use Linux: If you know how to do a thing manually on the command line, you can automate it by putting the some command in a script file. What could be easier? Whereas with an obscure GUI tool I have to remember what to click where and in which order every couple of weeks when I need to Do The Thing.)
In short: This (former) beginner rather liked the command line.
-
R relay@relay.infosec.exchange shared this topic
