Maybe Kotlin can be a good addition to Elements

Non-Tech
1

Although, iam studying Oxygene and silver,

I recently discovered Kotlin the JVM language.

I can’t imagine how comeplex it is to add another language.

but it would be awesome to use elements with kotlin language.

just saying.

Thank you

2

My vote would be for F#. Although I am still learning it but I am really liking what I have seen so far.

3

Would it be a big task to make F# work with your tool chain?

4

Quite a big task. F# is vastly different than any of the languages we have now.

5

I prefer Groovy support.
Groovy can use the same syntax of Java but add many functionalities not present at Java with a cleaner syntax.

6

What does Groovy (or Kotlin) give that isn’t covered by either Oxygene, C# or Swift?

7

Probably nothing, just the better syntax especially compared with Swift optionals.

8

Groovy could be a good replacement for Java, maybe could be used instead or together Java at Iodine.
Groovy syntax is less redundant and Groovy can infer type. For example:
Java:
Client c = new Client()
Grovy:
def c = new Client()
And c will be a Client at both.

9

(a) have you tried var c = new Client() in our Java preview? :wink:

(b) all our languages also have type inference, so I’m that’s not really a big selling point for Groovy, on its own…

10

Very nice to know that! It helps a lot! :+1: :smile:
But Groovy can do others things like:

class A {
   String getA1() {
      return "1"
   }
}

var a = new A()
print (a.a1)    // will print 1

As you can see the a1 property was not directly defined at code but infered by Groovy because we defined an accessor: get or set. In fact, a1 is a read-only property as we do not defined a set accessor.

Another possibility is:

class A {
   String a1 = "1"
}

var a = new A()
a.a1 = "T"

In that case Groovy will create for us the get and set accessors.

Groovy has a lot of syntax sugars that Java don’t have and a better support to introspection because Groovy is a dynamic language designed for scripts.

In fact a Groovy script is a class itself. Then if I had a script named a.groovy with follow code:

String a1 = “1”

I could import it as a class and make:

var a = new A()
print a.a1

The name of script will be the name of the class :wink:

I could say much more but instead of a post it will be a book :laughing:

11

ok. i get that the Java language (currently :wink: is limited. but none of this bows me away as a C#, Oxygene or Swift developer?

12

Swift is a good replacement but optionals have a complex syntax, when we need to accept null.
I like both Swift and Groovy and I am using both at my projects, I just prefer Groovy than Java to write code to Java platform where Groovy integrates very nice.
Groovy have an advantage that can run a Java code without modification. Groovy is 100% compatible with Java. I just think that Groovy is better than Java itself and could be supported in the place of Java language with many advantages.
Groovy would be a better addition to Elements than Java itself because we could create code at Groovy style or Java style including a mix with a few of each. Considering that you intend to support Java language why not Groovy instead? Just will add more funtionalities than Java without any loss.
I don’t think that Groovy competes with Oxygene, C# or Swift but with the new Java support, where I think that add Groovy support will be advantage. Just my 2 cents.

13

i suppose if Groovy is a full superset of Java, we could look at supporting it as part of Iodine… i’ll have a look…

14

Yes!!! Nice to hear that! :smile:

15

Reading up on groovy: http://stackoverflow.com/questions/4272068/is-groovy-syntax-an-exact-superset-of-java-syntax

groovy isn’t a strict superset of java?

16

Well, appear that you found an incompatibility unknown by me.