Python for x86?

[Zane H. Healy]

It feels odd to say this, but one of the reasons I've been looking forwards
to running the x86 version of VMS, is to have access to Python 3. The Alpha
version of VMS only has Python 2, and I'm trying to force myself to use
Python more. Is Python avaialble for x86, and if so where?

I was pleased to see that Perl is included with the base OS.

Zane

[Arne Vajhøj]

On 4/8/2023 10:34 AM, Zane H. Healy wrote:
> It feels odd to say this, but one of the reasons I've been looking forwards
> to running the x86 version of VMS, is to have access to Python 3. The Alpha
> version of VMS only has Python 2, and I'm trying to force myself to use
> Python more. Is Python avaialble for x86, and if so where?

https://vmssoftware.com/products/python/

only has Itanium.

But since it is VSI and VSI want to push VMS x86-64, then
it seems reasonable to expect Python for VMS x86-64 to show
up at some point in time. Only VSI knows when.

Arne

[Zane H. Healy]

Arne Vajh?j <ar...@vajhoej.dk> wrote:
> https://vmssoftware.com/products/python/
>
> only has Itanium.
>
> But since it is VSI and VSI want to push VMS x86-64, then
> it seems reasonable to expect Python for VMS x86-64 to show
> up at some point in time. Only VSI knows when.
>
> Arne

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.

Zane

[Robert A. Brooks]

I know next-to-nothing about open source on VMS, but if Python requires
C++ to build, then that would be an impediment to its being built for X86_64.

The native C++ compiler on X86_64 is in field test.

--

--- Rob

[John Dallman]

In article <u0s9hd$1bhr0$1...@dont-email.me>, FIRST...@vmssoftware.com

(Robert A. Brooks) wrote:

> I know next-to-nothing about open source on VMS, but if Python
> requires C++ to build, then that would be an impediment to its
> being built for X86_64.
>
> The native C++ compiler on X86_64 is in field test.

The reference Python implementation, CPython, is written in C, and needs
a C99-capable compiler (C11 from Python 3.11). So the VSI C ought to be
adequate for 3.10 and earlier, but waiting for an LLVM-based C compiler
would allow building an up-to-date CPython.

John

[Arne Vajhøj]

The standard and the one VSI is using Python implementation
is supposedly written in pure C.

But:

https://github.com/vmssoftware/cpython

claims :

Python 61.4%
C 36.4%
C++ 0.7%

and:

https://github.com/vmssoftware/python_3_8_2

claims:


Python 56.9%
C 40.1%
C++ 0.7%

so maybe there is a tiny little bit of C++ somewhere.

Arne

[Simon Clubley]

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.

[Craig A. Berry]

On 4/11/23 8:23 AM, 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.)

I don't think there was any such choice and I agree that having a Python
package available is essential. I'm not sure why Python isn't available
yet. The native C and C++ compilers are still in field test state and
have long lists of known issues, so it's possible the dependencies just
aren't there quite yet to build CPython.

Perl is available because I built it with the cross tools kit and VSI
repackaged and signed it with my blessing. That means, among other
things, that you can't build Perl extensions with the native compilers
until Perl itself is built with them. Building Perl with the native
compilers is well under way but not quite there yet. Perl and its test
suite have a way of revealing bugs in the C compiler, the CRTL, and even
the OS itself occasionally.

[Arne Vajhøj]

Python is way more popular than Perl today, so we know it is not
a business priority.

It could be a technical dependency problem as you describe.

But it could also be an estimated effort problem. It is my impression
that Perl is evolving reasonable slowly and that the VMS port has
been rock solid for decades. And all versions has been build
for both Alpha and Itanium. That sort of make it easier to
port and know what is a source problem and what is a tool problem.
Python situation is a bit more uncertain. The Python language is
evolving pretty quickly as they have joined the arms race with
C++/Java/C#/PHP about having most features. And first JFP did 2.x on
both Alpha and Itanium, then JFP did a 3.x on Itanium only and finally
VSI did a 3.x on Itanium only. As we speak (hmm, write) there is an
outstanding question on VSI Python over on the VSI forum. I suspect that
an estimate for Python port to x86-64 would be much higher than the Perl
one.

Arne

PS: And a million thanks to the people that have worked on Perl and
Python over the years!!

[Zane H. Healy]

Arne Vajh?j <ar...@vajhoej.dk> wrote:
> But it could also be an estimated effort problem. It is my impression
> that Perl is evolving reasonable slowly and that the VMS port has
> been rock solid for decades. And all versions has been build
> for both Alpha and Itanium. That sort of make it easier to
> port and know what is a source problem and what is a tool problem.

One thought I had, after reading the replies. The technical reasons make
sense. However, in reality, might there not be more Perl code running on
VMS than Python? I know that on my personal servers I have a fair amount of
Perl, but then I've spent over 26 years with Perl as my primary language.
My interest in Python is that I am now doing things that require it, so
being able to use it on VMS would be an advantage to me.

Zane

[Arne Vajhøj]

Maybe.

If we look at the IT industry over all then:
- Perl is a niche language known by the smart *nix nerds
primarily used for admin scripting today (after having had
some golden years in the late 90's early 00's for web
development)
- Python is one of the top 3 languages - widely used for
admin scripting, big data/data-analysis/ML/AI, web
development (Django), education etc. etc.

But VMS is not like the overall IT industry.

A lot of VMS systems are old and from a time where
Perl was bigger than Python.

In traditional admin scripts for VMS there are
probably way more Perl than Python (DCL is still king
in this area despite its various gaps).

But there has also been done a lot of Python work on VMS
the last 15 years in the area of integration between
VMS applications and other stuff the companies are
running.

Arne

[Craig A. Berry]

On 4/12/23 11:37 AM, Arne Vajhøj wrote:
> On 4/12/2023 11:30 AM, Zane H. Healy wrote:
>> Arne Vajh?j <ar...@vajhoej.dk> wrote:
>>> But it could also be an estimated effort problem. It is my impression
>>> that Perl is evolving reasonable slowly and that the VMS port has
>>> been rock solid for decades. And all versions has been build
>>> for both Alpha and Itanium. That sort of make it easier to
>>> port and know what is a source problem and what is a tool problem.
>>
>> One thought I had, after reading the replies.  The technical reasons make
>> sense.  However, in reality, might there not be more Perl code running on
>> VMS than Python?  I know that on my personal servers I have a fair
>> amount of
>> Perl, but then I've spent over 26 years with Perl as my primary language.
>> My interest in Python is that I am now doing things that require it, so
>> being able to use it on VMS would be an advantage to me.
>
> Maybe.
>
> If we look at the IT industry over all then:
> - Perl is a niche language known by the smart *nix nerds
>   primarily used for admin scripting today (after having had
>   some golden years in the late 90's early 00's for web
>   development)

And not just local admin scripting. It's a dependency for autoconf.
It's heavily used by other build processes and system utilities in the
BSD and Linux worlds. Various potentially breaking changes in Perl
analogous to those in Python 3 have been shot down because the whole
internet would stop. And because Hyrum's Law.

> - Python is one of the top 3 languages - widely used for
>   admin scripting, big data/data-analysis/ML/AI, web
>   development (Django), education etc. etc.

It's had massive investment by Google and others and its original author
has stuck around to see it through the 2 to 3 transition even if
stepping back from the role of benevolent dictator for life. Its success
is impressive but I don't know how much it has to do with the language
itself.

> But VMS is not like the overall IT industry.
>
> A lot of VMS systems are old and from a time where
> Perl was bigger than Python.
>
> In traditional admin scripts for VMS there are
> probably way more Perl than Python (DCL is still king
> in this area despite its various gaps).
>
> But there has also been done a lot of Python work on VMS
> the last 15 years in the area of integration between
> VMS applications and other stuff the companies are
> running.

Python 3 requires libffi. I believe it was an impediment to getting
Python 3 on Alpha because it involved finding someone who knew Alpha
assembler who could implement a module in that. Obviously a lot of
people, relatively speaking, know x86 assembler, but the ones at VSI may
have other stuff to do. Also, I believe Perl is a dependency for
building OpenSSL, which is part of the VMS base install. While the
current OpenSSL kits are probably cross builds, that may be changing
soon and it may have something to do with the order of porting. I also
have the impression that at least some people at VSI use Perl frequently
as the swiss army chainsaw it's known for.

[Neil Rieck]

Actually, the original author, Guido van Rossum, was hired by Google for no other reason than to port python2 up tp python3 along the lines that google wanted. As an enticement, he was told to work on python3 only in the mornings so would be allowed to work on anything else the rest of the day. IIRC, he stayed in that roll for seven years.

And although python is used to do a lot of admin scripting on Linux platforms (tools like "yum" and "firewall-cmd" are written in python), python does a really good job supporting server-side scripting under apache cgi-bin. I don't know how this is possible, but python programs are faster than compiled DEC-BASIC programs started via apache.

So IMHO python3 on OpenVMS is a must-have.

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

[Arne Vajhøj]

On 4/13/2023 6:44 AM, Neil Rieck wrote:
> Actually, the original author, Guido van Rossum, was hired by Google
> for no other reason than to port python2 up tp python3 along the
> lines that google wanted. As an enticement, he was told to work on
> python3 only in the mornings so would be allowed to work on anything
> else the rest of the day. IIRC, he stayed in that roll for seven
> years.

Yes. According to wikipedia:

CWI -2005
Google 2005-2012
Dropbox 2012-2019
retired 2019-2020
Microsoft 2020-

> And although python is used to do a lot of admin scripting on Linux
> platforms (tools like "yum" and "firewall-cmd" are written in
> python), python does a really good job supporting server-side
> scripting under apache cgi-bin. I don't know how this is possible,
> but python programs are faster than compiled DEC-BASIC programs
> started via apache.

That is unexpected. If both are run via CGI mechanism then
script activation should be the same. And compiled code should be
faster than interpreted code. And if libraries used are also the
same then it is a mystery.

High performance Python web services would use Flask or
something similar to avoid the activation overhead.

> So IMHO python3 on OpenVMS is a must-have.

Absolutely.

Python is a very important language today.

And it has to be Python 3 as Python 2 is obsolete.

Arne

[Arne Vajhøj]

On 4/13/2023 6:44 AM, Neil Rieck wrote:

> Actually, the original author, Guido van Rossum, was hired by Google
> for no other reason than to port python2 up tp python3 along the
> lines that google wanted. As an enticement, he was told to work on
> python3 only in the mornings so would be allowed to work on anything
> else the rest of the day. IIRC, he stayed in that roll for seven
> years.

Yes. According to wikipedia:

CWI -2005
Google 2005-2012
Dropbox 2012-2019
retired 2019-2020
Microsoft 2020-

> And although python is used to do a lot of admin scripting on Linux
> platforms (tools like "yum" and "firewall-cmd" are written in
> python), python does a really good job supporting server-side
> scripting under apache cgi-bin. I don't know how this is possible,
> but python programs are faster than compiled DEC-BASIC programs
> started via apache.

That is unexpected. If both are run via CGI mechanism then
script activation should be the same. And compiled code should be
faster than interpreted code. And if libraries used are also the
same then it is a mystery.

High performance Python web services would use Flask or
something similar to avoid the activation overhead.

> So IMHO python3 on OpenVMS is a must-have.

[Jan-Erik Söderholm]

The performance depends a lot on if you are using standard Apache CGI
or Apache "loadable modules". If you are just writing your own server
apps, I guess they run as standard CGI (one process started per call).
And I would expect Python to be available as a "loadable module". And
that makes a big differnce, in particular on VMS with it's process
creation overhead.

Here are some figures for WASD and Apache.
http://wasd.vsm.com.au/wasd_root/wasdoc/features/#11.2.scripting

We are using Python 2 in the form of PyRTE (persisting processes) and
have OK performance. First call (starting the Python process) does have
a 1-2 sec overhead, but following calls are processes in fractions of a
second (incl. Rdb processing).

We are currently looking at writing our own persistent server processes
to see if we can tweek the performance a bit more by using compiled
code (Cobol, in our case).

