From: craigberry@nospam.mac.com   
      
   On 12/6/25 5:46 PM, Arne Vajhøj wrote:   
   > On 12/6/2025 4:28 PM, Craig A. Berry wrote:   
   >> On 12/5/25 8:41 PM, Arne Vajhøj wrote:   
   >>> What I see left is the "RATFOR approach" (in this century it should   
   >>> probbaly be called "transpiling approach", but I suspect more people   
   >>> here know about RATFOR than all the transpiling to JavaScript being   
   >>> done today). Pre-processing extended DCL to old DCL.   
   >>   
   >>   
   >> I don't see how transpilation could get you 64-bit integers, hashes,   
   >> regular expressions integrated into the language, or other things that   
   >> would be expected from a modern scripting language.   
   >   
   > 64 bit integers with external operations performance would be horrible.   
   >   
   > I believe f$re_match and f$re_replace could work OK.   
   >   
   >>                                  
   Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â    Even if user-   
   >> written lexicals were possible, you couldn't really use them to create   
   >> or manage very interesting data structures given that DCL symbol values   
   >> are limited to 1024 characters.   
   >   
   > I believe it is 8192 today.   
      
   Current online help for LIB$SET_SYMBOL says 1024. Current RTL manual   
   says 4096.  Dunno what's right.  But with people using scripting   
   languages to process massive vectors to train LLM models, it all seems   
   pretty puny.   
      
   > And unless the code is really quirky then I would assume going   
   > to 32K would be easy.   
   >   
   >> I don't think VSI is really big enough to invent and maintain an   
   >> entirely new language. They should probably leave DCL as-is and start   
   >> porting .NET and thus PowerShell.  As far as I know, all the relevant   
   >> bits are open source and MIT license, and PowerShell is intended to work   
   >> as both a CLI and a scripting language. It would be a big project, but   
   >> probably smaller than creating a new DCL implementation.   
   >   
   > .NET on VMS would be great.   
   >   
   > Not just for PS but for a lot of stuff: C# language,   
   > ASP.NET MVC + ASP.NET Web API etc..   
   >   
   > It would also bring DBL to x86-64 as they support .NET   
   > as platform.   
   >   
   > All relevant parts of both PS and .NET should be MIT.   
   >   
   > (Windows specific stuff are not relevant)   
   >   
   > PS is *the* shell for Windows admins, but has it caught on   
   > with Linux admins?   
   >   
   > I would have thought those were mostly bash and Python.   
      
   Probably. Although if you administer Linux VMs or Linux-based services   
   in Azure, you're probably using PS.   
      
   > BTW, I have never liked PS - it just doesn't appear logical   
   > to me, but that is just my personal opinion.   
   >   
   > And PS cmdlet's are like a combo of the existing DCL capability   
   > to add verbs and the non-existing DCL capability for user defined   
   > lexicals.   
      
   It is not elegant but it is powerful.  It is downright ugly at first but   
   feels better thought out and more consistent the deeper you get into it.   
   I can never guess the names of commands and qualifiers the way I can   
   with DCL.   
      
   SEARCH [...]*.*    
      
   becomes:   
      
   Get-ChildItem -Recurse | Select-String -Pattern    
      
   On Windows, it's often quicker to pop open a WSL window and do "grep -R"   
   than to look up that command. But PowerShell really shines if you need   
   to go beyond the very simple because you have the whole .NET API to draw   
   on.  For example, if you want not only to find files matching certain   
   criteria, but compress and encrypt them and e-mail them to a list of   
   contacts stored in a database, that's everyday stuff with PowerShell.   
   Of course it is with Perl and Python too, but somehow I don't see   
   either of those working as a CLI replacement.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)