←back to thread

320 points IroncladDev | 7 comments | | HN request time: 0.001s | source | bottom
Show context
rollcat ◴[] No.43670593[source]
I don't understand the obsession with 1980s terminals. They're even less powerful than the contemporary 8-bit home computers. It's perfectly OK to be a retro enthusiast, it's another thing to claim that this is the peak tech to power our modern CLIs, or a solid foundation for portable UIs.

From the docs:

    Stop thinking in standard CSS units like px, em, rem, %
    Start thinking in Character Cells for spacing, sizing, and positioning
A VT102 already has a character grid, but it needs a serial protocol to allow applications on the mainframe to talk to it. You can loop around this and use the raw mode to address individual cells.

The web browser has an insanely powerful typographic and layout engine. Now we're looping back into character cells. Something went wrong here, at least once.

That said, I like the aesthetic and the default color palette. It's quirky, but it has its places.

replies(13): >>43670672 #>>43670690 #>>43671003 #>>43671094 #>>43671420 #>>43671663 #>>43672234 #>>43673068 #>>43673112 #>>43674448 #>>43675035 #>>43676127 #>>43678300 #
geocar ◴[] No.43671094[source]
> Something went wrong here, at least once

The higher-level view of data-over-time is inherently serial, and I don't think there's anything anyone can do about it: Serial is the correct/best abstraction.

That being said, I acknowledge the problem you're referring to, because serial what exactly? Every time we complete the circle, it gets a little smaller, and our collective knowledge of what is actually going on improves.

It should make a certain amount of sense if you look at it this way: Use a serial decoder to fill a memory bank of character cells or pixels or whatever, and share that memory bank with a video encoder, and the software guys say: well, how about I just fill up that memory bank directly. Then, you don't want character cells but triangles, and you find you're just DMA'ing in that shared buffer and working around the timing of another process reading it and your ring-based memory buffer has turned back into a serial protocol before you know it.

I think the main problem is that programming languages are terrible at serial, so programmers keep trying to work around it, and then convert to/from serial at the edges.

> it's another thing to claim that this is the peak tech to power our modern CLIs, or a solid foundation for portable UIs.

I can't explain all of it, but terminal UI remain without match: Even today (2025) I use a terminal because there's no better human-computer interface for doing intellectual work.

A picture of a terminal, is not a terminal, so I understand why stuff like this confuses.

replies(1): >>43671670 #
pjmlp ◴[] No.43671670[source]
Yes there is, it is called a REPL, Xerox PARC has plenty of examples across all their workstation variants, followed by Oberon, and some of that work even inspired Plan 9 and Inferno UI and related developers editor, ACME.
replies(1): >>43673308 #
geocar ◴[] No.43673308[source]
I don't understand exactly what you are trying to say.

