[COFF] Commonality of 60s-80s Print Standards

[COFF] Commonality of 60s-80s Print Standards

[segaloco via COFF]

Good morning folks, I'm hoping to pick some brains on something that is troubling me in my search for some historical materials.

Was there some policy prior to mass PDF distribution with standards bodies like ANSI that they only printed copies of standards "to order" or something like that?  What has me asking is when looking for programming materials prior to when PDF distribution would've taken over, there's a dearth of actual ANSI print publications.  I've only come across one actual print standard in all my history of searching, a copy of Fortran 77 which I guard religiously.  Compare this with PALLETS'-worth, like I'm talking warehouse wholesale levels of secondary sources for the same things.  I could *drown* in all the secondary COBOL 74 books I see all over the place but I've never seen seen a blip of a suggestion of a whisper of an auction of someone selling a legitimate copy of ANSI X3.23-1974.  It feels like searching for a copy of the Christian Bible and literally all I can find are self help books and devotional readers from random followers.  Are the standards really that scarce, or was it something that most owners of back in the day would've thrown in the wood chipper when the next edition dropped, leading to an artificial narrowing of the amount of physical specimens still extant?

To summarize, why do print copies of primary standards from the elden days of computing seem like cryptids while one can flatten themselves into a pancake under the mountains upon mountains of derivative materials out there?  Why is filtered material infinitely more common than the literal rule of law governing the languages?  For instance the closest thing to the legitimate ANSI C standard, a world-changing document, that I can find is the "annotated" version, which thankfully is the full text but blown up to twice the thickness just to include commentary.  My bookshelf is starting to run out of room to accommodate noise like that when there are nice succint "the final answer" documents that take up much less space but seem to virtually not exist...

- Matt G.

[COFF] Re: Commonality of 60s-80s Print Standards

[Paul Winalski]

On 8/17/23, segaloco via COFF <coff@tuhs.org> wrote:
>
> To summarize, why do print copies of primary standards from the elden days
> of computing seem like cryptids while one can flatten themselves into a
> pancake under the mountains upon mountains of derivative materials out
> there?  Why is filtered material infinitely more common than the literal
> rule of law governing the languages?

I worked as a software engineer in the 1980s and '90s in Digital
Equipment Corporation's unit that developed tools for programmers,
including the compilers.  I don't recall the policies and procedures
of the various ANSI computer language standards committees regarding
publication of the standards.

I think the reason that there aren't many extant copies of them out
there is that not many people actually cared what the standard said.
What was important was the details of the particular implementation of
the language that you as a programmer had to use.  Even within DEC's
compiler group, there were only a couple of copies of the ANSI
standard document for any particular language.  A typical compiler
group has only one engineer tasked with standard interpretation and
compliance.  The rest of the compiler developers work from the
specification for the upcoming release.

>  For instance the closest thing to the
> legitimate ANSI C standard, a world-changing document, that I can find is
> the "annotated" version, which thankfully is the full text but blown up to
> twice the thickness just to include commentary.  My bookshelf is starting to
> run out of room to accommodate noise like that when there are nice succint
> "the final answer" documents that take up much less space but seem to
> virtually not exist...

For a compiler developer, that isn't "noise".  Official specifications
for computer languages often contain--despite the best efforts of the
committee members to prevent them--errors, inconsistencies, vague
language, and outright contradictions.  It's the compiler
developers--especially those working on incoming bug reports--who have
to deal with problems in the standard.  It helps to have an idea of
what the committee members' intentions were, and what their rationale
was, for particular verbiage in the standard.  I know DEC's
representatives to the C standard committee, and in the case of the C
and Fortran standards the extra verbiage was completely intentional.

In case law, the Judge's decision in a trial usually is a page long,
sometimes only a sentence or two.  But there may be 80 pages of legal
reasoning explaining just why the judge came to that conclusion.
Compiler developers end up being language lawyers.  When a problem
comes up regarding a language feature, they want to know the
committee's intentions and rationale for why the standard says what it
does say (or appears to say).

-Paul W.

[COFF] Re: Commonality of 60s-80s Print Standards

[segaloco via COFF]

