Re: Hardware independent programming

[Shark8 <onewingedshark@gmail.com>]

On Sunday, June 28, 2020 at 10:42:22 PM UTC-6, ldries46 wrote:
> Hardware can in some cases have limits you have to consider when writing 
> a program.
>   At this moment I can mention three:
> 
>  1. The printer. The format of the documents you want to print must fit
>     on the printers available to the user. In general the problem is
>     solved by the possibility of printer drivers to shrink you document
>     f.i. from A4 to A4 or saving the document to a file that can be
>     printed elsewhere.
This is a solved problem with PostScript; and has been for literally decades.

>  2. The monitor on the system your program is running. Creating a window
>     that is to large for your screen resolution can be trouble some but
>     you do not know the resolution of the the customer using your
>     program. The solution for such a problem can only be hardware
>     independent programming. Your program should know the resolution of
>     your screen and adjust to  that or in the worst case decide that
>     system is not suitable for the program.
There are similar solutions to the postscript model; hell, Borland's BGI in the late 80s handled this problem. There was even an extension to Postscript: Display PostScript. — That you are having issues with this problem now, after decades of experience, is illustrative of my thesis that C and C++ has set the industry back decades.

>  3. The available memory. Your program will in some cases need to know
>     the limits to which the heap stretches within the memory (in cases
>     where it is necessary  to use very large bulks of data). For
>     operating systems that have the possibility to stretch the heap with
>     a part on disc both boundaries (with and without disc data) are of
>     interest.
Memory management is... tricky. Besides being rather technical and needing precise adherence to a particular model, oftentimes that sort of low-level thinking gets in your way. -- There was an excellent Guy Steele talk (I think it was "How to think about parallel programming. NOT!") where he made an analogy between memory management and parallel processing, noting how just as the explicit-style of earlier years (ie "put this value into a register") got in the way of more advanced register-allocation so too is the accumulator/sequential-solution going to get in the way of parallelization.

> There should be a package in Ada that like GNAT.OS-lib does with 
> operating system differences, makes such hardware parameters available 
> for the programmer.
Possibly. The problem is that there's a *LOT* of [possible] parameters, and you'd have to multiply that by all your targets, so that's a lot of extra work to foist on Ada implementers. — I'm not saying that it isn't a good idea, just that it's a lot of work... though this could be mitigated, perhaps, if the Ada/OS interfaces weren't sometimes done the stupid way around (eg directory-paths as strings rather than as lists).