I think a REPL is the real-eval-print-loop used by lisp systems to talk to a terminal, or something that looks/works like that (but maybe doesn't use lisp). These days I think lots of things have REPLs. Even Python. The only ones to survive 40 years though, have been serial ones, and I don't think that's an accident.

That command box/area that the user uses and re-uses in Oberon and Acme is something else and specifically worse than a REPL because you can't script it: There's no GNU expect for rio, and no DESQview-learn for Oberon and their command language just isn't good enough. This interface has not proven particularly efficient for users either, but terminals are still around.

Emacs is what I'd consider "peak terminal", and it has a REPL and an excellent command language. You can also script Emacs with emacs, by literally running emacs in an emacs terminal.

replies(1): >>43674004 #
pjmlp ◴[] No.43674004[source]
That is a a barebones REPL from early 1960's, not the experience I was mentioning.

Imagine Emacs mixed with Jupiter netbooks, for the whole OS stack.

replies(1): >>43674268 #
1. geocar ◴[] No.43674268[source]
> Imagine Emacs mixed with Jupiter netbooks, for the whole OS stack.

Sounds dreadful.

> That is a a barebones REPL from early 1960's, not the experience I was mentioning.

No, that is a definite article. I was talking about three things, two of which are things you brought up in an effort to find common ground. If you don't know Oberon or Acme then there's no point in talking to you about them. I still don't know what you're trying to tell me, and I'm beginning to think you don't either.

replies(2): >>43676455 #>>43679193 #
2. rollcat ◴[] No.43676455[source]
> Sounds dreadful.

Depends. Emacs has had brilliant ideas, did brave things, it just remained stagnant for the past 30 years. (Unlike terminal emulators, which do boring things, and have been stagnant for 40 years.)

A slightly better REPL doesn't have to be brave. It just needs a sensible text editing widget, that's already a tenfold improvement. The cognitive load between Ctrl-C and Ctrl-Shift-C drives me crazy.

replies(1): >>43678569 #
3. geocar ◴[] No.43678569[source]
> it just remained stagnant for the past 30 years. (Unlike terminal emulators, which do boring things, and have been stagnant for 40 years.)

I disagree with all of this.

> The cognitive load between Ctrl-C and Ctrl-Shift-C drives me crazy

If you use emacs like you say, you should know you can bind ^C to whatever you want.

I like ^C being what it always has been, and I'm not persuaded by one person's inability to perform an internet search or read the manual of software they claim to use.

replies(1): >>43678959 #
4. rollcat ◴[] No.43678959{3}[source]
> If you use emacs like you say, you should know you can bind ^C to whatever you want.

Hell no. I've suffered Emacs bankruptcy several times over the past 20 years. I try to keep my init.el under 1k lines to avoid another one. Rebinding Ctrl-X or Ctrl-C never works without addressing a dozen quirks, and there's always another one waiting around the corner. Hell no.

> I disagree with all of this. [...] I like ^C being what it always has been [...]

You're entitled to your opinions, but I'm arguing for more consistent behaviour for applications. This can be objectively measured by answering questions such as: "does this application copy and paste text? if so, does it use the same key shortcuts as the next application?"

replies(1): >>43680701 #
5. pjmlp ◴[] No.43679193[source]
> Sounds dreadful.

To people stuck in UNIX mindset, maybe.

> If you don't know Oberon or Acme then there's no point in talking to you about them. I still don't know what you're trying to tell me, and I'm beginning to think you don't either.

Oh boy, I definitely know Oberon.

Here is my detailed explaination.

You write the REPL like code you feel like on a pane, you can the use the sigils that map if the command (loaded dynamically as instances from Oberon commands in modules), refers to existing text, selected wigdet on another pane, or requests user for additional infortmation, mouse select the command and execute it.

replies(1): >>43682916 #
6. geocar ◴[] No.43680701{4}[source]
> Rebinding Ctrl-X or Ctrl-C never works without addressing a dozen quirks, and there's always another one waiting around the corner. Hell no.

:)

> I'm arguing for more consistent behaviour for applications

I think that's tilting at windmills.

You can solve your own problems, or you can ignore them, but there's no way you can just whinge on the Internet about how much you love Emacs but hate the copy/paste keys and get anywhere. You already know this. I'm sorry. Good luck with that.

> This can be objectively measured by answering questions such as: "does this application copy and paste text? if so, does it use the same key shortcuts as the next application?"

Since my first mouse, it has always been select with left button and paste with second button. That's how it is in OS/2, in every unix, and even on VMS. That's how it still is with every terminal I use. It's just simply not an application concern in my world and I think it was bad engineering for Apple and Microsoft to try and get the Application involved in the clipboard.

7. geocar ◴[] No.43682916[source]
> Oh boy, I definitely know Oberon.

> You write the REPL like code you feel like on a pane, you can the use the sigils that map if the command (loaded dynamically as instances from Oberon commands in modules), refers to existing text, selected wigdet on another pane, or requests user for additional infortmation, mouse select the command and execute it.

Ok. I feel like I already explained why TextFrames is (a) not a REPL, and (b) absolutely worse than what you can do in a terminal.

> To people stuck in UNIX mindset, maybe.

I don't know man. I don't know anyone who doesn't use UNIX every day, and I don't know anyone who uses Oberon every day. I am telling you in a way why I don't think that's an accident, and we can talk about that aspect if you want, but I think the cobol forms on a 3270 are a way more interesting version of terminals than what UNIX does with them, and programming/scripting the terminal is really the thing I think that makes them better than any other human-computer-interface.