3 ms·

I really don't get it. Started using computers when that was the only affordable way to use computers. For some reason, some people really love to live in 197

by pjmlp 6mo ago

I really don't get it. Started using computers when that was the only affordable way to use computers. For some reason, some people really love to live in 1970's with their expensive HiDPI monitors.

aninteger 6mo ago
And some of us love to live in the 1970s with cheap non-HiDPI monitors (or maybe it's just me).
hvb2 6mo ago
Because it's all keyboard based. Depending on your field of work a good UI can be very different. A few years ago I watched an account work through my companies numbers using their accounting software. It's entry method? A windows commander like tool. The menu options like add expense etc were all numbered. So he never left the numeric part of his keyboard. The tool looked super old and obsolete but as soon as you see a power user use it, you see why.
- pjmlp 6mo ago
  GUIs can also be keyboard based, and there are language REPLs as well.
munk-a 6mo ago
I don't mind a GUI (as long as it isn't an obnoxiously large ribbon or anything) - but if I'm doing work my input device is the keyboard. I don't want to interface with software through moving a mouse pointer when I can just tell it what to do with a few keystrokes.
- pjmlp 6mo ago
  Xerox PARC REPL sytle, and better you can get the inline graphics for free, as there is no need to emulate a teletype.
benjamincburns 6mo ago
I wasn't alive in the 70s, but I still prefer a terminal. I can string together a complex series of text-related tasks far more effectively as a shell pipeline than I can by pointing and clicking in a UI. I can scale that sequence of tasks out to operate on every file on the filesystem if I want, or down to a single character in a single file. Claude Code being a full-featured TUI is also helpful because I can quickly/easily use it remotely via SSH without having to deal with setting up X forwarding, VNC, Parsec, etc. The remote host doesn't even need to have a window manager. Sure, it'd be nice if it also had an elegant multi-page GUI so I could more easily drill into the actions its performing and make better use of my large screen to watch it do multi-agent things, but if I have to choose between the two, I prefer the TUI. That said, I'd much rather use a GUI to do things that are actually visual/spatial in nature.
- pjmlp 6mo ago
  I can do the same in a language REPL, with the advantage it doesn't need to emulate a teletype.
  - 1718627440 6mo ago
    The terminal is a language REPL, which the advantage, that it is the environment the whole OS runs on.
    - pjmlp 6mo ago
      It is an handicapped REPL, not really the same. Such statements can only be voiced by those that never experienced what using a proper REPL actually feels like. Not something that emulates a vt100 teletype.
      - 1718627440 6mo ago
        The "vt100 teletype emulation" only concerns the protocol in which the program describes what to draw on the display. It might be inconvenient for the programmer, but for the user it is kinda irrelevant. > Such statements can only be voiced by those that never experienced what using a proper REPL actually feels like. Maybe. What do you mean with proper REPL? SBCL just runs fine in my terminal emulator. As do all other kind of programming languages, like Prolog. When I interface with the OS, I want to start programs, control the processes, setup communication channels (pipes) and tell to computer to combine multiple programs to filter, combine, split stuff and redirect it to files and other programs. These should be also be able to run several times with slight differences. All of that works just fine in my shell. What are you missing?
canpan 6mo ago
It might be overcompensation. I think UI, UX and GUIs got better up until the 90s, and early 2000s, but then somewhere GUIs suddenly got a lot worse. So a modern CLI is better and more standardized than a modern GUI.
- pjmlp 6mo ago
  A modern CLI would be a REPL.
- thewebguyd 6mo ago
  > then somewhere GUIs suddenly got a lot worse Electron is the reason, and the elusive dream of "write once, run anywhere" that got us cross platform UIs that are bespoke and don't follow native OS conventions (or keyboard navigation), plus once marketing got involved and GUIs started needing to be branded instead of just fitting in with every other native app on that OS.
  - rafterydj 6mo ago
    I see arguments like this particularly against Electron and the web development sphere in general and I think it's more nuanced than either programmers or "marketing" (read: anyone not a programmer) gives credit towards. The "elusive dream" of 'write once, run anywhere' is realistically just people wanting to write software with direct product or service use in mind. Native OS conventions are subject to the middlemen of OS vendors, whereas the web (while basically subject to the same vendors) makes a substantial attempt at bridging the gap of writing software for your own purposes without native OS problems. This is a symptom of OSes catering/selling to developers as a platform and hooking them in the 1990s and 2000s. This attitude that wanting to just make useful code for people and not worry about a windows 11 update breaking everything because they are irresponsible - to think that is not a valid desire is IMO a big problem. On the other hand, you have a point that it quickly gets out of hand in terms of standards and accessibility and performance bottlenecks. WebAssembly and the WASI are so slow to come out and will by design always be slower than native performance. This doesn't and shouldn't stop us from having decently performant and decently usable program experiences, but it is a prerequisite to care about those things, and the other inheritors of the web development sphere clearly do not want to develop things properly if they take longer than the next fiscal quarter. There is 100% good Electron code out there, just as 100% there is bad native OS code. The problem isn't inherently the goals of the 'write once, run anywhere' idea; it's more the casualty of other interests pulling away from what developers actually want.

