[Info-vax] Userland programming languages on VMS.

[Arne Vajhøj]

On 1/29/2022 3:21 PM, Arne Vajhøj wrote:
> 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.

And it is not just me.

The rust people are rewriting GNU Coreutils (C) in
rust.

https://www.phoronix.com/scan.php?page=news_item&px=Rust-Coreutils-Jan-2022

Arne