[Info-vax] DCL's flaws (both scripting and UI)

[David Froble]

Simon Clubley wrote:
> I 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.

> Some of DCL's UI flaws:
> 
> 1) 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.

> 2) 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.

> With 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.

> Any 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.

I still remember, with a grin, JF's idea of user name and password 
completion.

:-)

:-)

> 4) No elegant incremental search through the command history (bash
> Ctrl-R style).
> 
> Some of DCL's scripting limitations:
> 
> 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 language".
"DCL is not a programming language".

> 2) 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".

But, there is GOTO ...

> 3) No ability to add site specific lexicals.

Write your own library routines, and call them from a reasonable 
language, such as Basic.

> 4) 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".


> 5) No regex support (this is also a UI issue).

"DCL is not a programming language".
"DCL is not a programming language".


> 6) Pathetic limits on the maximum size of symbol contents.

"DCL is not a programming language".
"DCL is not a programming language".

> 7) 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".

> DCL 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".

> 8) You cannot delete a directory tree in one go.

But, you can have a command procedure to do so ...

> 9) 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.

But yeah, I jump through hoops when I want to compare a bunch of source 
programs.  I share that pain.

> I 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.

Through 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.

Not 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.