Rich Alderson <news@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

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

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.

On 4/22/2023 5:16 PM, hb@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

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.

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.

On 4/23/2023 6:06 AM, hb@end.of.inter.net wrote:
> 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.

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

On 4/23/23 8:39 AM, Arne Vajhøj wrote:
> On 4/23/2023 6:06 AM, hb@end.of.inter.net wrote:

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

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.

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

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.

On 4/21/2023 7:24 PM, Scott Dorsey wrote:
> In article <u1ugra$2r211$2@dont-email.me>,
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>> On 4/21/2023 1:00 PM, Scott Dorsey wrote:
>>> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@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.
>>
>> https://github.com/dbetz/xlisp
>>
>> ?
>
> Yes. Builds on just about anything. Pretty well supported. Suited for
> embedded systems if you're into that kind of thing.

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

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

On 2023-04-21, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 4/21/2023 1:09 PM, Simon Clubley wrote:
>> On 2023-04-21, Arne Vajhøj <arne@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.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2023-04-21, Rich Alderson <news@alderson.users.panix.com> wrote:
>=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>
>> On 4/21/2023 1:09 PM, Simon Clubley wrote:
>
>>> On 2023-04-21, Arne Vajhøj <arne@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.

:-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 4/24/2023 8:16 AM, Simon Clubley wrote:
> On 2023-04-21, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 4/21/2023 1:09 PM, Simon Clubley wrote:
>>> On 2023-04-21, Arne Vajhøj <arne@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

On Fr 21 Apr 2023 at 11:14, Arne Vajhøj <arne@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

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

> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@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

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

> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>
>> On 4/21/2023 1:09 PM, Simon Clubley wrote:
>
>>> On 2023-04-21, Arne Vajhøj <arne@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

On 4/24/2023 12:18 PM, Andreas Eder wrote:
> On Fr 21 Apr 2023 at 17:00, kludge@panix.com (Scott Dorsey) wrote:
>
>> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@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?

bill

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

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, kludge@panix.com (Scott Dorsey) wrote:
>>> =?UTF-8?Q?Arne_Vajh=c3=b8j?=  <arne@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

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

> On 4/24/2023 12:18 PM, Andreas Eder wrote:
>> On Fr 21 Apr 2023 at 17:00, kludge@panix.com (Scott Dorsey) wrote:
>>
>>> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@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

On 4/25/2023 6:55 AM, Andreas Eder wrote:
> On Mo 24 Apr 2023 at 12:48, bill <bill.gunshannon@gmail.com> wrote:
>
>> 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.

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

On 2023-04-24 14:16, Simon Clubley wrote:
> On 2023-04-21, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 4/21/2023 1:09 PM, Simon Clubley wrote:
>>> On 2023-04-21, Arne Vajhøj <arne@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

On 4/13/2023 8:26 AM, Simon Clubley wrote:
> On 2023-04-13, Arne Vajhøj <arne@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

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

On 2023-05-01, Arne Vajhøj <arne@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.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.