From: seaohveh@hoffmanlabs.invalid   
      
   On 2024-12-19 06:56:43 +0000, David Meyer said:   
      
   > Does VSI have a preferred or official language for system programming   
   > for OpenVMS?   
      
   Starting in the early 1990s, the language choice for DEC OpenVMS was C.   
      
   > I know system programming for VAX/VMS was done in MACRO-32 and   
   > BLISS-32, and at least some system programs were written in C when   
   > Alpha was introduced.   
   >   
   > VSI has the BLISS reference manual on the Legacy shelf.   
      
   BLISS was retired as a salable layered product long ago.   
      
   The BLISS compilers became available on the Freeware.   
      
   BLISS remains necessary for OpenVMS itself. As is MACRO-32, and some   
   layered products including Notes.   
      
   > Have all the MACRO and BLISS programs been ported to C or C++, or will   
   > they be in the future?   
      
   No, and no.   
      
   Back around Y2K, MACRO-32, BLISS, and C were roughly divided in thirds   
   of the ~64K source modules in OpenVMS Alpha and OpenVMS I64 source   
   pool, with the percentage of C rapidly increasing starting with the C   
   system programming work introduced at V6.1.   
      
   VSI is likely still following those longstanding DEC OpenVMS practices   
   here, and will be writing new code in C, rewriting existing code being   
   overhauled into C, and maintaining and modifying the rest of the   
   existing code in the original language as needed.   
      
   Some code gets rewritten due to other constraints, such as the PL/1   
   code, and the Ada code.   
      
   Rewriting existing code is best approached with great caution, as it   
   can very easily become exceedingly expensive, and tedious. It also   
   requires immense resources. And even the best results can be perilous.   
      
   In a manner of consideration, rewrites are a whole lot like platform   
   ports, though rewrites are far bigger and far riskier and far more   
   costly projects. And keep other development work constrained for even   
   longer than the port tends to cause.   
      
   There are, of course, other and even better ways to spend vast sums for   
   negligible benefits for the OpenVMS vendor, such as a Linux "kernel   
   transplant" that was suggested by a few folks around here. Though if   
   you do want that something akin to that approach, have a look at Sector   
   7 product.   
      
   I'd suggest reading some of Martin Fowler's writings in the area of   
   incremental rewrites and refactoring, as that might help avoid some   
   common missteps.   
      
      
   --   
   Pure Personal Opinion | HoffmanLabs LLC   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)