Using a test C application (just returns a timestamp to the browser, the
reply time including starting the VMS process is 172 ms. Additional calls
to the server with the process started are around 60 ms. As reported by
the performance tools in Firefox.
(Firefix running ona Citrix server pointing to one of our DS20e systems.)

[Jan-Erik Söderholm]

Den 2023-04-13 kl. 12:44, skrev Neil Rieck:

The performance depends a lot on if you are using standard Apache CGI
or Apache "loadable modules". If you are just writing your own server
apps, I guess they run as standard CGI (one process started per call).
And I would expect Python to be available as a "loadable module". And
that makes a big differnce, in particular on VMS with it's process
creation overhead.

Here are some figures for WASD and Apache.
http://wasd.vsm.com.au/wasd_root/wasdoc/features/#11.2.scripting

We are using Python 2 in the form of PyRTE (persisting processes) and
have OK performance. First call (starting the Python process) does have
a 1-2 sec overhead, but following calls are processes in fractions of a
second (incl. Rdb processing).

We are currently looking at writing our own persistent server processes
to see if we can tweek the performance a bit more by using compiled
code (Cobol, in our case).

Using a test C application (just returns a timestamp to the browser, the
reply time including starting the VMS process is 172 ms. Additional calls
to the server with the process started are around 60 ms. As reported by
the performance tools in Firefox.
(Firefix running ona Citrix server pointing to one of our DS20e systems.)





>

[Simon Clubley]

On 2023-04-13, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> On 4/13/2023 6:44 AM, Neil Rieck wrote:
>> And although python is used to do a lot of admin scripting on Linux
>> platforms (tools like "yum" and "firewall-cmd" are written in
>> python), python does a really good job supporting server-side
>> scripting under apache cgi-bin. I don't know how this is possible,
>> but python programs are faster than compiled DEC-BASIC programs
>> started via apache.
>
> That is unexpected. If both are run via CGI mechanism then
> script activation should be the same. And compiled code should be
> faster than interpreted code. And if libraries used are also the
> same then it is a mystery.
>

Maybe. Maybe not. Based purely on some comments from people here who
know/use DEC Basic, it's quite possible that DEC Basic has a RTL which
imposes some serious runtime overheads.

Perhaps for one of your many articles (:-)), you may be interested in
coding the same set of problems in the various DEC languages and seeing
what the performance differences are.

[Jan-Erik Söderholm]

Den 2023-04-13 kl. 14:26, skrev Simon Clubley:
> On 2023-04-13, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 4/13/2023 6:44 AM, Neil Rieck wrote:
>>> And although python is used to do a lot of admin scripting on Linux
>>> platforms (tools like "yum" and "firewall-cmd" are written in
>>> python), python does a really good job supporting server-side
>>> scripting under apache cgi-bin. I don't know how this is possible,
>>> but python programs are faster than compiled DEC-BASIC programs
>>> started via apache.
>>
>> That is unexpected. If both are run via CGI mechanism then
>> script activation should be the same. And compiled code should be
>> faster than interpreted code. And if libraries used are also the
>> same then it is a mystery.
>>
>
> Maybe. Maybe not. Based purely on some comments from people here who
> know/use DEC Basic, it's quite possible that DEC Basic has a RTL which
> imposes some serious runtime overheads.
>
> Perhaps for one of your many articles (:-)), you may be interested in
> coding the same set of problems in the various DEC languages and seeing
> what the performance differences are.
>
> Simon.
>

I'm quite sure that the difference seen come from the fact that
the Basic application is using standard CGI (one process per call)
and Python is a "Loadable Module" in Apache (stays loaded between
calls).

If both was using the same server technique, I'd expect the Basic
process to be faster. Of course, also depends on what the server
applications actualy does...

Or was the Basic application written as a "loadable module"?

[Arne Vajhøj]

On 4/12/2023 9:49 PM, Craig A. Berry wrote:
> On 4/12/23 11:37 AM, Arne Vajhøj wrote:
>> - Python is one of the top 3 languages - widely used for
>>    admin scripting, big data/data-analysis/ML/AI, web
>>    development (Django), education etc. etc.
>
> It's had massive investment by Google and others and its original author
> has stuck around to see it through the 2 to 3 transition even if
> stepping back from the role of benevolent dictator for life. Its success
> is impressive but I don't know how much it has to do with the language
> itself.

The relationship between language syntax/features and language
success is rarely clear.

:-)

I remember back when Perl, Python and Tcl was 3 equivalent choices
for scripting.

They evolved very different - Perl stayed where it was, Python became
a widely used language and Tcl is practically dead.

Why did Python become such a success while the other did not?

My guess:
- Python managed to get into education - not just CS like
Perl but much broader
- Python web approaches with Django etc. turned more future oriented
than Perl CGI
- Python got on the big data / analytics / ML / AI train
and when that took off it pulled Python with it

> Python 3 requires libffi.  I believe it was an impediment to getting
> Python 3 on Alpha because it involved finding someone who knew Alpha
> assembler who could implement a module in that.

I remember the Python 3 "port problem" being libffi.

But if the libffi problem is assembler knowledge then I am
puzzled - I would expect way more Alpha assembler programmers
than Itanium programmers.

> Also, I believe Perl is a dependency for
> building OpenSSL, which is part of the VMS base install.  While the
> current OpenSSL kits are probably cross builds, that may be changing
> soon and it may have something to do with the order of porting.  I also
> have the impression that at least some people at VSI use Perl frequently
> as the swiss army chainsaw it's known for.

:-)

Arne

[Jan-Erik Söderholm]

Den 2023-04-13 kl. 14:31, skrev Arne Vajhøj:

>
> I remember the Python 3 "port problem" being libffi.
>

A few weeks ago I got information from JFP on his new
Python 3 port to Itanium.

I do not have any Itanium server, so I havn't looked further.
And I have no idea about this libffi thing...

And VSI has a Python 3 offering.
https://vmssoftware.com/products/python/

I do not know if I have missed something, but why is Python 3
discusses as an issue? Would it not be expected that these
Python 3 ports also would build on x86?

[Arne Vajhøj]

On 4/13/2023 8:40 AM, Jan-Erik Söderholm wrote:
> And VSI has a Python 3 offering.
> https://vmssoftware.com/products/python/
>
> I do not know if I have missed something, but why is Python 3
> discusses as an issue? Would it not be expected that these
> Python 3 ports also would build on x86?

I think everybody is expecting Python 3 to become available
on VMS x86-64.

But it is not available yet.

While Perl is.

And given the huge interest here in speculating about anything
VMS related, then we are just guessing on why Perl came before
Python.

:-)

Arne

[Arne Vajhøj]

On 4/13/2023 8:26 AM, Simon Clubley wrote:
> On 2023-04-13, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 4/13/2023 6:44 AM, Neil Rieck wrote:
>>> And although python is used to do a lot of admin scripting on Linux
>>> platforms (tools like "yum" and "firewall-cmd" are written in
>>> python), python does a really good job supporting server-side
>>> scripting under apache cgi-bin. I don't know how this is possible,
>>> but python programs are faster than compiled DEC-BASIC programs
>>> started via apache.
>>
>> That is unexpected. If both are run via CGI mechanism then
>> script activation should be the same. And compiled code should be
>> faster than interpreted code. And if libraries used are also the
>> same then it is a mystery.
>>
>
> Maybe. Maybe not. Based purely on some comments from people here who
> know/use DEC Basic, it's quite possible that DEC Basic has a RTL which
> imposes some serious runtime overheads.

VMS Basic is a language with a high level of abstraction
so more "happens under the hood" than in C/Fortran/Cobol.

There are some overhead due to that.

Obvious example is strings. VMS Basic use dynamic
strings. The RTL does some work there.

But Python is even more high level and does similar
work - including the equivalent of dynamic strings.

But it is still interpreted (for standard Python
implementation) while VMS Basic get compiled.

Only thing in Pythons favor is that there must
be spent 1000 times more effort optimizing Python
libraries than optimizing VMS Basic RTL.

Arne

[Arne Vajhøj]

One can do a little test.

VMS Alpha.

$ type app.c
#include <stdio.h>
#include <string.h>

void app(char *buf, int n)
{
int i;
for(i = 0; i < n; i++)
{
strcat(buf, "X");
}
}

int main(int argc, char *argv[])
{
char buf[100];
strcpy(buf, "");
app(buf, 10);
printf("%s\n", buf);
return 0;
}
$ cc app
$ link app
$ run app
XXXXXXXXXX
$ type app.bas
program appdemo

declare string buf
external sub app(string, integer)

buf = ""
call app(buf, 10)
print buf

end program
!
sub app(string buf, integer n)

declare integer i

for i = 1 to n
buf = buf + "X"
next i

end sub
$ bas app
$ link app
$ run app
XXXXXXXXXX

C compiler generates:

0000 APP::
EE200020 0000 BLE R17, L$11
; 001948
23DEFFC0 0004 LDA SP, -64(SP)
; 001945
B77E0000 0008 STQ R27, (SP)
B75E0008 000C STQ R26, 8(SP)
B45E0010 0010 STQ R2, 16(SP)
B47E0018 0014 STQ R3, 24(SP)
B49E0020 0018 STQ R4, 32(SP)
B4BE0028 001C STQ R5, 40(SP)
B7BE0030 0020 STQ FP, 48(SP)
47FE041D 0024 MOV SP, FP
47FF0405 0028 CLR R5
47F10404 002C MOV R17, R4
47F00403 0030 MOV R16, R3
47FB0402 0034 MOV R27, R2
2FFE0000 0038 UNOP
2FFE0000 003C UNOP
0040 L$6:
; 001948
A7420020 0040 LDQ R26, 32(R2)
; 001950
40A03005 0044 ADDL i, 1, i
; R5, 1, R5 ; 001948
47E30410 0048 MOV buf, R16
; R3, R16 ; 001950
22220030 004C LDA R17, 48(R2)
47E05419 0050 MOV 2, R25
A7620028 0054 LDQ R27, 40(R2)
6B5A4000 0058 JSR R26, DECC$STRCAT
; R26, R26
40A409A0 005C CMPLT i, n, R0
; R5, R4, R0 ; 001948
F41FFFF7 0060 BNE R0, L$6
47FD041E 0064 MOV FP, SP
; 001952
A75D0008 0068 LDQ R26, 8(FP)
A45D0010 006C LDQ R2, 16(FP)
A47D0018 0070 LDQ R3, 24(FP)
A49D0020 0074 LDQ R4, 32(FP)
A4BD0028 0078 LDQ R5, 40(FP)
A7BD0030 007C LDQ FP, 48(FP)
23DE0040 0080 LDA SP, 64(SP)
0084 L$11:
6BFA8001 0084 RET R26
2FFE0000 0088 UNOP
2FFE0000 008C UNOP

Basic compiler generates:

