On 2023-05-10 17:00, Arne Vajhøj wrote:
> On 5/10/2023 9:16 AM, Johnny Billquist wrote:
>> On 2023-05-10 11:59, Chris Townley wrote:
>>> On 10/05/2023 04:39, Dave Froble wrote:
>>>> The defaults in Basic are LONG integers and Single FP.  A number,
>>>> such as 1, is treated as a single precision FP, so that makes not
>>>> being specific even worse.
>>>>
>>>> Note, I really don't like the FP default.  Any program I write
>>>> specifies the defaults for both integers and FP.  Something like:
>>>>
>>>> OPTION SIZE = ( INTEGER WORD , REAL DOUBLE )
>>>
>>> Our coding standards insisted on
>>>
>>> OPTION TYPE = EXPLICIT
>>
>> That actually don't solve the problem observed here.
>> That only makes the compiler give errors if you don't explicitly
>> declare variables. However constants are still being of the default
>> type defined.
>
> I am not a Basic person so not sure how much my opinion
> should count, but I think it would be nice with:
>
> $ BASIC/VAR_TYPE_DEFAULT=EXPLICIT/LITERAL_TYPE_DEFAULT=INTEGER ...

Yeah. And I actually don't know what happens with constants when you say
type is explicit. I sortof suspect they end up as FP again... :-/

I don't have VMS BASIC around to check there, but in BASIC+2 this is the
case. With TYPE_DEFAULT set to EXPLICIT, literals become floating point
unless % is added.

Johnny

On 10/05/2023 16:52, Johnny Billquist wrote:
> On 2023-05-10 17:00, Arne Vajhøj wrote:
>> On 5/10/2023 9:16 AM, Johnny Billquist wrote:
>>> On 2023-05-10 11:59, Chris Townley wrote:
>>>> On 10/05/2023 04:39, Dave Froble wrote:
>>>>> The defaults in Basic are LONG integers and Single FP.  A number,
>>>>> such as 1, is treated as a single precision FP, so that makes not
>>>>> being specific even worse.
>>>>>
>>>>> Note, I really don't like the FP default.  Any program I write
>>>>> specifies the defaults for both integers and FP.  Something like:
>>>>>
>>>>> OPTION SIZE = ( INTEGER WORD , REAL DOUBLE )
>>>>
>>>> Our coding standards insisted on
>>>>
>>>> OPTION TYPE = EXPLICIT
>>>
>>> That actually don't solve the problem observed here.
>>> That only makes the compiler give errors if you don't explicitly
>>> declare variables. However constants are still being of the default
>>> type defined.
>>
>> I am not a Basic person so not sure how much my opinion
>> should count, but I think it would be nice with:
>>
>> $ BASIC/VAR_TYPE_DEFAULT=EXPLICIT/LITERAL_TYPE_DEFAULT=INTEGER ...
>
> Yeah. And I actually don't know what happens with constants when you say
> type is explicit. I sortof suspect they end up as FP again... :-/
>
> I don't have VMS BASIC around to check there, but in BASIC+2 this is the
> case. With TYPE_DEFAULT set to EXPLICIT, literals become floating point
> unless % is added.
>
>   Johnny
>

I believe they follow the same rules, hence the use of % for integers

--
Chris

On 5/10/2023 11:52 AM, Johnny Billquist wrote:
> On 2023-05-10 17:00, Arne Vajhøj wrote:
>> On 5/10/2023 9:16 AM, Johnny Billquist wrote:
>>> On 2023-05-10 11:59, Chris Townley wrote:
>>>> On 10/05/2023 04:39, Dave Froble wrote:
>>>>> The defaults in Basic are LONG integers and Single FP.  A number,
>>>>> such as 1, is treated as a single precision FP, so that makes not
>>>>> being specific even worse.
>>>>>
>>>>> Note, I really don't like the FP default.  Any program I write
>>>>> specifies the defaults for both integers and FP.  Something like:
>>>>>
>>>>> OPTION SIZE = ( INTEGER WORD , REAL DOUBLE )
>>>>
>>>> Our coding standards insisted on
>>>>
>>>> OPTION TYPE = EXPLICIT
>>>
>>> That actually don't solve the problem observed here.
>>> That only makes the compiler give errors if you don't explicitly
>>> declare variables. However constants are still being of the default
>>> type defined.
>>
>> I am not a Basic person so not sure how much my opinion
>> should count, but I think it would be nice with:
>>
>> $ BASIC/VAR_TYPE_DEFAULT=EXPLICIT/LITERAL_TYPE_DEFAULT=INTEGER ...
>
> Yeah. And I actually don't know what happens with constants when you say
> type is explicit. I sortof suspect they end up as FP again... :-/
>
> I don't have VMS BASIC around to check there, but in BASIC+2 this is the
> case. With TYPE_DEFAULT set to EXPLICIT, literals become floating point
> unless % is added.

