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

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

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

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

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.

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.

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

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.

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.

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.

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:

o->f(a1, a2, a3) to be C++
f(o, a1, a2, a3) to be C
o->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

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

> But I consider:
>
> o->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.

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:
>>
>> o->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

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:
>>>
>>> o->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

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

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