[Info-vax] Userland programming languages on VMS.

John Dallman jgd at cix.co.uk
Sat Jan 29 14:54:00 EST 2022


In article <st401o$jaa$1 at dont-email.me>, davef at tsoft-inc.com (Dave Froble)
wrote:

> I have never used Bliss, don't know it at all. So I cannot be the 
> judge of its worthiness. But all I seem to  read is "it's old" 
> and "nobody knows it". Neither of those actually addresses its 
> suitability.

I've done several assembly languages, BCPL and lots of C. I read the
Bliss manual last year, and posted about it in March 2021. 

It is a language from the era when all programming was assumed to be hard,
requiring detailed design documents, and painstaking specification of
every data structure. This was entirely appropriate for a time when a
mainframe's memory was measured in small numbers of megabytes. However,
the hardware has changed. Packing data into every spare bit is rarely
worthwhile. Using some of the computer's resources to make programming
easier is usually desirable. Bliss is certainly better than assembler,
but it assumes resources are scarce. 

The language seems unforgiving. An extra or missing "." or ";" can change
the meaning of code in important ways. It's quite hard for a compiler to
detect programming errors, more so than with C. Training programmers to
be productive with Bliss looks as if it will take longer than teaching
them appropriate C idioms for low-level programming, and will certainly
produce more complaints. 

I don't know if equally skilled C or Bliss programmers would be more
productive writing OS kernel code. I suspect it would depend on who had
the better set of library routines and other project-specific tools. But
if I had to put a team together for such work, I'd always choose C over
Bliss. Doing the same makes sense for VSI, because they /are not DEC/.
They don't have large pools of programmers to call on. They need to be
able to hire people and have them become productive reasonably quickly. 

John 



More information about the Info-vax mailing list