0120 APP::
; 000011
23DEFF00 0120 LDA SP, -256(SP)
473FF019 0124 AND R25, 255, R25
B75E00C0 0128 STQ R26, 192(SP)
B77E0000 012C STQ R27, (SP)
B7FE0008 0130 STQ R31, 8(SP)
B45E00C8 0134 STQ R2, 200(SP)
B47E00D0 0138 STQ R3, 208(SP)
B49E00D8 013C STQ R4, 216(SP)
B4BE00E0 0140 STQ R5, 224(SP)
B4DE00E8 0144 STQ R6, 232(SP)
B7BE00F0 0148 STQ FP, 240(SP)
63FF0000 014C TRAPB
47FE041D 0150 MOV SP, FP
47FB0402 0154 MOV R27, R2
47F00403 0158 MOV R16, R3
432059B0 015C CMPLT R25, 2, R16
B63E00B0 0160 STQ R17, 176(SP)
F600003A 0164 BNE R16, L$4
43205DB0 0168 CMPLE R25, 2, R16
2FFE0000 016C UNOP
E600003A 0170 BEQ R16, L$5
A63BFF90 0174 LDQ R17, -112(R27)
A75BFFA0 0178 LDQ R26, -96(R27)
221E0008 017C LDA R16, 8(SP)
47E05419 0180 MOV 2, R25
A762FFA8 0184 LDQ R27, -88(R2)
22310084 0188 LDA R17, 132(R17)
2FFE0000 018C UNOP
6B5A4000 0190 JSR R26, DBASIC$INIT
; R26, R26
A41D00B0 0194 LDQ R0, 176(FP)
; 000016
2C200000 0198 LDQ_U R1, (R0)
2E000003 019C LDQ_U R16, 3(R0)
482004C1 01A0 EXTLL R1, R0, R1
4A000D50 01A4 EXTLH R16, R0, R16
44300404 01A8 BIS R1, R16, R4
43E40004 01AC SEXTL R4, R4
47E03405 01B0 MOV 1, I
; 1, R5
EC800010 01B4 BLE R4, L$8
24DF010E 01B8 LDAH R6, 270(R31)
; 000017
20C60001 01BC LDA R6, 1(R6)
01C0 L$10:
A7420030 01C0 LDQ R26, 48(R2)
40481011 01C4 ADDL R2, 64, R17
47E30410 01C8 MOV R3, R16
225D00B8 01CC LDA R18, 184(FP)
B23D00BC 01D0 STL R17, 188(FP)
B0DD00B8 01D4 STL R6, 184(FP)
47E30411 01D8 MOV R3, R17
47E07419 01DC MOV 3, R25
A7620038 01E0 LDQ R27, 56(R2)
6B5A4000 01E4 JSR R26, STR$CONCAT
; R26, R26
40A03805 01E8 ADDL/V I, 1, I
; R5, 1, R5 ; 000018
40A40DA0 01EC CMPLE I, R4, R0
; R5, R4, R0
F41FFFF3 01F0 BNE R0, L$10
40A03925 01F4 SUBL/V I, 1, I
; R5, 1, R5
01F8 L$8:
; 000020
A742FFD0 01F8 LDQ R26, -48(R2)
221D0008 01FC LDA R16, 8(FP)
63FF0000 0200 TRAPB
47E03419 0204 MOV 1, R25
A762FFD8 0208 LDQ R27, -40(R2)
2FFE0000 020C UNOP
6B5A4000 0210 JSR R26, DBASIC$END
; R26, R26
63FF0000 0214 TRAPB
; 000012
47FD041E 0218 MOV FP, SP
A75D00C0 021C LDQ R26, 192(FP)
A45D00C8 0220 LDQ R2, 200(FP)
47E03400 0224 MOV 1, R0
; 000020
A47D00D0 0228 LDQ R3, 208(FP)
; 000012
A49D00D8 022C LDQ R4, 216(FP)
A4BD00E0 0230 LDQ R5, 224(FP)
A4DD00E8 0234 LDQ R6, 232(FP)
A7BD00F0 0238 LDQ FP, 240(FP)
23DE0100 023C LDA SP, 256(SP)
6BFA8001 0240 RET R26
2FFE0000 0244 UNOP
2FFE0000 0248 UNOP
2FFE0000 024C UNOP
0250 L$4:
; 000011
261F001B 0250 LDAH R16, 27(R31)
2210830C 0254 LDA R16, -31988(R16)
000000AA 0258 GENTRAP
025C L$5:
261F001B 025C LDAH R16, 27(R31)
221082CC 0260 LDA R16, -32052(R16)
000000AA 0264 GENTRAP

That is:
* roughly 2.5 times as many instructions (looks like
error handling is a part of those extras)
* STR$CONCAT does more work than DECC$STRCAT
* two extra calls for DBASIC$INIT and DBASIC$END

Arne

[Single Stage to Orbit]

On Thu, 2023-04-13 at 08:43 -0400, Arne Vajhøj wrote:
> And given the huge interest here in speculating about anything
> VMS related, then we are just guessing on why Perl came before
> Python.

"I was here first!"
--
Tactical Nuclear Kittens

[Jan-Erik Söderholm]

Are my post about standard-CGI vs. "loadable modules" lost?

[Arne Vajhøj]

> Are my post about standard-CGI vs. "loadable modules" lost?

No. It is there. And it is all true. CGI is not an efficient
method to run code.

But Neil wrote "python does a really good job supporting server-side
scripting under apache cgi-bin" and I assumed that to be correct
with "If both are run via CGI mechanism then script activation
should be the same". The assumption for all of the above is that
Python is being run via CGI similar to Basic.

If that is not the case, then we have a very good explanation.

Arne

[Arne Vajhøj]

On 4/13/2023 8:18 AM, Jan-Erik Söderholm wrote:
> Den 2023-04-13 kl. 12:44, skrev Neil Rieck:
>> And although python is used to do a lot of admin scripting on Linux
>> platforms (tools like "yum" and "firewall-cmd" are written in python),
>> python does a really good job supporting server-side scripting under
>> apache cgi-bin. I don't know how this is possible, but python programs
>> are faster than compiled DEC-BASIC programs started via apache.
>
> The performance depends a lot on if you are using standard Apache CGI
> or Apache "loadable modules". If you are just writing your own server
> apps, I guess they run as standard CGI (one process started per call).
> And I would expect Python to be available as a "loadable module". And
> that makes a big differnce, in particular on VMS with it's process
> creation overhead.
>
> Here are some figures for WASD and Apache.
> http://wasd.vsm.com.au/wasd_root/wasdoc/features/#11.2.scripting

It is well known that CGI is not suited for high performance. And has
been known so for 25+ years.

Note though that the numbers in that link are awfully low per modern
standards. Today tens of thousands of requests per second is expected.

(it is even possible to find benchmarks showing hundreds of thousands
and even millions of requests per second, but those are very special
cases)

> We are using Python 2 in the form of PyRTE (persisting processes) and
> have OK performance. First call (starting the Python process) does have
> a 1-2 sec overhead, but following calls are processes in fractions of a
> second (incl. Rdb processing).
>
> We are currently looking at writing our own persistent server processes
> to see if we can tweek the performance a bit more by using compiled
> code (Cobol, in our case).
>
> Using a test C application (just returns a timestamp to the browser, the
> reply time including starting the VMS process is 172 ms. Additional
> calls to the server with the process started are around 60 ms. As
> reported by
> the performance tools in Firefox.

Why not try something like Python Flask?

Arne

[Simon Clubley]

On 2023-04-13, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>

> I remember back when Perl, Python and Tcl was 3 equivalent choices
> for scripting.
>
> They evolved very different - Perl stayed where it was, Python became
> a widely used language and Tcl is practically dead.
>
> Why did Python become such a success while the other did not?
>
> My guess:
> - Python managed to get into education - not just CS like
> Perl but much broader
> - Python web approaches with Django etc. turned more future oriented
> than Perl CGI
> - Python got on the big data / analytics / ML / AI train
> and when that took off it pulled Python with it
>

Add:

- Python is an excellent way to add automation/scripting capabilities to
a wide range of applications.

Try doing the following with Perl: :-)

https://docs.blender.org/api/current/info_overview.html

Another example:

https://www.panda3d.org/

In this example, you can use either C++ and Python depending on your
requirements.

To compare the Python and C++ options:

https://docs.panda3d.org/1.10/python/index

Python has turned out to be a _really_ good way to provide a very
wide range of scripting functionality across the computing world
in general.

[Craig A. Berry]

On 4/14/23 7:19 AM, Simon Clubley wrote:
> On 2023-04-13, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>
>> I remember back when Perl, Python and Tcl was 3 equivalent choices
>> for scripting.
>>
>> They evolved very different - Perl stayed where it was, Python became
>> a widely used language and Tcl is practically dead.
>>
>> Why did Python become such a success while the other did not?
>>
>> My guess:
>> - Python managed to get into education - not just CS like
>> Perl but much broader

The P in Perl stands for "Practical." Larry Wall is a linguist, not a
computer scientist, and computer scientists can rarely be accused of
being practical :-). There have been books on such things as functional
programming in Perl but I don't think it was ever big with computer
scientists.

>> - Python web approaches with Django etc. turned more future oriented
>> than Perl CGI

The use of a web framework like Django has nothing to do with the
presence or absence of CGI. You can in fact run Django using CGI and
people used to do that. But for some time now you wouldn't because WSGI
is better. It's no different in the Perl world. While you can run Perl
scripts via CGI, today you'd be more like to use PSGI.

>> - Python got on the big data / analytics / ML / AI train
>> and when that took off it pulled Python with it
>>
>
> Add:
>
> - Python is an excellent way to add automation/scripting capabilities to
> a wide range of applications.
>
> Try doing the following with Perl: :-)
>
> https://docs.blender.org/api/current/info_overview.html

I saw the smiley, but what exactly is your point? That you can embed a
Python interpreter in another application? Perl has that capability
too, and has had for decades.

I'm not trying to start language war and I have a lot of respect for the
accomplishments of the Python community. But the capabilities of Python
aren't as unique as some people seem to think and probably haven't
played that big a role in its market dominance.

[Simon Clubley]

My point is that Python has a major thing going for it in that it is
relatively easy to learn and use by people who are not professional
programmers or professional sysadmins. At the same time, it's also
a very powerful tool for people who _are_ experts in these areas.

The two examples I gave were not by accident, especially Blender.

These are examples of programs used by people who are skilled in their
own areas of expertise, but who are not professional programmers or
sysadmins. Python is a relatively easy language for these people to
learn, which is one of the reasons it has really taken off in terms
of this application-level integration, and has also really helped to
drive Python use in general.

[bill]

On 4/14/2023 1:46 PM, Simon Clubley wrote:
>
>
> My point is that Python has a major thing going for it in that it is
> relatively easy to learn and use by people who are not professional
> programmers or professional sysadmins.

And if all there was to programming was syntax that might be a good
thing. But it isn't and having all these totally unqualified asses
writing "programs" is certainly not a good thing.

bill

[Arne Vajhøj]

On 4/14/2023 8:19 AM, Simon Clubley wrote:
> On 2023-04-13, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> Why did Python become such a success while the other did not?
>>
>> My guess:
>> - Python managed to get into education - not just CS like
>> Perl but much broader
>> - Python web approaches with Django etc. turned more future oriented
>> than Perl CGI
>> - Python got on the big data / analytics / ML / AI train
>> and when that took off it pulled Python with it
>
> Add:
>
> - Python is an excellent way to add automation/scripting capabilities to
> a wide range of applications.
>
> Try doing the following with Perl: :-)
>
> https://docs.blender.org/api/current/info_overview.html

It is possible to embed Perl as well.

I would say Perl and Python is similar in that regard.

https://docs.python.org/3/extending/embedding.html

https://perldoc.perl.org/perlembed

More prefer Python than Perl today though.

> Another example:
>
> https://www.panda3d.org/
>
> In this example, you can use either C++ and Python depending on your
> requirements.
>
> To compare the Python and C++ options:
>
> https://docs.panda3d.org/1.10/python/index

Having a scripting language utilize a C/C++ library
is also very standard.

Arne

[Arne Vajhøj]

On 4/14/2023 11:48 AM, Craig A. Berry wrote:
>
> On 4/14/23 7:19 AM, Simon Clubley wrote:
>> On 2023-04-13, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>>
>>> I remember back when Perl, Python and Tcl was 3 equivalent choices
>>> for scripting.
>>>
>>> They evolved very different - Perl stayed where it was, Python became
>>> a widely used language and Tcl is practically dead.
>>>
>>> Why did Python become such a success while the other did not?
>>>
>>> My guess:
>>> - Python managed to get into education - not just CS like
>>>     Perl but much broader
>
> The P in Perl stands for "Practical." Larry Wall is a linguist, not a
> computer scientist, and computer scientists can rarely be accused of
> being practical :-).  There have been books on such things as functional
> programming in Perl but I don't think it was ever big with computer
> scientists.

Maybe not big with Knuth style CS.

But it is my impression that practically all Perl users are
IT professionals. A lot of them with a CS degree even though
they may be more practical than academic.

And I would also call Larry Wall for a programmer even though
he did not study CS.

>>> - Python web approaches with Django etc. turned more future oriented
>>>     than Perl CGI
>
> The use of a web framework like Django has nothing to do with the
> presence or absence of CGI.  You can in fact run Django using CGI and
> people used to do that.  But for some time now you wouldn't because WSGI
> is better. It's no different in the Perl world.  While you can run Perl
> scripts via CGI, today you'd be more like to use PSGI.

I am not an expert in Django but a bit of googling indicate
that Django has never supported CGI and that they
deprecated/removed FastCGI support in 2014/2015. When Django
was invented 2005-2008 then CGI was already an obsolete technology.
All Django tutorials I can find do not use CGI or FastCGI.

I am sure there are other options than CGI for Perl (even I have
heard about mod_perl). And I am also sure that modern web
frameworks similar to Django has been created for Perl (Google
find Mojolicious).

But if you look at the web landscape today then Django and Flask
(on Python and not using CGI) are widely used and Perl is niche - and
a good chunk of that niche is 20+ years old CGI scripts.

Could Mojolicious and Perl had become widely used with Django and
Python as niche? Probably, but it did not happen.

Arne

[Simon Clubley]

That is a totally out of touch and _extremely_ elitist thing to say Bill.

We are talking about applications and areas that have skilled domain
knowledge experts, but who are not computer programmers. What you
appear to be saying is that these people are not allowed to use their
expertise until they become C or C++ experts.

Python is being used to allow these people to make full of their
specialised knowledge without having to learn C or C++.

