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

[Stephen Hoffman]

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