[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