[Info-vax] Programming languages on VMS

DaveFroble davef at tsoft-inc.com
Sun Jan 28 18:49:49 EST 2018


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.


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



More information about the Info-vax mailing list