Post by David FroblePost by Simon ClubleyI think it's time once again to build a list of DCL's flaws now that
VSI are around. Don't forget however that DCL is both a scripting
language and a UI. My initial list is below.
Do you mind if I'm an ass for a bit? I promise to be more reasonable
at the end.
Post by Simon Clubley1) You can't edit commands across line boundaries. Even Windows CLIs
can do this.
It has been explained in the past that the problem was this stuff was
implemented in the terminal driver. I'd suggest looking at a different
implementation, such as an application that could do the command line
length and buffer and history, and maybe running multiple copies. Yes,
it is a PITA.
Ayup. The terminal driver, another hunk of legacy VMS code. Code
that's accumulated more than a little technical debt, and which is
inherently a very complex piece of code. Code that's best either
overhauled or even re-architected and reworked into a newer and simpler
design, but this would break compatibility for the applications that
(still?) need the more arcane features of the classic terminal driver.
Serial port controllers themselves are legacy designs, beyond (maybe)
the console, and that's often replaced with a management processor.
There is a cost to providing compatibility.
Post by David FroblePost by Simon Clubley2) You can't save your command history automatically, bash style, and
have it restored automatically at the next session.
See above for better implementation, not a patch on the terminal driver.
DCL does most of the command processing already, it's the current
command line processing where DCL depends on the features of the
terminal driver, and the driver itself can't manage the long-line wrap.
DCL either reads out or loads in command lines, using the terminal
driver.
Post by David FroblePost by Simon ClubleyWith bash, you can have multiple shells active at the same time and
only the commands entered during a specific session will be added to
the history file when that session exits even though the shell has the
full command history from previous shells available (up to a user
defined limit).
I don't know why anyone would want 2 script processors at the same
time. Isn't that multiple sessions?
I also don't understand retaining the history.
History means your commands are available over separate logins, and
over server reboots. It's really handy to have. You're not copying
and pasting commands into files or into notebooks, for when you get
back to work the next day. It's increasingly common to hack this
feature into VMS with RECALL commands, but that's rather clunky.
Post by David FroblePost by Simon ClubleyAny implementation needs to think about the multiple shells active at
the same time issue before proposing a solution to this.
3) No filename completion. This is _really_ annoying especially since
it even exists (after a fashion) in the command prompt on current
versions of Windows.
Filename and full-on command completion would be handy to have.
Post by David FrobleI still remember, with a grin, JF's idea of user name and password completion.
:-)
:-)
Yes, a joke. But there are parts of the login that are pretty crufty.
Certificate-based logins would be handy. Not quite the same as
password completion, but something that's used very heavily with
ssh-based logins. Other systems use biometric readers (problems and
all) or two-factor with tokens or out-of-band authentication.
Post by David FroblePost by Simon Clubley4) No elegant incremental search through the command history (bash
Ctrl-R style).
1) No structured programming constructs such as (for example) while
loops.
Learn the mantra,
"DCL is not a programming language".
"DCL is not a programming language".
"DCL is not a programming languaige".
"DCL is not a programming language".
Is that like "we've always done it this way" or "nobody needs more than
640K"? DCL is a programming language. It's just an old and clunky
one, and part of dusting off VMS means updates.
Post by David FroblePost by Simon Clubley2) No ability to iterate cleanly over a list of items (bash "for i in"
style)
"DCL is not a programming language".
"DCL is not a programming language".
"DCL is not a programming language".
An iterator would be very handy. Cleaner code.
Post by David FrobleBut, there is GOTO ...
Computed goto, if you're willing to hack the symbols. Hard to
troubleshoot, though. Or patching your code on the fly, if you're
willing to substitute a GOTO for some other command.
Post by David FroblePost by Simon Clubley3) No ability to add site specific lexicals.
Write your own library routines, and call them from a reasonable
language, such as Basic.
Why not from the command language?
Post by David FroblePost by Simon Clubley4) The output from the lexicals should be an immutable collection of
objects which you can then iterate over without having to worry about
the state changing during iteration.
"DCL is not a programming language".
"DCL is not a programming language".
That's variously referred to as an iterator, and that would be handy.
More than a few DCL procedures around are iterating over a pattern
match of records within a file, or within a list of files, after all.
(This is also where having a JIT would be handy too, as these sorts of
loops can be automatically detected and internally compiled within DCL,
and the performance of the DCL procedure would hopefully then improve,
and this with minimal or no effort on the part of the DCL programmer.
The JIT hopefully improves some parts of the DCL procedure performance
"for free", as far as the DCL programmer can see. Now figuring out how
and then retrofitting a JIT into DCL itself, that won't be easy. That
the DCL commands can change at run-time based on a symbol substitution
somewhere else can make something like a JIT slightly more interesting.)
Post by David FroblePost by Simon Clubley5) No regex support (this is also a UI issue).
"DCL is not a programming language".
"DCL is not a programming language".
DCL does shedloads of pattern-matching — badly — so having regular
expressions would be useful. The wildcards % and * only get you so
far, and pretty soon you're rolling your own substring matching — this
once you're past the stage where you're looking for an FTP tool with
in-built scripting or pattern-matching logic, and have decided to write
some DCL to provide for the application requirements. (If you're not
re-designing your way out of using FTP, of course.)
Post by David FroblePost by Simon Clubley6) Pathetic limits on the maximum size of symbol contents.
"DCL is not a programming language".
"DCL is not a programming language".
Yeah, and the lack of binary data support here, too. This also ties
into having objects, where I can deal with a blob of data without
having to specifically manage the blob.
Adding UTF-8 can get ugly if you don't go "all in" on UTF-8 throughout,
as you're then having to identify the data encoding in the strings and
file records explicitly, or trying to detect it manually. UTF-8 also
means that character string lengths aren't the same as the number of
bytes in the string, too.
Post by David FroblePost by Simon Clubley7) No array or collection of objects support. (In addition to normal
arrays, DCL should also support associative arrays.)
"DCL is not a programming language".
"DCL is not a programming language".
Yeah; arrays in DCL using symbol substitution is ugly. Dictionaries —
arrays that work something like indexed files, also called key-value
stores, and probably what you're referring to with associative arrays —
would be handy, too. More than a little DCL code around ends up
either hacking in arrays, or using an RMS indexed (dictionary) or
relative (array) file, or ending up having to create and then connect
with some compiled code.
Post by David FroblePost by Simon ClubleyDCL has absolutely no way to group related variables together in the
way you can with structs in C or objects in other languages.
"DCL is not a programming language".
"DCL is not a programming language".
Scopes are sort-of kind-of related to symbol visibility, but they're
rather murky. Having something akin to a structure or an object would
be useful.
Post by David FroblePost by Simon Clubley8) You cannot delete a directory tree in one go.
But, you can have a command procedure to do so ...
As others have commented, with V8.4, you can add a qualifier to get there.
Post by David FroblePost by Simon Clubley9) differences is very limited by today's standards. The functionality
in GNU diff, with (for example) it's ability to find differences in
whole directory trees and produce patch files for the differences
in an entire tree, should be the minimum baseline for functionality
these days.
We know I don't get out much, but when I have something to compare, I
move it to VMS to use DIFF there. Guess I'm missing something.
There are other interesting and useful and different tools around; part
of what learning another system can help with, even if you're (staying)
on VMS.
Post by David FrobleBut yeah, I jump through hoops when I want to compare a bunch of source
programs. I share that pain.
A good IDE can help here, too.
For folks on OS X and going beyond the various BSD and GNU tools that
are available, the differences support in Xcode can be handy, as can
the third-party Kaleidoscope.app differences application.
Post by David FroblePost by Simon ClubleyI also find the unified diff output to be a _lot_ more readable than
the output from the DCL differences command.
Simon.
Ok, sorry, got carried away with the "paste" ...
:-)
DEC used to do this thing, they used to let people vote on desired
enhancements, and then choose projects based upon demand. This might
be a good practice to continue. Doing so on the internet, rather than
a couple times a year at DECUS.
I'm actually somewhat skeptical on that, particularly if you've got
something new or very different in mind. Voting does work, but tends
to get incremental improvements. Having done more than a few customer
surveys and related, it's unusual to get significant new features
through this path. Now for incremental changes such as getting zip and
unzip into the base distro, that got voted on and unfortunately never
happened.
Post by David FrobleThrough all of what you wrote, there is this "feeling" that you are
writing from the perspective of a workstation, not a "server". Things
such the command line recall and length just don't come up when you're
running programs. As a software person, I can appreciate what you're
asking for. But from a production perspective, I don't see that it's
relavent.
Much of what Simon is suggesting is directly or indirectly associated
with application development on VMS, and with using tools such as
scripting language improvements that allows more complex and more
maintainable applications to be put together more quickly and easily.
That's dead-on deep into server application territory, too.
Post by David FrobleNot saying you should not have all that you listed. But, I'd like you
to discuss them not from a development and / or management station, but
from a "running production" perspective.
History is about the only one that isn't directly production-execution
related, and keeping track of command history is something increasingly
common in production environments.
All its warts aside, DCL is a programming language, and folks can and
do write real programs in it. But DCL can be improved. Or DCL can be
replaced with something more tightly specified. Why? For a number
of tasks, applications written in scripting languages are generally
faster to develop and to deploy than are applications written in
compiled languages. But then DCL doesn't interface with compiled
languages all that well — how many of us are tossing around
lib$set_logical and lib$set_symbol and related code and not something
like "$ program_result = compiled_program_invocation(arg1, arg2)"
syntax — so going full-on compiled for an application is still pretty
common. That's before discussing the various issues with the compilers
and of the development environments, too.
Or turning around that whole "DCL is not a programming language" that
you're used here, ask yourself why that is, what the issues and
limitations of DCL are here, and whether those can be addressed in DCL
or in a hypothetical replacement. Look less at what can't be done, and
more at what can and should be.
Now as for what VSI plans here, we'll find out. They've more than a
little work ahead of them, and they're going to want to reach
sustainable revenues.
--
Pure Personal Opinion | HoffmanLabs LLC