> In case law, the Judge's decision in a trial usually is a page long,
> sometimes only a sentence or two. But there may be 80 pages of legal
> reasoning explaining just why the judge came to that conclusion.
> Compiler developers end up being language lawyers. When a problem
> comes up regarding a language feature, they want to know the
> committee's intentions and rationale for why the standard says what it
> does say (or appears to say).
> 
> -Paul W.

That's actually a very, very good comparison, it certainly helps me see it in a different way.

For some of the background on the angle I'm approaching this from:  I've worked in the EPA-regulated US environmental sector since late 2012, first as a chemist for 4 years until enough patches and suggestions up to our data system team got me on their radar enough to jump over the fence.  Back in the lab days, our governing literature came from only a handful of sources:

    - EPA SW-846 ("Waste")
    - EPA Clean Water Act (NPDES, "Wastewater")
    - ASTM
    - Standard Methods for the Examination of Water and Wastewater

Each of these groups maintains (the former two, gratis, the later two for licensing fees...) a plethora of chemical analysis methodology, often quite prescriptive, describing the legal expectations of running that method.  In all my time working with the methods, we always, and I mean *always* had a copy of the legally binding document at arms length, often copies littered throughout the lab (although any formal investigation or dispute required a "controlled" signed and dated copy from the QA office.)  On the flip side, I don't recall seeing *any* sort of general literature books around the lab akin to the computing books we see everywhere that were derivatives and digestions *of* the lore that was the legally binding method text.  Then our work is usually broken up by program (and by matrix i.e. solid, water, organic waste) and the appropriate method for the program, permit, and sample matrix must be strictly adhered to.  For instance, if you are running anything related to the Clean Water Act in wastewater for mid-level heavy metals analysis, it must be EPA method 200.7, no ifs ands or buts about it.  As such, working from literally any other document is just setting yourself up for disaster because then, what if that author left out that you need to perform a filtration on the field-preserved sample before it goes on the instrument or it isn't valid 200.7 analysis?  A book on ICP-AES may not tell you that, some random work someone wrote commenting on their experiences or observations with heavy metals analysis may not mention that little bit, but you can sure as heck bet that it will be precisely in section whatever subsection whatever paragraph whatever of the legally binding document.  If you didn't read the standard and skipped this step, at the very least your data gets recalled, at most, you wind up in court for data fraud.

Am I getting into apples vs oranges here?  Is the difference here that standards like the ANSI standards here are more like "you must conform to this to say that you conform to it" but you do not need to conform to this to say that you are programming in a given programming language, or to sell products on a specific platform or in a specific industry, or something like that.  Perhaps what I'm missing is the difference between the regulatory teeth involved in the EPA's expectation of data quality vs the fact that "quality" in off the shelf computing products on the private market is a suggestion, not a legal requirement to even operate?  Is it that standards existed as a way to give products a nice marketing banner to fly under if they so chose and way to signal quality and compatibility to customers with the confidence that others won't go parading around like they're also comparable when they really aren't?  That would certainly explain the difference between what I see in my chemistry side of things and what I see in computing if the expectation of computing standards is just "you don't have to follow this, but if you do you can flaunt it"?

To put it even shorter, as a chemist working with regulatory EPA methodology, my bookshelf better be full of those legal documents and my work better *perfectly* match it or I can find myself in all sorts of hot water.  For most bookshelves of programming books I've seen in stores, libraries, professors offices, etc. I scarcely *ever* see governing documents at all despite countless languages being legally defined and yet everyone hums along business as usual.  Thanks for entertaining this question by the way, it's kinda "out there" but this is like the only circle of folks I've found that I consistently hear good insights on this sort of stuff from, which I appreciate.  I wish I could articulate what I'm getting at more succinctly but it is what it is.

- Matt G.

[COFF] Re: Commonality of 60s-80s Print Standards

[Stuff Received]

On 2023-08-17 18:11, segaloco via COFF wrote (in part):
 > Am I getting into apples vs oranges here?

Yes.  In some areas (such as crypto, whence I came), if you did
not follow the standards, then you would not interoperate.  There were
no testing labs for compliance (as there was for FIPS, for example).
I recall compliance tests for ANSI C but that stopped with the
adoption of ISO C (if my aging memory is correct).

