I try one more time on list, but if you want to discuss more, let's go off-list.
On Mon, Dec 17, 2018 at 2:56 PM Paul Koning <[email protected]> wrote: > > Not unique to VMS nor even to DEC. I agree - that is exactly what I was saying. It was the way I/O was done in the 60s - which seems to have had a rebirth as part of modern Frameworks. And if you are programmer that grew up with I/O byte streams, then you think in terms of line terminators for text files; not variable length records. As Dennis Ritchie once said to me, the whole idea behind a byte stream was for the OS to just get the bits and then user code do the interpretation (which of course can be in a library). But don't make the OS need to know much -- just get the bits from storage and shove it into memory and let user interrept them. My guess is this is one of those cyclical arguments. Before the OSses of the 60s, when code ran raw on the HW, a programmer needed to add those libraries in your runtime deck. Putting 'record management' into the OS was seen as easier and made progammng simplier and fast. The problem of course is it was different for different systems and languages. So one person's easy, became another person's burden. By the time of Dennis and Ken are doing their thing -- they are fighting the native system I/O. Streams was a lot easier in Dennis's mind (and I tend to agree - I came up on IBM systems from the 60s, then PDP-10's, and VMS before UNIX). Eventually, as C and UNIX spread, what OSses followed and languages made easy followed that vision. And today most programmers have not seen the 'old ways.' FWIW: Years later, we start creating all these different ways of packaging up libraries and methods (a.k.a. programming frameworks) to hide the byte structure of files. So instead of learning ISAM/VSAM etc... you used some different set if API's that called sql-lite, *etc.*.. Who knows what will be 'natural' in the future. Clem ᐧ
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
