[Info-vax] inertia or fundamentals about langages?

[Stephen Hoffman]

On 2019-05-26 08:37:28 +0000, gérard Calliet said:

> Le 24/05/2019 à 19:06, Arne Vajhøj a écrit :
>> The third approach is to focus on doing something really technically 
>> advanced and hope that somebody will be impressed.

That's one possible path for acquiring new customers.  Probably one of the few.

> So it was once upon a time with VMS.   But Stephen Hoffman could say, 
> now not so true.

It'll be tough for a small team given the ever-increasing scale of 
software development, but it's certainly within the realm.  I have no 
doubt Clair has some ideas here, too.

> I thought about a fourth approach. Not so far from inertia concept, but 
> about the opposite: "it fits you".
> 
> The awfull "bespoke".
...
> And on computer domain, now a lot of people (Stephen Hoffman knows 
> them), say "bespoke" is *bad* .

Bespoke code gets expensive, and the development tooling and APIs that 
are provided for OpenVMS doesn't help with that.

Bespoke code that is unique and that adds value for the business or the 
products of the business can be good.

Bespoke code that replicates existing features and capabilities gets 
wasteful, as now you're maintaining and updating it in parallel, and 
spending comparatively less time on unique and useful source code and 
features.

It's quite common to start out with the former case—unique and valuable 
source code—and to drift into the latter case—replicating other 
solutions—over time.

Some source code can be a Savile Suit. Or a spectacular and very 
expensive and fitted dress, and made of the finest silk.  Some other 
source code is canvas flour sacks and spray adhesive.

It's quite common for code to start out with the former, and for at 
least some of it to drift toward the latter as requirements change and 
as alternatives are improved.

As an example of this drift, OpenVMS itself started out with a nice 
flat 30-bit address space for apps, and now we have a dog's breakfast 
of APIs and qualifiers and feature and compiler limitations for 64-bit 
virtual addressing.

Or logical names as a configuration interface, for that matter.  Once 
developers have seen better ways to deal with this stuff, using 
volatile and very limited key-value storage known as logical names 
looks... clunky.

It's also quite common for app source code—good, bad, or indifferent—to 
have a minimal set of features to meet the criterial for a working 
solution, but to omit a whole lot of nice-to-have features.  That code 
slowly starts to lack features as the requirements and expectations 
change.  Maybe features for online backups, online file 
defragmentation, failover and clustering support, sketchy or no logging 
and little or no debugging support, maybe recompilation is required to 
make configuration changes, latent or overt problems with security, or 
any number of examples.    The code works, but drifts out of focus.  
Don't mess with it more than necessary, spend your time working on 
features or capabilities or troubleshooting elsewhere, keep it all 
going, and maybe don't look to port it.  Inertia.

Then you—or your customers, or your management, or your 
competitors—might discover a better API or tool or environment, and 
suddenly you have a much bigger problem.

This is also part of why I've suggested getting out and trying other 
tools and environments as part of your own personal enrichment or 
whatever you want to call it, whether for your own career, or for your 
apps and designs and tooling.

As for new work at VSI akin to what Arne references?  Clustering and 
multi-host RAID-1 are two of the more obvious areas where the existing 
OpenVMS foundation fares well.  Though really using those features is a 
problem.  As is the related documentation. Which gets back to 
overhauling and updating documentation, distributed scheduling, APIs, 
distributed security and encryption, LDAP integration, etc.



-- 
Pure Personal Opinion | HoffmanLabs LLC