Also, given the interactive nature of many of these applications, Python is
way more suited than C or C++ anyway, at least when it comes to initially
exploring a problem.

Besides, how would you even _use_ C or C++ as a scripting language
in (for example) Blender anyway ?

[bill]

On 4/17/2023 8:15 AM, Simon Clubley wrote:
> On 2023-04-14, bill <bill.gu...@gmail.com> wrote:
>> On 4/14/2023 1:46 PM, Simon Clubley wrote:
>>>
>>>
>>> My point is that Python has a major thing going for it in that it is
>>> relatively easy to learn and use by people who are not professional
>>> programmers or professional sysadmins.
>>
>> And if all there was to programming was syntax that might be a good
>> thing. But it isn't and having all these totally unqualified asses
>> writing "programs" is certainly not a good thing.
>>
>
> That is a totally out of touch and _extremely_ elitist thing to say Bill.

Really? Do you apply the same opinion to doctors? Lawyers?
The investment bankers handling your retirement money? How
about the mechanic who's going to work on your Tesla or Porsche?

There is much more to programming than just knowing the syntax
of a language.

>
> We are talking about applications and areas that have skilled domain
> knowledge experts, but who are not computer programmers. What you
> appear to be saying is that these people are not allowed to use their
> expertise until they become C or C++ experts.

No, what I am saying is they should be coordinating with someone
skilled in programming to get the job done. Remember a language
called Pilot? How about Hypertalk? These were going to take the
task of programming out of the hands of programmer and put it in
the hands of elementary school teachers. How'd that work out?

>
> Python is being used to allow these people to make full of their
> specialised knowledge without having to learn C or C++.

So you would be OK with the guy who fixes lawnmowers using his
"specialized skills" to fix your Cadilac Escalade? After all,
their both just devices with ICE.

>
> Also, given the interactive nature of many of these applications, Python is
> way more suited than C or C++ anyway, at least when it comes to initially
> exploring a problem.

Yeah, well, I don;'t agree with that either, but that is another
problem entirely.

>
> Besides, how would you even _use_ C or C++ as a scripting language
> in (for example) Blender anyway ?

Any task you can do with a scripting language you can do with a real
language. Picking the right language for the job is part of what used
to be software engineering. But then, if your not going to have an
engineer design and build your software. Let's apply that to other
tasks like bridges. I can build nice bridges with Lego blocks so I
should be able to design and build the next big highway bridge.


I really miss the days before software engineering when we had
domain specific languages and program were actually designed to
accomplish specific tasks. Oh wait, we have Agile now and there
is no longer a need for a design because reaching an endpoint is
no longer required.

bill

[Jan-Erik Söderholm]

Thinking that there exist an "end-point" is out of touch with
anything today. Applications are living creaturea and changes
all the time. There might be check-points that you reach and
pass on the way to the next requirements on the applications
but they will usually never be completely "finished".

This is also one reason that development and maintenance is now
going back from outsourcing companies to own resources. It is
easier to get a continuous maintenance with no specific endpoint.

[Dave Froble]

Gotta say, I'm 100% with Bill on this subject. Yes, the user knows what is
needed. But the user may not understand subtle issues. Case in point.

In CODIS we've provided what I'll call web services. May not meet Jan Erik's
definition of a web services, but they do the job. One allowed a socket
connection to inquire about inventory availability. Someone setting up a web
based "shopping cart" could invoke the service to get the availability of
products. Now, there is a bit of overhead in the inquiry. Ask for a socket
connection, do the handshake stuff, send the inquiry, receive the data, and then
break down the connection. One web "programmer" managed to just about drag the
entire application to a halt. He was looking for the availability of thousands
of products. And so issued thousands of connections. Lots of overhead. The
designer of the web service understood what could be needed, and set up the
design to allow thousands of products to be requested in one connection. Note,
this was well documented. However, the user didn't do the research, just did
what he needed, and didn't worry about the overall task. That's what happens
when some hacker who doesn't understand, or care about, the overall task throws
together something.

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

[Jan-Erik Söderholm]

OK. But that can happen no matter what tools the server was built with.
It is not that you should *only* use one or the other. Both compiled
apps for the high volume/high performance tasks and scripted things
does have there roles to play.

We have for many years used Python scripts for our web backend services.
Right now, I'm looking at, for one new and specific application, using
compiled Cobol apps instead. Just becuse we'd like to get the best
throughput possible for this specific application.

First POCs points to approx 50-60 ms roundtrip from the browser,
through the web server itself, to the separate web service process
and back again to the browser. That is an "empty" application without
the business logic just to check the overhead.

And yes, we got exactly the same figures with C and Cobol (as expected).

[Simon Clubley]

On 2023-04-17, bill <bill.gu...@gmail.com> wrote:
> On 4/17/2023 8:15 AM, Simon Clubley wrote:
>>
>> Besides, how would you even _use_ C or C++ as a scripting language
>> in (for example) Blender anyway ?
>
> Any task you can do with a scripting language you can do with a real
> language. Picking the right language for the job is part of what used
> to be software engineering. But then, if your not going to have an
> engineer design and build your software. Let's apply that to other
> tasks like bridges. I can build nice bridges with Lego blocks so I
> should be able to design and build the next big highway bridge.
>

Bill, there is a vast, vast, world out there that you are very clearly
unaware of. The act of typing a program into an editor, and then
compiling it into executable architecture-specific machine code from
a command line is only a small part of the computing world.

Do you even know what Blender is (for example) ?

Here is a link I posted previously:

https://docs.blender.org/api/current/info_overview.html

How exactly would you use C or C++ to do scripting in such an environment ?

>
> I really miss the days before software engineering when we had
> domain specific languages and program were actually designed to
> accomplish specific tasks. Oh wait, we have Agile now and there
> is no longer a need for a design because reaching an endpoint is
> no longer required.
>

In many ways, Python is effectively a domain specific language, but
due to the way the domain knowledge is implemented in Python, the
same language can be used in multiple areas.

From the above page:

|Here is a simple example which moves a vertex attached to an object named
|"Cube":
|
|import bpy
|bpy.data.objects["Cube"].data.vertices[0].co.x += 1.0
|
|This modifies Blender's internal data directly. When you run this in the
|interactive console you will see the 3D Viewport update.

How exactly is that not effectively a domain specific language ?

The same is true for all the other applications that have integrated
Python into them as a scripting and automation language.

[Scott Dorsey]

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2023-04-14, bill <bill.gu...@gmail.com> wrote:
>> On 4/14/2023 1:46 PM, Simon Clubley wrote:
>>>
>>> My point is that Python has a major thing going for it in that it is
>>> relatively easy to learn and use by people who are not professional
>>> programmers or professional sysadmins.
>>
>> And if all there was to programming was syntax that might be a good
>> thing. But it isn't and having all these totally unqualified asses
>> writing "programs" is certainly not a good thing.
>>
>
>That is a totally out of touch and _extremely_ elitist thing to say Bill.
>
>We are talking about applications and areas that have skilled domain
>knowledge experts, but who are not computer programmers. What you
>appear to be saying is that these people are not allowed to use their
>expertise until they become C or C++ experts.

I don't think it is elitist or out of touch at all.

25 years ago, those skilled domain knowledge experts would be sitting down
with a programmer and telling the programmer what they wanted, and the
programmer would be saying things like "Would it be okay if we did it in
THIS order because it would be faster?" and things like "If this value is
zero, it's not going to work, so will this ever be zero?" There would be
a team with the programmer and the subject matter expert.

Now more likely we have SMEs writing code and I hate to say it but this is
often a very very bad idea. "It's okay, I can use Matlab for the database
engine!" I wish I were joking about that but I am not.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Dave Froble]

On 4/17/2023 3:00 PM, Scott Dorsey wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>> On 2023-04-14, bill <bill.gu...@gmail.com> wrote:
>>> On 4/14/2023 1:46 PM, Simon Clubley wrote:
>>>>
>>>> My point is that Python has a major thing going for it in that it is
>>>> relatively easy to learn and use by people who are not professional
>>>> programmers or professional sysadmins.
>>>
>>> And if all there was to programming was syntax that might be a good
>>> thing. But it isn't and having all these totally unqualified asses
>>> writing "programs" is certainly not a good thing.
>>>
>>
>> That is a totally out of touch and _extremely_ elitist thing to say Bill.
>>
>> We are talking about applications and areas that have skilled domain
>> knowledge experts, but who are not computer programmers. What you
>> appear to be saying is that these people are not allowed to use their
>> expertise until they become C or C++ experts.
>
> I don't think it is elitist or out of touch at all.
>
> 25 years ago, those skilled domain knowledge experts would be sitting down
> with a programmer and telling the programmer what they wanted, and the
> programmer would be saying things like "Would it be okay if we did it in
> THIS order because it would be faster?" and things like "If this value is
> zero, it's not going to work, so will this ever be zero?" There would be
> a team with the programmer and the subject matter expert.

This is most of the problem. The hackers, Ok, SME, don't consider anything
except what they want to do.

Another simple example. A third party accepts and stores credit card
information, so vendors don't have to. Some web designer didn't know how to
query if the credit card info was already on file, so he just created a new
credit card entry for every usage. No problem for him. But, when a capable
person did an inquiry to see if the card was already on file, back came
thousands of the same CC #. Caused real problems, but not for the hacker.

> Now more likely we have SMEs writing code and I hate to say it but this is
> often a very very bad idea. "It's okay, I can use Matlab for the database
> engine!" I wish I were joking about that but I am not.
> --scott

Can be a very, very, very bad idea ...

[Arne Vajhøj]

On 4/17/2023 3:00 PM, Scott Dorsey wrote:

"shadow IT" is a real problem. Adhoc hacked code with no
development process that is impossible to maintain, contains security
vulnerabilities, performs poorly etc.etc..

But it is not all types of programming that requires a formal
development process.

Sure for the major application that are doing something important
and are expected to live for 10-20-30-40 years years, then it
should be a given.

But there are other types of programming:
* the finance person that need to automate some stuff
in Excel and do it in VBA
* the finance person that want to see how various
interest scenarios impact the budget and do it
in Python
* the sys admin that need to automate some processes
and do it in shell/Python
* the sys admin that need to move a lot of stuff around
as a one time thing and do it in shell/Python
* the data person that need to export a lot of data from
some data sources and load them into a DWH and do it
in Python
* the data science person that need to try out hundreds
of different forecast models to find the best model and
do it in Python/R/Matlab
etc.

In those cases the formal development process does not
make any sense. It takes too long time and cost too much
money.

Arne

[Arne Vajhøj]

On 4/17/2023 1:46 PM, Simon Clubley wrote:
> On 2023-04-17, bill <bill.gu...@gmail.com> wrote:
>> On 4/17/2023 8:15 AM, Simon Clubley wrote:
>>> Besides, how would you even _use_ C or C++ as a scripting language
>>> in (for example) Blender anyway ?
>>
>> Any task you can do with a scripting language you can do with a real
>> language. Picking the right language for the job is part of what used
>> to be software engineering. But then, if your not going to have an
>> engineer design and build your software. Let's apply that to other
>> tasks like bridges. I can build nice bridges with Lego blocks so I
>> should be able to design and build the next big highway bridge.
>
> Bill, there is a vast, vast, world out there that you are very clearly
> unaware of. The act of typing a program into an editor, and then
> compiling it into executable architecture-specific machine code from
> a command line is only a small part of the computing world.

True.

> Do you even know what Blender is (for example) ?
>
> Here is a link I posted previously:
>
> https://docs.blender.org/api/current/info_overview.html
>
> How exactly would you use C or C++ to do scripting in such an environment ?

I don't think there is anything preventing such a thing.

Someone would need to develop a C interpreter or use a
callable C compiler.

I have never heard about such for C, but I cannot see any technical
reasons why it would be impossible.

The reason that it has not been done is that C would be a terrible
language for that purpose.

An embedded scripting language:
* should be very high level / powerful aka lot of functionality
per line of code
* should not require any "how computers actually work" stuff, but
let the developers just express the desired logic without worrying
about data types, memory allocation and deallocation etc.

That is not C.

That is Python.

Arne

[Arne Vajhøj]

On 4/17/2023 8:39 AM, bill wrote:

> On 4/17/2023 8:15 AM, Simon Clubley wrote:
>> Besides, how would you even _use_ C or C++ as a scripting language
>> in (for example) Blender anyway ?
>
> Any task you can do with a scripting language you can do with a real
> language.  Picking the right language for the job is part of what used
> to be software engineering.  But then, if your not going to have an
> engineer design and build your software.  Let's apply that to other
> tasks like bridges.  I can build nice bridges with Lego blocks so I
> should be able to design and build the next big highway bridge.

