6 ms·

The future repeats the past. This looks much like the back-end systems I used to design on TurboPascal in the late 1980s / early 1990s. https://ilyabirman.net/

The future repeats the past. This looks much like the back-end systems I used to design on TurboPascal in the late 1980s / early 1990s. https://ilyabirman.net/meanwhile/pictures/tp-80.png https://ilyabirman.net/meanwhile/pictures/tp-80.png

naikrovek 6y ago
I miss the simplicity and utility of textual UIs. Nothing unneeded, and everything you need. No filler. No giant gaps between elements or wasted pixels. No fads which do silly things like hide scrollbars or other interactive elements. Except for CAD applications and some games, almost everything we do online today could be accomplished via textual UI. Almost the entire internet could be replaced with TUIs and a lot of things would be better and more straightforward, and nearly everyone would be able to do what they need to do online. TUIs are fast, they are light, they are ultra responsive and ... Yeah. They're definitely underrated. They're probably a lot easier for screen-readers, too. I'm not suggesting that we undo everything and make a TUI web, but I do want to point out that we do a hell of a lot on today's UIs that we don't need to do, solely because some designer who wants to make pretty things that function poorly said so.
- rexreed 6y ago
  Where's lynx when you need it? [0] [0] https://lynx.browser.org/ https://lynx.browser.org/ And I might add, it's the oldest web browser still being maintained. Since 1992.
  - jeroenjanssens 6y ago
    Why does this website write "Un*x" as if it's some kind of swear word?
    - soneil 6y ago
      It's a common way to express "things that are unix-like" and avoiding the pedanticism of what is & isn't an actual UNIX™
      - jehb 6y ago
        I tend to use *nix for things that are UNIX-like. I think of un*x in the older sense from the other parent "it's not actually UNIX and f*ck the trademark" but I'm not sure that dichotomy in my mind is useful anymore.
    - roel_v 6y ago
      It was, at the time of the Unix wars, a rather childish way of 'protesting' the use of trademarks on the name 'UNIX' by AT&T, Novell, SCO etc. in their fights against other Unixy OS vendors. There were urban legends going around on IRC and Usenet that those companies would sue everybody using the word 'Unix' but not using the full name would absolve you of that responsibility. Legally this in the class of 'cops can't lie to you when you ask them if they're a cop' and 'free men doctrine' and such but it was wide spread at the time. The irony is of course that Unix-like OS vendors spend so much time fighting each other that it was basically mutually assured destruction, and proprietary Unix systems went the way of the dinosaur after the dot com crash.
