[Info-vax] Evolve, or... (was: Re: 64 bit DCL ?)

[johnwallace4 at yahoo.co.uk]

On Sunday, 18 January 2015 20:58:36 UTC, Stephen Hoffman  wrote:
> On 2015-01-18 17:55:12 +0000, JF Mezei said:
> 
> > On 15-01-18 12:10, Stephen Hoffman wrote:
> > 
> >> There is a whole lot that DCL is just not very good at, whether it's
> >> the perpetual confusion around how many single and double-quotes and
> >> ampersands are needed that confuse new users and trip experienced
> >> users,
> > 
> > Touché.
> > 
> > But don't all shells have some problem with the quoting ? VMS may be 
> > worse than others, but not alone.
> 
> 
> Operating systems are a very competitive business.  You're competing 
> with a pricing floor of free operating systems[1], and probably with a 
> price ceiling of what Microsoft charges for their Windows Server, RHEL  
> or whatever other products are the leading contenders in the target 
> markets.   Success is not from doing what was always done, nor from 
> aiming for what your competitors are doing now, nor from doing 
> everything exactly how it has always been done.   Sure, quality and 
> stability are important.  But so are costs, ease of use, and 
> portability of applications.
> 
> Certainly aim at the existing VMS market long enough to get the 
> business going, and until VSI figures out what markets they're most 
> successful with now and which markets they can grow with, but any 
> vendor needs to aim at some combination of better, easier, faster, 
> simpler, cheaper or other benefits, if the vendor wants to attract new 
> customers.
> 
> Getting to a competitive and successful product is also not about 
> keeping current customers happy with what they have now, either.    
> It's about making the current customers really want to upgrade their 
> current VMS installations, and about making third-party developers 
> really want to build and deploy on VMS.
> 
> If the customers and the third-party providers aren't investing in VMS 
> upgrades, then there's a serious business problem.  If the folks are 
> not seeing the value and are not spending their money, that's bad for 
> the future of VMS.
> 
> If VSI is smart and aggressive and can get enough of a revenue stream 
> going, then they'll hopefully also start training VMS customers to 
> expect some of the most crufty parts in VMS will get replaced and 
> removed, too.  Give the folks that need stability a long-term-support 
> (LTS) plan for their current application code, and get the 
> stability-oriented folks accustomed to doing upgrades on a ten-year 
> schedule[2], for instance.  But when those ten years are up, the old 
> stuff is gone from support, and the worst of the deprecated and 
> decrepit and superseded features and APIs are potentially then removed, 
> too.  Yes, this is disruptive, but it's how a vendor can move faster, 
> and can adapt to changing requirements and expectations.   I'd rather 
> have improvements and rather less compatibility, particularly if I have 
> a upgrade schedule to work toward.  This whether I'm looking at more 
> bleeding-edge work for some projects, or toward an LTS upgrade schedule 
> for some production servers.
> 
> Predicting what the customers might want isn't easy, though.   If 
> there's not a good, embeddable, debuggable command line interface and 
> particularly that can attract upgrades and new users, then VSI might 
> choose to provide one.   But then spending buckets of time and money on 
> DCL enhancements or on a CLI replacement for DCL that doesn't then 
> encourage (enough) new users and existing upgrades?  That's a problem 
> for any vendor.
> 
> Being "worse than the others" isn't a particularly good strategy for 
> success.  Not unless you're much better in some other areas.  VSI has 
> to figure out how to get there, and to get folks to want to install and 
> to upgrade VMS, and to do so profitably.  It's _really easy_ to lose 
> money in the operating system business, after all.
> 
> Shells and quoting?  Most languages don't require double- or 
> triple-quoting, nor unbalanced single-quoting.   C-like languages tend 
> to use a backslash as an escapement and not doubling or tripling the 
> quoting characters, too.  The weird quoting with DCL implies there are 
> missing features and/or accumulated hacks or different solutions, and 
> DCL is most certainly missing features such as arrays and dictionaries 
> and objects and asynchronous event notifications and asynchronous I/O 
> and UTF-8 support and command completion and binary data handling and 
> non-PIPE piping and the performance of JITing and the embed-ability of 
> compilation and...   Yes, various of those can be hacked into your DCL 
> procedures.  Then maintaining compatibility with some of that.   Which 
> is part of how we got into this whole mess.
> 
> Interesting times.  VSI has really smart folks working for them, and 
> has a whole lot of hard work and makes some good predictions.  Then 
> we'll see if VMS can swim.
> 
> ######
> [1] Linux and the BSDs are free.   RHEL is effectively free, in the 
> guise of its clones.   OS X and Windows licenses are embedded with the 
> hardware purchases.  VSI may or may not decide to follow free licenses 
> with paid support, and/or free licenses and upgrades with VSI-branded 
> hardware packages and/or paid support.
> [2] Some of the same stability-oriented folks are also going to want to 
> and need to mitigate the possibility that VSI might not be around in a 
> decade, too.  That might lead to requests that the VSI source code be 
> escrowed or archived somewhere, for instance.
> 
> 
> -- 
> Pure Personal Opinion | HoffmanLabs LLC

Hoff wrote
" Most languages don't require double- or triple-quoting, nor
unbalanced single-quoting.   C-like languages tend to use a backslash
as an escapement and not doubling or tripling the quoting characters,
too.  "

I can only assume you've never tried to use any of the popular scripting
languages to write portable code that handles strings where a backslash
is a valid character in e.g. user input for something more complicated
than a simple filespec. Or you had better luck than I did.

I tried it a few years back and I can't remember the details but I do
remember the nightmare.

Oddly enough it was in connection with writing yet another diff tool. My
boss wanted one that was able to provide statistics on adds/moves/changes
and unfortunately nothing off the shelf at zero cost fitted the
requirements (there were for-money products that did the job, but...).

In the bigger picture here, I'm mostly with Dave F in general. Specifically...

DCL is a command language, originating as an MCR replacement in the
PDP11 era, for issuing simple commands to the OS and for building
simple scripts.

On VMS, DCL grew, maybe because users wanted it to. It grew so much
that at least one commercially available book exists on the subject
of Writing Real Programs in DCL. Times appear to have changed. 

Python's got a lot of neat features. Plus some horrible misfeatures
which are now fundamental to the language. Sensitivity to whitespace
is A Bad Idea, and the deliberate incompatibilities between Python 2
and Python 3 don't seem that clever to me either.

In five years time, school leavers will stand a fair chance of being
as fluent in Python as they are in English, if Raspberry Pi succeeds.

All that said, a proper VMS implementation of Python (2 and/or 3?) would 
surely go a long way?