[Info-vax] The Kotlin language, something for VMS as well?

[Jan-Erik Soderholm]

Den 2017-07-13 kl. 14:02, skrev Arne Vajhøj:
> On 7/13/2017 4:37 AM, Dirk Munk wrote:
>> Arne Vajhøj wrote:
>>> On 7/12/2017 4:13 PM, Brett Cameron wrote:
>>>> Just FYI, I had a bit of a play around with Kotlin a few weeks back
>>>> and pretty much all the JVM stuff seems to work okay on OpenVMS with
>>>> Java 8 (the interactive shell has a couple of minor issues, but
>>>> that’s about all I’ve hit so far)...
>>>
>>> Most JVM languges should be easy to get working:
>>>
>>> Kotlin
>>> Scala
>>> Groovy
>>> Jython (Python) [I am rather interested in that one]
>>> JRuby (Ruby)
>>> Clojure (Lisp derivative)
>>> JGnat (Ada)
>>> Rembulan (Lua)
>>> Rhino or Nashorn (JavaScript) [comes with Java out the box and works]
>>> Renjin (R)
>>>
> 
>> Thank you very much Arne, this is very interesting information. I wasn't 
>> aware of these developments.
>>
>> Let's take Jython as an example. If I'm going to use an application 
>> written in Python now, then it will come with all the clutter of a Python 
>> runtime system in its directories. Another application written in Python 
>> will have the same clutter, preferably with another (sub)version of Python.
>>
>> With Jython you would only have the application in .jar files in its 
>> directories, perhaps a kind of Jython library as well, and run the whole 
>> thing with the standard JVM that you already have installed. No more 
>> clutter.
>>
>> It also means you don't need Jython (Python!) versions for every OS, only 
>> for desktop operating systems. Those would be Windows, Linux and Mac OS.
>>
>> If I understand John Reagon's contribution correctly, the Python 
>> developers could also build a LLVM compiler kit, add some VMS specific 
>> code, and build a LLVM Python compiler on VMS. With that you can produce 
>> Python executables. Don't know if that would be useful, but that's not 
>> the point for this discussion.
>>
>> So my conclusion is that if you want to add a new language to VMS, makes 
>> sure it runs with the JVM, and/or produce a LLVM kit, adapt it somewhat 
>> for the VMS specifics, and build a LLVM compiler to produce executables 
>> for the new language. (The LLVM stuff is on x86-VMS of course!!)
>>
>> Am I correct?
> 
> I don't think there is any silver bullet, but I do see some advantages
> of the JVM model.
> 
> Native languages will typical be:
> 
> language A
>     large runtime for A
>     database drivers etc. for A
> language B
>     large runtime for B
>     database drivers etc. for B
> language C
>     large runtime for C
>     database drivers etc. for C
> 
> JVM languages will typical be:
> 
> Java
>     huge Java runtime
>     database drivers etc. for Java
> language A
>     small runtime for A
> language B
>     small runtime for B
> language C
>     small runtime for C
> 
> I don't know much about how LLVM works. But I thought it was
> more of a compiler backend meaning that it would make it much
> easier to produce a native language for a platform, but that
> it would not really change the deployment model. But I may
> be wrong.
> 
> Arne
> 

I also thought that you need a language specific frontend to LLVM,
much as you need for GEM. Maybe LLVM can produce code runable
in the JVM, no idea...