Based on docs this is seems to be the case for VMS Basic as well.

If /TYPE_DEFAULT=INTEGER then 1 and 2 are integer literals
otherwise (including /TYPE_DEFAULT=EXPLICIT) they are FP literals.

Which is why I want the 2 qualifiers - one to require that
variables are declared and one to make 1 and 2 integer literals.

Alternatively I could just learn VMS Basic.

:-)

Arne

On 5/10/2023 11:00 AM, Arne Vajhøj wrote:
> On 5/10/2023 9:16 AM, Johnny Billquist wrote:
>> On 2023-05-10 11:59, Chris Townley wrote:
>>> On 10/05/2023 04:39, Dave Froble wrote:
>>>> The defaults in Basic are LONG integers and Single FP. A number, such as 1,
>>>> is treated as a single precision FP, so that makes not being specific even
>>>> worse.
>>>>
>>>> Note, I really don't like the FP default. Any program I write specifies the
>>>> defaults for both integers and FP. Something like:
>>>>
>>>> OPTION SIZE = ( INTEGER WORD , REAL DOUBLE )
>>>
>>> Our coding standards insisted on
>>>
>>> OPTION TYPE = EXPLICIT
>>
>> That actually don't solve the problem observed here.
>> That only makes the compiler give errors if you don't explicitly declare
>> variables. However constants are still being of the default type defined.
>
> I am not a Basic person so not sure how much my opinion
> should count, but I think it would be nice with:
>
> $ BASIC/VAR_TYPE_DEFAULT=EXPLICIT/LITERAL_TYPE_DEFAULT=INTEGER ...
>
> Arne
>
>

The thing is, when working with any language, one should be aware of many
things, including defaults, and such. For anyone who doesn't intimately know a
language to just start writing code is usually a recipe for disaster.

I've worked with Basic+, BP2, and VAX/DEC Basic since 1974. I'm very familiar
with the language, and still, I'm sure I don't know everything. One look at
Arne's code and I was immediately aware of issues.

Ok, now I can be kicked off my soapbox.

:-)

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

On 5/10/2023 11:08 AM, Chris Townley wrote:
> On 10/05/2023 16:00, Arne Vajhøj wrote:
>> On 5/10/2023 9:16 AM, Johnny Billquist wrote:
>>> On 2023-05-10 11:59, Chris Townley wrote:
>>>> On 10/05/2023 04:39, Dave Froble wrote:
>>>>> The defaults in Basic are LONG integers and Single FP. A number, such as
>>>>> 1, is treated as a single precision FP, so that makes not being specific
>>>>> even worse.
>>>>>
>>>>> Note, I really don't like the FP default. Any program I write specifies
>>>>> the defaults for both integers and FP. Something like:
>>>>>
>>>>> OPTION SIZE = ( INTEGER WORD , REAL DOUBLE )
>>>>
>>>> Our coding standards insisted on
>>>>
>>>> OPTION TYPE = EXPLICIT
>>>
>>> That actually don't solve the problem observed here.
>>> That only makes the compiler give errors if you don't explicitly declare
>>> variables. However constants are still being of the default type defined.
>>
>> I am not a Basic person so not sure how much my opinion
>> should count, but I think it would be nice with:
>>
>> $ BASIC/VAR_TYPE_DEFAULT=EXPLICIT/LITERAL_TYPE_DEFAULT=INTEGER ...
>>
>> Arne
>
> When using Basic, it is not difficult to get in the habit of using %, or if
> valid FP use, for example, 1.0
> Within my team I would always check for this in code reviews
>

