[Info-vax] Userland programming languages on VMS.

[Arne Vajhøj]

On 1/29/2022 2:53 PM, John Dallman wrote:
> 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.

Note that for the task that triggered this thread (DIRECTORY command)
which consist of:
- retrieving parameter and qualifiers
- get info via RMS calls
- output result
then something even higher level than C would make sense. There is no
need for any of the "flexibility" of C.

Arne