<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 28-Jan-18 18:32, Clem Cole wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAC20D2PCsrUjzF=WYm7-5MSHCdt2pi=M=QRQ-wZ0zTNo308Eyg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif"><br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sun, Jan 28, 2018 at 4:43 PM,
khandy21yo <span dir="ltr"><<a
href="mailto:khandy21yo@gmail.com" target="_blank"
moz-do-not-send="true">khandy21yo@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div><br>
</div>
<div><font color="#ff0000">Never had BLISS on anything
until long after it would have been useful. So how
does BLISS compare to C as a systems programming
language? Is it worth learning at this late date?</font></div>
</blockquote>
<div><br>
</div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif"><font
color="#0000ff">I'll try to answer your questions in
verse order - probably not worth learning; except for
some education value and the ability to read and really
understand any BLISS code you might come upon (if the
later is something you really need/want to do).</font></div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif"><br>
</div>
<div class="gmail_default"><font face="arial, helvetica,
sans-serif" color="#0000ff">Armando Stetner, of the TIG
(Telephone Industries Group in MKO) once made a set of
'BLISS is Ignorance' buttons which he gave to a lot of
people (I still have mine). </font><font face="arial,
helvetica, sans-serif" color="#0000ff"> While I loved
the language, I loathed it too. </font><font
style="font-family:arial,helvetica,sans-serif"
face="arial, helvetica, sans-serif"></font><font
color="#0000ff"><font face="arial, helvetica,
sans-serif"><font face="arial, sans-serif">I'm in a
interesting position here, because I learned BLISS
before I learned C, since I was CMU type at the time
and a student of Wulf and his wife.</font></font></font></div>
<div class="gmail_default"><font color="#0000ff"><font
face="arial, helvetica, sans-serif"><font face="arial,
sans-serif"><br>
</font></font></font></div>
<div class="gmail_default"><font color="#0000ff"><font
face="arial, helvetica, sans-serif"><font face="arial,
sans-serif">40 years later, I've written way more C
then BLISS. But as Tim was saying there were some
things about BLISS which I still miss - primarily
the macro system and the way conditional compilation
was handled. It was much more sane that C's
preprocessor; and </font>the PDP-11 optimizer
(discussed in the Green Book) made the Ritchie C
compiler see almost like a toy.</font></font></div>
<div class="gmail_default"><font color="#0000ff"><font
face="arial, helvetica, sans-serif"><br>
</font></font></div>
<div class="gmail_default"><font face="arial, helvetica,
sans-serif" color="#0000ff">Remember, part of there
design of the language was with software engineering in
mind. Parnas et al was publishing and there was a lot
of thought about what made for good programs. Hence, no
goto. Similarly, it included a macro and
conditional compilation system - which I think was
something that really made BLISS and C much more useful
than say PASCAL. In fact, people wrote macro systems
like m4 and RATFOR so that PL/1 and FORTRAN could be
conditionally compiled in a manner than was reasonable.
I've always said, for really SW engineering you need to
have it (the problem with C/C++ is that it gets abused
and some resulting code is worse because of it).</font></div>
<div class="gmail_default"><font face="arial, helvetica,
sans-serif" color="#0000ff"><br>
</font></div>
<div class="gmail_default"><font face="arial, helvetica,
sans-serif" color="#0000ff">The CMU BLISS compiler had
one of my favorite errors of all time BTW. You could
use single letter like i, j, and k for loop variables,
but if your real variable were less than 6 chars, you
could get an 'unimaginative variable name' warning. So
for real system programs, expressions tended to actually
have meaning and code was readable and easy to
understand.</font></div>
<div class="gmail_default"><font face="arial, helvetica,
sans-serif" color="#0000ff"><br>
</font></div>
<div class="gmail_default"><font face="arial, helvetica,
sans-serif" color="#0000ff">BTW, like C, everything in
BLISS is an expression and I think that worked well.
Also for the PDP-10 at least, it is had no language
runtime (by the time of Alpha I think that was not
wholly true). There were a ton of associated
libraries, but the compiler did everything. C never
really quite got to that because the Ritchie compiler
was much smaller, so Dennis put a lot into the runtime
under the covers. Frankly, as a user since you are
always using libraries, I never saw much of a
difference.</font></div>
<div class="gmail_default"><font color="#0000ff"><font
face="arial, helvetica, sans-serif"><br>
</font></font></div>
<div class="gmail_default"><font color="#0000ff"><font
face="arial, helvetica, sans-serif">BLISS suffered one
major design error (which was self inflicted and is an
example of theory vs. practice) and a number of
smaller ones that became sort of a death of thousand
cuts.</font></font></div>
<div class="gmail_default"><font color="#0000ff"><font
face="arial, helvetica, sans-serif"><br>
</font></font></div>
<div class="gmail_default"><font color="#0000ff"><font
face="arial, helvetica, sans-serif">The big issue is
the Wulf's choice of a 'store into' and 'contents of'
operators vs. the traditional 'assignment' and C style
pointer indirection. His theory is 100% correct and
it made the language much cleaner and >>once
you understood it<<; much more regular. C ended
up with *, &, -> and a dot operator to handle
different </font></font><font face="arial, helvetica,
sans-serif" color="#0000ff">linguistic items. BLISS is
much more compact and from a >>compiler's writers
standpoint<< mathematically explicit (which is
what Bill was of course). The idea was that if the
language was consistent it make for better programs. The
problem is that in practice, humans do not read code the
same way as a compiler and the BLISS conventions take a
lot of getting used to. Plus if you are
'multi-lingual' your brain has to switch between the two
schemes. [Bill would later admit privately at least,
it was great concept that in practice, just did not pan
out].</font></div>
<div class="gmail_default"><font face="arial, helvetica,
sans-serif" color="#0000ff"><br>
</font></div>
<div class="gmail_default"><font face="arial, helvetica,
sans-serif" color="#0000ff">And finally, in the days of
the old drum printers, if you ever look at printouts you
will see a certain amount of 'bouncing' of text in a
line, caused by the head solenoids firing a little early
or late. This means tops and bottoms of characters
were often cut off and small symbols (like the period)
might not be seen at all on the paper (although if you
looked carefully you might see a small indentation from
where is was supposed to have been -- I have examples of
this effect in some old listings BTW). We used to say,
if your program did not work, get a pepper shaker and
a sponge then pour a few dots and remove a few others,
and it would start to work ;-)</font></div>
<div class="gmail_default"><font face="arial, helvetica,
sans-serif" color="#0000ff"><br>
</font></div>
<div class="gmail_default"><font face="arial, helvetica,
sans-serif" color="#0000ff">On the smaller side, there
were things like the N different exits. IIRC Wulf used
to say that was a bad idea and he should have supported
labels and then allowed and 'exit' to got to a label.
The language took the Algol BEGIN/END and Algol68 idea
of spelling word backwards to note the end of a
something (SET TES, NSET TESN ...). And of course
because the implementation of the language was done
originally on the PDP-10 and then later moved to create
a PDP-11 target but as a cross compiler, the language
needed a PDP-10 to use it. In both cases, there was a
lot of memory available and style of the was used to
develop the compiler, showed.</font></div>
<div class="gmail_default"><font face="arial, helvetica,
sans-serif" color="#0000ff"><br>
</font></div>
<div class="gmail_default"><font face="arial, helvetica,
sans-serif" color="#0000ff">The self hosting of the B
and C compilers by Ken and Dennis on a small memory
system ensured them to be able to be used. It forced
the compiler passes to be in separate processes and the
passes used disk files (as opposed to memory) to
share information. It also meant things like needing
to use a separate assembler to create the output
objects, which BLISS could do directly.</font></div>
<div class="gmail_default"><font face="arial, helvetica,
sans-serif" color="#0000ff"><br>
</font></div>
<div class="gmail_default"><font face="arial, helvetica,
sans-serif" color="#0000ff">But these things could have
been solved if it had been worth it. I think Tim's
observation about the pricing was what killed the
language. I've often wondered if a the sources had
been available and the compiler was free, would people
have used it to create back-ends for other processors,
such as the 8-bit or 16 microprocessors that show up in
the mid to late 70s?</font></div>
<div class="gmail_default"><font face="arial, helvetica,
sans-serif" color="#0000ff"><br>
</font></div>
<div class="gmail_default"><font face="arial, helvetica,
sans-serif" color="#0000ff">We used C because we a head
start with the Ritchie and later Johnson compilers.
Part of the deal with DEC when Gordon brought BLISS in,
was that DEC got exclusive rights to the CMU compiler
(which CMU was perfectly happy to sell to them --
that's another sad story of my alma mater). Plus you
needed a PDP-10, which when it was designed was not an
issue; because most CS depts did have one. But few
places really got to see the sources and if you look at
were the first microprocessor compilers show up, they
were not from place like MIT, Stanford or CMU. It was
at smaller schools running PDP-11s (although later the
MIT C compilers would become the standard basis for the
8086 and 68000 from Steve Ward's RTS team).</font></div>
<div class="gmail_default"><font face="arial, helvetica,
sans-serif" color="#0000ff"><br>
</font></div>
<div class="gmail_default"><font face="arial, helvetica,
sans-serif" color="#0000ff">Clem</font></div>
<div class="gmail_default"><font color="#0000ff"><font
face="arial, helvetica, sans-serif"><br>
</font></font></div>
<br>
</div>
</div>
</div>
</blockquote>
C as an expression language is a bit of a stretch. Most C
statements don't return a value; all bliss statements (except ';')
do.<br>
<br>
Read the Belanger paper that I referenced earlier for his (BLISS's)
side of the comparison, including remarks on the dot operator.
There are lots of stories about dot bugs, since languages that avoid
implicit dereferencing of addresses are not what people first
experience. In reality, there were fewer dot bugs that survive first
contact; they tend to have obvious effects. Period, however, was an
unfortunate choice for the lexeme. It could look like comma on an
LPT, as well as perforate. In defense of BLISS, I would point out
that the C rules for implicit dereferencing and the 5 operators
(Clem left out []) are also confusing to novices. Especially when
combined with precedence. Dot is no worse than remembering to apply
gender in French/Spanish (and neuter in Russian) if you're a native
English speaker. Or Sigil's in Perl.<br>
<br>
Belanger points out, and I agree, that the biggest design error was
that values don't have a size; all BLISS values are the native
wordsize. This causes some unnecessary awkwardness, and math using
%BPUNIT, %BPVAL, %BPADDR and %UPVAL when defining values in
structures. This usually gets hidden with macros (or SDL) - but is
unnecessarily awkward compared to C.<br>
<br>
C requires an RTL, even if you don't do I/O. The real RTL issue is
not so much whether one is required, but whether it's segmented so
that it can be used in kernel mode. E.g. the usermode malloc() does
not work in a device driver. But other RTL routines assume malloc()
is available. This is quite doable if planned for; in the case of
VAX C, the goal was user mode compatibility, not kernel mode use.
This was a reasonable goal (allowed POSIX compliance), but inhibited
adoption for system programming.<br>
<br>
Fred Kleinsorge managed to find a subset of VAXC constructs that
avoided the worst of the RTL, and was able to put VWS (and
DECWindows) terminal emulation into inner modes. I used this for
some specialized drivers (rather than BLISS because I reused and
modified Fred's code).<br>
<br>
The Alpha port of VMS emphasized writing new stuff in C, and a real
subset kernel mode RTL was developed for DECC. (DECC is more
dependent on an RTL than VAXC).<br>
<br>
I, too, have ended up writing much more C than BLISS. (And still
more if you count the C cousins like javascript & Perl.)<br>
<br>
It's like VHS and Beta. Partly religious, but the best technology
doesn't win when when "good enough" is cheaper.<br>
<br>
BLISS is like the PDP-10. I miss both, but the world has (mostly)
moved on.<br>
<br>
I'm mostly agnostic; "pick the tool that fits the job". But
constrained by the era :-(<br>
<br>
<br>
</body>
</html>