- SiVal 6y ago
  I agree with your claims about the potential advantages of a TUI, but in this case, almost all of these TUIs using Rich will be running as GUI graphics inside a GUI window on top of a GUI OS subsystem, driven by an interpreted Python subsystem, all on an OS juggling many other simultaneous deep-stack processes. In other words, it's a keyboard-driven GUI app making use of the GUI advantages to provide you with your choice of high-quality fonts and designer colors to emulate a TUI. That doesn't make it bad. I still like it. But like you, I wish we had more options to fully exercise the power of a TUI much closer to the metal, like the old days. Apps where almost every keystroke completes an operation faster than the fastest typist can move from key to key.... Of course, beyond a certain speed, more speed wouldn't matter, so maybe I could get it by installing a (local, not remote) desktop Linux without any GUI and using only CLI dev tools. Is anyone doing this?
  - iib 6y ago
    On Ubuntu, sometimes I like to do Ctrl-Alt-F3 to get into a tty, login, and then do `sudo init 3` to shutdown everything pertaining to the graphical shell. The interaction with the computer is much faster there. After I get bored, I do either `sudo init 7` to be sure, but mostly just Ctrl-Alt-F1, which brings me back to my graphical shell. This method has the advantage that you are always on the same system, not needing anything else. Oh, also the music works, if you don't kill the GUI with the first `init` call. Coupled with tmux, emacs/vim, nvlc, lynx, and coreutils, you can really be more productive there, from the extra speed, less memory requirements, and less available distractions. EDIT: I could not find the actual link to the library either on HN or in the OP, so I am linking it here [1], for the convenience of myself and others. [1] https://github.com/willmcgugan/rich https://github.com/willmcgugan/rich
    - teddyh 6y ago
      > sudo init 3` to shutdown everything pertaining to the graphical shell The modern systemd equivalent is: systemctl isolate multi-user > sudo init 7 […] which brings me back to my graphical shell. systemctl isolate graphical or systemctl isolate default
- xingyzt 6y ago
  > They're probably a lot easier for screen-readers, too. That might be true for more minimal TUIs, but I don't think most screen-readers can handle the multi-paneled ones like OP.
  - TeMPOraL 6y ago
    They could if the TUI had runtime/library designed for it. Emacs as a platform is a good example here - the TUI that you can achieve in it is similar to web GUIs made of standard components - in the the UI isn't just pixels on a 256-bit canvas, but it's made of building blocks that you can inspect, select, copy, and that gracefully enhance/degrade when you switch between graphical and terminal modes.
- CJefferson 6y ago
  One thing, TUIs are MUCH MUCH worse for screen readers than (well made) websites. TUIs (as currently designed) have no structure, so it's very difficult to move around from section to section. A website with headers and auto-wrapping text is much easier to move around and read with a screen reader.
  - acapybara 6y ago
    At one point, web designers were making an effort to use semantic markup and create a "semantic web." That sure would have been nice for the screen readers.
    - CJefferson 6y ago
      In practice, much of the modern web still works well with screen readers (although it could be better of course). Some things break horribly (in particular, infinite scrolling is often a problem).
  - ta988 6y ago
    On the other hand, emacs works really well with emacsspeak. So it is possible.
- zokier 6y ago
  > No giant gaps between elements or wasted pixels. No fads which do silly things like hide scrollbars or other interactive elements I call bullshit on this. Using fixed character cell grid for UI absolutely wastes ton of space. First of all just basic text takes more space in fixed-width than variable width. But the biggest offender is any layout or ui elements that would not need whole cell. Even basic 1px horizontal line takes 10px of height or whatever. Places where 1 or 2 px padding could do will use full cell instead. And then there is of course the space waste from forcing all text to be same size. For tons of applications the UI elements could do with smaller font than content, but none of that is possible with TUI. I find your example of hiding scrollbars hilarious, considering that TUIs are in general far worse offenders in that area specifically. For example none of the examples for Rich here show scrollbars.. I do also believe that in terms of performance TUIs leave lot on the table, because they are forced to go through all sort of weird legacy layers. Pushing pixels on screen and receiving key events directly almost certainly should be faster/more efficient than going through tty layer and terminal emulation.
  - bityard 6y ago
    > Pushing pixels on screen and receiving key events directly almost certainly should be faster/more efficient than going through tty layer and terminal emulation. Why do you think it needs to be faster? Do you currently have issues with complexity or latency? Have you measured it? Do you think that replacing the current abstractions with new abstractions will really be a net improvement? A terminal emulator is pretty much the least non-trivial resource-intensive graphical application I can think of. I've been running Linux on the desktop for over two decades and can't think of a single time I thought the terminal emulator I was using at the time was too slow. (Which is why I don't really understand the need for CPU-accelerated terminal emulators, but that's a different kettle of worms.)
  - rabidrat 6y ago
    > Even basic 1px horizontal line takes 10px of height or whatever. Places where 1 or 2 px padding could do will use full cell instead. This is not true; there is an underline attribute which can add a ~1px horizontal line without taking up any additional space.
- invalidToken 6y ago
  as a person who has the basic HTML version of gmail as his default, I understand.
VHRanger 6y ago
Terminals are a really solid front-end interface if you can get by the inherent tradeoffs.
CGamesPlay 6y ago
I wouldn't say it repeats it. These new programs are similar to the old ones in much the same way that new books are similar to old books. The medium is the same but what's being expressed and accomplished is vastly different. Two specific categories that come to mind: these new programs are vastly easier to use with modern UI principles than "RTFM" you'd find in the old ones; and validation/error handling is similarly much simpler. It's reinventing the wheel, but a car tire is a welcome improvement to a wooden wagon wheel.
- aduitsis 6y ago
  Your point is very well taken, but using Turbo Pascal to create an application with a TUI was surprisingly easy back in the day. You could just add some small boilerplate and you basically had something with a TUI running. So the entry barrier was extremely low, which had the effect of giving you a quick reward to motivate you to understand and build more advanced features.
- fmakunbound 6y ago
  What tools are the car tire in this analogy? I recall it was ridiculously easy to develop rich text applications from Turbo Pascal/Turbo Vision. I believe there’s a modern port of Turbo Vision as well
CoffeeDregs 6y ago
I think I agree but with the point "Isn't this a solved problem?" I'm not sure if the first library should be written in C, Rust, C++, etc but it seems as though very similar libraries-but-in-different-languages are being repeatedly written. I certainly get that a good library yesterday might not be good today or that an existing library's style might not meet this language's style but I doubt the need to rewrite existing libraries so often. Even with the much-maligned PHP, libraries were frequently bindings to other libraries.
alfiedotwtf 6y ago
Although Turbo Vision and nCurses was great for the time, today’s TUI libraries are a different beast
voldacar 6y ago
The little drop shadows under the buttons are a great touch. love it
james-bcn 6y ago
I was thinking exactly the same thing! There used to be a really cool library for creating windows and buttons using ascii codes.
pridkett 6y ago
Well, you’re in luck! There’s a modern version of TurboVision that works on modern systems. I used it the other day to show tvedit to some of the folks at work who were using nano. They were kinda mind-blown by the fact that editors in the late 80’s/early 90’s weren’t terrible. https://github.com/magiblot/tvision https://github.com/magiblot/tvision
- magiblot 6y ago
  Show them this, too: https://github.com/magiblot/turbo https://github.com/magiblot/turbo Applications like tvedit were designed for MS-DOS, which offered full interaction with the mouse and keyboard, and many of them were commercial products aimed at a general audience. TUI applications from the Unix tradition, however, were designed for use in terminals with limited capabilities, and were aimed at more technical users (or were created by the users themselves). User-friendly TUI applications in MS-DOS were succeeded by Windows applications, while the largest revolution in the last 20 years in Unix TUIs has been the widespread support of 256/24-bit colors and UTF-8. Hence the gap in usability between the two worlds.

naikrovek 6y ago

I miss the simplicity and utility of textual UIs. Nothing unneeded, and everything you need. No filler. No giant gaps between elements or wasted pixels. No fads which do silly things like hide scrollbars or other interactive elements. Except for CAD applications and some games, almost everything we do online today could be accomplished via textual UI. Almost the entire internet could be replaced with TUIs and a lot of things would be better and more straightforward, and nearly everyone would be able to do what they need to do online. TUIs are fast, they are light, they are ultra responsive and ... Yeah. They're definitely underrated. They're probably a lot easier for screen-readers, too. I'm not suggesting that we undo everything and make a TUI web, but I do want to point out that we do a hell of a lot on today's UIs that we don't need to do, solely because some designer who wants to make pretty things that function poorly said so.

rexreed 6y ago
Where's lynx when you need it? [0] [0] https://lynx.browser.org/ https://lynx.browser.org/ And I might add, it's the oldest web browser still being maintained. Since 1992.
- jeroenjanssens 6y ago
  Why does this website write "Un*x" as if it's some kind of swear word?
  - soneil 6y ago
    It's a common way to express "things that are unix-like" and avoiding the pedanticism of what is & isn't an actual UNIX™
    - jehb 6y ago
      I tend to use *nix for things that are UNIX-like. I think of un*x in the older sense from the other parent "it's not actually UNIX and f*ck the trademark" but I'm not sure that dichotomy in my mind is useful anymore.
  - roel_v 6y ago
    It was, at the time of the Unix wars, a rather childish way of 'protesting' the use of trademarks on the name 'UNIX' by AT&T, Novell, SCO etc. in their fights against other Unixy OS vendors. There were urban legends going around on IRC and Usenet that those companies would sue everybody using the word 'Unix' but not using the full name would absolve you of that responsibility. Legally this in the class of 'cops can't lie to you when you ask them if they're a cop' and 'free men doctrine' and such but it was wide spread at the time. The irony is of course that Unix-like OS vendors spend so much time fighting each other that it was basically mutually assured destruction, and proprietary Unix systems went the way of the dinosaur after the dot com crash.
SiVal 6y ago
I agree with your claims about the potential advantages of a TUI, but in this case, almost all of these TUIs using Rich will be running as GUI graphics inside a GUI window on top of a GUI OS subsystem, driven by an interpreted Python subsystem, all on an OS juggling many other simultaneous deep-stack processes. In other words, it's a keyboard-driven GUI app making use of the GUI advantages to provide you with your choice of high-quality fonts and designer colors to emulate a TUI. That doesn't make it bad. I still like it. But like you, I wish we had more options to fully exercise the power of a TUI much closer to the metal, like the old days. Apps where almost every keystroke completes an operation faster than the fastest typist can move from key to key.... Of course, beyond a certain speed, more speed wouldn't matter, so maybe I could get it by installing a (local, not remote) desktop Linux without any GUI and using only CLI dev tools. Is anyone doing this?
- iib 6y ago
  On Ubuntu, sometimes I like to do Ctrl-Alt-F3 to get into a tty, login, and then do `sudo init 3` to shutdown everything pertaining to the graphical shell. The interaction with the computer is much faster there. After I get bored, I do either `sudo init 7` to be sure, but mostly just Ctrl-Alt-F1, which brings me back to my graphical shell. This method has the advantage that you are always on the same system, not needing anything else. Oh, also the music works, if you don't kill the GUI with the first `init` call. Coupled with tmux, emacs/vim, nvlc, lynx, and coreutils, you can really be more productive there, from the extra speed, less memory requirements, and less available distractions. EDIT: I could not find the actual link to the library either on HN or in the OP, so I am linking it here [1], for the convenience of myself and others. [1] https://github.com/willmcgugan/rich https://github.com/willmcgugan/rich
  - teddyh 6y ago
    > sudo init 3` to shutdown everything pertaining to the graphical shell The modern systemd equivalent is: systemctl isolate multi-user > sudo init 7 […] which brings me back to my graphical shell. systemctl isolate graphical or systemctl isolate default
