Hacker News Reader

Comment by BiteCode_dev | Hacker News Reader

I really like this trend of "making the terminal great again". Between rich/textual in python and lipgloss/bubble tea for golang, this turns cmd from "the default ugly stuff that is easy to produce" into "something fun and pretty".

Also note that those projects have the (not anymore) secret goal to also produce a web app from the same code base automatically.

I imagine native will follow, or wasm, or something. Nevertheless, having the terminal as the smallest denominator for UI makes a lot of sense for small utilities. You won't build the next Figma with it but a lot of scripts could benefit from that.

View on HN

I feel the opposite, these kinds of projects imho are just moving terminals away from their key benefits, being simple, predictable, brutally functional with no gratuitous animations or flourishes, allowing no-hassle adaptation to any colortheme and font.

Indeed, if all the features of modern graphical/web applications are dragged into terminals, then what is the point of using terminal anymore instead of native graphics/web?

Furthermore the CLI proponent in me is saddened seeing this being largely another step away from CLI tools, although strictly speaking its true that the technology doesn't really define the interaction model.

I agree. Seeing the next generation of terminal apps that often seem to use "pretty" and "fancy" output formatting (read: "non-parseable" and "overly-decorated") makes me sad. Plain, simple, human-readable, and machine-parseable output can't be beat in my mind.

Human-readable and machine-readable: not the same thing in the general case.

Hence -porcelain and friends.

I think there’s room for two categories of terminal apps. “Library” apps, and “User” apps.

Library apps are intended to be consumed by other terminal apps, or by advanced users. User apps are strictly intended for humans.

Take ffmpeg as an example. This is an excellent “library” app, so much that there are many actual libraries that are thin wrappers around it. It’s incredibly versatile.

Do I want to interact with ffmpeg, though? For one-off tasks, no, I’ll just fire up VLC or some other tool instead of reading the ffmpeg man pages.

Friendly, stylized, non-parseable, “user” terminal apps are a comfortable middle ground between hard-core “library” apps and full-on GUI apps.

Git follows this model as well, calling it porcelain and plumbing (the internals). Arguably, there’s a third layer in actual GUIs wrapping the porcelain (and sometimes plumbing).

ffmpeg specifically is a bit of an outlier; together with some other tools like qemu.

For the rest of things, you can go a long way by just aligning things nicely, indentation, wrapping/indenting properly according to the terminal width, and maybe adding a bit of bold text which is both easily parsed by machines and human readable.

I generally think these are often considerably more user-friendly than outputting 6 different colours – half of which don't work well on many background colours so it's unreadable – assuming the terminal is 290 characters wide – many tools these days seem to think you've got infinitely wide screens – and all the other things these "modern" things do.

