Niklaus Wirth has died

I have used DECALN, which is sometimes useful for testing purpose (especially in full screen, although sometimes even if it isn't).

I will want to see support for the PC character set, for EUC character sets (including EUC-TRON), TRON-8 character code, bitmap fonts (including non-Unicode fonts), Xaw-like scrolling and xterm-like selecting, ability to disable receiving (not only sending) 8-bit controls (which should be used to switch between EUC-JP and EUC-TRON, as well as other purposes), a "universal escape" sequence (recognized anywhere even in the middle of other sequences), and some security features (I have some ideas that I don't even know if it is possible on Linux or on BSD, such as checking the foreground process, and being able to discard any data the terminal emulator sent to the application program that as not yet been read yet, which can avoid a file or remote server to send answerbacks which will execute commands in the shell, if you add a cancellation code into the shell prompt, etc)

It's a one-liner to fill your screen, and the fraction of people who even know DECALN exist is so small I wouldn't be surprised if the total invocations of DECALN by terminal users in recent decades is smaller than the number of indirect invocations by terminal implementers via vttest.

It made sense as a service tool on a physical terminal, not much now. It's not that it's a problem - it's trivial to support. It's just that it is an example of one of hundreds of little features that are box-ticking exercises that would cause about a dozen people worldwide to shrug if they noticed they weren't there before they'd do the same thing a slightly different way and not think about it again.

Some of the ones you list are useful some places, but many of them don't need to be in every terminal. I want more, but smaller, options built from generic reusable components.

E.g. most of my terminal does not care what your character set is, or what type of fonts you want to use, or how your scrolling works, or if you have scroll bars, or whether there is a shell, or whether there's a program being run by a terminal vs. a program embedding the terminal, or if it's running in a window, or whether it has GUI output at all or is entirely headless. This is true for most terminals. Yet these components are rarely separated and turned into reusable pieces of code.

Most of the features you list are features I don't need, won't implement, and don't care about. But what I do care about is that with some exceptions (e.g. the Gnome VTE widget) most terminals reinvent way too much from scratch (and frankly most users of terminal widgets like VTE still reinvent way too much other stuff from scratch), put too much effort into supporting far too many features that are rarely used, instead of being able to pick a terminal that is mostly just pulling in generic components as a starting point.

The result is a massive amount of code that represents the same features written over and over and over again and sucking time out of the bits that differentiate terminals in ways useful to users.

E.g. just now I've been starting to untangle the bits in my terminal that handles setting up the PTY and marshaling IO between the shell or other program running in it and the bits that handle the output to the actual terminal. The goal is to make it as easy for casual scripts to open a terminal window and control it as it was on the Amiga, without having to spawn a separate script to "run in it".

On the Amiga you could e.g. do "somecommand >CON:x/y/w/h/Sometitle" to redirect "somecommands" output to a separate terminal window without any foreground process, with the given dimensions and title, and assorted other flags available (e.g. "/CLOSE" would give yo ua close button, "/WAIT" would keep the window open after the process that opened it went away etc.).

If you've written a terminal, then part of your terminal represents 99% of the code to provide something almost like that.

Beyond that, I'm going to rip the escape code handling out too, so code that don't want to do escape codes still can pretend they're talking to a terminal with a somewhat ncurses-y interface but with the freedom to redirect the rendering or render on top of it, or whatever, then that makes "upgrading" from a terminal UI to somewhat of a GUI far easier (the Amiga, again, had a lot of this, with apps that'd mix the same system console handler used for the terminal with few graphical flourishes; it lowered the threshold to start building more complex UI's immensely)

Then I'm going to extract out the actual rendering to the window into a separate component from the code that maintains the (text) screen buffer, so that I can write code that uses the same interface to render either to a terminal or directly to a window.

Same for e.g. font-handling - I've decided I don't care about bitmap fonts, but the actual bit of my terminal that cares about any kind of fonts is ~40 lines of code, and to most of my terminal components it doesn't matter if you output anything anywhere, but even of the remaining code actually dealing with GUI output, 3/4 doesn't care, or know, about fonts at all (managing a window, clearing, filling, scrolling take up more). Making it pluggable so someone could plug in either a client side bitmap font renderer or code to use the old X11 text drawing calls is trivial.

Because with all of these things broken out into components it doesn't matter much if my terminal doesn't support your feature set, if "writing another terminal" doesn't mean writing the 95% of the code that implements shared functionality over and over again.

You could write literally half a dozen of custom tiny terminals like that before even approaching the line count of xterm's mouse button handling code alone.

I agree with all the points.

It's been long time since I last used lua and only positive memories remained :) I used it for adding scripting in the apps I worked on and the experience was very good -- sandboxed from the start, decent performance.

Perhaps having 0-based indexes would've been bad for our users but I don't think they used arrays at all.

I think it was a very minor contribution ... they wrote a pseudo-Algol program as a form of documentation of their network protocol and were concerned about checking the grammar/syntax of the program (people actually cared about the quality of documentation back then), and I wrote a syntax checker for it in Meta V, as it was on hand because it was written at UCLA (I don't know whether it was Dewey (Val) who designed and implemented Meta V or someone else) and was used by people in the Comp Sci Dept. to design programming languages. But the dept was shifting to networking at the time (the IMP had just arrived) under the direction of Leonard Kleinrock and through the efforts of pioneers Steve Crocker, Vint Cerf, and Jon Postel (all of whom had attended Taft High School together) ... this is why the authors of that network protocol were visiting UCLA. I got involved because I worked for Crocker, under the direct management of Charley Kline, who was the fellow who made the first ever networked login.

Hi kragen, hi amatecha!

Someone sent me this thread so I could answer, and I do agree. I for one think uxn is trivial, it was directly inspired by the VM running Another World and created to address a similar need. It's not especially fast, or welcoming to non-programmers, it was a way for my partner and I to keep participating in this fantastic universe that is software development, even once our access to reliable hardware was becoming uncertain. It's meant to be approachable to people in a similar situation and related interests, and possibly inspire people to look into assembly and stack machines -- but it has no lofty goals beyond that. We're humbled that it may have inspired a handful of developers to consider what a virtual machine designed to tackle their own needs might look like.

A lot of our work is owed to Wirth's fantastic documentation on Oberon, to the p-machine and to pascal. Niklaus' works has influenced us in ways that it would be very unlikely that we could pass forward. I'm sad to hear of Nicklaus' passing, there are people who inspire me in similar ways, that are alive today and that I look up to for inspiration, but to me, Wirth's work will remain irreplaceable. :)

-- Devine

http://wiki.xxiivv.com/site/devlog