[Info-vax] Programming languages on VMS

[Jan-Erik Soderholm]

Den 2018-01-29 kl. 00:49, skrev DaveFroble:
> Bill Gunshannon wrote:
>> On 01/27/2018 04:57 AM, Henry Crun wrote:
>>> On 27-Jan-2018 11:42, Jan-Erik Soderholm wrote:
>>>> Den 2018-01-27 kl. 04:02, skrev Bill Gunshannon:
>>>>> On 01/26/2018 06:06 PM, DaveFroble wrote:
>>>>>> Bill Gunshannon wrote:
>>>>>>> On 01/26/2018 03:36 PM, Johnny Billquist wrote:
>>>>>>>> On 2018-01-24 18:26, Bill Gunshannon wrote:
>>>>>>>>> Given what it was designed for BASIC was never taken seriously. Even
>>>>>>>>> after ANSIfication it was still not overly practical as most versions
>>>>>>>>> were interpreted and not compiled. What data type of none-integer 
>>>>>>>>> does
>>>>>>>>> BASIC support that can do calculations with decimals without the
>>>>>>>>> cumulative error common to floating point?
>>>>>>>>
>>>>>>>> Is that a trick question?
>>>>>>>> BASIC can actually do arithmetic on strings, with arbitrary precision.
>>>>>>>> And that's been in several different BASIC dialects I've played with.
>>>>>>>
>>>>>>> But the problem with BASIC is every one is different.  Not the kind
>>>>>>> of language I would be betting my business on today.
>>>>>>>
>>>>>>>>
>>>>>>>>  From the BP2 help:
>>>>>>>>
>>>>>>>>    FUNCTIONS
>>>>>>>>
>>>>>>>>      BUILT-IN
>>>>>>>>
>>>>>>>>        SUM$
>>>>>>>>
>>>>>>>>   The SUM$ function returns a string whose value is the sum of two 
>>>>>>>> numeric
>>>>>>>>   strings.
>>>>>>>>
>>>>>>>>   Format
>>>>>>>>
>>>>>>>>       str-vbl = SUM$(str-exp1, str-exp2)
>>>>>>>>
>>>>>>>>   Example
>>>>>>>>
>>>>>>>>   600    Sigma$ = SUM$("234.444", A$)
>>>>>>>>
>>>>>>>>
>>>>>>>> You also have DIF$, PROD$ and QUO$.
>>>>>>>
>>>>>>> Totally unique to DEC.  Later RSTS, RSX and then VMS.  I have
>>>>>>> worked with a number of versions of BASIC and no others did it.
>>>>>>>
>>>>>>> Considering that VMS BASIC has the DECIMAL type makes one wonder
>>>>>>> why they keep STRING Arithmetic.
>>>>>>>
>>>>>>> bill
>>>>>>>
>>>>>>>
>>>>>>> bill
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Once it's in there, it may be more trouble to rip it out, and then 
>>>>>> there are possible customers using the capability.
>>>>>
>>>>> Guess that depends on why they added an equivalent feature.  If it
>>>>> was to become standard compliant than after a suitable time when the
>>>>> old way was marked "deprecated" it should go away.
>>>>>
>>>>>>
>>>>>> So what if it's DEC specific.  Many DEC specific things were / are 
>>>>>> better than anything else available.  Why would anyone want to choose 
>>>>>> lowest common denominator when there is better available. Your 
>>>>>> argument makes no sense, unless you expect the DEC stuff to go away, 
>>>>>> which, was an issue for a while.
>>>>>
>>>>> I don;t expect the DEC stuff to go away.  I merely pointed out that
>>>>> the biggest problem with BASIC is that no two are the same.  It isn't
>>>>> least common denominator.  It's what is in the standard.  There is a
>>>>> reason people go to so  much trouble to make standards.  Too bad so
>>>>> few people end out following them.
>>>>>
>>>>>>
>>>>>> Do you choose your cars based upon conformity to a Yugo?
>>>>>
>>>>> Yugo was never a standard.  Well, maybe a standard for poor
>>>>> quality.
>>>>>
>>>>>>
>>>>>> Do you do ANYTHING based upon conformity to "lowest common denominator"?
>>>>>
>>>>> Probably not, but the standard is not "lowest common denominator".
>>>>> Or, maybe they are and we should just stop writing standards.  How
>>>>> do you think the automotive industry would be without SAE?  (Or DIN
>>>>> in Germany!) Cars was your example....
>>>>>
>>>>> bill
>>>>>
>>>>
>>>> Yes, some/most standards are a good thing. Just think how it would
>>>> be if not everyone used a metric measuring system! What a mess...
>>>>
>>>>
>>>>
>>>
>>> Its been said before, specifically about DEC BASIC: If it had not been 
>>> called BASIC, but say DEC Business Oriented Language, all this 
>>> comparison with different varieties of BASIC would be moot.
>>
>> I have long said this.  When you change a language you should change
>> the name and not expect the language to morph to your desires.  I
>> still consider K&R to be C.  And  not just because of my penchant for
>> older systems.
>>
>>>  From my experience working with BP2 on a financial system with several 
>>> thousand modules, transferred fairly painlessly from PDP 11-70 RSTS to 
>>> early (circa V5.5) VMS on VAX and then to Alpha where as far as I know 
>>> it is still extant.
>>>
>>
>> I have no doubt, but what if you had to move it to an IBM 4331?  Or a
>> Univac-1100? (Both of the same point in time.)  Both had BASIC but not
>> the same language as DEC.  Thus a good reason to use standard languages
>> rather than languages so full of "extensions" they hardly represent
>> the language they claim to be.
>>
>> bill
> 
> If it weren't for what DEC made the language, it probably wouldn't be worth 
> using.
> 
> I don't HAVE to move software to an IBM, or anything else.  I'm happy with 
> VMS.
> 
> If someone does desire such a move, they are going to pay, dearly.  I had a 
> customer that for some reason wanted to move away from VMS, and to 
> weendoze. Note that this was to most reliable system they had.  I gave them 
> a quote which I figured would put a stop to such ideas.  They're desire was 
> so strong that they came up with the money.  And so I totally re-wrote the 
> software using VB6. Any sort of port was nonsense.  I of course used the 
> original for reference. And I cashed the check.
> 

And what happened to the VB6 app? Still in use? The maintenance situation
for VB6 is quite bad today...