4 ms·

OK this is cool and all, and I'm sure it took a lot of effort to build. But I really think that textual interfaces were a mistake. This thing was inherited fro

by hsn915 5y ago

OK this is cool and all, and I'm sure it took a lot of effort to build. But I really think that textual interfaces were a mistake. This thing was inherited from Unix which was made in the 70s or so. All screens now are graphical so why are we programming as if the "standard output" is a text file? We should be writing code that writes to a pixel buffer instead of to a file handle. It's 2022 and there's still no good GUI debugger for C on linux. Someone tweeted this a few days ago which I thought really captures why text is a poor UI: > It's 2022 and the two common debugging methods on Linux—"just printf" and "gdb -tui if that's not enough"—still can't be used at the same time without it screwing up.

salmo 5y ago
This reminds me of 1998. I was in college and working at a mid sized business replacing a dumb terminal system on a VAX with a nice NT based GUI. I mocked the TUI. So antiquated running off a minicomputer. We rolled out the PCs and updated software and salespeople’s and CSRs’ productivity was killed. They could fill in the screens on the old system before it finished painting. The new one had the same “screens”, but flipping to the mouse and back was awful. A year later the vendor finally got everything straight with the keyboard (tab order, hot keys, etc). But it still took longer to render and blocked input and was generally awkward. I set them up with telnet on their PCs back to the VAX. New folks found the GUI easier, but experienced users still hated it. Eventually the vendor required moving the DB off the VAX and the TUI was dead. I had started building web UIs by then. Thick clients were already becoming passé. But that experience really has stuck with me. The tech you use doesn’t actually matter at all. Enabling people to work faster, better, easier is what matters. Sometimes a short-term but steeper learning curve is better in the long run. Sometimes ease of adoption is more important. And sometimes the tech doesn’t change the fact that a tool just sucks. Good tech becomes an extension of human ability. I love vim and awk. I’d rather write documents in troff or LaTeX w/ git. But I also love Pixelmator and actually even outlook these days. I feel awkward without them. Interestingly, as I type this, I can’t think of a single web UI that I have that unconscious relationship with.
- hsn915 5y ago
  I do acknowledge that GUI programming in 2022 still sucks. I fail to see how this is an argument in favor of TUIs in principle.
  - salmo 5y ago
    I think the “in principle” is the problem. The tech isn’t the principle. The experience is. Use the right thing for for the audience. Use a GUI, use a TUI, use a basic CLI tool for day-to-day. And sometimes that can even be additive where more than one is the right answer. The clicks stuff in this does feel silly to me. But I think that sometimes there’s value in not reaching for a mouse. If you care about the tech in principle, then I think the answer is to work on a library/framework you love, like they did, vs a user app. I’m not reinventing those wheels, and will borrow stuff like this when it seems right. And anything is better than curses :).
    - hsn915 5y ago
      The principle is the problem. When your program is a TUI, it means stdout is useless. The tweet I quoted illustrates this problem. If you do both printf debugging and use a TUI debugger, you will not be able to see the output from the printf statements. You want to draw a GUI but you're using a text stream to issue commands to the terminal to draw text and color regions of the screen - while at the same time hiding the std output buffer (and losing the ability to select and copy/paste the text being drawn). As if drawing text and colored boxes is so fundamentally difficult it can't be done any other way. As if handling shortcuts in a GUI program is so fundamentally difficult that it's easier to do it in a TUI.

by hsn915 5y ago

salmo 5y ago

This reminds me of 1998. I was in college and working at a mid sized business replacing a dumb terminal system on a VAX with a nice NT based GUI. I mocked the TUI. So antiquated running off a minicomputer. We rolled out the PCs and updated software and salespeople’s and CSRs’ productivity was killed. They could fill in the screens on the old system before it finished painting. The new one had the same “screens”, but flipping to the mouse and back was awful. A year later the vendor finally got everything straight with the keyboard (tab order, hot keys, etc). But it still took longer to render and blocked input and was generally awkward. I set them up with telnet on their PCs back to the VAX. New folks found the GUI easier, but experienced users still hated it. Eventually the vendor required moving the DB off the VAX and the TUI was dead. I had started building web UIs by then. Thick clients were already becoming passé. But that experience really has stuck with me. The tech you use doesn’t actually matter at all. Enabling people to work faster, better, easier is what matters. Sometimes a short-term but steeper learning curve is better in the long run. Sometimes ease of adoption is more important. And sometimes the tech doesn’t change the fact that a tool just sucks. Good tech becomes an extension of human ability. I love vim and awk. I’d rather write documents in troff or LaTeX w/ git. But I also love Pixelmator and actually even outlook these days. I feel awkward without them. Interestingly, as I type this, I can’t think of a single web UI that I have that unconscious relationship with.

hsn915 5y ago
I do acknowledge that GUI programming in 2022 still sucks. I fail to see how this is an argument in favor of TUIs in principle.
- salmo 5y ago
  I think the “in principle” is the problem. The tech isn’t the principle. The experience is. Use the right thing for for the audience. Use a GUI, use a TUI, use a basic CLI tool for day-to-day. And sometimes that can even be additive where more than one is the right answer. The clicks stuff in this does feel silly to me. But I think that sometimes there’s value in not reaching for a mouse. If you care about the tech in principle, then I think the answer is to work on a library/framework you love, like they did, vs a user app. I’m not reinventing those wheels, and will borrow stuff like this when it seems right. And anything is better than curses :).
  - hsn915 5y ago
    The principle is the problem. When your program is a TUI, it means stdout is useless. The tweet I quoted illustrates this problem. If you do both printf debugging and use a TUI debugger, you will not be able to see the output from the printf statements. You want to draw a GUI but you're using a text stream to issue commands to the terminal to draw text and color regions of the screen - while at the same time hiding the std output buffer (and losing the ability to select and copy/paste the text being drawn). As if drawing text and colored boxes is so fundamentally difficult it can't be done any other way. As if handling shortcuts in a GUI program is so fundamentally difficult that it's easier to do it in a TUI.