Two more tech demo's.

VMS Tech Demo 14 - Groovy for scripting:
https://www.vajhoej.dk/arne/articles/vmstd14.html

Covering:
* basic scripting
* using to SYS$ and LIB$ functions
* accessing index-sequential files, databases and message queues

VMS Tech Demo 15 - Groovy for applications:
https://www.vajhoej.dk/arne/articles/vmstd15.html

Covering:
* Groovy calling Java
* Java calling Groovy
* Groovy calling C/Pascal/Basic
* C/Pascal/Basic calling Groovy

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/2/24 7:14 PM, Arne Vajhøj wrote:

Two more tech demo's.

VMS Tech Demo 14 - Groovy for scripting:
  https://www.vajhoej.dk/arne/articles/vmstd14.html

How does Groovy compare to BeanShell?

https://github.com/beanshell/beanshell

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/3/2024 9:38 AM, Craig A. Berry wrote:

On 3/2/24 7:14 PM, Arne Vajhøj wrote:

Two more tech demo's.

VMS Tech Demo 14 - Groovy for scripting:
   https://www.vajhoej.dk/arne/articles/vmstd14.html

How does Groovy compare to BeanShell?

https://github.com/beanshell/beanshell

Good question.

And I am not an expert on the topic.

But to my understanding then:
* they are relative similar in language syntax and features today
* they came from a very different (opposite) background:
- BeanShell started as Java interpreter and evolved
into a full script language with optional typing
- Groovy started as a Java-like scripting language
without typing that added typing later
* they are used for different purposes:
- BeanShell is very much used for JSR223 embedded
scripting language in Java applications
- Groovy got a much broader usage:
. web applications (Grails framework, Groovelets)
. more general scripting (the world dominated by
Perl and Python)
. JSR223 embedded scripting language in Java applications
* Groovy is more used than BeanShell - especially
Grails have a reasonable big user base

I have only used BeanShell as embedded script engine
for 100% Java compatible. I have dabbled in Groovy for both
web and scripting.

A job search at dice.com find 239 Groovy jobs and 0
BeanShell jobs. I am sure there are plenty of jobs
where BeanShell is used but its usage is not
important enough to warrant being mentioned in the ad.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/3/2024 12:54 PM, Arne Vajhøj wrote:

A job search at dice.com find 239 Groovy jobs and 0
BeanShell jobs. I am sure there are plenty of jobs
where BeanShell is used but its usage is not
important enough to warrant being mentioned in the ad.

Or to to rephrase: "Groovy developer" is a thing while
"BeanShell developer" is not a thing. BeanShell is a skill
like JDBC, JPA, JMS, JNI etc. for a "Java developer".

This is of course totally non-technicial. But it is
how the languages are perceived in the industry.

IMHO. YMMV.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-03-03, Arne Vajh�j <arne@vajhoej.dk> wrote:

On 3/3/2024 12:54 PM, Arne Vajh�j wrote:

A job search at dice.com find 239 Groovy jobs and 0
BeanShell jobs. I am sure there are plenty of jobs
where BeanShell is used but its usage is not
important enough to warrant being mentioned in the ad.

Or to to rephrase: "Groovy developer" is a thing while
"BeanShell developer" is not a thing. BeanShell is a skill
like JDBC, JPA, JMS, JNI etc. for a "Java developer".

$ set response/mode=good_natured

Hmmm, I wonder how many Java developers claiming JNI as a "skill"
could actually _use_ JNI (and make it work!) ? :-)

JNI requires a very different mindset and knowledge base than most
of the other Java development skills...

Simon.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/3/24 11:54 AM, Arne Vajhøj wrote:

On 3/3/2024 9:38 AM, Craig A. Berry wrote:

On 3/2/24 7:14 PM, Arne Vajhøj wrote:

Two more tech demo's.

VMS Tech Demo 14 - Groovy for scripting:
   https://www.vajhoej.dk/arne/articles/vmstd14.html