by pjmlp 6mo ago

I really don't get it. Started using computers when that was the only affordable way to use computers. For some reason, some people really love to live in 1970's with their expensive HiDPI monitors.

aninteger 6mo ago

And some of us love to live in the 1970s with cheap non-HiDPI monitors (or maybe it's just me).

hvb2 6mo ago

Because it's all keyboard based. Depending on your field of work a good UI can be very different. A few years ago I watched an account work through my companies numbers using their accounting software. It's entry method? A windows commander like tool. The menu options like add expense etc were all numbered. So he never left the numeric part of his keyboard. The tool looked super old and obsolete but as soon as you see a power user use it, you see why.

pjmlp 6mo ago
GUIs can also be keyboard based, and there are language REPLs as well.

munk-a 6mo ago

I don't mind a GUI (as long as it isn't an obnoxiously large ribbon or anything) - but if I'm doing work my input device is the keyboard. I don't want to interface with software through moving a mouse pointer when I can just tell it what to do with a few keystrokes.

pjmlp 6mo ago
Xerox PARC REPL sytle, and better you can get the inline graphics for free, as there is no need to emulate a teletype.

benjamincburns 6mo ago

I wasn't alive in the 70s, but I still prefer a terminal. I can string together a complex series of text-related tasks far more effectively as a shell pipeline than I can by pointing and clicking in a UI. I can scale that sequence of tasks out to operate on every file on the filesystem if I want, or down to a single character in a single file. Claude Code being a full-featured TUI is also helpful because I can quickly/easily use it remotely via SSH without having to deal with setting up X forwarding, VNC, Parsec, etc. The remote host doesn't even need to have a window manager. Sure, it'd be nice if it also had an elegant multi-page GUI so I could more easily drill into the actions its performing and make better use of my large screen to watch it do multi-agent things, but if I have to choose between the two, I prefer the TUI. That said, I'd much rather use a GUI to do things that are actually visual/spatial in nature.

pjmlp 6mo ago
I can do the same in a language REPL, with the advantage it doesn't need to emulate a teletype.
- 1718627440 6mo ago
  The terminal is a language REPL, which the advantage, that it is the environment the whole OS runs on.
  - pjmlp 6mo ago
    It is an handicapped REPL, not really the same. Such statements can only be voiced by those that never experienced what using a proper REPL actually feels like. Not something that emulates a vt100 teletype.
    - 1718627440 6mo ago
      The "vt100 teletype emulation" only concerns the protocol in which the program describes what to draw on the display. It might be inconvenient for the programmer, but for the user it is kinda irrelevant. > Such statements can only be voiced by those that never experienced what using a proper REPL actually feels like. Maybe. What do you mean with proper REPL? SBCL just runs fine in my terminal emulator. As do all other kind of programming languages, like Prolog. When I interface with the OS, I want to start programs, control the processes, setup communication channels (pipes) and tell to computer to combine multiple programs to filter, combine, split stuff and redirect it to files and other programs. These should be also be able to run several times with slight differences. All of that works just fine in my shell. What are you missing?

canpan 6mo ago

It might be overcompensation. I think UI, UX and GUIs got better up until the 90s, and early 2000s, but then somewhere GUIs suddenly got a lot worse. So a modern CLI is better and more standardized than a modern GUI.

pjmlp 6mo ago
A modern CLI would be a REPL.
thewebguyd 6mo ago
> then somewhere GUIs suddenly got a lot worse Electron is the reason, and the elusive dream of "write once, run anywhere" that got us cross platform UIs that are bespoke and don't follow native OS conventions (or keyboard navigation), plus once marketing got involved and GUIs started needing to be branded instead of just fitting in with every other native app on that OS.
- rafterydj 6mo ago
  I see arguments like this particularly against Electron and the web development sphere in general and I think it's more nuanced than either programmers or "marketing" (read: anyone not a programmer) gives credit towards. The "elusive dream" of 'write once, run anywhere' is realistically just people wanting to write software with direct product or service use in mind. Native OS conventions are subject to the middlemen of OS vendors, whereas the web (while basically subject to the same vendors) makes a substantial attempt at bridging the gap of writing software for your own purposes without native OS problems. This is a symptom of OSes catering/selling to developers as a platform and hooking them in the 1990s and 2000s. This attitude that wanting to just make useful code for people and not worry about a windows 11 update breaking everything because they are irresponsible - to think that is not a valid desire is IMO a big problem. On the other hand, you have a point that it quickly gets out of hand in terms of standards and accessibility and performance bottlenecks. WebAssembly and the WASI are so slow to come out and will by design always be slower than native performance. This doesn't and shouldn't stop us from having decently performant and decently usable program experiences, but it is a prerequisite to care about those things, and the other inheritors of the web development sphere clearly do not want to develop things properly if they take longer than the next fiscal quarter. There is 100% good Electron code out there, just as 100% there is bad native OS code. The problem isn't inherently the goals of the 'write once, run anywhere' idea; it's more the casualty of other interests pulling away from what developers actually want.