Something like "df" is a simple but classic example; GNU df at least aligns nicely no matter the column sizes (some other dfs, like NetBSD df, don't) and that's still easily used by machines and humans. Maybe -h should be the default though (which would break scripts, so it can't be changed for /usr/bin/df, but in an ideal world...)

Basically, you can have your cake and eat it too.

Not all console programs are meant to be batch tools whose output needs to be piped and parsed.

Sometimes you need an interactive tool and you may want to run then in a console.

Emacs is an example

Yet Emacs is commonly run as a batch tool, whose output needs to be piped and parsed! For example, web sites which are generated via org-mode (I used to do this, about a decade ago). My Emacs config has unit tests, which are run via a non-interactive command (since tests are meant to find problems, and I don't want those problems to 'infect' the Emacs process I'm using for work)

More and more terminal apps come with a --json parameter, so that their output can be easily machine parseable.

Cramming output intended for humans, and output intended for data transfer between processes into the same format makes the lives of both groups of recipients worse.

It's pretty common to write terminal apps so that if they are connected to a pipe, they use raw text that is very parsable, and if they are hooked up to a tty, they present a user experience that is much more human friendly. There is great value to both modes of operation.

you might be (unintentionally) conflating CLI tools with TUI ones.

CLI by and large treat the terminal as something to read/write lines to, with maybe some rudimentary interaction support like redrawing the same line for a progress bar etc.

TUI use the various positioning and mode configuration escape sequences of the terminal to (typically) display "full-screen" applications within a terminal.

Vim/Emacs would be obvious examples, or any of the Curses-based menu-ish systems.

Try piping vim (not in batch mode) to a pager, and it doesn't really know what to do.

There is some middle-ground, Github's `gh' command will use a TUI-lite interactive menu prompts for various parameters if omitted, but can run non-interactively and be piped / folded / mutilated etc if the appropriate args are given.

I'll take two examples of interesting TUIs I've enjoyed over the years:

- clonezilla boots by default to a very simple tui, in the vein of make menuconfig on Linux. You can forward, backward, see all options, expert or simple, and check or uncheck them, and get some contextual help. Once you've set up everything, you can start cloning (or restoring) and it gives you simple progress bars. But before you start it gives you the command-line you can just run next time you want to do the exact same operation, which is quite handy...

- AFL (the fuzzing tool) renewed the interest (to me at least) in 'progress TUIs'. Fuzzing can be very long and there are many things that usually flby2go well at first, so you want a dashboard and AFL provides one. Bonus: it's quite fun to look at and you end up trying to optimize some metrics (like the number of fuzzing cases per second...) since the TUI taunts you. For long-term monitoring AFL also maintains TSV files, with gnuplot scripts, but the UI makes the tool fun to use (doesn't hurt that AFL was so easy to use and landed crashes real quick). Praised be Michał Zalewski, aka lcamtuf.

Both have an optional TUI that make the user experience so much more powerful (sorry I know we're nitpicking the word today...).

> Indeed, if all the features of modern graphical/web applications are dragged into terminals, then what is the point of using terminal anymore instead of native graphics/web?

It's not "all the features", but just being able to build a basic interface without too much trouble is a blessing. Several use cases:

- The most important: you don't have access to native graphics/web. A lot of people still need to work with remote servers where installing X is not viable and you can't access web ports.

- Simplicity. For simple interfaces, it's far easier to just use the terminal with an extra Python dependency, than it is to create a regular UI that will require a graphical server, graphics libraries and such. A web interface would be even harder to do.

- Easy adding interfaces to existing scripts. In fact I used textualize precisely for this, a script that launched some long running tasks, and I wanted to check the progress and be able to stop/throttle them. Launching a simple interface was easy enough, the rest of the script is still a regular Python script, but for that situation it just pops up a TUI.

Also, it's not like TUI apps are new. A lot of terminal applications will launch a TUI sometimes because it's just easier. See for example some configuration dialogs for APT.

Well said! I do a lot of my work over SSH or Mosh with tmux to remote servers. Projects like Textualize fulfill a real need here. Another cool hack: using a terminal backend for matplotlib to get inline plots while working via SSH/Mosh.

is there a backend in particular you've found to work?

I've looked periodically for something in this vein, but the only one I can see right now is https://pypi.org/project/matplotlib-terminal/ which I haven't had much luck getting running.

Another great thing is that they are keyboard driven. Keyboard driven computing is far more powerful than using a mouse for many things.

Powerful? you mean it can do more than is actually possible to do with a mouse?

Power is the amount of work done over a period of time, so even if you can do the same exact set of things with a mouse and keyboard, if the keyboard is faster at doing them, it's more powerful.

You can do all your text entry by clicking keys on an on-screen keyboard if you like, but saying that a physical keyboard is a more "powerful" way to enter text seems reasonable to me.

(sorry in advance, I know this is needlessly "well ackchually" lol)

> but saying that a physical keyboard is a more "powerful" way to enter text seems reasonable to me

No. It's faster and that's all. So call it by that word which is very precise.

If you say 'power' = 'speed' then you've destroyed the meaning of one of those words, just for the modern habit of co-opting a fancier word for a simpler one. I'd prefer people didn't do that, and differentiated 'speed' from a thing you call power which indicates "I can't do that at all, at any speed".

If you don't like bullshit marketing and PR, don't follow it.

Interesting, so do you avoid describing one programming language as being "more powerful" than another? They're all Turing complete, after all... it's just a question of how fast you can develop in one, right?

Good question, 'power' I reserve for turing completeness (some aren't, such as SQL before recursive CTEs were added, and... well, here's a list https://iq.opengenus.org/non-turing-complete-programming-lan...)

For "how much crap do I have to write to get it to do something", I call that expressivity. Scala is more expressive than fractran (I guess...).

Sounds like you are consistent with your usage of terms, and I understand the logic and the motivation.

I would just caution that it's fairly idiosyncratic - plenty of people out there don't use the word "power" the way you do. For example, here is how Paul Graham talks about the "power" of programming languages: http://www.paulgraham.com/avg.html

Just saying, as consistent as your definitions are internally, being too rigid about it may hinder your ability to communicate with others in the field. Good luck buddy <3

Thoughtful reply and it is much appreciated dude, take care!

What's the case for power equals Turing completeness over power equals speed of development?

If we go by the physics definition power is work over time, so the same work over a shorter time is by definition more powerful. I don't think applying that term to software is inherently wrong.

by the physics definition work is kilograms * meter^2 / sec^2 what computer users do on a computer is not work in the physics sense, maybe in the economic sense

I didn't say "power = speed", I said power is work over time, which is the actual definition and supports the rest of my post. You're the one redefining "power".

Again, I fully acknowledge this is nitpicky to the point of absurdity and we're arguing semantics. But if we're gonna argue semantics, then the definitional meaning of power is on my side.

> No. It's faster and that's all. So call it by that word which is very precise.

Definition of "power" is work done over some unit of time, so OP was using it precisely.

One benefit is that you can operate “blindly”, without needing the hand-eye-coordination feedback loop. This tends to make frequent operations more automatic and decrease cognitive overhead.

Another benefit is that keyboard input is higher-bandwith than mouse operations. Imagine a mouse-only interface for everything you can do on the Linux command line, or all the operations you can do in Vim or Emacs (beyond actual text input).

It’s more powerful in the sense of “power user”.

The keyboard may make things easier, I grant. Then the word is 'easier'. and 'faster'. I do use and like emacs BTW.

Then again I have RSI, do you reckon that's easier/faster for me?

> Another benefit is that keyboard input is higher-bandwith than mouse operations

Depends on the job - a mouse is far higher bandwidth for graphics editing, and I know cos I've done that when mice weren't a standard thing.

There's a simplicity of your argument here that misses an important point, use the right tool for the right job.

NB. I use a trackball and IMO that is better than a mouse in all situations I can think of. I recommend them.

One pointing tool I highly recommend for RSI is the contour rollermouse.

Yes.

With a mouse I can select text between brackets and delete it, with vim I can tell the editor to do that.

Well, what's the difference?

The difference is the editor won't accidentally delete one of the brackets ever. That's not possible with the mouse. That's possible with the keyboard.

You've never hit the wrong key on a keyboard and made a mess, ever? I have.

If I mess up I literally hit u before consciously realizing it. I'm not ready to swear I've never mistyped `dib` but it doesn't happen often. Let's say `d8b` for the sake of argument: okay, `d8budib` is a longer way of saying it.

Mouse doesn't have an undo button.

I use the mouse a lot actually, no rodent allergy here. It's not as powerful a tool, it's just not, but it's versatile and literal, the multitool of the UX: I can always click my way to the state I need if all else fails.

> Mouse doesn't have an undo button.

Your keyboard does though, as probably does the GUI of your editor in a toolbar or menu item. It isn't like you have to use only the mouse. The mouse was meant to be used together with the keyboard, not as a replacement.

Yes, yet in a thread specifically about what keyboards can do which mouses can't, "you can use the keyboard for that" is the point.

There's a menu item for Undo in most GUI applictions. But who has time? If you can undo from TUI vim without a keystroke, I don't happen to know how.

The point was the original question "you mean it can do more than is actually possible to do with a mouse?" was wrong because it isn't a question of mouse vs keyboard since mice are not meant to be used by themselves but instead they augment what you can already do with the keyboard.

> the editor won't accidentally delete one of the brackets ever

There's too much faith in your editor. Also. A mouse is a precision pointing device with some tools built in. By the time you've counted how many lines and characters you need to jump in a specific direction, I've already placed my cursor there with a mouse and proceeded with the task I needed to perform.

Because there's no dichotomy between a mouse and a keyboard as vim users would have us believe. These are two tools that people use, effectively, and together.

It actually depends. I'm an emacs user and C-h will select the current 'paragraph', repeated C-h will select the next one down, repeatedly. Moving by paragraphs can be very quick. If you want that, it's almost instant.

Also C-u allows multiples of whatever you want. I can move say, 19 lines up with C-u C-u C-p C-u C-p C-n (move up 16 lines, move up 4 lines, move down one line) and it can be quicker than you'd think - there is a cost of moving your hand to and from the mouse/trackball.

If you know it's 19 lines exactly, C-u 1 9 C-p.

It can be quicker, depending. For precise selection down to the character where gross markers aren't present, yeah, I deffo go with the mouse.

I'm agreeing with you here, just adding a perspective.

> Also C-u allows multiples of whatever you want. I can move say, 19 lines up with C-u C-u C-p C-u C-p C-n (move up 16 lines, move up 4 lines, move down one line)

Or, you know, one click with the mouse. Because sane people don't count lines and characters.

Dick comment. I'm talking from experience that keyboard is sometimes faster, and I actually say (clearly you didn't read to the 4th para) that a mouse is better in other cases. Try reading an entire post before responding.

I was responding to a specific example you chose. You could've chosen a different one. And yet here we are, counting lines and doing math and pretending it "can be faster than a mouse".

For imprecise text scrolling a regular PageUp/PageDown will be faster than calculating the number of lines you need to go up/down. For precise random access nothing beats the mouse. Unless you're in a structured text your editor understands. But then, again, there's no mouse/keyboard dichotomy.

> and pretending it "can be faster than a mouse".

Jesus. I use mouse and keyboard as what's best for the task of that moment. In some cases it's a faster to do some complex things using a keyboard, at others, I pick the mouse. Depends on what I'm doing, how well the emacs commands fit that task, how tired I am etc. I'm talking from many years experience. Get a couple of years solid emacs under your belt then we can talk because evidently you have little to none.

https://www.reddit.com/r/programming/comments/6h1geu/is_the_...

linked to

https://danluu.com/keyboard-v-mouse/

> Jesus. I use mouse and keyboard as what's best for the task of that moment. In some cases it's a faster to do some complex things using a keyboard

Yes. In some cases. Not in the bizarre "let's do arithmetic to figure out how to jump to a line", which is exactly what I was responding to. No idea what got you so worked up.

> Get a couple of years solid emacs under your belt then we can talk because evidently you have little to none.

Ah. The person accusing me of dickish comments goes for the jugular and devolves into personal attacks.

I had two years with emacs. In the end I was very unimpressed, and switched to, drum roll, IDEA. That I use primarily from keyboard, by the way.

I regret to tell you, `dib` is a specific action you just can't beat with a mouse.

Type it for me. dib.

C'mon.

I'm not a member of the ratpoison squad, and use vim commands because they are eloquent. Sometimes that's fast, sometimes it isn't.

I use a mouse because it is versatile and I'm not competitive at vim golf or trying to be.

dib is great though, right up there with ddO.

No idea what dib is, and you haven't explained what it is.

Are there specific actions that might be faster than mouse in vim? Yes.

Does it mean that vim is always faster? No.

Does it mean that there exists a dichotomy between keyboard and mouse? No.

> Does it mean that vim is always faster? No.

Yes. You don’t have to move your hands away from the home row, you don’t have to do some random moves with your mouse to locate the pointer. Vim is pretty much always faster. The important thing here is not the speed though - who cares if you spend 2 vs 5 seconds to select a paragraph anyway. It’s just that vim has much more convenient and most importantly precise way to interact with text objects, that’s it. Precision is the key.

Decide whether it's "vim is almost always faster" or "it's not the speed though who cares if you spend 2 vs 5 seconds".

> Precision is the key.

It's funny how you say this and dismiss an actual precision pointing device. It's also funny we are in a subthread that shows how to do arithmetic just to move up and down a certain number of lines and precisely position cursor where it's needed.

Also, a good article on keyboard vs. mouse someone linked in the thread: https://danluu.com/keyboard-v-mouse/

> I regret to tell you, `dib` is a specific action you just can't beat with a mouse.

> Type it for me. dib.

Ok. I took the bait and typed it. Fro the looks of it found the next matching set of parentheses, deleted content between them, and placed the cursor between them.

I'm.... supposed to be impressed by this random action of destruction?

> dib is great though, right up there with ddO.

Delete a line and insert one empty line? (As far as I could deduce from typing it several times).

But at this point we're veering into the territory discussing weird Vim commands :)

--- offtopic ---

IDEA's versions for this are, on a Mac:

dib:

- Option + Arrow Up to semantically select groups of words. Where "semantically" means "depends on the language". Atrribute value -> attribute value with quotes -> attribute_name="attribute value" -> tag etc. if it's HTML. Value -> declaration -> block -> etc. if it's a programming language (in reality more complex than that)

- Backspace to delete

ddO:

- Cmd + Backspace to delete line - Option + Cmd + Enter (insert line above) to insert new line in place of the deleted one

The great thing about vim is every major IDE has a vim emulator. So even when I use JetBrains I still get to use vim plus all the other great things in their IDEs. IDEA Vim is great. I had a job where I had to use many tech stacks and different IDEs and they all had vim.

> I'm.... supposed to be impressed by this random action of destruction?

I use di" more often but it's the same thing really. fnCall("a| string"), `di"` lets me replace the string, `dib` to replace the argument (all of them ofc if there's more than one).

If ddO isn't available, granted, Cmd-right-backspace will clean up just as fast. Or Cmd-left-delete if you have both keys.

I still have no idea what di or dib does. (There should be an explain vim a la https://explainshell.com :) )

> `dib` to replace the argument (all of them ofc if there's more than one).

I prefer editors that are aware of context :)

> right up there with ddO

I believe S or even cc is more succinct

See that's vim golfing! I kid, I kid.

I use ddO because I use dd and I use O, while I've never gotten 'conceptually fluent' with using the c range to do delete-then-edit. I know it's there but I don't use it.

TUI apps are not inherently more keyboard driven than GUI apps. Indeed, if you look at the demo video linked in the article, majority of the interactions are done with mouse.

Textual supports both keyboard and mouse control. But we are aiming for a keyboard-first interface, which I feel is a better fit for terminals.

Not really, as proven by keyboard + mouse chords.

While TUI apps are not new, and I’m not inherently against them (I very much like them), I am worried that the recent proliferation of frameworks is going to give a lot of developers a shiny new toy to build fancy apps with that will now be much more limited as a result.

IMO, the simple input/output and parsable nature of a good CLI app lends itself to chainability, scriptability, and reusability that is still more powerful and flexible than just about anything else.

Put in other terms, you can build a GUI/TUI over one or more CLI apps, but you can’t build CLI apps over one or more GUI/TUI apps.

If developers using these tools realize the need to build these things in layers and not force usage of their app solely through the TUI, then great - everyone wins.

But I’m pessimistic that will be the case.

I don’t know, even with good frameworks TUI interfaces are harder to do than simple CLI. From what I’ve seen, interfaces made with these framework aren’t replacing CLI tools, just augmenting them. In fact I think the use cases are usually completely different, when a TUI comes up it’s because you really need interactivity and not just “launch command and see the output”. And viceversa, I don’t see anyone making TUIs for use cases that are just sending commands and seeing output.

I think you are being blinded by UNIXisms. If you want something that is chainable, scriptable, and reusable you want a library. You can build many different user interfaces over the same library. Unlike a CLI you don't have to serialize and deserialize into strings and doing error handling is much easier.

A library limits you to the language it is written in, meanwhile a CLI program can be combined/chained with other CLI programs regardless of the language it is written - you can mix programs written in C, Java, C#, Haskell, Rust, Python, Go, etc without caring about these languages or even having their development tools/compilers installed just so you can tie them together.

Eventually they will rediscover Expect as well, then we will have a renaissance of TUI scripting languages.

Ah but that's the best part about TUI, you can fall back on the cli when you don't want the whole burrito.

Well, sticking with the analogy you're falling back to a taco made from different ingredients rather than just a part of the burrito. That can be intrusive if they decide to put chicken instead of ground beef in it.

More concretely, it's using a totally different tool to get a subset of functionality you want vs other solutions.

Personally I don't see a reason why one would do that, but more power to you if you do. If anything, ordering the taco sometimes is going to give you a more refined palette than if you got the same burrito each time (i.e. more experience in the problem space you're working in).

(I'm getting hungry now...)

.... if the tui app includes the functionality.

Nobody forces you to use them.

in practice, i rarely see a tool that only offers a tui. most tui tools i encounter will respond helpfully to a `--help` flag and let me do anything i need from a script. any tool that doesn't is nearly useless - i don't think this is lost on most cli app developers, and i don't think it's at odds with the quest for 'pretty' UIs in interactive mode.

> I feel the opposite, these kinds of projects imho are just moving terminals away from their key benefits, being simple, predictable, brutally functional with no gratuitous animations or flourishes

This stuff is not "new" at all. It's just the latest twist on the ANSI art of old, and the use case is similar.

As someone who started out using pre-PC micro-computers (TRS-80, Apple ][, CP/M), I often would like to have access to a good suite of what we now call TUI programs.

Having a common TUI would be a bonus, which briefly existed back in Borland’s heyday.

I feel the same. Simple ANSI color is enough. Call me old school, I don't want emojis in my terminal.

With emojis you usually also get unicode, which is great for all the non-ascii-languages out there.

Non-ASCII language support is good. Poop emojis and smileys? No thanks.

Except Japanese, where unicode is a big regression.

I still use IRSSI as an IRC client, running in a screen session, through SSH, from multiple machines or even from my phone. The TUI in gnu screen over SSH setup is really handy for securely accessing a continuously-running application from anywhere you happen to be. I could use irccloud or some other web based thing, sure, but I like hosting my own services and having auth and device whitelisting uniformly handled the SSH way. Yet a chat client doesn't work well as a set of CLI commands as opposed to a TUI. Email from TUI might not be too bad either. There are lots of cases where I think it'd fit.

I got pretty used to using Mutt back in the day. I was pulling my email from my ISP via IMAP, running Procmail on it and putting it into maildirs. Somewhere along the lines I got really lazy and Gmail became "good enough". I will admit that it's much nicer for viewing and sending rich content.

> Indeed, if all the features of modern graphical/web applications are dragged into terminals, then what is the point of using terminal anymore instead of native graphics/web?

This isn't it at all. Great example: k9s [0]. Sure, you can manage k8s via kubectl. Or you can manage it via some web UI. And both of those options are a pain in the ass compared to what you can do in k9s in a few keystrokes. The TUI is the perfect combination, when done well, between a GUI and CLI apps. The interface can get out of the way and the usage can be driven by keyboard input vs the duality of click 'n type, or memorizing commands with a myriad of nested subcommands / flags.

[0] https://k9scli.io/

Dealing with the DOM is so bad in browsers webdevs want to escape it at any cost.

What they don't realize is that the reason the DOM is bad is because of webdevs like them.

So we will end up with a DOM in the terminal and the locust plague of JS developers will move somewhere else.

I agree. I immediately associate this with "show-off computing", which would probably look good on brain-dead TV shows about l33t haXors or "Anonymous" documentaries..but what's the point of slowing down your terminal even if it's just by 0.000001 seconds per keystroke only to look at Emojis? Will get old very fast.

Aren't these all just the next evolution of ncurses?

That's not exactly new, and has been around long enough that I dont think these other project are moving the cli any further away.

Most tui these days are not that functional. Compared to some as400 days apps or some old repls. Maybe recent projects are too frivolous but it's cool to see energy flowing there. More appealing than the heavy web imo.

Yes, and some are even intended only for the X terminal, not the real TTY.

What is missing is a nice library for high level languages, as ncurses is famous and all that, but who, unless they are coding in C, can interface with it and even understand the documentation.

Agreed. I cut my programming teeth on the Dr. Dobbs/Al Stevens "D-flat" series which was a text-based windowing system in C. Some of the most fun I've ever had programming. The hardest part was waiting for the next issue to be published!

I've tried to find the most recent version of that library, even emailing the author, but he's long since moved on and I could only find bits and pieces.

Maybe https://archive.org/details/dflat is best now?

Try https://github.com/ghaerr/dflat, which is D-Flat version 2.0 ported to Linux and macOS.

Funnily enough, I just happened to have ported D-Flat to macOS and Linux in the last couple of weeks. Check it out (w/screenshots): https://github.com/ghaerr/dflat. It uses a small TUI library that maps multi-byte ANSI/xterm arrow key and mouse wheel inputs into unicode private-use codes for internal processing by D-Flat. It also remaps all of the IBM PC code page 437 characters for unicode output, and converts the entire "PC-compatible" screen image including attributes into ANSI terminal output, thanks to some nice code from the Cosmopolitan Project.

That is great - I starred the repo.

Are the original articles available somewhere?

Yes, they're available on the archived Dr Dobbs Journal DVD V6 (https://archive.org/details/DDJDVD6), starting in the May 1991 section, or thereabouts.

He eventually ported them into Turbo Pascal as well, that is when I bumped into the series.

The general workflow I'm finding useful is to generate a ton of simple logs, ingest all those logs into a SQLite database (that acts like a "data lake"), and then use the customized REPL to generate some charts (typically .png files), CSV, or ascii reports.

I could see using a REPL to generate a TUI, e.g., "run a query and generate your own `top`". This seems like it could be a lot easier than trying to generate a PDF, interactive Excel, or complex HTML report (which usually means a bunch of javaScript).

There's something about text interfaces that just fundamentally "flows" from most programming environments.

imagine cross platform apps that work just as well on phones, and built using this type of almost scripting like code. (check out pywebio too)

Like a Web browser?

yes, minus the Javascript.

I really don't, I started my coding life on 8 bit computers, went through all MS-DOS versions starting with MS-DOS 3.3, and on the UNIX side with Xenix, all the time wishing stuff like the Amiga, Atari ST and Acorn would be the standard way of computing.

Turbo Vision was the best TUI framework, with a compiled language, in 1990, 32 years ago!

I really don't get this terminal nostalagia.

I personally think it's because in many ways we're not building native, snappy, keyboard-driven desktop apps any longer.

Everything is moving to the web or web-like. Most of the apps I use at work are web-based and mouse-heavy. The overall slowness and latency of the UI is killing me.

TUI apps represent a weird niche. People building them are _usually_ into providing a UX that is fast, productive, offline-first and composable (ie: lends itself to automation). It's a breath of fresh air.

I agree. It's easier to build TUI apps (and more portable usually) then fully native GUI applications.

Another point for TUI apps is that they are usually keyboard focused unlike GUI and webapps which require using the mouse (and are therefore less efficient)

Reply on news.ycombinator.com