How does Groovy compare to BeanShell?

https://github.com/beanshell/beanshell

Good question.

And I am not an expert on the topic.

But to my understanding then:
* they are relative similar in language syntax and features today
* they came from a very different (opposite) background:
  - BeanShell started as  Java interpreter and evolved
    into a full script language with optional typing
  - Groovy started as a Java-like scripting language
    without typing that added typing later
* they are used for different purposes:
  - BeanShell is very much used for JSR223 embedded
    scripting language in Java applications
  - Groovy got a much broader usage:
    . web applications (Grails framework, Groovelets)
    . more general scripting (the world dominated by
      Perl and Python)
    . JSR223 embedded scripting language in Java applications
* Groovy is more used than BeanShell - especially
  Grails have a reasonable big user base

I have only used BeanShell as embedded script engine
for 100% Java compatible. I have dabbled in Groovy for both
web and scripting.

That makes sense. I don't do much with Java very often and I've never encountered Groovy in the wild; I've only encountered BeanShell once and
it was embedded in an app specifically for making that app's
capabilities scriptable, so even my very limited experience is
consistent with yours.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/4/2024 8:16 AM, Simon Clubley wrote:

On 2024-03-03, Arne Vajhøj <arne@vajhoej.dk> wrote:

On 3/3/2024 12:54 PM, Arne Vajhøj wrote:

A job search at dice.com find 239 Groovy jobs and 0
BeanShell jobs. I am sure there are plenty of jobs
where BeanShell is used but its usage is not
important enough to warrant being mentioned in the ad.

Or to to rephrase: "Groovy developer" is a thing while
"BeanShell developer" is not a thing. BeanShell is a skill
like JDBC, JPA, JMS, JNI etc. for a "Java developer".

$ set response/mode=good_natured

Hmmm, I wonder how many Java developers claiming JNI as a "skill"
could actually _use_ JNI (and make it work!) ? :-)

JNI requires a very different mindset and knowledge base than most
of the other Java development skills...

True.

JNI is tricky (read: it sucks).

But in 5-10 years JNI will hopefully be replaced by
Foreign Function.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 4 Mar 2024 15:49:27 -0500, Arne Vajhøj wrote:

JNI is tricky (read: it sucks).

I managed to do some stuff in Android with it, back in the day. I
created a Python script
<https://bitbucket.org/ldo17/jniglue/src/master/> that generates
slightly more convenient wrappers around the entry points in the
JNIEnv object, e.g. for the NewStringUTF method:

static inline jstring JNNewStringUTF(JNIEnv* env, const char* a1)
{
return
(**env).NewStringUTF(env, a1);
} /*NewStringUTF*/

so you call it like this:

const jstring msgobj = JNNewStringUTF(env, usebuf);

I felt it made things much more bearable.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/4/2024 4:25 PM, Lawrence D'Oliveiro wrote:

On Mon, 4 Mar 2024 15:49:27 -0500, Arne Vajhøj wrote:

JNI is tricky (read: it sucks).

I managed to do some stuff in Android with it, back in the day. I
created a Python script
<https://bitbucket.org/ldo17/jniglue/src/master/> that generates
slightly more convenient wrappers around the entry points in the
JNIEnv object, e.g. for the NewStringUTF method:

static inline jstring JNNewStringUTF(JNIEnv* env, const char* a1)
{
return
(**env).NewStringUTF(env, a1);
} /*NewStringUTF*/

so you call it like this:

const jstring msgobj = JNNewStringUTF(env, usebuf);

I felt it made things much more bearable.

That converts the C++ API to a C API, but there is more
hassle in JNI than that.

Arne

PS: (**env).Foobar is rather unusual - the common style is
(*env)->Foobar.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 4 Mar 2024 19:17:03 -0500, Arne Vajhøj wrote:

That converts the C++ API to a C API ...

No, it’s all strictly C.

PS: (**env).Foobar is rather unusual - the common style is
(*env)->Foobar.

