From: clubley@remove_me.eisner.decus.org-Earth.UFP   
      
   On 2025-12-05, Arne Vajhøj  wrote:   
   > Context   
   > -------   
   >   
   > 1)   
   >   
   > My opinion is that DCL:   
   > * is fine for interactive use   
      
   [Oh dear, Arne, oh dear... :-)]   
      
   No, it most certainly is not fine for interactive use.   
      
   1) You can't edit a line longer than the terminal width. Either fix the   
   terminal driver or add the functionality to DCL itself.]   
      
   2) No easy incremental search of command history (Bash Ctrl-R style).   
      
   3) No saving of command history into a history file with just the commands   
   entered into multiple simultaneous DCL sessions added to the end of the   
   history file.   
      
   4) No automatic restoration of command history during startup of a new   
   DCL session.   
      
   5) Piping is seriously clunky.   
      
   6) Nothing matching "man -k" in the DCL HELP facility.   
      
   7) VMS diff is lousy compared to GNU diff and its unified diff mode.   
   GNU diff is available from third parties for VMS. It should be a part of VMS.   
      
   8) VMS SEARCH functionality is weak compared to grep.   
      
   > * is fine for small scripts (5-25 lines with at most a few lexical   
   >    functions, a few if statements and 'Pn' usage   
   > * is not up to expectations for writing large scripts aka   
   >    programming in DCL   
   >   
   > One can argue that DCL should not be used for programming, but fact   
   > is that it is used that way.   
   >   
      
   All systems require scripting capabilities as part of normal system   
   operations and supply a scripting language for that purpose. DCL is   
   the scripting language chosen for DCL and hence needs to be looked   
   at in that light.   
      
   > So what is missing for programming? I would say biggest   
   > items are:   
   > * loops   
   > * switch/case   
   > * arrays   
   > * user defined lexicals   
   >   
      
   New functionality is implemented as a OO model in C, which sits alongside   
   the existing procedural code in Macro-32.   
      
   Lists/dictionaries/tuples/etc should be a core facility.   
      
   General OO functionality with structured imports of the objects.   
      
   Generation of the VMS header files for all the languages will also   
   include generation of DCL OO headers and modules that can be directly   
   imported by a DCL script.   
      
   As such, there is no need for user defined lexicals (which, with the   
   current DCL design, would have to run in user mode instead of supervisor   
   mode anyway for security reasons). You just import the OO module containing   
   the system service that you want to call.   
      
   >   
   > This mean VSI cannot break backwards compatibility for DCL - whatever   
   > ran in 1985 has to run the exact same way today.   
   >   
      
   No problem. You keep the existing interfaces and add OO functionality   
   on top of it for use by new scripts, or any existing scripts you might   
   want to spend the time modifying. There's no reason why all the new OO   
   stuff can't simply be written in C that runs alongside the existing   
   Macro-32 code. Likewise for all the new control structures stuff.   
      
   Simon.   
      
   --   
   Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP   
   Walking destinations on a map are further away than they appear.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)