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.
-
@wolf480pl fair enough, not “text” though
@kevin
not in the everyday sense of the wordthere is a specialist sense of the word in the context of IT that roughly means "any sequence of bytes that can be both unabiguously typed on most computer keyboards, and unambiguously displayed on most computer screens", though the set of computer keyboards, screens, and extra software that can be involved in it is somewhat context-dependent
-
@kevin
not in the everyday sense of the wordthere is a specialist sense of the word in the context of IT that roughly means "any sequence of bytes that can be both unabiguously typed on most computer keyboards, and unambiguously displayed on most computer screens", though the set of computer keyboards, screens, and extra software that can be involved in it is somewhat context-dependent
@kevin
I think the latter meaning would benefit from a better term and a better definition, but I'm not aware of anyone who understands the usefulness of that format well enough to formalize what it is. -
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 there is a unique command line property where sending an instruction for how to do something is easy to send and receive by default. partially why they remain prevalent in developer spaces tbh because our community structures are so text-based. i've idly thought for a while on how can we bridge this for gui with this level of universality (i.e., not just hardcoded "share" paths for special cases) and have come up short
-
@kevin there is a unique command line property where sending an instruction for how to do something is easy to send and receive by default. partially why they remain prevalent in developer spaces tbh because our community structures are so text-based. i've idly thought for a while on how can we bridge this for gui with this level of universality (i.e., not just hardcoded "share" paths for special cases) and have come up short
@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.
-
@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.
@atsuzaki but you’re absolutely right, I think in essence that it’s really important that there always be a programmatic way to do something, not just a gestural one.
-
Also: as anyone who has followed my work will know, the “simplicity” of plain text is illusory. Like I recently saw a “text editor” that explicitly had RTL text “out of scope.” That’s not a text editor, that’s an English editor. You can make anything simple by being a cultural chauvinist!
@kevin HOW DID I MISS THIS!!!
-
@kevin HOW DID I MISS THIS!!!
@kevin have i shown you https://codeberg.org/cosmicexplorer/corporeal yet
-
@kevin have i shown you https://codeberg.org/cosmicexplorer/corporeal yet
@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"
-
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 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 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/