"Picking the right language for the job" is exactly what it is
all about.

And the bridge analogy is perfect.

If you are to build a highway bridge, then you want an engineer to
design it, you want concrete that match some well defined specs,
you will use heavy equipment, you want skilled people to
operate the equipment etc..

But what if your wife ask you to make a cute 3 ft long 1 ft wide
bridge over a pond in your backyard.

Do you send for an engineer, trucks with concrete, heavy equipment and
a large crew?

Or do you drive to Home Depot or Lowes, pick up some lumber +
some stones + a few bags of concrete and do it yourself?

> I really miss the days before software engineering when we had
> domain specific languages and program were actually designed to
> accomplish specific tasks.  Oh wait, we have Agile now and there
> is no longer a need for a design because reaching an endpoint is
> no longer required.

Agile requires both architecture and design.

But only what is needed/warranted by the problem - not
what is mandated by some process.

Arne

[Arne Vajhøj]

On 4/17/2023 10:17 AM, Dave Froble wrote:
> Gotta say, I'm 100% with Bill on this subject.  Yes, the user knows what
> is needed.  But the user may not understand subtle issues.  Case in point.
>
> In CODIS we've provided what I'll call web services.  May not meet Jan
> Erik's definition of a web services, but they do the job.

In standard IT industry terminology "web service" is used for
text payloads transported over HTTP(S).

But I don't think your point depends on whether it is text over HTTP(S)
or binary over plain TCP.

>   One allowed a
> socket connection to inquire about inventory availability.  Someone
> setting up a web based "shopping cart" could invoke the service to get
> the availability of products.  Now, there is a bit of overhead in the
> inquiry.  Ask for a socket connection, do the handshake stuff, send the
> inquiry, receive the data, and then break down the connection.  One web
> "programmer" managed to just about drag the entire application to a
> halt.  He was looking for the availability of thousands of products.
> And so issued thousands of connections.  Lots of overhead.  The designer
> of the web service understood what could be needed, and set up the
> design to allow thousands of products to be requested in one
> connection.  Note, this was well documented.  However, the user didn't
> do the research, just did what he needed, and didn't worry about the
> overall task.  That's what happens when some hacker who doesn't
> understand, or care about, the overall task throws together something.

I have a very different take on that example.

If the service documentation said that an argument X
should be 10 characters, the client developer did not read
it and send 12 characters and as a result the server
crashed - then I assume we would agree that it was a
bad design/implementation of the server, because it
should check the length and handle invalid input.

But the overload situation is really the same. The
server should be prepared for a high request rate and
limit the request rate so the service could not bring
down the server.

If the first 10 of those 1000 requests took 50 ms each
and the rest took 500 ms each, then the client developer
would quickly start reading docs or ask someone.

So I think this is a case of the server side being
bad design.

There is a little extra twist here. If the service
had been a standard web service, then it would not
have been necessary to implement the request rate
limit in the service itself. Instead a setup like:

client--API gateway--service

could have been used and the API gateway could
do rate limiting defined in configuration (it could
also do caching, access control and other useful
stuff all defined in configuration).

Arne

[Arne Vajhøj]

On 4/17/2023 3:14 PM, Dave Froble wrote:
> On 4/17/2023 3:00 PM, Scott Dorsey wrote:
>> 25 years ago, those skilled domain knowledge experts would be sitting
>> down
>> with a programmer and telling the programmer what they wanted, and the
>> programmer would be saying things like "Would it be okay if we did it in
>> THIS order because it would be faster?" and things like "If this value is
>> zero, it's not going to work, so will this ever be zero?"  There would be
>> a team with the programmer and the subject matter expert.
>
> This is most of the problem.  The hackers, Ok, SME, don't consider
> anything except what they want to do.
>
> Another simple example.  A third party accepts and stores credit card
> information, so vendors don't have to.  Some web designer didn't know
> how to query if the credit card info was already on file, so he just
> created a new credit card entry for every usage.  No problem for him.
> But, when a capable person did an inquiry to see if the card was already
> on file, back came thousands of the same CC #.  Caused real problems,
> but not for the hacker.

Obviously a disaster design/implementation.

But usually it is the SME's problem if business rules are
not properly implemented.

Arne

PS: Having the credit card information even transient should be
sufficient to trigger PCI-DSS compliance requirements even
if persisted elsewhere.

[Dave Froble]

On 4/17/2023 9:43 PM, Arne Vajhøj wrote:
> On 4/17/2023 3:14 PM, Dave Froble wrote:
>> On 4/17/2023 3:00 PM, Scott Dorsey wrote:
>>> 25 years ago, those skilled domain knowledge experts would be sitting down
>>> with a programmer and telling the programmer what they wanted, and the
>>> programmer would be saying things like "Would it be okay if we did it in
>>> THIS order because it would be faster?" and things like "If this value is
>>> zero, it's not going to work, so will this ever be zero?" There would be
>>> a team with the programmer and the subject matter expert.
>>
>> This is most of the problem. The hackers, Ok, SME, don't consider anything
>> except what they want to do.
>>
>> Another simple example. A third party accepts and stores credit card
>> information, so vendors don't have to. Some web designer didn't know how to
>> query if the credit card info was already on file, so he just created a new
>> credit card entry for every usage. No problem for him. But, when a capable
>> person did an inquiry to see if the card was already on file, back came
>> thousands of the same CC #. Caused real problems, but not for the hacker.
>
> Obviously a disaster design/implementation.
>
> But usually it is the SME's problem if business rules are
> not properly implemented.

But the SME is only worried about what affects him. That's not enough.

> Arne
>
> PS: Having the credit card information even transient should be
> sufficient to trigger PCI-DSS compliance requirements even
> if persisted elsewhere.

This example was about a vendor selling PCI type of services. Why they let
multiple copies of a CC#, that's another story.

[Dave Froble]

But what's the problem of running ideas past some decent analysts? That assumes
said analysts will provide the time.

[Dave Froble]

That wasn't the issue.

> But the overload situation is really the same. The
> server should be prepared for a high request rate and
> limit the request rate so the service could not bring
> down the server.

The server performed adequately. It was the hacker who complained, and then we
had to look at what he was doing. Then we had to point him to the
documentation, which he hadn't read throughly. It was his stuff that was slow.

> If the first 10 of those 1000 requests took 50 ms each
> and the rest took 500 ms each, then the client developer
> would quickly start reading docs or ask someone.

You got it. Now try to get some of the hackers to actually read the docs.

> So I think this is a case of the server side being
> bad design.

No,it worked quite well.

> There is a little extra twist here. If the service
> had been a standard web service, then it would not
> have been necessary to implement the request rate
> limit in the service itself. Instead a setup like:

Guess you got a problem with apps that work quite well?

> client--API gateway--service
>
> could have been used and the API gateway could
> do rate limiting defined in configuration (it could
> also do caching, access control and other useful
> stuff all defined in configuration).

Same result, the hacker would have had poor performance.

[Arne Vajhøj]

> But what's the problem of running ideas past some decent analysts?  That
> assumes said analysts will provide the time.

Just time and money.

:-)

Arne

[Arne Vajhøj]

I know. But the issue sounded pretty similar.

>> But the overload situation is really the same. The
>> server should be prepared for a high request rate and
>> limit the request rate so the service could not bring
>> down the server.
>
> The server performed adequately.  It was the hacker who complained, and
> then we had to look at what he was doing.  Then we had to point him to
> the documentation, which he hadn't read throughly.  It was his stuff
> that was slow.

Ah. It was the client application that was "about drag the entire
application to a halt". I read it as the server application.

My mistake.

>> So I think this is a case of the server side being
>> bad design.
>
> No,it worked quite well.
>
>> There is a little extra twist here. If the service
>> had been a standard web service, then it would not
>> have been necessary to implement the request rate
>> limit in the service itself. Instead a setup like:
>
> Guess you got a problem with apps that work quite well?
>
>> client--API gateway--service
>>
>> could have been used and the API gateway could
>> do rate limiting defined in configuration (it could
>> also do caching, access control and other useful
>> stuff all defined in configuration).
>
> Same result, the hacker would have had poor performance.

I misunderstood the problem.

Arne

[Simon Clubley]

On 2023-04-17, Dave Froble <da...@tsoft-inc.com> wrote:
> On 4/17/2023 8:00 PM, Arne Vajhøj wrote:
>
>> There is a little extra twist here. If the service
>> had been a standard web service, then it would not
>> have been necessary to implement the request rate
>> limit in the service itself. Instead a setup like:
>
> Guess you got a problem with apps that work quite well?
>

Someone was able to bring it to its knees because they didn't read
the documentation. I wouldn't call that working well.

>> client--API gateway--service
>>
>> could have been used and the API gateway could
>> do rate limiting defined in configuration (it could
>> also do caching, access control and other useful
>> stuff all defined in configuration).
>
> Same result, the hacker would have had poor performance.
>

But everyone else would have had a functional (if slow) server to connect to.

Arne is absolutely correct here. In a server application, you should always
aim to be the one in control of the situation, which means you don't enforce
it in the documentation, you enforce it in the server application.

BTW, when it comes to rate limiting based on general server load instead
of a raw number of connections, has VMS made any progress towards providing
an ongoing load average and making that information available to server
applications ?

That's one thing in Unix which is very useful and which is also easily
available to programs.

[Simon Clubley]

On 2023-04-18, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>
> I misunderstood the problem.
>

I'm not convinced you did. The client still managed to open 1000s of
connections based on David's description. That's exactly where
server-enforced rate limiting should have kicked in.

[Dave Froble]

Well, maybe I don't explain things well enough ...

:-)

[Dave Froble]

On 4/18/2023 8:17 AM, Simon Clubley wrote:
> On 2023-04-18, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>
>> I misunderstood the problem.
>>
>
> I'm not convinced you did. The client still managed to open 1000s of
> connections based on David's description. That's exactly where
> server-enforced rate limiting should have kicked in.
>
> Simon.
>

Ok, probably not explained well by me.

The response time for clients using the web server was poor, to say the least.
The server(s) had no problem. The hacker first tried to blame the server(s),
because it took so long to load all the product info. That's when we were
called in. But our logs showed the server was processing connection requests
just fine. The logs also showed the volume of connection requests, and that's
when we took a look at what the hacker was doing, and pointed him at the docs.

Once the hacker batched his requests, ie; included all products in one
connection request, his application worked fine.

So, the problem was the hacker not researching his solution adequately. That
gets back to the concept of "gee, it sure would be nice if he knew what he was
doing". A "real programmer" would have considered things a bit better.

[Scott Dorsey]

=?UTF-8?Q?Arne_Vajh=c3=b8j?= <ar...@vajhoej.dk> wrote:
>On 4/17/2023 3:00 PM, Scott Dorsey wrote:
>> Now more likely we have SMEs writing code and I hate to say it but this is
>> often a very very bad idea. "It's okay, I can use Matlab for the database
>> engine!" I wish I were joking about that but I am not.
>
>"shadow IT" is a real problem. Adhoc hacked code with no
>development process that is impossible to maintain, contains security
>vulnerabilities, performs poorly etc.etc..
>
>But it is not all types of programming that requires a formal
>development process.
>
>Sure for the major application that are doing something important
>and are expected to live for 10-20-30-40 years years, then it
>should be a given.

I'm not talking about a formal development process with structured
walkthroughs and unit tests and descriptions of the expected use across
the software lifecycle.

I'm talking about having skilled programmers writing code, sitting next to
and working with subject matter experts. Instead of the SMEs writing something
up in Matlab and then wondering why it is so slow and doesn't always work.

>But there are other types of programming:
>* the finance person that need to automate some stuff
> in Excel and do it in VBA
>* the finance person that want to see how various
> interest scenarios impact the budget and do it
> in Python
>* the sys admin that need to automate some processes
> and do it in shell/Python
>* the sys admin that need to move a lot of stuff around
> as a one time thing and do it in shell/Python
>* the data person that need to export a lot of data from
> some data sources and load them into a DWH and do it
> in Python
>* the data science person that need to try out hundreds
> of different forecast models to find the best model and
> do it in Python/R/Matlab

Yes, these people should have a Python/R/Matlab expert on hand instead of
going it alone.

[Arne Vajhøj]

On 4/18/2023 1:21 PM, Scott Dorsey wrote:

> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <ar...@vajhoej.dk> wrote:
>> But there are other types of programming:
>> * the finance person that need to automate some stuff
>> in Excel and do it in VBA
>> * the finance person that want to see how various
>> interest scenarios impact the budget and do it
>> in Python
>> * the sys admin that need to automate some processes
>> and do it in shell/Python
>> * the sys admin that need to move a lot of stuff around
>> as a one time thing and do it in shell/Python
>> * the data person that need to export a lot of data from
>> some data sources and load them into a DWH and do it
>> in Python
>> * the data science person that need to try out hundreds
>> of different forecast models to find the best model and
>> do it in Python/R/Matlab
>
> Yes, these people should have a Python/R/Matlab expert on hand instead of
> going it alone.

I find it very difficult to imagine such a setup.

Arne

[Arne Vajhøj]

On 4/14/2023 7:22 PM, Arne Vajhøj wrote:
> On 4/14/2023 8:19 AM, Simon Clubley wrote:
>> - Python is an excellent way to add automation/scripting capabilities to
>> a wide range of applications.
>>
>> Try doing the following with Perl: :-)
>>
>> https://docs.blender.org/api/current/info_overview.html
>
> It is possible to embed Perl as well.
>
> I would say Perl and Python is similar in that regard.
>
> https://docs.python.org/3/extending/embedding.html
>
> https://perldoc.perl.org/perlembed

Of course JSR 223 is pretty cool in this regard.

import javax.script.ScriptEngine;
import javax.script.ScriptEngineManager;
import javax.script.ScriptException;

public class EmbeddedScript {
public static void test(String language, String source) throws
ScriptException {
System.out.println(language + ":");
System.out.print(source);
ScriptEngineManager sem = new ScriptEngineManager();
ScriptEngine se = sem.getEngineByName(language);
se.eval(source);
}
public static void main(String[] args) throws ScriptException {
test("javascript", "for(i = 0; i < 3; i++) {\r\n" +
" print(\"Hi from JavaScript!\")\r\n" +
"}\r\n");
test("python", "for i in range(3):\r\n" +
" print(\"Hi from Python!\")\r\n");
test("ruby", "for i in 1..3 do\r\n" +
" puts 'Hi from Ruby!'\r\n" +
"end\r\n");
test("php", "<?php\r\n" +
"for($i = 0; $i < 3; $i++) {\r\n" +
" echo \"Hi from PHP!\\r\\n\";\r\n" +
"}\r\n" +
"?>\r\n");
test("groovy", "for(i in 1..3) {\r\n" +
" println \"Hi from Groovy!\"\r\n" +
"}\r\n");
test("perl", "for(1..3) {\r\n" +
" print(\"Hi from Perl!\\n\");\r\n" +
"}\r\n");
test("lua", "for i = 1,3\r\n" +
"do\r\n" +
" print(\"Hi from Lua!\")\r\n" +
"end\r\n");
test("Lisp", "(dotimes (n 3)\r\n" +
" (format t \"Hi from Lisp!~%\"))\r\n");
test("tcl", "for {set i 0} {$i < 3} {incr i} {\r\n" +
" puts \"Hi from Tcl!\"\r\n" +
"}\r\n");
}
}

outputs:

javascript:
for(i = 0; i < 3; i++) {
print("Hi from JavaScript!")
}
Hi from JavaScript!
Hi from JavaScript!
Hi from JavaScript!
python:
for i in range(3):
print("Hi from Python!")
Hi from Python!
Hi from Python!
Hi from Python!
ruby:
for i in 1..3 do
puts 'Hi from Ruby!'
end
Hi from Ruby!
Hi from Ruby!
Hi from Ruby!
php:
<?php
for($i = 0; $i < 3; $i++) {
echo "Hi from PHP!\r\n";
}
?>
Hi from PHP!
Hi from PHP!
Hi from PHP!
groovy:
for(i in 1..3) {
println "Hi from Groovy!"
}
Hi from Groovy!
Hi from Groovy!
Hi from Groovy!
perl:
for(1..3) {
print("Hi from Perl!\n");
}
Hi from Perl!
Hi from Perl!
Hi from Perl!
lua:
for i = 1,3
do
print("Hi from Lua!")
end
Hi from Lua!
Hi from Lua!
Hi from Lua!
Lisp:
(dotimes (n 3)
(format t "Hi from Lisp!~%"))
Hi from Lisp!
Hi from Lisp!
Hi from Lisp!
tcl:
for {set i 0} {$i < 3} {incr i} {
puts "Hi from Tcl!"
}
Hi from Tcl!
Hi from Tcl!
Hi from Tcl!

PS: You need ABCL, GHroovy, JACL, JRuby, LuaJ, Perlito5 and Quercus
in classpath.

PPS: Some of the script code may not be optimal - I am not
familiar with all the languages.

PPPS: everything is pure Java and should run fine on VMS Itanium
and in the future VMS x86-64 (Java 1.5 on VMS Alpha is too old
for some of these).

Arne

[Craig A. Berry]

Seems odd to omit BeanShell from a list of embedded scripting
capabilities based on Java:

<https://github.com/beanshell/beanshell>


I think Java people often prefer to do their scripting in a subset of
Java rather than some other language.

[Arne Vajhøj]

> Seems odd to omit BeanShell from a list of embedded scripting
> capabilities based on Java:
>
> <https://github.com/beanshell/beanshell>
>
> I think Java people often prefer to do their scripting in a subset of
> Java rather than some other language.

BeanShell is probably the most common scripting language
in Java and it supposedly supports JSR 223.

But I could not get it working. Neither 2.0b4 or 2.0b5
worked with JSR 223 call.

And 2.0b6 docs said:

<quote>
BeanShell 2.0b6 is a security update that is functionally equivalent to
the previous version 2.0b5.

No other functionality has changed since 2.0b5, but this is a
recommended update for all BeanShell users, as it fixes a remote code
execution vulnerability.
</quote>

But guess what - it works with 2.0b6!

So:

test("beanshell", "for(int i = 0; i < 3; i++) {\r\n" +
" System.out.println(\"Hi from
BeanShell!\");\r\n"+
"}\r\n");

beanshell:
for(int i = 0; i < 3; i++) {
System.out.println("Hi from BeanShell!");
}
Hi from BeanShell!
Hi from BeanShell!
Hi from BeanShell!

Arne

[Craig A. Berry]

On 4/20/23 6:54 PM, Arne Vajhøj wrote:
> On 4/20/2023 7:29 AM, Craig A. Berry wrote:


>> Seems odd to omit BeanShell from a list of embedded scripting
>> capabilities based on Java:
>>
>> <https://github.com/beanshell/beanshell>
>>
>> I think Java people often prefer to do their scripting in a subset of
>> Java rather than some other language.
>
> BeanShell is probably the most common scripting language
> in Java and it supposedly supports JSR 223.
>
> But I could not get it working. Neither 2.0b4 or 2.0b5
> worked with JSR 223 call.

Dunno. I've used things that use it but never tried using it directly.
In any case the current release is 2.1.1 and the README says, "The
only reccomended [sic] version is a manual build of the master branch."
So when in doubt, try what's current and/or recommended.

[Chris Townley]

On 21/04/2023 14:31, Arne Vajhøj wrote:
>
> Getting abcl (lisp) working was really random luck.
>
> :-)

Is Lisp still used these days?

--
Chris

[Arne Vajhøj]

ABCL (Common Lisp on JVM and actually able to run on VMS)
is actively maintained.

And I believe there are several other Lisp implementations
that are not EOL.

That said then I do believe that Lisp is very much
niche today.

And I can clearly state that I am totally ignorant
about Lisp.

:-)

Arne

PS: Back in the 10's there was actually a Lisp dialect
for JVM (Clojure) that was pretty "hot" in the press.

[Scott Dorsey]

=?UTF-8?Q?Arne_Vajh=c3=b8j?= <ar...@vajhoej.dk> wrote:
>On 4/21/2023 10:51 AM, Chris Townley wrote:
>> On 21/04/2023 14:31, Arne Vajhøj wrote:
>>> Getting abcl (lisp) working was really random luck.
>>>
>>> :-)
>>
>> Is Lisp still used these days?
>
>ABCL (Common Lisp on JVM and actually able to run on VMS)
>is actively maintained.
>
>And I believe there are several other Lisp implementations
>that are not EOL.

I think most folks using lisp under VMS are using xlisp. Which builds nicely
under VMS and a whole lot of other operating systems, and is pleasantly
common-lisp compatible if you like that sort of thing.

[Simon Clubley]

On 2023-04-21, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> On 4/21/2023 10:51 AM, Chris Townley wrote:
>>
>> Is Lisp still used these days?
>