S.

[COFF] Re: Commonality of 60s-80s Print Standards

[segaloco via COFF]

> > Am I getting into apples vs oranges here?
> 
> 
> Yes. In some areas (such as crypto, whence I came), if you did
> not follow the standards, then you would not interoperate. There were
> no testing labs for compliance (as there was for FIPS, for example).
> I recall compliance tests for ANSI C but that stopped with the
> adoption of ISO C (if my aging memory is correct).
> 
> S.

Okay I think it's making sense to me now.  So the apples of programming standards would come down to:

    - If you want to advertise/contract for interoperability with standards-compliant components, then your component must likewise adhere or you are lying to your customers and liable.
    - Otherwise, if you just want to push something but don't want to pad your market performance with attracting vendors interested in said interoperability, you're free to do so and don't face legal ramifications, you're just selling what could be assessed as a sub-par product, but you're within your legal right to do so as long as you don't suggest otherwise.

Whereas the oranges of EPA standards I'm trying to compare it to are:

    - If you want to produce legal regulatory information that can be used in EPA-related disputes, you must adhere to these legally binding regulations put out by the EPA.
    - You can tell someone yeah I'll test your water for lead, but if they intend to use that number in litigation, a formal environmental survey, or some other legally-binding case, then you're held to the higher standard.  In this case the particulars do matter because you're not selling a random product on the market, you're specifically selling regulatory acceptability as a factor of the product.

I presume the only situations then where adherence to a programming standard by ANSI or another body could actually play some legal role in their operation are either:

    - The vendor is under contract to ensure the product they're producing is conformant (i.e. USDoD requiring NT to present POSIX calls)
    - The vendor cites the standard in published material as applying to their product

But in both cases their due diligence is to prove that they're meeting the standards *for customers that expect it* not that there is any legal requirement that they do this in absence of said expectation.

- Matt G.

P.S. I'll disclaim for anyone that answers that I'm not seeking legal advise by the way, I don't want anyone to feel like they're under the microscope on this :P  If the day comes I'm citing COFF in a court of law I'll just try and fly to Jupiter because bizarro world is probably upon us.

[COFF] Re: Commonality of 60s-80s Print Standards

[Paul Winalski]

On 8/17/23, segaloco <segaloco@protonmail.com> wrote:
>
> IIs the difference here that
> standards like the ANSI standards here are more like "you must conform to
> this to say that you conform to it" but you do not need to conform to this
> to say that you are programming in a given programming language, or to sell
> products on a specific platform or in a specific industry, or something like
> that.

Here I think you have found the crux of the matter.  A big difference
between the ANSI standards for programming languages and the EPA
regulations is the legal requirement for conformance.   Nobody who
uses a programming language is under any sort of legal requirement to
conform to the ANSI standard--neither those who write compilers for
the language, nor those who write programs in that language.  The only
"enforcement" of the standard that exists is consumer fraud law.  If
you market a compiler claiming that it is ANSI standard-compliant, and
it isn't, you could be liable for civil or possibly criminal fraud/
But that's it.  Very different from the EPA regulations that you
cited, where failure to conform to the regulations can have very
severe legal and financial consequences.

Hence the lack of widespread use of the standards documents.  Proper
ANSI language standard compliance is important to compiler vendors who
claim that their product conforms to the standard.  The compiler
groups I have worked in at DEC and Intel have had someone on the front
end team for each language who is an expert on the fine print of the
standard and whose job it is to see to it that the product (the
compiler) stays standard-conformant.  This person does have a complete
copy of the ANSI standard on their desk.

Users of compilers claiming to be standard-conformant are under no
legal obligation whatsoever to write standard-conformant programs.
There is thus no reason for them to have a copy of the standard
readily at hand.  However, every IT shop I've worked in does have
their own in-house standard for programming practices, and this
includes which features of the programming language are allowed to be
used and sometimes how they are to be used.  In a well-run programming
shop, these rules are written down in detail, every programmer has a
copy of them, and they are rigidly enforced--you can't check in your
code if you've violated them.  Failure to follow the in-house
programming regulations can also have negative career advancement
implications.

-Paul W.