[Info-vax] "Clever code", was: Re: wrong file format

[Dave Froble]

On 1/8/2021 10:16 AM, Stephen Hoffman wrote:
> On 2021-01-08 13:14:12 +0000, Simon Clubley said:
>
>> Yes. The VMS terminal driver is an example of this idiotic mindset and
>> is also the reason why, in 2021, we can't even do something as simple
>> as edit DCL command lines which are longer than the terminal width. :-(

The first job of any computer is to "get the job done".  Bells and 
whistles fall far below this requirement.  I've never seen one instance 
where a user of an app had any use for line editing.

> Pragmatically, the terminal driver class-and-port design has survived
> for an unusually long time for software, and is still in active use.
>
> Terminals and storage I/O are the two biggest class-and-port driver
> stacks, and for similar reasons—trying to have logic common to all
> devices, without having to maintain and update common code across
> multiple monolithic device drivers; splitting device-generic from
> device-specific processing.
>
> The design assumptions and trade-offs around the terminal driver and
> LOGINOUT and JOB_CONTROL and CLI are all inter-related, too. Might
> command editing be better implemented in the CLI? Quite possibly.
> Probably. Sure. But there are requirements around responsiveness, and
> moving editing further from the hardware usually adds latency. In years
> past, terminal hardware was really slow. And some was even slower. So
> too was VAX slow. And debugging a CLI gets... interesting, too.

I still remember lag in terminal entry.  Back on the PDP-11 systems, 
I've watched users enter lines on an order.  They could get several 
lines ahead of what the computer was echoing back to the terminal.  They 
just knew the job well enough they could enter the data without seeing 
the echo.  (Try that on a WEENDOZE GUI.)  Yes, responsiveness is critical.

> For why this line-editing length limit still exists? Not clever nor
> idiotic code. I'd tie that limit to a ~thirty year old class-and-port
> driver design mixed with support for yet older hardware and sorta-kinda
> support for far newer software terminals, with a very large dollop of
> compatibility-preservation, along with fewer non-revenue-focused
> long-term investments than any of us including the folks in OpenVMS
> development might prefer. Forever-compatibility has its costs. And
> rip-and-replace is less than popular with the apps and users dependent
> on the existing behavior. (There was some other and non-technical "fun"
> arising here aeons ago, too.)
>
> Past some threshold app size or app complexity, it's never simple.
> Trade-offs all the way down, too.
>
> I'm usually running terminal line widths ~200 characters, and usually
> using scripts or cut-and-paste for longer commands and repeated
> commands. Yes, this line-editing limit is annoying. Many other areas of
> OpenVMS are ripe for updates, too. Feature-competitive operating systems
> are very large projects. Very. Large.
>
> Ponder the very long list of feature requests at VSI, and at the very
> limited budget and staff available, and at what from that list can get
> implemented, and what revenue that work might bring in. VSI hasn't
> surveyed the paying folks and prolly won't, but I'd put the x86-64 port,
> the 2 TiB and other file system limits, and better integrated database
> support, all ahead of extended line editing, among other details.

+1


-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486