[Info-vax] Programming languages on VMS

[Henry Crun]

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.
 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.

-- 
No Micro$oft products were used in the URLs above, or in preparing this message.
Recommended reading: http://www.catb.org/~esr/faqs/smart-questions.html#before