Please make it stop
> On Feb 15, 2019, at 10:56 PM, Brian White <[email protected]> wrote: > > By tightly coupled, I mean that Telcom has inside knowledge of the rest of > the system. > > The tpdd does not. > > (nor the dvi, and I'd put money on the chipmunk too) > > The only reason you can produce examples of other software and systems doing > things like that, is because it's something that used to be very common, and > even today every new programmer takes some time to learn better, and some > never do. But by now it is recognized as an antipattern. After > Joe-self-taught-teenager-programmer-from-the-70s-80s writes a bunch of such > stuff, it's all fine at first, and only later he discovers that he has > written an unmaintainable and unportable brick. Customer wants the tiniest > change and it's practically impossible, because the code is riddled with > assumptions that should never have been made. > > > John did raise some points that no tpdd emulator to date has emulated the > drive *really* though, else they would use disk images instead of files. And > the knitting machines don't use files either. > > I personally don't think that's a strong enough argument, but it is at least > an argument. I think that just means a tpdd emulator is a filesystem instead > of a disk. OK, so I would not tolerate a filesystem that modified the files > either. > > > As to Mikes point about causing harm: > > Preserving data is never causing harm. > > If there is harmful data, then the harm was caused by the thing that created > that harmful data. > > I see that as "two wrongs don't make a right". > > If a text editor added eof, that was a bad text editor, and it's more helpful > to the user to have the bad data and thus indirectly the cause of the bad > data, be exposed and corrected, rather than silently allowed to persist and > even propagate over time. So that you go on thinking you actually have good > data when you don't and it just fails tomorrow in any other context. > > -- > bkw > > > On Fri, Feb 15, 2019, 2:44 PM Gary Weber <[email protected] > <mailto:[email protected]> wrote: > GW>> Since when is it NOT wrong for TELCOM to disallow recording of <EOF> > into a .DO file being downloaded, but it IS wrong for the LaddieAlpha/TS-DOS > combination during the same operation? > BW> the fact that telcom is part of a very tightly coupled and managed > system. It's not generic software that runs anywhere > > You have clearly, and strongly, stated the some very sound engineering > principles. Honestly I doubt anyone (or at least many) would question the > principles in the universal generic sense. > > But I would assert LaddieAlpha is not universal or generic. It has a very > defined stated purpose, and has always made specific concessions for Model Ts > & WP2s. Using it outside of this context is at your own peril, so to speak. > And you're bringing up not just edge cases but actually *corner* cases to > the usage model. > > Secondly, TELCOM doesn't know where data is coming from via the COM: port, so > I question the claim that it is part of a very tightly coupled and managed > system in the context of how it downloads data. Rather, it filters the data > to be appropriate to the machine. The LaddieAlpha/TS-DOS coupling is no more > nefarious than this, and to knowingly permit that combination to crash the > machine, while TELCOM protects the machine, would not only be silly, it would > be irresponsible. > > Unless the user directs it to do so of course, whereby my > --allow_file_system_corruption switch would suffice. ;-) > > > On Fri, Feb 15, 2019 at 11:31 AM Brian White <[email protected] > <mailto:[email protected]>> wrote: > All else being equal, it IS wrong for telcom not to record whatever bytes are > sent. > > It's excuse is, at the time such ideas hadn't been recognized and discarded > yet, and the fact that telcom is part of a very tightly coupled and managed > system. It's not generic software that runs anywhere, it's part of a rom, and > so it's less of a crime to be tightly coupled with the other parts of that > rom, like making presumptions about what kind of data may exist in a file > with a certain kind of name. > > The tpdd makes no such presumptions. > > Telcom also only ever claimed to operate like a user application that deals > in text just like a text editor. How the text editor and telcom package up > data internally are their own business. They just accept keystrokes and > display characters. That is an entirely different domain. > > What you should ask is, when you tell BASIC to read or write from COM:, does > BASIC presume to modify the data? > > Similarly would you tolerate a file compressor or other encoder that didn't > spit back out exactly the data you put into it? > > Telcom processing the data as though it's text is like an image editor adding > metadata on it's own. It's an allowed part of it's job because it's job is to > deal in displaying a visual image to you, not to hold that data in trust for > something else. IT is the app whose defined role is to manipulate and process > the data. > > But then when you take that image data the the image editor made, and put it > into a zip file, and save it to a thumb drive, and then read it back from a > thumb drive, it's entirely wrong for any of those things to output one single > bit different from what they were given. > > On Fri, Feb 15, 2019, 5:19 AM Gary Weber <[email protected] > <mailto:[email protected]> wrote: > Since when is it NOT wrong for TELCOM to disallow recording of <EOF> into a > .DO file being downloaded, but it IS wrong for the LaddieAlpha/TS-DOS > combination during the same operation? > > On Fri, Feb 15, 2019 at 2:29 AM Brian White <[email protected] > <mailto:[email protected]>> wrote: > Since when does a disk drive decide what is and is not supposed to be treated > as text vs binary data? The application author who decides which flags to use > with open() does that, or the ftp client user does that by using the bin > option *which exists*. The the drive subsystem never ever decides that. > > No one answered the question about the sewing machines which also used these > drives. > > "AFAIK "good programming practices and principles" are suggestions and > recommendations, not laws." > Indeed. > 1) I never said anything else. > 2) Why is a "good practice" good in the first place? For a reason, not > because god said so or something. Something is good or bad because of the > harm it lessens or increases. > > > > > -- > Gary Weber > [email protected] <mailto:[email protected]> > > > -- > Gary Weber > [email protected] <mailto:[email protected]>
