[Info-vax] Userland programming languages on VMS.

[cao...@pitbulluk.org]

On Saturday, January 29, 2022 at 9:55:18 PM UTC, Arne Vajhøj wrote:
> 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>, da... 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.
> One can of course always discuss levels - there is no clear 
> definition, but I would rank like: 
> 
> Python, PHP, Perl 
> C++, Ada95, Java 
> Pascal, Basic, Ada83, Fortran 9X 
> Fortran 77, Cobol 
> C 
> Bliss 
> Macro 
> 
> YMMV 
> 
> Arne

Perhaps we should just have done with it and get .NET ported to VMS.... and then not bother with the VMS bit.