xingyzt 6y ago
> They're probably a lot easier for screen-readers, too. That might be true for more minimal TUIs, but I don't think most screen-readers can handle the multi-paneled ones like OP.
- TeMPOraL 6y ago
  They could if the TUI had runtime/library designed for it. Emacs as a platform is a good example here - the TUI that you can achieve in it is similar to web GUIs made of standard components - in the the UI isn't just pixels on a 256-bit canvas, but it's made of building blocks that you can inspect, select, copy, and that gracefully enhance/degrade when you switch between graphical and terminal modes.
CJefferson 6y ago
One thing, TUIs are MUCH MUCH worse for screen readers than (well made) websites. TUIs (as currently designed) have no structure, so it's very difficult to move around from section to section. A website with headers and auto-wrapping text is much easier to move around and read with a screen reader.
- acapybara 6y ago
  At one point, web designers were making an effort to use semantic markup and create a "semantic web." That sure would have been nice for the screen readers.
  - CJefferson 6y ago
    In practice, much of the modern web still works well with screen readers (although it could be better of course). Some things break horribly (in particular, infinite scrolling is often a problem).
- ta988 6y ago
  On the other hand, emacs works really well with emacsspeak. So it is possible.
zokier 6y ago
> No giant gaps between elements or wasted pixels. No fads which do silly things like hide scrollbars or other interactive elements I call bullshit on this. Using fixed character cell grid for UI absolutely wastes ton of space. First of all just basic text takes more space in fixed-width than variable width. But the biggest offender is any layout or ui elements that would not need whole cell. Even basic 1px horizontal line takes 10px of height or whatever. Places where 1 or 2 px padding could do will use full cell instead. And then there is of course the space waste from forcing all text to be same size. For tons of applications the UI elements could do with smaller font than content, but none of that is possible with TUI. I find your example of hiding scrollbars hilarious, considering that TUIs are in general far worse offenders in that area specifically. For example none of the examples for Rich here show scrollbars.. I do also believe that in terms of performance TUIs leave lot on the table, because they are forced to go through all sort of weird legacy layers. Pushing pixels on screen and receiving key events directly almost certainly should be faster/more efficient than going through tty layer and terminal emulation.
- bityard 6y ago
  > Pushing pixels on screen and receiving key events directly almost certainly should be faster/more efficient than going through tty layer and terminal emulation. Why do you think it needs to be faster? Do you currently have issues with complexity or latency? Have you measured it? Do you think that replacing the current abstractions with new abstractions will really be a net improvement? A terminal emulator is pretty much the least non-trivial resource-intensive graphical application I can think of. I've been running Linux on the desktop for over two decades and can't think of a single time I thought the terminal emulator I was using at the time was too slow. (Which is why I don't really understand the need for CPU-accelerated terminal emulators, but that's a different kettle of worms.)
