[Info-vax] DCL Output Parsing, Compatibility, and Terrible User Interfaces
Stephen Hoffman
seaohveh at hoffmanlabs.invalid
Mon Dec 3 14:18:55 EST 2018
On 2018-12-03 18:30:39 +0000, Jairo Alves said:
>
>> This isn't a specific problem, it's a general problem. Basically,
>> you're not going to ever get any values that require 33 or more bits
>> from system data structures that are limited to 32 bits.
>
> Can't it have a flag for signaling continuation, like an IP packet?
>
> In the lexical function, if it receives back this special bit serving
> as a flag set, ask for the second part and then process the output
> before showing the result to the end user.
>
> I imagine something like that could work in a new project, but it would
> break retro-compatibility.
That'd probably be more commonly termed a data-overflow flag and/or
data-valid flag. There's no path to return that flag within the
context of existing DCL lexical functions other than as in-band
data—magic return values—and in-band always gets ugly.
And the whole approach is also setting up folks for a surprise months
or years into the future too, when some subtly-linked configuration
assumption is broken by an apparently-unrelated software or hardware
change.
Problems with descriptors and with in-band magic numbers and the rest
then leads to discussions of OO-style programming and scripting
interfaces, though that's also a much larger project. See .NET and
PowerShell for some examples here, as well as Python.
https://jakevdp.github.io/PythonDataScienceHandbook/01.05-ipython-and-shell-commands.html
Once you decide to break a few APIs and a few limits, you're better off
breaking a bunch of related APIs and limits, and making room for other
changes and/or for better or easier designs. Make moving forward more
valuable to many current folks and to new folks, and not just an
exercise in migrating old source code.
--
Pure Personal Opinion | HoffmanLabs LLC
More information about the Info-vax
mailing list