On 4/17/2023 10:47 PM, Dave Froble wrote:
> On 4/17/2023 7:25 PM, Arne Vajhøj wrote:
>> 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.gunshannon@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.
>>
>> "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.
>
> 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

On 4/17/2023 10:54 PM, Dave Froble wrote:
> On 4/17/2023 8:00 PM, Arne Vajhøj wrote:
>> 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.
>
> That wasn't the issue.

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

On 2023-04-17, Dave Froble <davef@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.

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

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

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

On 4/18/2023 8:10 AM, Arne Vajhøj wrote:
> On 4/17/2023 10:54 PM, Dave Froble wrote:
>> On 4/17/2023 8:00 PM, Arne Vajhøj wrote:
>>> 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.
>>
>> That wasn't the issue.
>
> 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

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

:-)

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

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

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

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

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

On 4/18/2023 1:21 PM, Scott Dorsey wrote:
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@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

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

On 4/19/23 7:27 PM, Arne Vajhøj wrote:
> 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).

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.

On 4/20/2023 7:29 AM, Craig A. Berry wrote:
>
> On 4/19/23 7:27 PM, Arne Vajhøj wrote:
>> 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!

> 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

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.

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

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.

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.

=?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.
--scott

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

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.

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

Lucky you...

Simon.

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

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?

Arne

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

?

Arne

=?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". ;-)

>> 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 news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

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

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

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.

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

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

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?

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

In article <u20kg3$3977v$1@dont-email.me>,
=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>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.

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

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

Lars Brinkhoff <lars.spam@nocrew.org> writes:

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

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 news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen