[Info-vax] Python 2 support ends 1-Jan-2020

[Dave Froble]

On 1/4/2019 4:32 PM, Stephen Hoffman wrote:
> On 2019-01-04 16:05:50 +0000, Dave Froble said:
>
>> Not everyone has the same perceptions of reality ....
>>
>> Now, I know nothing of Python.  But the little I "think" I understand,
>> from reading here in c.o.v, is that some people who are working on
>> Python 3 have a vision that is incompatible with older versions of
>> Python.  Is that a fair assessment?
>
> Ponder whether fixing stuff is utterly impossible with OpenVMS, for
> those cases that cannot be fixed compatibly.
>
> The password hash length being a salient example.

You've been dwelling on this point for too long maybe?  VSI has, I 
believe, made the improvements to this issue, or at least plans to in 
the x86 product.  Don't know, haven't been following it.

Yes, it needed enhanced, and is being done.

Further, I don't believe this will break anything, because if anyone 
actually did anything with the data in any production apps, it was an 
improper and stupid move, and stupid doesn't deserve to be supported.

Yes, I've done a few things to extract data, but not in any apps, just 
to extract some data for me.

If LDAP is a good idea, I'm all for that also.  With hooks, OO if you 
will, to get at data in a supported method.

> All decisions and all designs and all limitations must absolutely be
> preserved forever, for always, and must never be changed.

If that were so, we'd all still be programming with jumpers on boards.

:-)

> Training customers to expect wholesale upward compatibility was one of
> the dumbest ideas DEC ever had, BTW.  Mostly compatible, sure. Entirely
> compatible?  That's a whole bucket of nope.

Change is inevitable.  Plan for it, and one will not be inconvenienced.

>> If so, then this might be a fair test of the acceptance, and therefore
>> viability, of visionaries attempting to drag others along into their
>> vision.  Regardless of the merits of the vision, remember the classic
>> case of VCR and Batamax.
>
> Betamax was purportedly a better format and was more expensive, and got
> undercut in the market.  Cheaper and good-enough, versus more expensive
> and less-than-clearly-differentiated.
>
> Itanium and x86-64 would be a closer and more familiar example.

No, itanic was never a good idea, and only because HP and then Intel 
pushed it did it exist for a short time.

The only thing x86 has going for it is volume.  Very large volume.

>> Similar to the advocates of OO.  The vision of some just may not be
>> adopted be others.
>
> Have you tried OOP, David?   Blows the sneakers off itemlists, in terms
> of its support for upward-compatibility.

I do believe I was doing some of the things that led to OO, long before 
there was the OO concept.  It's just good design practice.  But I'm not 
a fanatic about it.  Fanatics usually go too far.

Item lists are not the worst thing ever.  I will admit that on a scale 
of 1-10, they fall somewhere below 5, or 4, or 3.

At this time I doubt I'll be doing much outside Basic, and VAX Basic 
does not have formal OO stuff.  If it did, I'd use it when appropriate.

> And yes, OOP and FP won't be adopted by everybody.  No scheme ever is.

Which is reality.

> No more than everybody will move off of PDP-11 or VAX hardware or
> emulation.

There are always exceptions.  However, for most cases, VAX should not be 
an issue, since there are follow on possibilities.  There do not seem to 
be much of follow on stuff for PDP-11.

> There will always be oddities and corners in the market.
>
> VSI exists in one of those corners now, and the question is whether they
> can expand out of their current corner.
>
> Change is the only way.

Few things can stand still.  Even cars only move in forward or reverse. 
  Neutral doesn't move.

>> Perhaps sometimes the visionaries will not be followed.  Perhaps
>> sometimes they should not be followed.
>
> There are many reasons not to do something.  Not changing is safe.  Not
> changing is comfortable.  Familiar.  Not changing is cheap.  Until it's
> not.

Change just for the sake of change is rather stupid.  Make work.  Change 
when needed is very good.  Who makes the decisions?

> The one thing I'm absolutely certain of here?
>
> OpenVMS will continue on its current path if VSI doesn't start dragging
> it forward, and that some of that dragging-forward will necessarily
> involve breaking existing APIs.

I'm all for breaking, when it's called for.  Well designed apps can 
usually handle such.  Poorly designed apps, well, the name says it all.

> The x86-64 port is just a very small part of what's necessary here, if
> the goal is to extend OpenVMS past what solely interests the installed
> base.

There are some things VMS needs, even for the installed base.

I think we're pretty much in agreement, even if our presentations may 
differ.

:-)

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486