From: craigberry@nospam.mac.com   
      
   On 12/16/25 8:05 AM, Dan Cross wrote:   
   > In article <10h3upk$3f20l$1@dont-email.me>,   
   > Craig A. Berry  wrote:   
   >> [...]  But with people using scripting   
   >> languages to process massive vectors to train LLM models, it all seems   
   >> pretty puny.   
   >   
   > This is a good point, but, I sometimes wonder if, perhaps, we   
   > need to recalibrate what we mean when we say, "scripting   
   > language."  I imagine that you are referring to Python here, as   
   > that seems to be the thing that the kids are all hip on these   
   > days when it comes to model training and such-like, but I think   
   > it's fair to say that that language has grown far beyond   
   > traditional "scripting" use.   
   >   
   > Python is interpreted, yes, but people who are using it to do   
   > numerical analysis are often using the jit-compiled variant, and   
   > more often the actual heavy computational lifting is being done   
   > in a library that's exposed to Python via an FFI; so the actual   
   > training code is in Fortran or C or some more traditional   
   > compiled language.   
      
   Yes, of course.  The scripting language will use a library (e.g., NumPy   
   or PyTorch) that exposes interfaces to various kinds of hardware   
   acceleration. But eventually there is processed data returned that gets   
   manipulated using ordinary constructs of the calling language.  My   
   comment arose in the context of DCL and Arne's suggestion of a new   
   wrapper language around DCL supplying new features; if any of those new   
   features tries to put more than 8192 bytes into a DCL symbol, that ain't   
   gonna work.  And the same would be true for a new lexical function in   
   current DCL.   
      
   > There is, evidently, a need (or at least desire) for a really   
   > good interpreted language to script various system management   
   > tasks; I gather folks feel that DCL is a bit long in the tooth   
   > and insufficient for that.  As I mentioned before, I feel like   
   > that is qualitatively different than using DCL as an interactive   
   > CLI; perhaps the solution here is just to build out a really   
   > nice set of officially supported modules for, say, Python (or a   
   > similar suitable language) and call it a day.   
      
   Python, Perl, and Lua all exist. Probably all could use additional work   
   for VMS-specific administrative tasks.  Not sure the state of Ruby, but   
   there is JRuby.  And at least a couple of other JVM-based scripting   
   options. So it's not like people are struggling between DCL and nothing.   
      
   In a way I agree with you that a good scripting language should not have   
   to be a good CLI and vice versa.  But there is an important category of   
   script that starts off as one long command, gets split into two or more   
   commands, wrapped in a loop, parameterized for different inputs, put in   
   a subroutine, and has features added like e-mailing the output to a   
   distribution list. Now you've got a program, and there is no obvious   
   point in that process where it's free or easy to switch languages.   
      
   So while it's certainly not the only paradigm for writing scripts, it's   
   darn convenient to have a CLI that can also function as a decent   
   programming language.  DCL would have fit the bill 30 years ago but now   
   not so much.  Thus the discussion about enhancing or replacing DCL.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)