[Info-vax] Programming languages on VMS

Bill Gunshannon bill.gunshannon at gmail.com
Sat Jan 27 09:46:26 EST 2018


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



More information about the Info-vax mailing list