- rabidrat 6y ago
  > Even basic 1px horizontal line takes 10px of height or whatever. Places where 1 or 2 px padding could do will use full cell instead. This is not true; there is an underline attribute which can add a ~1px horizontal line without taking up any additional space.
invalidToken 6y ago
as a person who has the basic HTML version of gmail as his default, I understand.

VHRanger 6y ago

Terminals are a really solid front-end interface if you can get by the inherent tradeoffs.

CGamesPlay 6y ago

I wouldn't say it repeats it. These new programs are similar to the old ones in much the same way that new books are similar to old books. The medium is the same but what's being expressed and accomplished is vastly different. Two specific categories that come to mind: these new programs are vastly easier to use with modern UI principles than "RTFM" you'd find in the old ones; and validation/error handling is similarly much simpler. It's reinventing the wheel, but a car tire is a welcome improvement to a wooden wagon wheel.

aduitsis 6y ago
Your point is very well taken, but using Turbo Pascal to create an application with a TUI was surprisingly easy back in the day. You could just add some small boilerplate and you basically had something with a TUI running. So the entry barrier was extremely low, which had the effect of giving you a quick reward to motivate you to understand and build more advanced features.
fmakunbound 6y ago
What tools are the car tire in this analogy? I recall it was ridiculously easy to develop rich text applications from Turbo Pascal/Turbo Vision. I believe there’s a modern port of Turbo Vision as well

