[Info-vax] BLISS, was: Re: VMS on ARM, was: Re: Small x86-64 servers, PCs

[Simon Clubley]

On 2021-03-22, John Dallman <jgd at cix.co.uk> wrote:
> In article <i8gjluFeutU1 at mid.individual.net>, bill.gunshannon at gmail.com
> (Bill Gunshannon) wrote:
>
>> I think the real problem isn't the limited number of people familiar
>> with them as much as the very limited number of people willing to
>> become familiar with them.
>
> Having read the 1987 BLISS Reference Manual, I agree. Most young
> programmers don't want to learn assembly languages, and while BLISS is
> not an assembly language, it is - quite deliberately - rather close to
> the metal.
>

Just to declare upfront, among the languages I know, I know multiple
8/16/32/64 bit assembly languages, C, C++, various Wirth languages, Ada
and other languages I have not used in a long time such as Fortran and Cobol.

The time for an assembly language as a general programming language has
long since passed and BLISS is close enough to an assembly language
compared to the alternatives that this applies to BLISS as well.

Even when doing bare-metal projects, I only use assembly language for the
first part of any startup code and interrupt handling as well as accessing
any architecture-specific low-level registers, etc. Everything else is done
in C as a minimum.

> It is similar in intent and capability to BCPL ("Basic" in BCPL has
> nothing to do with the BASIC programming language), which uses the same
> kinds of data types. However, BCPL feels more like a higher-level
> language, while BLISS feels more like assembler. What make me think that?
>
>
> BLISS keywords are shown as all UPPERCASE in the manual, and while there
> is a hint that you can use lowercase, the point is not clearly addressed
> that I can find. This is hard on the eyes of people used to lowercase
> languages. This is only a question of what you're used to, but it's an
> initial barrier. 
>

The Ada 83 RM also used upper case keywords (which was annoying to read,
but fortunately I started with Ada 95) and many of the Wirth languages
also use upper case keywords in the actual language implementation itself
(which is even more annoying because you have to write your code like that).

The use of upper case keywords seems to have been a product of the time.

My main issue with BLISS is that it is much more error-prone than even C
because even C syntax has enough built into it to catch errors at compile
time that would simply get through an assembler or BLISS compiler.

> More assembler-like features include the "." operator, which is easier to
> miss than BCPL's similar "!" operator, and the rules on when you don't
> need it are more complex than they seem to need to be. The ability to
> have imperative, rather than advisory, register declarations, is also
> rather like assembler. 
>

And if you mess up pointer dereferencing in C, there's a really good
chance the C compiler will actually stop you outright unlike with BLISS
or with an assembly language.

>
> Being an expression language is interesting, but hasn't been a compelling
> feature of any language that had it AFAIK. The syntax creates places
> where the presence or absence of a semi-colon makes a difference to
> semantics, and the compiler can't really warn the programmer. BLISS seems
> a very unforgiving language. 
>

It is much more error-prone than even C. It's better somewhat than raw
assembly language, but even C leaves both of them in the dust when it comes
to writing more reliable code and in which it is possible to express your
intentions in a way that allows the compiler to catch more mistakes.

BTW, if you want to look at another DEC language but from the other end of
the reliability and robustness scale, you might want to read the online
copy of the Pillar reference manual. Pillar was going to be used in Mica
before Mica was cancelled.

I really wish Pillar had survived the Mica cancellation. Our low-level
programming language choices might look very different these days if it had.

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.