On 3/1/25 3:28 PM, Clem Cole wrote:
Funny thing, I
have always said huge reason BLISS lost was that DEC charged for $5000
per CPU for it on TOPS or VMS, while C was free with UNIX - even though
the difference is the resulting code was remarkable. So many people
stayed away because they did not want to spend the extra $s.
The price certainly was an impediment to adoption, and arguably so even
within DEC.
At CWRU we did a lot of things in Common BLISS (-36, -16) including
changes to the TOPS-20 monitor. Some of those were bought back by DEC
but an impediment to that was they didn't want any of the TOPS-20 source
to be in BLISS. The reason given was that source customers didn't want
the burden of purchasing the license but it was hard to tell whether
that was the real reason vs. a cultural rejection within DEC.
I forget how this was resolved but think it was a "take the generated
code and add comments" solution -- that BLISS' code generation was
pretty awesome made that workable if tedious.
Common BLISS was a pretty flexible and rich development tool, it would
have been interesting to see it gain more traction though I can't see it
"winning" vs. C given how much traction C had. The earlier BLISS-10/-11
dialects were less compelling and quirkier.
The UNIX-related part of this was that among the things we used BLISS
for was a package called PAUNIX that attempted to implement the V7 UNIX
interfaces using the mechanisms/form used to implement TOPS-10
compatibility (PA1050). Like the TOPS-10 compatibility it was a run-time
veneer over TOPS-20 that mapped the UNIX functionality onto it and
buffered the differences. I describe it as "attempted to" as it was
successful as far as it got but it was a hobby project that got to about
80% done (meaning about 80% of the total effort remained) before life
and other assignments preempted it.
(Although, with my PiDP-10 running TOPS-20, a fun exercise in nostalgic
futility might be to haul PAUNIX out of the closet and try to finish it.)