In Emacs. Unfortunately. :-(

What a bloody horrible monstrosity of a language. :-(

I wish they had used something else for Emacs. Anything else.

>
> And I can clearly state that I am totally ignorant
> about Lisp.
>

Lucky you...

[Arne Vajhøj]

On 4/21/2023 1:09 PM, Simon Clubley wrote:
> On 2023-04-21, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 4/21/2023 10:51 AM, Chris Townley wrote:
>>> Is Lisp still used these days?
>
> In Emacs. Unfortunately. :-(
>
> What a bloody horrible monstrosity of a language. :-(
>
> I wish they had used something else for Emacs. Anything else.

I am sure a lot of people agree.

But what were the alternatives when Emacs Lisp was
created?

Emacs Basic?

Arne

[Arne Vajhøj]

https://github.com/dbetz/xlisp

?

Arne

[Rich Alderson]

=?UTF-8?Q?Arne_Vajh=c3=b8j?= <ar...@vajhoej.dk> writes:

> On 4/21/2023 1:09 PM, Simon Clubley wrote:

>> On 2023-04-21, Arne Vajhøj <ar...@vajhoej.dk> wrote:

>>> On 4/21/2023 10:51 AM, Chris Townley wrote:

>>>> Is Lisp still used these days?

>> In Emacs. Unfortunately. :-(

>> What a bloody horrible monstrosity of a language. :-(

ITYM "what a wonderfully polymorphic language capable of expressing multiple
programming paradigms at once". ;-)

>> I wish they had used something else for Emacs. Anything else.

> I am sure a lot of people agree.

> But what were the alternatives when Emacs Lisp was created?

> Emacs Basic?

EMACS began life as a library of macros for the MIT AI Lab's dialect of TECO
for the PDP-10. (TECO itself was written in MIDAS, a powerful macro assembler
that originated on the PDP-6.) Initially, a real time editing feature was
added, and several hackers created small libraries of their own favorite
macros, then a hacker named Richard Stallman gathered up all those libraries,
eliminated duplicates and rationalized the implementation, and released the
result to the community.

EMACS was ported from the ITS operating system on their PDP-10s to TENEX
(ancestral to TOPS-20) by porting TECO there.

EMACS was also ported to Multics on the Honeywell 6180 processor at the MIT
Laboratory for Computer Science, but not by porting TECO. Instead, the MACLISP
dialect of LISP, another creation of the AI Lab, had already been ported to
Multics, so that was used as the base language for the EMACS port.

Meanwhile, an editor with the capabilities of EMACS was desired for the Lisp
machines being created by the AI Lab, so taking their cue from the Multics port
two Lisp based editors, EINE ("EINE Is Not EMACS") and ZWEI ("ZWEI Was EINE
Initially"), were created.

By now, Stallman was interested in creating an unburdened operating system for
exotic hardware (like VAXes and SUNs), and needed an editor, so he ported the
underlying Lisp and established an Emacs on top.

There might have been alternatives, but why fuck with a good thing?

--
Rich Alderson ne...@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

[Scott Dorsey]

In article <u1ugra$2r211$2...@dont-email.me>,

Yes. Builds on just about anything. Pretty well supported. Suited for
embedded systems if you're into that kind of thing.

[Lars Brinkhoff]

Rich Alderson wrote:
> Meanwhile, an editor with the capabilities of EMACS was desired for
> the Lisp machines being created by the AI Lab, so taking their cue
> from the Multics port two Lisp based editors, EINE ("EINE Is Not
> EMACS") and ZWEI ("ZWEI Was EINE Initially"), were created.

Minor correction: EINE was create in 1977, before Multics Emacs was
started in 1978.

[Po Lu]

BTW, GNU Emacs once worked on VMS. However, the code was deleted when
it seemed that HP was about to give up on VMS entirely.

Since VMS is alive again, would anyone like to step up to resurrect the
old port?

[Arne Vajhøj]

On 4/22/2023 1:13 AM, Po Lu wrote:
> BTW, GNU Emacs once worked on VMS. However, the code was deleted when
> it seemed that HP was about to give up on VMS entirely.
>
> Since VMS is alive again, would anyone like to step up to resurrect the
> old port?

Version 21.2 is on the freeware CD.

https://www.digiater.nl/openvms/freeware/v80/emacs/

Latest is supposedly 28.2 so 7 major versions difference, but maybe
those versions did not add so much OS specific.

Arne

[Scott Dorsey]

In article <u20kg3$3977v$1...@dont-email.me>,

Again, I believe these don't know anything about file structure and so
everything is treated as stream_lf.

[Rich Alderson]

Good to know. I never saw EINE, only ZWEI on the Symbolics 3600, but used the
Multics port extensively for a project at UChicago.

[Rich Alderson]

Rich Alderson <ne...@alderson.users.panix.com> writes:

[ snip a whole bunch of stuff ]

I suppose I should have included my bona fides, in the form of my .sig post 1999:

| Rich Alderson Last LOTS Tops-20 Systems Programmer, 1984-1991
| Current maintainer, MIT TECO EMACS (v. 170)
| last name @ XKL dot COM Customer Interface, XKL LLC

[h47...@gmail.com]

On Saturday, April 22, 2023 at 6:58:34 PM UTC+2, Scott Dorsey wrote:
> >Version 21.2 is on the freeware CD.
> >
> >https://www.digiater.nl/openvms/freeware/v80/emacs/
> >
> >Latest is supposedly 28.2 so 7 major versions difference, but maybe
> >those versions did not add so much OS specific.
> Again, I believe these don't know anything about file structure and so
> everything is treated as stream_lf.
> --scott

There is probably more gone than just the support for VMS record formats. And yes, emacs for VMS created files with variable length format. But I can imagine that nowadays some people prefer that editors on VMS create stream_lf files.

[Arne Vajhøj]

On 4/22/2023 5:16 PM, h...@end.of.inter.net wrote:
> On Saturday, April 22, 2023 at 6:58:34 PM UTC+2, Scott Dorsey wrote:
>>> Version 21.2 is on the freeware CD.
>>>
>>> https://www.digiater.nl/openvms/freeware/v80/emacs/
>>>
>>> Latest is supposedly 28.2 so 7 major versions difference, but
>>> maybe those versions did not add so much OS specific.
>> Again, I believe these don't know anything about file structure and
>> so everything is treated as stream_lf.
>

> There is probably more gone than just the support for VMS record
> formats. And yes, emacs for VMS created files with variable length
> format. But I can imagine that nowadays some people prefer that
> editors on VMS create stream_lf files.

My point was that if someone took the 28.2 source and
put back all the #ifdef vms code from 21.2 then what would
be missing? How much of the new stuff added would require
new #ifdef vms code?

I don't think I have played with GNU Emacs since VMS VAX
days (early 90's) and I have no idea about what has been added
to GNU Emacs the last few decades, but I am sort of guessing
that the new stuff would be most "edit stuff" and not
so much "system interface stuff". Of course I could
be totally wrong.

Arne

[Lars Brinkhoff]

Rich Alderson wrote:
> Good to know. I never saw EINE, only ZWEI on the Symbolics 3600, but
> used the Multics port extensively for a project at UChicago.

I gather EINE was a somewhat short lived affair in the early days of
CADR development, and few people would have seen it. I see files for an
unnamed editor going back to early 1977. The name EINE officially
appeared August that year. I previouly never looked into it, but now
that I check it seems the ZWEI project was started late 1978. This is
from a November 1978 message by Weinreb:

"ZWEI is the second version of EINE, of course. It stands for Zwei
Was Eine Initially. It is a complete rewrite for about six reasons
which I will type in one of these days. It wan't announced in mail
because everyone here heard about it by word of mouth.

[h47...@gmail.com]

On Sunday, April 23, 2023 at 1:31:32 AM UTC+2, Arne Vajhøj wrote:
> My point was that if someone took the 28.2 source and
> put back all the #ifdef vms code from 21.2 then what would
> be missing? How much of the new stuff added would require
> new #ifdef vms code?
>
> I don't think I have played with GNU Emacs since VMS VAX
> days (early 90's) and I have no idea about what has been added
> to GNU Emacs the last few decades, but I am sort of guessing
> that the new stuff would be most "edit stuff" and not
> so much "system interface stuff". Of course I could
> be totally wrong.

The sources on the freeware cd are said to be based on Emacs 21.2. The files in the EMACS21_2.ZIP archive are a snapshot of a development environment. I could not find these changes in the Emacs sources and could not find the Emacs sources on which this development environment is based. But that may be my fault not trying harder. There may be changes in Emacs which make the known VMS code obsolete or require new VMS specific code. It seems a lot of work to get VMS support back into the current Emacs sources. How many users are there which want/need a current version of Emacs?

Using that development environment it's possible to build Emacs for x86. (The IA64 additions in EMACS21_2_IVMS.ZIP can be ignored; they deal with IA64 specifics especially with Short Data.) I did that some time ago. There were minor run-time problems. At that time it was not obvious what caused them: a build problem with the cross tools environment, exception handling, ...? I should try a(nother) native build.

I used MMK for the builds. A few steps to build Emacs are better done on the target platform. MMK for x86 needed a couple of changes. I didn't put them back to https://github.com/endlesssoftware/mmk. But I just noticed a pull request, which probably describes similar changes to build MMK for x86.

[Arne Vajhøj]

I had to try build.

Something like:

$ cre/dir [.bin]
$ cre/dir [.lib]
$ cflags="/include=[-.include]/names=as_is"
$ set def [.src]
$ cc'cflags' unstuff
$ cc'cflags' xlansi
$ cc'cflags' xlapi
$ cc'cflags' xlcobj
$ cc'cflags' xlcom
$ cc'cflags' xldbg
$ cc'cflags' xldmem
$ cc'cflags' xlfasl
$ cc'cflags' xlftab
$ cc'cflags' xlfun1
$ cc'cflags' xlfun2
$ cc'cflags' xlfun3
$ cc'cflags' xlimage
$ cc'cflags' xlinit
$ cc'cflags' xlint
$ cc'cflags' xlio
$ cc'cflags' xlmain
$ cc'cflags' xlitersq
$ cc'cflags' xlmath
$ cc'cflags' xlobj
$ cc'cflags' xlosint
$ cc'cflags' xlprint
$ cc'cflags' xlread
$ cc'cflags' xlsym
$ libr/obj/crea [-.lib]xlisp *.obj
$ set def [-]
$ set def [.xlisp]
$ cc'cflags' xlisp
$ link/exe=[-.bin]xlisp.exe xlisp + [-.lib]xlisp/lib
$ exit

?

And I get a bunch of %CC-I-RIGHTSHIFTOVR due to:

/* xwrlonghf - built-in function 'write-long-high-first' */
xlValue xwrlonghf(void)
{
short int val;
xlValue fptr,v;
v = xlGetArgFixnum(); val = (short int)xlGetFixnum(v);
fptr = xlMoreArgsP() ? xlGetOutputPort() : xlCurOutput();
xlLastArg();
xlPutC(fptr,(val >> 24) & 0xff);
xlPutC(fptr,(val >> 16) & 0xff);
xlPutC(fptr,(val >> 8) & 0xff);
xlPutC(fptr,val & 0xff);
return xlTrue;
}

/* xwrlonglf - built-in function 'write-long-low-first' */
xlValue xwrlonglf(void)
{
short int val;
xlValue fptr,v;
v = xlGetArgFixnum(); val = (short int)xlGetFixnum(v);
fptr = xlMoreArgsP() ? xlGetOutputPort() : xlCurOutput();
xlLastArg();
xlPutC(fptr,val & 0xff);
xlPutC(fptr,(val >> 8) & 0xff);
xlPutC(fptr,(val >> 16) & 0xff);
xlPutC(fptr,(val >> 24) & 0xff);
return xlTrue;
}

which seems to assume that short int is 32 bit.

Arne

[Arne Vajhøj]

So 21.2 will build on all VMS incl. x86-64, but porting VMS changes to
28.2 may be a lot of work because it is not a clean diff from
standard 21.2.

> I used MMK for the builds. A few steps to build Emacs are better done
> on the target platform. MMK for x86 needed a couple of changes. I
> didn't put them back to https://github.com/endlesssoftware/mmk. But I
> just noticed a pull request, which probably describes similar changes
> to build MMK for x86.

We need MMK on VMS x86-64.

:-)

Arne

[Craig A. Berry]

We have it, or at least will have it when Tim resurfaces and merges my
PR that hb alluded to:

<https://github.com/endlesssoftware/mmk/pull/101>

If anyone notices anything I forgot, feel free to comment there. I
wasn't thrilled about turning off warnings to build the MACRO module:

<https://github.com/endlesssoftware/mmk/pull/101/commits/f6dac868a9a2735ab0f253637e4e5602d203fa1a>

but I don't do MACRO and this seemed like the quickest, safest solution.

[Single Stage to Orbit]

On Sun, 2023-04-23 at 09:39 -0400, Arne Vajhøj wrote:


> We need MMK on VMS x86-64.

MMS is available.
--
Tactical Nuclear Kittens

[Arne Vajhøj]

On 4/23/2023 11:03 AM, Single Stage to Orbit wrote:
> On Sun, 2023-04-23 at 09:39 -0400, Arne Vajhøj wrote:
>> We need MMK on VMS x86-64.
>
> MMS is available.

I believe VMS needs options not just one of each.

Arne

[Craig A. Berry]

On 4/23/23 10:03 AM, Single Stage to Orbit wrote:
> On Sun, 2023-04-23 at 09:39 -0400, Arne Vajhøj wrote:
>
>
>> We need MMK on VMS x86-64.
>
> MMS is available.

If you are a hobbyist or are able/willing to pay extra for the license.

[Simon Clubley]

On 2023-04-21, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> On 4/21/2023 1:09 PM, Simon Clubley wrote:
>> On 2023-04-21, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>> On 4/21/2023 10:51 AM, Chris Townley wrote:
>>>> Is Lisp still used these days?
>>
>> In Emacs. Unfortunately. :-(
>>
>> What a bloody horrible monstrosity of a language. :-(
>>
>> I wish they had used something else for Emacs. Anything else.
>
> I am sure a lot of people agree.
>
> But what were the alternatives when Emacs Lisp was
> created?
>
> Emacs Basic?
>

That would have been better. :-)

ALGOL/Pascal/etc was also in use by the mid 1970s, so perhaps they could
have created a runtime embedded language based around those general concepts.

But no, Lisp was what they knew, so Lisp is what it was, even in the mid
1980s when GNU Emacs was created and Lisp was way obsolete by that point. :-(

[Simon Clubley]

On 2023-04-21, Rich Alderson <ne...@alderson.users.panix.com> wrote:
>=?UTF-8?Q?Arne_Vajh=c3=b8j?= <ar...@vajhoej.dk> writes:
>
>> On 4/21/2023 1:09 PM, Simon Clubley wrote:
>
>>> On 2023-04-21, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>
>>>> On 4/21/2023 10:51 AM, Chris Townley wrote:
>
>>>>> Is Lisp still used these days?
>
>>> In Emacs. Unfortunately. :-(
>
>>> What a bloody horrible monstrosity of a language. :-(
>
> ITYM "what a wonderfully polymorphic language capable of expressing multiple
> programming paradigms at once". ;-)
>

You are in a maze of nested brackets, all alike.

If you try to understand them, your mind is likely to be eaten by a grue.

:-)

[Arne Vajhøj]

On 4/24/2023 8:16 AM, Simon Clubley wrote:
> On 2023-04-21, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 4/21/2023 1:09 PM, Simon Clubley wrote:
>>> On 2023-04-21, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>>> On 4/21/2023 10:51 AM, Chris Townley wrote:
>>>>> Is Lisp still used these days?
>>>
>>> In Emacs. Unfortunately. :-(
>>>
>>> What a bloody horrible monstrosity of a language. :-(
>>>
>>> I wish they had used something else for Emacs. Anything else.
>>
>> I am sure a lot of people agree.
>>
>> But what were the alternatives when Emacs Lisp was
>> created?
>>
>> Emacs Basic?
>
> That would have been better. :-)
>
> ALGOL/Pascal/etc was also in use by the mid 1970s, so perhaps they could
> have created a runtime embedded language based around those general concepts.
>
> But no, Lisp was what they knew, so Lisp is what it was, even in the mid
> 1980s when GNU Emacs was created and Lisp was way obsolete by that point. :-(

There are a few options. But only like 1/10 th of what is today.

But yes they could have created something Pascal like.

DEC did!!

EVE with TPU in 1986.

(TPU is very Pascal like)

Arne

[Andreas Eder]

On Fr 21 Apr 2023 at 11:14, Arne Vajhøj <ar...@vajhoej.dk> wrote:

> On 4/21/2023 10:51 AM, Chris Townley wrote:

>> On 21/04/2023 14:31, Arne Vajhøj wrote:
>>> Getting abcl (lisp) working was really random luck.
>>>
>>> :-)

>> Is Lisp still used these days?
>

> ABCL (Common Lisp on JVM and actually able to run on VMS)
> is actively maintained.
>
> And I believe there are several other Lisp implementations
> that are not EOL.

Yes, certainly!

a) open source common lisp
sbcl https://www.sbcl.org/ the fastest open source implementation

ecl https://ecl.common-lisp.dev/ an embeddabale lisp

clisp https://clisp.sourceforge.io/

abcl https://armedbear.common-lisp.dev/ runs on the jvm

clozure https://ccl.clozure.com/

b) commercial common lisp
allegro https://franz.com/products/allegro-common-lisp/

lispworks http://www.lispworks.com/

> PS: Back in the 10's there was actually a Lisp dialect
> for JVM (Clojure) that was pretty "hot" in the press.

That is not common lisp, but still a good lisp for the jvm.

'Andreas

[Andreas Eder]

On Fr 21 Apr 2023 at 17:00, klu...@panix.com (Scott Dorsey) wrote:

> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <ar...@vajhoej.dk> wrote:
>>On 4/21/2023 10:51 AM, Chris Townley wrote:

>>> On 21/04/2023 14:31, Arne Vajhøj wrote:
>>>> Getting abcl (lisp) working was really random luck.
>>>>
>>>> :-)
>>>
>>> Is Lisp still used these days?
>>
>>ABCL (Common Lisp on JVM and actually able to run on VMS)
>>is actively maintained.
>>
>>And I believe there are several other Lisp implementations
>>that are not EOL.
>

> I think most folks using lisp under VMS are using xlisp. Which builds nicely
> under VMS and a whole lot of other operating systems, and is pleasantly
> common-lisp compatible if you like that sort of thing.

Compared to a real common lisp xlisp is just a toy.

'Andreas

[Andreas Eder]

On Fr 21 Apr 2023 at 16:31, Rich Alderson <ne...@alderson.users.panix.com> wrote:

> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <ar...@vajhoej.dk> writes:
>
>> On 4/21/2023 1:09 PM, Simon Clubley wrote:
>

>>> On 2023-04-21, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>
>>>> On 4/21/2023 10:51 AM, Chris Townley wrote:
>
>>>>> Is Lisp still used these days?
>
>>> In Emacs. Unfortunately. :-(
>
>>> What a bloody horrible monstrosity of a language. :-(
>
> ITYM "what a wonderfully polymorphic language capable of expressing multiple
> programming paradigms at once". ;-)

+1

>
>>> I wish they had used something else for Emacs. Anything else.
>
>> I am sure a lot of people agree.
>
>> But what were the alternatives when Emacs Lisp was created?
>
>> Emacs Basic?
>
> EMACS began life as a library of macros for the MIT AI Lab's dialect of TECO
> for the PDP-10. (TECO itself was written in MIDAS, a powerful macro assembler
> that originated on the PDP-6.) Initially, a real time editing feature was
> added, and several hackers created small libraries of their own favorite
> macros, then a hacker named Richard Stallman gathered up all those libraries,
> eliminated duplicates and rationalized the implementation, and released the
> result to the community.
>
> EMACS was ported from the ITS operating system on their PDP-10s to TENEX
> (ancestral to TOPS-20) by porting TECO there.
>
> EMACS was also ported to Multics on the Honeywell 6180 processor at the MIT
> Laboratory for Computer Science, but not by porting TECO. Instead, the MACLISP
> dialect of LISP, another creation of the AI Lab, had already been ported to
> Multics, so that was used as the base language for the EMACS port.
>
> Meanwhile, an editor with the capabilities of EMACS was desired for the Lisp
> machines being created by the AI Lab, so taking their cue from the Multics port
> two Lisp based editors, EINE ("EINE Is Not EMACS") and ZWEI ("ZWEI Was EINE
> Initially"), were created.

Wasn't there also DREI (DREI was EINE Initially)?

> There might have been alternatives, but why fuck with a good thing?

+1

'Andreas

[bill]

Why? Did "real common lisp" go OOP like all the rest?

bill

(Up until my departure the University was still using Lisp in
the CS course and we used CLisp.)

[Arne Vajhøj]

On 4/24/2023 12:48 PM, bill wrote:
> On 4/24/2023 12:18 PM, Andreas Eder wrote:
>> On Fr 21 Apr 2023 at 17:00, klu...@panix.com (Scott Dorsey) wrote:
>>> =?UTF-8?Q?Arne_Vajh=c3=b8j?=  <ar...@vajhoej.dk> wrote:
>>>> On 4/21/2023 10:51 AM, Chris Townley wrote:
>>>>> On 21/04/2023 14:31, Arne Vajhøj wrote:
>>>>>> Getting abcl (lisp) working was really random luck.
>>>>>>
>>>>>> :-)
>>>>>
>>>>> Is Lisp still used these days?
>>>>
>>>> ABCL (Common Lisp on JVM and actually able to run on VMS)
>>>> is actively maintained.
>>>>
>>>> And I believe there are several other Lisp implementations
>>>> that are not EOL.
>>>
>>> I think most folks using lisp under VMS are using xlisp.  Which
>>> builds nicely
>>> under VMS and a whole lot of other operating systems, and is pleasantly
>>> common-lisp compatible if you like that sort of thing.
>>
>> Compared to a real common lisp xlisp is just a toy.
>
> Why? Did "real common lisp" go OOP like all the rest?

Not sure about "go" but at least "support".

Common Lisp supposedly have something called CLOS
(Common Lisp Object System) that Wikipedia describe as
"The Common Lisp Object System (CLOS) is the facility for
object-oriented programming which is part of ANSI Common Lisp.".

That sounds OOP to me.

Arne

[Andreas Eder]

On Mo 24 Apr 2023 at 12:48, bill <bill.gu...@gmail.com> wrote:

> On 4/24/2023 12:18 PM, Andreas Eder wrote:
>> On Fr 21 Apr 2023 at 17:00, klu...@panix.com (Scott Dorsey) wrote:
>>
>>> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <ar...@vajhoej.dk> wrote:
>>>> On 4/21/2023 10:51 AM, Chris Townley wrote:
>>>>> On 21/04/2023 14:31, Arne Vajhøj wrote:
>>>>>> Getting abcl (lisp) working was really random luck.
>>>>>>
>>>>>> :-)
>>>>>
>>>>> Is Lisp still used these days?
>>>>
>>>> ABCL (Common Lisp on JVM and actually able to run on VMS)
>>>> is actively maintained.
>>>>
>>>> And I believe there are several other Lisp implementations
>>>> that are not EOL.
>>>
>>> I think most folks using lisp under VMS are using xlisp. Which builds nicely
>>> under VMS and a whole lot of other operating systems, and is pleasantly
>>> common-lisp compatible if you like that sort of thing.
>> Compared to a real common lisp xlisp is just a toy.
>
> Why? Did "real common lisp" go OOP like all the rest?

CL was OOP before most other languages.
Look at CLOS. It is by far the ness OOP system. And there also is a
meta object protocol.

'Andreas

[bill]

Thankfully, I don't anticipate ever having to do anything with Lisp
again.

On a curious side note, while cleaning up one of my home offices :-)
I came across the full printout of Lawrence Livermore Labs Lisp.
Probably dates back to the 70's. I wonder if it would even compile
on anything today?

bill

[Johnny Billquist]

On 2023-04-24 14:16, Simon Clubley wrote:
> On 2023-04-21, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 4/21/2023 1:09 PM, Simon Clubley wrote:
>>> On 2023-04-21, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>>> On 4/21/2023 10:51 AM, Chris Townley wrote:
>>>>> Is Lisp still used these days?
>>>
>>> In Emacs. Unfortunately. :-(
>>>
>>> What a bloody horrible monstrosity of a language. :-(
>>>
>>> I wish they had used something else for Emacs. Anything else.
>>
>> I am sure a lot of people agree.
>>
>> But what were the alternatives when Emacs Lisp was
>> created?
>>
>> Emacs Basic?
>>
>
> That would have been better. :-)
>
> ALGOL/Pascal/etc was also in use by the mid 1970s, so perhaps they could
> have created a runtime embedded language based around those general concepts.
>
> But no, Lisp was what they knew, so Lisp is what it was, even in the mid
> 1980s when GNU Emacs was created and Lisp was way obsolete by that point. :-(

Honestly, Lisp is so much better than any of those alternatives. Not to
mention that Lisp have this wonderful idea that there is no difference
between data and code. Which a lot of other languages have, and which is
a constant headache.

Johnny

[Arne Vajhøj]

On 4/13/2023 8:26 AM, Simon Clubley wrote:
> On 2023-04-13, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 4/13/2023 6:44 AM, Neil Rieck wrote:
>>> And although python is used to do a lot of admin scripting on Linux
>>> platforms (tools like "yum" and "firewall-cmd" are written in
>>> python), python does a really good job supporting server-side
>>> scripting under apache cgi-bin. I don't know how this is possible,
>>> but python programs are faster than compiled DEC-BASIC programs
>>> started via apache.
>>
>> That is unexpected. If both are run via CGI mechanism then
>> script activation should be the same. And compiled code should be
>> faster than interpreted code. And if libraries used are also the
>> same then it is a mystery.
>>
>
> Maybe. Maybe not. Based purely on some comments from people here who
> know/use DEC Basic, it's quite possible that DEC Basic has a RTL which
> imposes some serious runtime overheads.
>
> Perhaps for one of your many articles (:-)), you may be interested in
> coding the same set of problems in the various DEC languages and seeing
> what the performance differences are.

I already have such code. Just needed to add a few VMS specific.

I don't think it can carry an independent article.

But here are some numbers:

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

We see that Basic is significant slower than C/Pascal/Fortran,
but still significant faster than Python.

Not a problem for Python. An extreme CPU intensive calculation
is not what one use an interpreted language for (but one may
very well use an interpreted language to control/orchestrate
such a calculation.

As a side note: on other platforms the PyPy (which uses JIT)
are about 60 times faster than regular CPython.

String operations (*)
Alpha sim Itanium
(no JIT) (older)
C 0.076 1.94
Pascal 0.005 0.32
Fortran 0.002 0.07
Basic 0.039 1.31
Ada (gnat make) 0.005 -
Ada (gnat make -gnatp "-O3") 0.005 -
Java 5 0.033 -
Java 8 - 1.76
Python 2 0.005 -
Python 3 - 0.65

*) string operations are done "natural", which means that they are done
different in different languages.

Here Basic actually do quite well.

Python also, which is probably because it calls some
functions written in C to do a lot of the work.

The high numbers for C probably just reflect that a fixed
size char array being appended to is more efficient than
working with real dynamic strings.

Arne

[Arne Vajhøj]

On 5/1/2023 7:36 PM, Arne Vajhøj wrote:
> On 4/13/2023 8:26 AM, Simon Clubley wrote:
>> Perhaps for one of your many articles (:-)), you may be interested in
>> coding the same set of problems in the various DEC languages and seeing
>> what the performance differences are.
>
> I already have such code. Just needed to add a few VMS specific.
>
> I don't think it can carry an independent article.
>
> But here are some numbers:

If someone want the code then I can post it.

Arne

[Simon Clubley]

On 2023-05-01, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>
> String operations (*)
> Alpha sim Itanium
> (no JIT) (older)
> C 0.076 1.94
> Pascal 0.005 0.32
> Fortran 0.002 0.07
> Basic 0.039 1.31
> Ada (gnat make) 0.005 -
> Ada (gnat make -gnatp "-O3") 0.005 -
> Java 5 0.033 -
> Java 8 - 1.76
> Python 2 0.005 -
> Python 3 - 0.65
>
> *) string operations are done "natural", which means that they are done
> different in different languages.
>

Thanks for posting the numbers.

std::string would be interesting here if you have access to a C++ compiler.

What string operations are you performing ? Is it simple concatenation or
something else ? The number of concatenations versus the size of each
concatenation could also make a difference, at least for the dynamically
allocated strings.