I don’t understand why. It’s the same number of characters either way.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/4/2024 8:53 PM, Lawrence D'Oliveiro wrote:

On Mon, 4 Mar 2024 19:17:03 -0500, Arne Vajhøj wrote:

That converts the C++ API to a C API ...

No, it’s all strictly C.

Your code is C. And I suspect the JNI code being called is C as well.

But I consider:

f(a1, a2, a3) to be C++

f(o, a1, a2, a3) to be C

f(o, a1, a2, a3) to be C++ API in C language

PS: (**env).Foobar is rather unusual - the common style is
(*env)->Foobar.

I don’t understand why. It’s the same number of characters either way.

True. But if you look at examples in documentation and elsewhere, then ...

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 5 Mar 2024 17:48:21 -0500, Arne Vajhøj wrote:

But I consider:

f(a1, a2, a3) to be C++

If you can refer to o as “this”, that’s C++. You can’t do that in C.

Learn to tell the difference.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/5/2024 7:34 PM, Arne Vajhøj wrote:

On 3/5/2024 5:53 PM, Lawrence D'Oliveiro wrote:

On Tue, 5 Mar 2024 17:48:21 -0500, Arne Vajhøj wrote:

But I consider:

f(a1, a2, a3) to be C++

If you can refer to o as “this”, that’s C++. You can’t do that in C.

But this is not available by magic. It is there because
it (at least in some implementations - I doubt that the
standard define the "how") pass it as a hidden 1st argument.

To illustrate:

$ type m.cxx
#include <iostream>

using namespace std;

class C
{
public:
virtual void M1(int v) = 0; // C++ API in C++
virtual void M2(char *s) = 0; // C++ API in C++
};

class C1 : public C
{
public:
void M1(int v) { cout << "C1 says: " << v << endl; }
void M2(char *s) { cout << "C1 says: " << s << endl; }
};

class C2: public C
{
public:
void M1(int v) { cout << "C2 says: " << v << endl; }
void M2(char *s) { cout << "C2 says: " << s << endl; }
};

extern "C"
{
void f(C **o);
}

int main()
{
C *o1 = new C1();
f(&o1);
delete o1;
C *o2 = new C2();
f(&o2);
delete o2;
return 0;
}

$ type s.c
#include <stdio.h>

struct C;

typedef void (*fptr1)(struct C **this, int v); // C++ API in C
typedef void (*fptr2)(struct C **this, char *s); // C++ API in C

struct C_vtable
{
fptr1 M1;
fptr2 M2;
};

struct C
{
struct C_vtable *vtable;
};

void f(struct C **o)
{
(*o)->vtable->M1(o, 123);
(*o)->vtable->M2(o, "ABC");
}
$ cxx m
$ cc s
$ cxxlink m + s
$ run m
C1 says: 123
C1 says: ABC
C2 says: 123
C2 says: ABC

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/5/2024 5:53 PM, Lawrence D'Oliveiro wrote:

On Tue, 5 Mar 2024 17:48:21 -0500, Arne Vajhøj wrote:

But I consider:

f(a1, a2, a3) to be C++

If you can refer to o as “this”, that’s C++. You can’t do that in C.

But this is not available by magic. It is there because
it (at least in some implementations - I doubt that the
standard define the "how") pass it as a hidden 1st argument.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 06/03/2024 00:39, Arne Vajhøj wrote:

Arne

As others have said - Don't feed the troll, especially when he turns
into a nasty b*stard


--
Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 5 Mar 2024 19:34:09 -0500, Arne Vajhøj wrote:

On 3/5/2024 5:53 PM, Lawrence D'Oliveiro wrote:

On Tue, 5 Mar 2024 17:48:21 -0500, Arne Vajhøj wrote:

But I consider:

f(a1, a2, a3) to be C++

If you can refer to o as “this”, that’s C++. You can’t do that in C.

But this is not available by magic.

It’s part of the language. That’s one way to tell that it’s C++ and not C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)