From: cross@spitfire.i.gajendra.net
In article <10hsiel$329ui$1@dont-email.me>,
Craig A. Berry wrote:
>
>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.
Sure. But the point is that, at that point, those are the parts
of the program that aren't (generally) performance-critical, or
where the relatively slow performance of interpreted Python
isn't a serious impedement, for one reason or another. Consider
writing that data to a file, for example; most of that is going
to be blocked on IO, not the interpreter.
>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.
That's fair, and I completely agree with you. I apologize, as I
realize I'm just quibbling over what one calls a "scripting
language," which entirely irrelevant to the topic at hand.
>> 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.
This is why I pointed at REXX on z/VM as an interesting example
of a system that, I think, does well in this area. The actual
"command interpreter" in CMS, as it is, is pretty anemic, but
ignoring EXEC2, essentially all scripts are written in REXX,
which is a real language. But its "enviornments" concept makes
it syntactically very easy to send commands to CMS or XEDIT in
that world.
Not that I'm suggesting that VSI adopt REXX for VMS, but rather
just pointing it out as an interesting example of a system in
this space that works remarkably well.
On a slightly humorous note, I've heard folks say that once you
get the point where your shell script exceeds ~10 lines, or more
than a single conditional, or you start to entertain the idea of
using a loop at all (other than simply over the arguments to the
script), it's time to reach for a Real language.
>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.
Yeah, I hear you on that.
I also keep thinking about Tcl, which Ousterhout imaged as both
a command language for interactive use and a scripting language.
It was really designed for interactive tools with captive user
interfaces; imagine the `ftp` or `telnet` clients, for example.
In the 1980s when Tcl was being developed, programs like these
frequently had a kind of janky ersatz command interpreter built
in and some amount of configurability via reading a file
(`.telnetrc`, for example), but it was always idiosyncratic and
weird.
But what if the interface for the tool was constructed from a
proper language? It's an interesting idea, but presumes tight
coupling with whatever program it is embedded in, thus not
really suited for use as a "shell".
I don't think it was as well thought-through as REXX in the VM
world, critically lacking the "environment" concept, but it's
another interesting point in the design space.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