If explicitly declaring variables and constants, the "%" and "$" are not
required. Regardless, unless numerics are declared, then the language defaults
do affect things.

So if I declare Long one, and use one instead of 1, that can be avoided. If
not, better know exactly what one is doing. So even while some do not like
using the "%" suffix, it really helps one from making a mistake.

Yes, the 1. or 1.0 does basically (sic) specify the data type. A reasonable
practice.

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

On 5/7/2023 11:52 AM, Arne Vajhøj wrote:
> Just realized that I had an error in the calculation for
> string performance in Fortran and Basic (I fucked up with the
> VMS_FACTOR constant that is used to keep string length under
> 32K).
>
> So again with C++ and (hopefully) with Fortran and Basic
> correct for string operations:

And then it turned out that the Basic integer test was
not good because I did not know how to write integer literals
in VMS Basic.

:-(

Updated results.

Integer operations
                                Alpha sim         Itanium
                               (no JIT)          (older)
C, C++, Pascal, Fortran, Basic (/NOCHECK) 24-29             246
Basic (/CHECK)                   19                45
Ada (gnat make)                 8                 -
Ada (gnat make -gnatp "-O3")    44                -
Java 5                           11                -
Java 8                           -                 286
Python 2                         0.05              -
Python 3                         -                 0.6

String operations
                                 Alpha sim         Itanium
                                 (no JIT)          (older)
C                                0.078             1.94
C++                              0.049             0.40
Pascal                           0.005             0.32
Fortran                          0.156             6.94
Basic                           0.004             0.13
Ada                   0.005             -
Java 5                           0.033             -
Java 8                           -                 1.76
Python 2                         0.005             -
Python 3                         -                 0.064

> If someone want to check themselves the sources are
> available at https://www.vajhoej.dk/arne/temp/bm.zip !

Updated with correct Basic code.

Arne

On 5/10/2023 8:14 PM, Arne Vajhøj wrote:
> Updated results.
>
> Integer operations
>                                           Alpha sim         Itanium
>                                           (no JIT)          (older)
> C, C++, Pascal, Fortran, Basic (/NOCHECK) 24-29             246
> Basic (/CHECK)                            19                45
> Ada (gnat make)                           8                 -
> Ada (gnat make -gnatp "-O3")              44                -
> Java 5                                    11                -
> Java 8                                    -                 286
> Python 2                                  0.05              -
> Python 3                                  -                 0.6
>
> String operations
>                                           Alpha sim         Itanium
>                                           (no JIT)          (older)
> C                                         0.078             1.94
> C++                                       0.049             0.40
> Pascal                                    0.005             0.32
> Fortran                                   0.156             6.94
> Basic                                     0.004             0.13
> Ada                                       0.005             -
> Java 5                                    0.033             -
> Java 8                                    -                 1.76
> Python 2                                  0.005             -
> Python 3                                  -                 0.064

x86-64 numbers:

Integer operations
VM x86-64
(older Xeon)
C, C++ (default), Pascal, Fortran 133-136
C++ (/opt=lev:4) 758
Java 8 703

String operations
VM x86-64
(older Xeon)
C 2.6
C++ 1.9-2.0
Pascal 0.14
Fortran 0.00
Java 8 15.4

It seems like G2L has some room for performance improvements
(/opt=lev:5 did not make any difference for C or Fortran).

And not surprising older Xeon is much faster than much older Itanium.

Arne

On Tuesday, April 11, 2023 at 9:23:42 AM UTC-4, Simon Clubley wrote:
> On 2023-04-08, Zane H. Healy <hea...@avanthar.avanthar.com> wrote:
> >
> > Thanks for the confirmation. I thought that was the case, but wasn't sure
> > if I was simply looking in the wrong place. These days Python is pretty
> > much a requirement. Even IBM z/OS supports Python 3 now.
> >
> And for very good reason. Python is an excellent scripting language
> that is suitable for a _wide_ range of scripting tasks.
>
> In fact, if VSI had to choose one only, I would have said that Python,
> instead of Perl, should have been the one that's part of the base
> installation. (Although it would be better to have both of them as
> part of the base installation.)
>
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.

python is a poor mans DCL ...

On Thursday, October 5, 2023 at 4:37:06 PM UTC-4, ultr...@gmail.com wrote:
> On Tuesday, April 11, 2023 at 9:23:42 AM UTC-4, Simon Clubley wrote:
> > On 2023-04-08, Zane H. Healy <hea...@avanthar.avanthar.com> wrote:
> > >
> > > Thanks for the confirmation. I thought that was the case, but wasn't sure
> > > if I was simply looking in the wrong place. These days Python is pretty
> > > much a requirement. Even IBM z/OS supports Python 3 now.
> > >
> > And for very good reason. Python is an excellent scripting language
> > that is suitable for a _wide_ range of scripting tasks.
> >
> > In fact, if VSI had to choose one only, I would have said that Python,
> > instead of Perl, should have been the one that's part of the base
> > installation. (Although it would be better to have both of them as
> > part of the base installation.)
> >
> > Simon.
> >
> > --
> > Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> > Walking destinations on a map are further away than they appear.
>
> python is a poor mans DCL ...

Not sure if I agree with this, While python2 was problematic, it was used to build a lot of system tools (yum and firewall-cmd are two of many) in EL7 (RHEL-7, CentOS-7). But the Google-commissioned rewrite yielded python3 which made all statements much more formalized. Putting all that aside, the free libraries which allow any python programmer to easily support sftp, https, or connect to almost any relational database, place python in a totally different category than DCL.

IMHO, the OS that doesn't support python today will soon be headed for the dust bin.

p.s. I started using DCL in 1987 and still use it today in 2023. There once was a time when everything installed on VMS, or OpenVMS, was dependent upon DCL (heck sys$update:VMSINSTAL is just one large DCL script). But even DEC gave up on that idea when they introduced PRODUCT installs. Can anyone tell me why many third party vendors (like Process Software) still use VMSINSTAL ??

Neil Rieck
Waterloo, Ontario, Canada.
http://neilrieck.net
http://neilrieck.net/OpenVMS.html

On Saturday, October 7, 2023 at 9:29:25 AM UTC-4, Neil Rieck wrote:
> On Thursday, October 5, 2023 at 4:37:06 PM UTC-4, ultr...@gmail.com wrote:
> > On Tuesday, April 11, 2023 at 9:23:42 AM UTC-4, Simon Clubley wrote:
> > > On 2023-04-08, Zane H. Healy <hea...@avanthar.avanthar.com> wrote:
> > > >
> > > > Thanks for the confirmation. I thought that was the case, but wasn't sure
> > > > if I was simply looking in the wrong place. These days Python is pretty
> > > > much a requirement. Even IBM z/OS supports Python 3 now.
> > > >
> > > And for very good reason. Python is an excellent scripting language
> > > that is suitable for a _wide_ range of scripting tasks.
> > >
> > > In fact, if VSI had to choose one only, I would have said that Python,
> > > instead of Perl, should have been the one that's part of the base
> > > installation. (Although it would be better to have both of them as
> > > part of the base installation.)
> > >
> > > Simon.
> > >
> > > --
> > > Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> > > Walking destinations on a map are further away than they appear.
> >
> > python is a poor mans DCL ...
> Not sure if I agree with this, While python2 was problematic, it was used to build a lot of system tools (yum and firewall-cmd are two of many) in EL7 (RHEL-7, CentOS-7). But the Google-commissioned rewrite yielded python3 which made all statements much more formalized. Putting all that aside, the free libraries which allow any python programmer to easily support sftp, https, or connect to almost any relational database, place python in a totally different category than DCL.
>
> IMHO, the OS that doesn't support python today will soon be headed for the dust bin.
>
> p.s. I started using DCL in 1987 and still use it today in 2023. There once was a time when everything installed on VMS, or OpenVMS, was dependent upon DCL (heck sys$update:VMSINSTAL is just one large DCL script). But even DEC gave up on that idea when they introduced PRODUCT installs. Can anyone tell me why many third party vendors (like Process Software) still use VMSINSTAL ??
>

One key thing that PRODUCT does not support is installing on more than one disk. The VMSINSTAL kit that I wrote basically asked, where do you want to put the code and where do you want to put the data.

There's also the problem of supporting old versions of VMS that don't have PRODUCT.