CoffeeDregs 6y ago

I think I agree but with the point "Isn't this a solved problem?" I'm not sure if the first library should be written in C, Rust, C++, etc but it seems as though very similar libraries-but-in-different-languages are being repeatedly written. I certainly get that a good library yesterday might not be good today or that an existing library's style might not meet this language's style but I doubt the need to rewrite existing libraries so often. Even with the much-maligned PHP, libraries were frequently bindings to other libraries.

alfiedotwtf 6y ago

Although Turbo Vision and nCurses was great for the time, today’s TUI libraries are a different beast

voldacar 6y ago

The little drop shadows under the buttons are a great touch. love it

james-bcn 6y ago

I was thinking exactly the same thing! There used to be a really cool library for creating windows and buttons using ascii codes.

pridkett 6y ago

Well, you’re in luck! There’s a modern version of TurboVision that works on modern systems. I used it the other day to show tvedit to some of the folks at work who were using nano. They were kinda mind-blown by the fact that editors in the late 80’s/early 90’s weren’t terrible. https://github.com/magiblot/tvision https://github.com/magiblot/tvision

magiblot 6y ago
Show them this, too: https://github.com/magiblot/turbo https://github.com/magiblot/turbo Applications like tvedit were designed for MS-DOS, which offered full interaction with the mouse and keyboard, and many of them were commercial products aimed at a general audience. TUI applications from the Unix tradition, however, were designed for use in terminals with limited capabilities, and were aimed at more technical users (or were created by the users themselves). User-friendly TUI applications in MS-DOS were succeeded by Windows applications, while the largest revolution in the last 20 years in Unix TUIs has been the widespread support of 256/24-bit colors and UTF-8. Hence the gap in usability between the two worlds.