20 Coolest Features of Non-Java JVM Languages
Tags: java, scala, groovy, kotlin
Published: 2020-05-13 21:40:57

> _"So I find words I never thought to speak
> In streets I never thought I should revisit
> When I left my body on a distant shore."_
>
> -- [T. S. Eliot](https://www.goodreads.com/quotes/588965-so-i-find-words-i-never-thought-to-speak-in)

---

Java [has been a key player](https://www.youtube.com/watch?v=Og847HVwRSI) in the programming landscape since it was created in the mid-90s. One of the big attractions of Java is its "write once, run anywhere" execution model, where Java source code is compiled to _bytecode_ by the compiler. This bytecode can later be executed by the Java Virtual Machine (JVM), which converts the Java bytecode to machine-specific instructions.

Separating the _writing_ of code from the _execution_ of code into two domains means that Java developers don't have to write architecture-specific instructions. They can just write Java code, and expect that the people building the JVM will take care of all of the machine-specific nuances.

Of course, the JVM doesn't know _how_ the bytecode was generated, just that it's supposed to run it. Language designers soon realised that this meant they could create _new_ languages which ran on the JVM, provided they created intermediate compilers that could convert those languages into Java bytecode. And so, almost immediately after the first version of Java was released, new JVM languages started to appear. What follows are some of the coolest features I've found in these non-Java JVM languages.

> __A small clarification:__ some of the features below are found in multiple languages on this list. Languages which developed later are naturally influenced by those that came before them, and languages which have more resources behind them can incorporate more features. This is why -- for instance -- the feature set of Kotlin (funded by JetBrains, which charge €500/year for their IDE, IntelliJ) is essentially a superset of all of the features of other popular modern languages like Scala and Groovy.
>
> I made no attempt to uncover which language _first_ implemented which particular feature below, rather, I wanted to simply highlight some interesting features which haven't (yet) been incorporated into Java, to the best of my knowledge. If you find any mistakes below, or know of any other neat features available in non-Java JVM languages, please let me know in the comments!

---

<a name="toc"></a>
## Table of Contents

1.  [__Ioke__ -- homoiconicity](#ioke)
2.  [__Gosu__ -- open type system](#gosu)
3.  [__Gosu__ -- optional and named parameters](#gosu2)
4.  [__Prompto__ -- standard dialects](#prompto)
5.  [__Frege and Eta__ -- "Haskell for the JVM"](#frege-eta)
6.  [__Ateji PX__ -- parallel blocks](#atejipx)
7.  [__Fantom__ -- "once" methods and lots of literals](#fantom)
8.  [__Whiley__ -- verification via formal specification](#whiley)
9.  [__Whiley__ -- flow-sensitive typing](#whiley2)
10. [__Jython & JRuby__ -- language interoperability](#jython-jruby)
11. [__Clojure__ -- "LISP for the JVM"](#clojure)
12. [__Scala__ -- "everything is an object" ](#scala)
13. [__Scala__ -- everything is an expression ](#scala2)
14. [__Scala__ -- case classes and pattern matching ](#scala3)
15. [__Scala__ -- implicit programming ](#scala4)
16. [__Groovy__ -- partial application and composition of functions ](#groovy)
17. [__Groovy__ -- easy regular expressions ](#groovy2)
18. [__Groovy__ -- JSON-to-classes ](#groovy3)
19. [__Kotlin__ -- JavaScript transpilation ](#kotlin)
20. [__Kotlin__ -- coroutines ](#kotlin2)

---

<a name="ioke"></a>
## #1. [Ioke](https://ioke.org/) -- _homoiconicity_

Homoiconicity is a subject which [takes a bit of explanation](https://dev.to/awwsmm/concept-of-the-day-homoiconicity-4did), but what it boils down to is that a homoiconic program is composed of language elements which can be interpreted as objects within the language itself.

You could imagine a programming language where every object is a directed graph -- loops are created with actual loops in the graph, and all information needed to run the program is contained within the vertices of the graph. If this language itself can manipulate graphs, then it can operate on its own source code. "Code as data" is a common maxim when working with homoiconic languages.

In __Ioke__, ["everything is an expression composed of a chain of messages"](https://ioke.org/wiki/index.php/Guide). The entire language syntax can be summarised as follows:

```java
program       ::=  messageChain?
messageChain  ::=  expression+
expression    ::=  message | brackets | literal | terminator
literal       ::=  Text | Regexp | Number | Decimal | Unit
message       ::=  Identifier ( "(" commated? ")" )?
commated      ::=  messageChain ( "," messageChain )*
brackets      ::=  ( "[" commated? "]" ) | ( "{" commated? "}" )
terminator    ::=  "." | "\n"
comment       ::=  ";" .* "\n"
```

Since every program is a message chain, and a message chain is itself an object in Ioke, Ioke programs can manipulate their own source code (or the source code of other Ioke programs) as data. While [the jury is still out](https://www.reddit.com/r/ProgrammingLanguages/comments/b0xqom/what_is_the_benefit_of_being_homoiconic/) as to whether homoiconicity is _a good thing™_ for a programming language to achieve, it certainly is an interesting feature, if nothing else.

[[ back to Table of Contents ]](#toc)

<a name="gosu"></a>
## \#2. [Gosu](https://gosu-lang.github.io/) -- _open type system_

Gosu is A JVM language that provides an _open type system_, meaning Gosu programmers can add functionality to classes, _even if they didn't create those classes themselves_. This includes built-in Java classes like `java.lang.String`. A simple example is given on [Gosu's Wikipedia page](https://en.wikipedia.org/wiki/Gosu_(programming_language)#Data_types):

```java
enhancement MyStringEnhancement : String {
  function print() {
    print(this)
  }
}
```

The above [`enhancement`](https://gosu-lang.github.io/docs.html#enhancements) adds a `print()` method to the `java.lang.String` class, meaning a `String` can now print itself:

```java
"Echo".print()
```

Gosu also provides extremely simple [closures](https://en.wikipedia.org/wiki/Closure_(computer_programming)) and `enhancements` to the `Iterable` interface, which -- combined with the language's scripting-like syntax -- make `Collection` manipulation a breeze:

```java
var lstOfStrings = { "This", "is", "a", "list" }
var longStrings  =
    lstOfStrings.where( \ s -> s.length > 2    )
                .map(   \ s -> s.toUpperCase() )
                .order()
print(longStrings.join(", ")) // prints "LIST, THIS"
```

[[ back to Table of Contents ]](#toc)

<a name="gosu2"></a>
## \#3. [Gosu](https://gosu-lang.github.io/) -- _optional and named parameters_

Gosu also brings to the JVM a feature which exists in many other languages, but is (as of this writing) still missing from Java: _optional parameters_.

In Java, there's no way to specify a default value for a parameter in a constructor. If you want to make a parameter optional, you have to use a [Builder Pattern](https://dzone.com/articles/design-patterns-the-builder-pattern), remove the parameter from the constructor entirely and rely on the user to set it after the fact, or create multiple constructors:

```java
public class Person {

    private String opt = "default";
    
    public Person (String opt) {
      this.opt = opt;
    }
    
    public Person() {
      // ...
    }
    
    //...
}
```

Gosu is one of many modern languages that makes this functionality a bit easier by offering _optional parameters_. Here's some Gosu code similar to the Java code above:

```java
class Person {

  var _opt : String

  construct (opt : String = "default") {
    _opt = opt
  }
   
  //...
}
```

This constructor provides a default value `"default"` to the parameter `opt`. This constructor can be called with a single `String` parameter, or with no parameters at all. In that case, the default value will be used.

Optional parameters can cause problems when constructors have more than one argument, though. Consider this case, for instance:

```java
class Person {

  var _opt : String
  var _ional : String

  construct (opt : String = "default", ional : String = "ditto") {
    _opt = opt
    _ional = ional
  }
   
  //...
}
```
 
This new `Person` implementation has _two_ optional parameters. So if we call its constructor with:
 
```gosu
new Person("potato")
```

...which parameter should be assigned the value `"potato"`? They're both `String`s and they both have default values, after all. What if we want to use the default value for `opt`, but a non-default value for `ional`? Gosu resolves this issue with _named parameters_. When we call the `construct` method, we can specify which parameter we want to assign this value to:
 
```gosu
new Person(:ional = "potato")
```

The named parameter makes it clear that we want to assign this value to `ional`, and not `opt`.

[[ back to Table of Contents ]](#toc)

<a name="prompto"></a>
## \#4. [Prompto](http://www.prompto.org/) -- _standard dialects_

[Prompto](http://www.prompto.org/) is a cloud-based programming language designed for building complete information systems, like client-facing web apps which need to interact with server-side data (e-commerce sites, for instance). Prompto is the name of the programming language used to build these applications, but also the platform on which they run.
 
Prompto (the platform) provides various development tools, including [a web-based REPL](http://www.prompto.org/?section=sandbox), database connectors, a debugger, a JVM-based compiler, and a JavaScript transpiler.
 
Prompto (the language) was started as an experiment in [reifying attributes](https://en.wikipedia.org/wiki/Reification_(computer_science)), and offers some radical features for a JVM language, including safe multiple inheritance, easy integration with various languages (including Java, JavaScript, C#, and Python, with Swift in the works), and -- my favourite feature -- dialects.
 
With Prompto dialects, "syntax is a detail". Programmers can write in whichever style suits them best, and code from one dialect can be losslessly translated into other dialects.
 
Prompto's three built-in dialects are:
 
1. __Objy__, for OOP-flavoured syntax
 
    ```java
    method main() {
        print("15 + 3.5");
        print("= 28.5");
    }
    ```
 
2. __Monty__, for Python-like syntax

    ```python 
    def main(options:Text<:>):
        print("15 + 3.5")
        print("= 28.5")
    ```

3. and __Engly__, for English-like syntax

    ```
    define main as method doing:
        print "15 + 3.5"
        print "= 28.5"
    ```

All three blocks of code above are the same Prompto code, expressed in different dialects. Every programming language must provide some syntax to perform a handful of basic tasks: defining variables, running code in a loop until some condition is met, printing information to the user, etc. With Prompto, you're not stuck with a single way to express these concepts, you can choose the style of programming which suits you best!
 
I'm personally very excited about the idea of dialects in programming languages and I wish more languages would follow Prompto's lead and incorporate this cool feature.

[[ back to Table of Contents ]](#toc)

<a name="frege-eta"></a>
## \#5. [Frege](https://github.com/Frege/frege) and [Eta](https://github.com/typelead/eta) -- _"Haskell for the JVM"_

[Frege](http://web.mit.edu/frege-lang_v3.24/Introduction_Frege.pdf) and [Eta](https://eta-lang.org/) are two JVM-based languages which both purport to be "[Haskell](https://en.wikipedia.org/wiki/Haskell_(programming_language)) for the JVM". ([Haskell](https://www.haskell.org/) is a programming language which has become nearly synonymous with the functional programming paradigm since the language's first release almost 30 years ago.) So one might expect both of these languages to bring pure functional programming to the JVM... so why are they two separate languages?

Eta isn't just meant to _look_ like Haskell, it _is_ Haskell (or a dialect of it), just running on the JVM. Eta strives for maximum compatibility with the Glasgow Haskell Compiler (GHC), and the common repository of Haskell libraries, Hackage. In addition, Eta offers Java interoperability with its strongly-typed Foreign Function Interface (FFI), meaning you can write functional code, but still use the Java classes and features you're used to.

Frege, [on the other hand](https://eta-lang.org/docs/faq#eta-vs-frege), "while it supports basic Haskell, lacks many of the key extensions required to compile Hackage, and hence cannot reuse the existing infrastructure." Frege's [_"Differences Between Frege and Haskell"_ page on their GitHub](https://github.com/Frege/frege/wiki/Differences-between-Frege-and-Haskell) was last updated in May 2017, and explains how Frege errs on the side of Java rather than Haskell:

> _"The Frege-Prelude defines many functions, type classes and types known from Haskell in a similar way. The goal is to implement most of the Haskell 2010 standard library in a most compatible way as far as this makes sense."_
>
> _"Apart from that, everything else will be quite different, because Frege uses the Java APIs whenever possible. At the time being, there is not much library support yet beyond the standard libraries._"

Frege is [more established](https://github.com/Frege/frege/graphs/contributors). Eta development has been [more active recently](https://github.com/typelead/eta/graphs/contributors). Both projects have one or two key developers, and so are maintained by very small teams. Although they both have roughly the same number of GitHub stars, "eta lang" returns almost 75x as many results on Google as "frege lang". Eta also has [an official website](https://eta-lang.org/).

While both languages are intriguing, and both advertise themselves as "Haskell for the JVM", if I had to learn only one of these two languages, I would probably pick Eta. _Es tut mir leid, Herr Doktor Frege._

[[ back to Table of Contents ]](#toc)

<a name="atejipx"></a>
## \#6. [Ateji PX](https://en.wikipedia.org/wiki/Ateji_PX) -- _parallel blocks_

["Do one thing, and do it well"](https://en.wikipedia.org/wiki/Unix_philosophy#Do_One_Thing_and_Do_It_Well), the mantra of UNIX architects in the 1970s, was well-heeded by the developers of Ateji PX, a programming language which extends Java with a single key feature -- easy parallelism.

> Ateji is pronounced ["ah-teh-gee"](http://ateji.blogspot.com/2007/10/whats-in-name.html?m=0), and the "PX" stands for "parallel extensions", which are what it provides for the Java ecosystem.

Writing parallelised (or "concurrent") code is still not easy, more than a decade into the era of multi-core processors. Different languages attack this problem in different ways. Some allow users to manually create threads, some allow higher-level management of pools of threads, some provide serialised and parallelised versions of the same methods, some implement actor models, and [many languages do many (or all) of these](https://books.google.ie/books?id=wSkRAAAAQBAJ). The programming language community doesn't seem to have yet come to a consensus on when and how parallelism should be applied, in spite of a well-established [pi-calculus](https://en.wikipedia.org/wiki/%CE%A0-calculus) having existed in theoretical computer science for decades.

Ateji PX threw its metaphorical hat into the ring around 2010, with its supremely simple parallelised blocks:

```java
public class HelloWorld {
  public static void main(String[] args) {
    [ System.out.println("Hello"); || System.out.println("World"); ]
  }
}
```

Above, the `[]` delimit a parallel block, inside of which, the operator `||` is used to create a parallel branch. The above code could print either

```
Hello
World
```

or

```
World
Hello
```

...depending on the order in which the parallel threads finish. On its own, this is pretty impressive, but Ateji PX uses the `||` operator in multiple places throughout the API, allowing users to easily parallelise loops:

```java
for||(int i : N) array[i]++; 
```

...implement recursive, parallelised algorithms:

```java
int fib (int n) {
  if (n <= 1) return 1;
  int fib1, fib2;

  // recursively create parallel branches
  [
    || fib1 = fib(n-1);
    || fib2 = fib(n-2);
  ]

  return fib1 + fib2;
}
```

...write elegant one-liners using sophisticated comprehension expressions:

```java
// sum all elements of the upper-left corner of matrix in parallel
int sum = `+ for|| (int i:N, int j:N, if i+j<N) matrix[i][j];
```

...use a concurrent channel (locally or across multiple machines) for passing messages between threads:

```java  
// declare a channel visible by both branches, and instantiate it 
Chan chan = new Chan(); 
[ 
  // in the first parallel branch, send a value over the channel 
  || chan ! "Hello"; 

  // in the second parallel branch, receive a value from the channel and print it 
  || chan ? s; System.out.println(s); 
]   
```

...and use _speculative parallelism_ to run multiple algorithms at once, returning a results as soon as the fastest one has finished:

```java
int[] sort(int[] array) {
  [
    || return mergeSort(array);
    || return quickSort(array);
  ]
}
```

You can read all about these (and more) features in [the whitepaper here](https://web.archive.org/web/20101223161629/http://www.ateji.com/px/whitepapers/Ateji%20PX%20for%20Java%20v1.0.pdf).

Unfortunately, Ateji, the company which created and maintained Ateji PX (as well as [OptimJ](https://en.wikipedia.org/wiki/OptimJ), another extension to Java), folded in 2012, so development of the language has stalled.

> If you're interested in reviving Ateji PX or applying its principles to your (or another) programming language, please send me a private message and I'd be happy to get you in touch with one of the original developers of the language, who has said he would be more than happy to help by contributing his expertise. You can check out the [language manual here](https://fr.slideshare.net/PatrickViry/ateji-px-manual) to get started.

I have to say that I'm actually kind of mad that I've never seen this notation before. It's -- if you can say this about a programming language -- beautiful. Abstracting away all the nonsense about `Thread`s and `Runnable`s and thread pools and replacing all of it with a single operator, `||`. What could be simpler?

[[ back to Table of Contents ]](#toc)

<a name="fantom"></a>
## \#7. [Fantom](https://www.fantom.org/) -- _"once" methods and lots of literals_

A neat feature of purely functional languages (because of the ["no side effects"](https://dzone.com/articles/side-effects-1) rule) is that they're often able to simplify values and methods by taking logical shortcuts. In some languages, for instance, functions which take no parameters but return a value may simply cache that value after having calculated it once. Then, when the function is called again, the value is simply returned and the body of the function is effectively ignored.

This technique, called [_memoization_](https://en.wikipedia.org/wiki/Memoization) can be used very effectively when, for instance, the user needs to interact with the disk. In a file explorer, for example, instead of interacting with the disk whenever the user moves into or out of a directory, we can simply cache the entire file tree (or a subset of it) ahead of time and the user can interact with that cached file tree, effectively eliminating disk read latency.

The Fantom programming language brings some interesting new features to the JVM, including memoization via its [`once` methods](https://www.fantom.org/doc/docLang/Methods#once):

```java
once Str fullName() { return "$firstName $lastName" }
```

> _(Fantom replaces Java's `String` type with `Str`.)_

`once` methods must be instance methods (not `static`), they must take no parameters, and they must return a value. They can throw `Exception`s, but then the body of the method will be re-run on subsequent calls until _some value_ is returned. Once a value is returned from the method, that value is cached and the body of the method is never again executed.

As you can see above, Fantom also allows for string interpolation. The values `firstName` and `lastName` are inserted in-place where they're included in a string with a preceding `$` character. In addition to string interpolation, Fantom offers [lots of small additions](https://www.fantom.org/doc/docLang/Literals) to Java's repertoire of _literals_, allowing object creation without explicitly invoking a `new` object. For instance:

```
0.2e+6D, 123_456d     // BigDecimal literals
100ms, -0.5sec, 2hr   // Duration literals
`/some/path/file.txt` // URI literals
0..5, 3..x, a..<b     // range literals (< == exclusive)
[1: "one", 2: "two"]  // Map literals
[10, 20, 30]          // List literals
...
```

Many, many more literals and improvements to string handling are available with Fantom. Fantom is a multi-paradigm language that supports functional programming through _closures_, concurrency through the _actor model_, and takes a "middle of the road" approach to static vs. dynamic typing. Fantom is truly a jack of all trades.

[[ back to Table of Contents ]](#toc)

<a name="whiley"></a>
## \#8. [Whiley](http://whiley.org/) -- _verification via formal specification_

Whiley, a JVM language introduced to the world around 2010, is David Pearce's attempt at introducing a programming language with a _verifying compiler_, [as described by Sir Tony Hoare](https://en.wikipedia.org/wiki/Whiley_(programming_language)):

> _"A verifying compiler uses mathematical and logical reasoning to check the correctness of the programs that it compiles."_

Hoare is famous for (among other things) his invention and subsequent condemnation of the _null reference_:

> _"I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years."_ [[ source ]](https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/)

Perhaps as a means of atoning for his "billion-dollar mistake", Hoare later developed a set of rules for reasoning about the correctness of programs, now known as [Hoare logic](https://en.wikipedia.org/wiki/Hoare_logic), or Floyd-Hoare logic. In 2003, Hoare put forth [a challenge](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.323.8760&rep=rep1&type=pdf) to computer scientists to develop a verifying compiler, warning that this might "involve [the] design of a new programming language and compiler, especially designed to support verification". Whiley attempts to do just that.

Unlike other programming languages, which had features tacked on in an attempt to introduce verifiability (like [ESC/Java](https://en.wikipedia.org/wiki/ESC/Java), [Frama-C](https://en.wikipedia.org/wiki/Frama-C) and others), Whiley was built from the ground up to facilitate verification.

Whiley is built on a pure functional foundation, and takes care to distinguish between _functions_ (no side effects, no state) and _methods_ (may introduce side effects, may have some internal state). Functions can be reasoned about with regards to verification, while methods are more complicated. Whiley also uses [a complex type system and defaults to immutable values](http://whiley.org/about/overview/) for compound variables like arrays and maps.

The following example Whiley function:

```java
function abs(int x) -> (int r)
ensures r >= 0
ensures r == x || r == -x:
    //
    if x >= 0:
       return x
    else:
       return -x
```

...has a [postcondition requirement](https://en.wikipedia.org/wiki/Postcondition) that the returned value must always be non-negative (`r >= 0`). During compilation, Whiley verifies that the returned value, `r`, meets this postcondition, through a logical analysis of the function definition (found below the postconditions).

By adding postconditions like this to functions throughout a program, Whiley can verify, at compile time, that a program is constructed correctly. This verification process _eliminates_ errors like divide-by-zero, array out-of-bounds and null dereference.

Whiley is still under active development, with the most recent version [(0.4.2)](http://whiley.org/2018/04/11/whiley-v0-4-2-released/) available as of April 2018.

[[ back to Table of Contents ]](#toc)

<a name="whiley2"></a>
## \#9. [Whiley](https://github.com/Whiley/WhileyCompiler) -- _flow-sensitive typing_

Another really neat feature of Whiley is its totally novel typing paradigm, _flow-sensitive typing_, which it introduced to the world in 2009. Whiley completely rewrites Java's typing model for ease of use, and to fulfill its goal of verifiability. First, __record types__ are introduced:

```java
type Circle    is { int x, int y, int radius }
type Square    is { int x, int y, int dimension }
type Rectangle is { int x, int y, int width, int height }
```

> Record types have [been proposed](https://openjdk.java.net/jeps/359) for inclusion in upcoming versions of Java, but are still only a preview feature in Java 14. Record types in Java would provide -- within an extremely compact definition -- a class definition with a default constructor, public instance variables based on the provided parameter names, and getters and setters for those parameters.

The above Whiley code is all that is needed to define three classes, with constructors and public instance variables. In addition, with Whiley, instance variables can be accessed and modified with the simpler dot notation, rather than using verbose setters and getters:

```java
Circle c1 = {x: 10, y: 20, radius: 30}
c1.x = 20
```

Whiley also provides __union types__:

```java
type Shape is Circle | Square | Rectangle
```

In the code above, `Shape` is a union type of `Circle`, `Square`, and `Rectangle`. The "pipes" `|` work in a very similar manner to the boolean OR operator from Java `|` -- an object is a `Shape` if it conforms to at least one of the three classes `Circle`, `Square`, or `Rectangle`.

Flow-sensitive typing means that the following is valid Whiley code:

```java
function area(Shape s) -> int:
    if s is Circle:
        return (3 * s.radius) * s.radius
    else if s is Square:
        return s.dimension * s.dimension
    else:
        return s.width * s.height
```

The `is` operator, above, checks during runtime if the object `s` conforms to the `Circle` or `Square` record definition. If the former, then we can simply use `Circle`-specific methods and accessors, without needing to explicitly cast `s` to a `Circle` object, like in Java. Since Whiley is aware of the definition of `Circle`, it can check that all operations performed using `s` after the `if s is Circle` clause are valid, according to the definition of `Circle`.

> _**N.B.**: [Whiley does not yet support floating-point numeric types](https://github.com/Whiley/WhileyCompiler/wiki), hence the incorrect circle area formula above. I assume this is due to the inherent granularity of floating-point types on digital computers and some difficulty with reasoning about the "correctness" of a program where [machine epsilons](https://en.wikipedia.org/wiki/Machine_epsilon) are important._

The above is accomplished through [__intersection types__](http://homepages.ecs.vuw.ac.nz/~djp/files/VMCAI13.pdf). Whiley takes the type of object `s`, whatever that happens to be, and intersects it with type `Circle`. Since `s` must be a `Shape`, there are three possibilities:

```java
Circle & Circle
Square & Circle
Rectangle & Circle
```

Whiley's compiler recognizes that the last two type intersections are the null set (because `Circle` doesn't extend either `Square` or `Rectangle` and vice versa), so the `if` statement will only execute if `s` is a `Circle` record. A more interesting version of this might be something like:

```
import string from std::ascii
import std::io

method main():
    integerOrString(10)
    integerOrString("10")

method integerOrString(int|string x):
    if x is int:
        io::println(x+5)
    else:
        io::println(x)
```

([Try it out here!](http://whileylabs.com/))

Whiley uses flow-sensitive typing to pick the `if` or `else` branch at runtime. If `x` is an `int`, it will be increased by 5, then printed. Otherwise, it will be printed as-is. This, of course, works similarly to `instanceof` in Java, but is much more elegant.

[[ back to Table of Contents ]](#toc)

<a name="jython-jruby"></a>
## \#10. [Jython](https://www.jython.org/) & [JRuby](https://www.jruby.org/) -- _language interoperability_

[Jython](https://github.com/jythontools/jython) and [JRuby](https://github.com/jruby/jruby) are two of the earliest non-Java JVM languages, first released in 1997 and 2001, respectively. These languages are designed to offer _interoperability_ between Java and Python, and Java and Ruby, respectfully. This means that Jython allows for Python code to be run from within Java, and vice versa. JRuby provides the same features, but for the Ruby language.

Here's an example of some simple Python code being run within Java using Jython:

```java
import org.python.util.PythonInterpreter;

public class JythonHelloWorld {
  public static void main (String[] args) {

    try(PythonInterpreter pyInterp = new PythonInterpreter()) {
      pyInterp.exec("print('Hello, World!')");
    } catch (Exception ex) {
      ex.printStackTrace();
    }

  }
}
```

...similar code, but for Ruby running with JRuby:

```java
import javax.script.ScriptEngine;
import javax.script.ScriptEngineManager;

public class JRubyHelloWorld {

  ScriptEngineManager mgr = new ScriptEngineManager();
  ScriptEngine rbEngine = mgr.getEngineByExtension("rb");

  public static void main (String[] args) {

    try {
      rbEngine.eval("puts 'Hello, World!'");
    } catch (ScriptException ex) {
      ex.printStackTrace();
    }
    
  }
}
```

Language interoperability is a bit of a hot topic in the JVM community at the moment, especially with the recently-released [GraalVM](https://en.wikipedia.org/wiki/GraalVM) Java Virtual Machine and Development Kit. GraalVM offers mutual interoperability between [multiple languages, including](https://www.graalvm.org/docs/getting-started/):

- JavaScript and Node.js
- Ruby and Ruby on Rails
- R
- Python 3
- LLVM-based languages

Will GraalVM -- an Oracle product -- spell the end for Jython and JRuby? Will Oracle peel developers away from these other projects to work on GraalVM? Will I think of a third example? We'll just have to wait and see.

[[ back to Table of Contents ]](#toc)

<a name="clojure"></a>
## \#11. [Clojure](https://www.jython.org/) -- _"LISP for the JVM"_

While [Frege and Eta](#frege-eta) provide slightly altered versions of Haskell for the JVM, [Jython and JRuby](#jython-jruby) offer interoperability with Python and Ruby, respectively, and GraalVM expands that interoperability to include JavaScript, R, and more, Clojure brings yet another language to the JVM: LISP.

I've developed an infatuation with LISP recently. I like the fact that -- like [Ioke](#ioke), above -- it's [a homoiconic language](https://dev.to/awwsmm/concept-of-the-day-homoiconicity-4did), meaning the program itself _is_ a data structure within the programming language, namely a list. This property means that LISP programs can operate on their own source code as though they were data (a list), because _they are_. Input, output, and source code all conform to the same structure, and can easily be read, written, and manipulated using the LISP language.

[Clojure](https://github.com/clojure/clojure/) brings this flexibility to the JVM, while refreshing and updating LISP for the twenty-first century. Clojure takes full advantage of the JVM, as well, allowing Java methods and classes to be called from within Clojure code:

```clojure
(doto (java.util.HashMap.)
  (.put "apple" 1)
  (.put "banana" 2))
```

The above code returns a `java.util.HashMap`; in Clojure syntax, this will be written as `{"banana" 2, "apple" 1}`. Threading macros in Clojure also allow for easy functional programming:

```clojure
(->> (range 10)
     (map inc)
     (filter even?))
```

The above code returns the list `(2 4 6 8 10)`.

With all of these amazing projects providing interoperability between Java and various other programming languages, I think the JVM will be around for a long, long time.

[[ back to Table of Contents ]](#toc)

<a name="scala"></a>
## \#12. [Scala](https://www.scala-lang.org/) -- _"everything is an object"_

As we get toward the end of this list, we're now in the region of "popular" non-Java JVM languages. Scala, Kotlin, and Groovy are [the only three languages on this list which crack the top 25 most popular languages on GitHub](https://www.benfrederickson.com/ranking-programming-languages-by-github-users/). As Scala is a language I am relatively familiar with, let's start there.

Scala is designed to be a **Sca**lable **La**nguage, great for short scripts, small projects, gigantic monolithic services, and agile microservices alike. Scala is the brainchild of [Professor Martin Odersky](https://people.epfl.ch/martin.odersky/bio?lang=en&cvlang=en) of l'École Polytechnique Fédérale de Lausanne (EPFL), who has helped to develop several JVM languages, including [Pizza](https://en.wikipedia.org/wiki/Pizza_(programming_language)) and [Generic Java](https://en.wikipedia.org/wiki/Generics_in_Java) (which became the basis of generic types in Java), as well as implementing the GJ compiler for Java, on which [javac](https://en.wikipedia.org/wiki/Javac) was then based.

Scala sits at the intersection of several popular paradigms and trends in programming. The first, and probably most obvious of these, is object-oriented programming. As a JVM language, Scala inherits and builds upon Java's object hierarchy.

While Java has always had a sort of two-worlds approach to OOP, with "primitives" treated differently than true `Object`s, Scala unifies the hierarchy by promoting these basic data types to "real" objects -- `int` becomes `Int`, `double` becomes `Double`, and so on. These [_value types_](https://en.wikipedia.org/wiki/Value_type_and_reference_type) all descend from a common value object, `AnyVal`.

"But what about boxing and unboxing?" you might ask, "...don't they effectively convert primitives to objects and vice-versa?" While this is true, this conversion must be explicitly performed if you want to, say, call a method on a Java primitive:

```java
jshell> 3.toString()
|  Error:
|  ';' expected
|  3.toString()
|    ^

jshell> int x = 3
x ==> 3

jshell> x.toString()
|  Error:
|  int cannot be dereferenced
|  x.toString()
|  ^--------^

jshell> (new Integer(3)).toString()
$2 ==> "3"
```

Scala _implicitly_ makes these conversions for you ([see #15](#scala4)), so all of `Integer`'s methods are available to use on integer literals:

```scala
scala> 3.toString()
res0: String = 3
```

And since the Scala compiler converts these to Java primitives at compile time, there is no performance overhead. An additional benefit of this is that no special operators need to be defined for primitives. The arithmetic operators `+`, `-`, `*`, `/` (and more) are simply defined as functions within Scala, which allows [all sorts of symbols](https://stackoverflow.com/a/7657692/2925434) within identifiers.

> Java's Project Valhalla aims to bring Scala-like value types to Java via [generic specializations](https://dzone.com/articles/what-is-project-valhalla). Valhalla [also introduces "value types"](https://en.wikipedia.org/wiki/Project_Valhalla_(Java_language)) for Java which are different from Scala's value types, and closer to [C's `struct`s](https://www.tutorialspoint.com/cprogramming/c_structures.htm).

Similarly, on the "Java-like object" side of the inheritance tree, we have `AnyRef`, which is the ancestor of all _reference types_. `AnyVal` and `AnyRef` both descend from `Any`, Scala's equivalent of Java's `Object` root class. Specifying `Any` in a type parameter means that _any_ data type can be substituted, even basic data types like `Int` and `Double`.

Similarly, at the bottom of the hierarchy, we have the `Null` and `Nothing` types. The `Null` singleton object can be substituted for any class which extends `AnyRef`, and `Nothing` can be substituted for any class at all. These "pinch points" at the bottom and top of the class hierarchy unify Scala's object model in a way which makes Java's look a bit fragmented and incomplete.

There are other, less obvious manifestations of the "everything is an object" philosophy in Scala. These are achieved primarily through [syntactic sugar](https://en.wikipedia.org/wiki/Syntactic_sugar), which interprets the name of an object (or a companion object of a class<sup>*</sup>) followed by a parameter list in parentheses as calling the `apply()` method on that object:

```scala
scala> :paste
// Entering paste mode (ctrl-D to finish)

object Example {
  def apply(x: Int) { println(s"x is $x") }
}

// Exiting paste mode, now interpreting.

defined object Example

scala> Example(4) // equivalent to Example.apply(4)
x is 4
```

> \* Objects defined with the `object` keyword in Scala are equivalent to singleton classes in Java. And a companion object can be thought of as a container for `static`-like methods, which can be called by any object of that class. Scala companion objects must have the same name as their companion class. (The confusion between `Object`s, `object`s and objects is real.)

This syntactic sugar means that we can have classes that code like classes but act like functions, including:

- [actual __`Function`s__](https://github.com/scala/legacy-svn-scala/blob/master/src/library/scala/Function1.scala) -- which are objects that `extend AnyRef` and have an `apply()` method

- [__`Map`s__](https://github.com/scala/legacy-svn-scala/blob/master/src/library/scala/collection/mutable/HashMap.scala) -- whose `apply()` functions take a key parameter and return a value

- [__`List`s__ and other sequences](https://github.com/derekwyatt/scala/blob/master/src/library/scala/collection/immutable/List.scala) -- whose `apply()` methods take an index and return the value at that index

These unifications of the object hierarchy and syntax mean that there are fewer "exceptions to the rules" in Scala. You don't access array elements with `[]` like you do in Java; `Function`s aren't a special type of construct, separate from objects; and there is no primitive/object distinction. Scala adds a bit of syntactic sugar, and extends the object hierarchy a bit, and everything seems to nicely fall into place.

[[ back to Table of Contents ]](#toc)

<a name="scala2"></a>
## \#13. [Scala](https://github.com/scala/scala) -- _everything is an expression_

Scala attempts to remove even more "exceptions to the rules" with the idea that ["everything is an expression"](https://www.james-willett.com/scala-expressions/). In most programming languages, there are distinctions between various kinds of syntactical constructs, like [expressions, operators, and control structures](https://link.springer.com/chapter/10.1007%2F978-1-4302-0856-3_3). As mentioned above, Scala eliminates the need for explicit, hard-coded _operators_ through its expanded class hierarchy, but it also streamlines many control structures by applying a few concepts from the functional programming paradigm.

In many languages, `if-else` is a control structure which looks something like

```c
if (condition) {
  // do something
} else {
  // do something different
}
```

Within the `if` and `else` blocks, you can affect the execution of the program through [_side-effects_](https://en.wikipedia.org/wiki/Side_effect_(computer_science)), by mutating variables or performing IO, etc. If we wanted a variable to depend on the value of the condition, we would do something like

```c
var y;

if (condition) {
  y = ...
} else {
  y = ...
}
```

This requires us to be able to mutate the value of `y` (ie. it's not constant, which can be undesirable), and it requires us to "reach up" out of the scope of the `if-else` block to affect the value of `y` in the enclosing scope.

In _many_ languages, you cannot do something like this, though:

```scala
var y = if (x < 3) "less then" else "greater than or equal to"
```

...that is, assigning the result of the `if-else` to a variable. This requires a bit of a re-orientation [from procedural to functional programming](https://en.wikipedia.org/wiki/Procedural_programming). In procedural programming, we have explicit `return` statements, [and often "return early" for performance and code cleanliness reasons](https://softwareengineering.stackexchange.com/q/104551/294935). Multiple and early returns are frowned upon in functional programming, however, because it makes it more difficult for the compiler to reason about the flow within the program.

One common trope in functional languages is the idea that the _last-computed value_ in a block is the "return value" of that block. This allows us to omit the `return` keyword entirely, and can simplify the flow of the code considerably. For example:

```scala
val area = {
  val pi = 3.14159
  val r  = 10
  pi * r * r
}
```

The lack of `return` statements means that this block will always run from start to finish. Because we're assigning to a variable, the expression isn't parameterized in any way, and the value of the block will always be the same. If this were a function, we could cache the result to avoid recomputing the same value over and over.

The "last computed value is the return value" concept means that even though the last line of the block (`pi * r * r`) wasn't assigned to any variable _within_ the block, because it's the last computed value in that block, it _is the value of the block_. Since the block can be evaluated, it can be assigned to a variable, as is done above.

`if-else` statements in Scala follow these same rules. The last computed value in a block is the value of that block, so while in Java, the following code

```scala
if (x < 3) {
  "less than"
} else {
  "greater than or equal to"
}
```

...would have no effect, in Scala, the entire `if-else` block assumes a value after running, which means it can be assigned to a variable

```scala
var y = if (x < 3) {
  "less than"
} else {
  "greater than or equal to"
}
```

And just like in Java, we can drop the `{}` around single-line `if-else` blocks:

```scala
var y = if (x < 3)
    "less than"
  else
    "greater than or equal to"

// or just
var y = if (x < 3) "less than" else "greater than or equal to"
```

Treating even basic control statements as expressions which "return" a value lets us [streamline our code and makes it easier to reason about and test program execution](https://alvinalexander.com/scala/best-practice-think-expression-oriented-programming-eop/).

> As a side note, we can kind of recreate this behavior using only "Java-style" `if`s and `return`s by using implicit conversions and by-name parameters:
> ```scala
> scala> :paste
> // Entering paste mode (ctrl-D to finish)
> 
> implicit class Elseable (x: Any) {
>  def ELSE (elval: => Any): Any = if (x == ()) return(elval) else return(x)
> }
> 
> def IF(cond: Boolean)(ifval: => Any): Any = if (cond) return(ifval)
> 
> // Exiting paste mode, now interpreting.
> 
> defined class Elseable
> IF: (cond: Boolean)(ifval: => Any)Any
> 
> scala> IF (true) { "T" } ELSE { "F" }
> res0: Any = T
> 
> scala> IF (false) { "F" } ELSE { "T" }
> res1: Any = T
> 
> scala> IF (true) { "T" }
> res2: Any = T
> 
> scala> IF (false) { "F" }
> res3: Any = ()
> ```

[[ back to Table of Contents ]](#toc)

<a name="scala3"></a>
## \#14. [Scala](https://web.archive.org/web/20071009004609/http://www.scala-lang.org/downloads/history.html) -- _case classes and pattern matching_

[Pattern matching](https://en.wikipedia.org/wiki/Pattern_matching) is like regular expressions, but for the structure of objects rather than for the structure of strings. Pattern matching can be found throughout professional Scala code, but one of the more obvious places it can be seen is in `match` expressions.

Think of a `match` expression like a superpowered `switch`. Whereas in Java, we define a `switch` with contains multiple `case`s, separated by `break`s, in Scala, we define a `match` expression with multiple `case`s, but the compiler inserts breaks for us whenever it encounters a new `case` keyword. This means there is no fall-through in Scala `match` expressions.

A simple, Java-like `match` expression might look like:

```scala
scala> :paste
// Entering paste mode (ctrl-D to finish)

val x = 3

x match {
  case 1 => "x is one"
  case 2 => "x is two"
  case 3 => "x is three"
}

// Exiting paste mode, now interpreting.

x: Int = 3
res4: String = x is three
```

...but that doesn't even scratch the surface of what can be done with Scala `match` expressions. You can add filters in your `case`s (and default matches, denoted by `case _ =>`):

```scala
scala> :paste
// Entering paste mode (ctrl-D to finish)

val x = 3

x match {
  case _: Int if x < 0 => "x is negative"
  case _: Int if x > 0 => "x is positive"
  case _ => "x is zero" // default
}

// Exiting paste mode, now interpreting.

x: Int = 3
res11: String = x is positive
```


You can match on specific types:

```scala
scala> def whatIsIt (x: Any) = x match {
     |   case _: Double => "x is a Double"
     |   case _: Int => "x is an Int"
     |   case _: String => "x is a String"
     | }
whatIsIt: (x: Any)String

scala> whatIsIt(3)
res8: String = x is an Int

scala> whatIsIt(3.4)
res9: String = x is a Double

scala> whatIsIt("3")
res10: String = x is a String
```

You can even use pattern matching to _deconstruct_ objects, pulling out the arguments that were used to create them:

```scala
scala> :paste
// Entering paste mode (ctrl-D to finish)

sealed trait Shape
case class Rect(height: Int, width: Int) extends Shape
case class Circle(radius: Int) extends Shape
case class Square(size: Int) extends Shape

// Exiting paste mode, now interpreting.

defined trait Shape
defined class Rect
defined class Circle
defined class Square

scala> def whatIsIt (s: Shape) = s match {
     |   case Rect(h, w) => s"a Rect with width $w and height $h"
     |   case Circle(r) => s"a Circle with radius $r"
     |   case Square(s) => s"a Square with side length $s"
     | }
whatIsIt: (s: Shape)String

scala> val r = Rect(3, 4)
r: Rect = Rect(3,4)

scala> val c = Circle(5)
c: Circle = Circle(5)

scala> val s = Square(9)
s: Square = Square(9)

scala> whatIsIt(r)
res15: String = a Rect with width 4 and height 3

scala> whatIsIt(c)
res16: String = a Circle with radius 5

scala> whatIsIt(s)
res17: String = a Square with side length 9

```

In that last example, I made use of a `sealed trait` which was extended by several `case class`es. Scala's `trait`s are similar to Java's `interface`s, and `case class`es are similar to [Whiley's record types](#whiley2).

`match` expressions and `case class`es are truly a _match_ made in heaven [hold for applause]. Why? Well, because by using the _type_ of the object to control the flow of the program, the compiler is helping to check if your code is correct.

A `sealed trait`, as used above, means that any classes which extend it _must appear in the same location_ (usually the same source code file) in which the `sealed trait` is defined. This means that in our example, `Rect`, `Circle`, and `Square` are _the only_ classes which extend `Shape`, so whenever we `match` on a `Shape`, the compiler can double-check that we've covered all our bases by providing patterns for `Rect`, `Circle`, and `Shape`, and only those three classes.

We will get a compile time error / warning if we have a non-exhaustive `match` (if we missed a `case class`) or if we try to match on a class which `s: Shape` could never match (a `Double`, for instance). `match` expressions and `case class`es are a really powerful duo in Scala.

[[ back to Table of Contents ]](#toc)

<a name="scala4"></a>
## \#15. [Scala](https://en.wikipedia.org/wiki/Scala_(programming_language)) -- _implicit programming_

One of the guiding principles of the Python programming language (the _Zen of Python_) is the phrase ["explicit is better than implicit"](https://en.wikipedia.org/wiki/Zen_of_Python). That quote, from Tim Peters, a major early contributor to Python and inventor of [the Timsort sorting algorithm](https://en.wikipedia.org/wiki/Timsort), must not have made it to Martin Odersky's ears before he started work on Scala just a few short years later. Scala is rife with implicits.

To be fair, Scala was built on top of Java, and to extend Java in any meaningful way -- for instance, to add functionality to a class defined in Java source code -- you need to jump through some hoops. This is made even more difficult for classes like `String`, which is immutable _and_ `final` (for [good reasons](https://javarevisited.blogspot.com/2010/10/why-string-is-immutable-or-final-in-java.html)). Scala uses a concept called _implicit conversions_ to automatically convert Java classes into Scala classes (and vice versa), covertly jumping through those hoops for you.

If you've programmed in Java before, [you've actually used implicit conversions already](https://en.wikipedia.org/wiki/Type_conversion#Implicit_type_conversion). When you write something like

```java
jshell> 1 + 3.0
$1 ==> 4.0
```

...Java is converting the `int 1` to a `double 1.0`, automatically and implicitly (nothing in the code tells you outright that that is what's happening). But [integer and floating-point numbers have very different internal representations](https://en.wikipedia.org/wiki/Primitive_data_type#Specific_primitive_data_types), so it's not just a matter of relabeling an `int` as a `double`, the compiler actually needs to shift bits around.

As we know from Java, even _explicit_ primitive conversions can be dangerous. If you try to convert a `long` to an `int`, you'd better be sure that that `long` doesn't exceed `Integer.MAX_VALUE`

```java
jshell> long l = Integer.MAX_VALUE + 2000000000L
l ==> 4147483647

jshell> int i = l
|  Error:
|  incompatible types: possible lossy conversion from long to int
|  int i = l;
|          ^

jshell> int i = (int) l
i ==> -147483649
```

Java will only implicitly _widen_ primitive types. To _narrow_ them (`double` -> `float` or `long` -> `int` -> `char` -> `byte`), you must explicitly declare the conversion with a typecast, as above. But this can lead to unexpected results, like the `long` above that wrapped around to a negative `int`.

To avoid overly verbose conversions between Java and Scala types, Scala uses implicit conversions to convert Java's primitives to Scala's wrapper types (which extend `AnyVal`), Java's `String`s to string-like helper classes in Scala, and more.

> __But this can be just as dangerous in Scala as it is in Java, so be careful!__

Implicit programming comes in different shapes and sizes in Scala, but the two most common usages are

1. `implicit` parameters, and
2. `implicit` conversions

[Implicit parameters](https://docs.scala-lang.org/tour/implicit-parameters.html) in Scala are arguments which are not explicitly sent to a function. These parameters must be declared `implicit` in the parameter list, and there must be an `implicit` variable of the same type within scope (defined by some slightly complex scoping rules):

```scala
scala> implicit val ii: Int = 42
ii: Int = 42

scala> def answer (to: String)(implicit num: Int) {
     |   println(s"The answer to $to is... $num!")
     | }
answer: (to: String)(implicit num: Int)Unit

scala> answer("life, the universe, and everything")
The answer to life, the universe, and everything is... 42!
```

Notice how, in the above code snippet, we didn't explicitly send the value `42` to the procedure `answer`. Instead, it knew it needed an `implicit Int`, and it looked for -- and found one -- within scope. There are rules for handling collisions between `implicit` parameters, passing multiple `implicit` arguments, and making `implicit` parameters explicit with the [`implicitly`](https://stackoverflow.com/a/3859512/2925434) keyword.

`implicit` parameters are usually used when you have many methods passing "environment"-type arguments to each other. Rather than clog up your code with lots of argument-passing, make everything implicit!

```scala
scala> implicit val bb = false
bb: Boolean = false

scala> implicit val dd = 19.0
dd: Double = 19.0

scala> implicit val ss = "my string"
ss: String = my string

scala> def myBool(implicit myb: Boolean) {
     |   println(s"  my boolean is $myb")
     | }
myBool: (implicit myb: Boolean)Unit

scala> def myDub(implicit myd: Double) {
     |   println(s"  my double is $myd")
     | }
myDub: (implicit myd: Double)Unit

scala> def myStr(implicit mys: String) {
     |   println(s"  my string is $mys")
     | }
myStr: (implicit mys: String)Unit

scala> def myThings() {
     |   println("These are my things:")
     |   myBool
     |   myDub
     |   myStr
     | }
myThings: ()Unit

scala> myThings
These are my things:
  my boolean is false
  my double is 19.0
  my string is my string
```

Implicit conversions are slightly more complex (and slightly more dangerous). They are disabled by default, but can be enabled with `import scala.language.implicitConversions`.

With the above package imported, when an object in Scala tries to access a method or value which it wouldn't normally have access to, the Scala compiler will look (following the same `implicit` scoping rules) for an `implicit def` which takes a single argument of that object's type, and returns an object of any type which has that missing method or value defined:

```scala
scala> "hey".exclaim()
<console>:12: error: value exclaim is not a member of String
       "hey".exclaim()
             ^

scala> import scala.language.implicitConversions
import scala.language.implicitConversions

scala> class Exclaimable (s: String) {
     |   def exclaim(): String = s + "!"
     | }
defined class Exclaimable

scala> implicit def string2Exclaimable (s: String): Exclaimable = new Exclaimable(s)
string2Exclaimable: (s: String)Exclaimable

scala> "hey".exclaim()
res1: String = hey!
```

Implicit conversions seem great at first glance (and they're used heavily by the language itself to convert Java <=> Scala), but -- I cannot stress this enough -- [they are dangerous](https://www.rallyhealth.com/coding/implicit-implications-part-2-implicit-conversions). [Since Scala 2.10](https://alvinalexander.com/scala/scala-2.10-implicit-class-example/), implicit conversions are discouraged, and should be replaced with [explicit converters](https://www.scala-lang.org/api/2.12.1/scala/collection/JavaConverters$.html) or `implicit class`es instead:

```scala
scala> "hey".exclaim()
<console>:12: error: value exclaim is not a member of String
       "hey".exclaim()
             ^

scala> implicit class Exclaimable (s: String) {
     |   def exclaim(): String = s + "!"
     | }
defined class Exclaimable

scala> "hey".exclaim()
res1: String = hey!
```

[[ back to Table of Contents ]](#toc)

<a name="groovy"></a>
## \#16. [Groovy](https://groovy-lang.org/) -- _partial application and composition of functions_

Apache's Groovy programming language offers [lots of neat ways of working with closures](https://groovy-lang.org/closures.html), defined in Groovy as "open, anonymous, block[s] of code that can take arguments, return a value and be assigned to a variable".

Groovy's closures take the form

```groovy
{ [closureParameters -> ] statements }
```

They are curly-brace-delimited blocks of code, with zero or more comma-separated parameters transformed into some output. They may return a value, cause side-effects like printing to the terminal, both, or neither. They can access variables outside the scope of their defining block as well. The following are all valid closures in Groovy:

```groovy
c0 = { x++ }
c1 = { x, y -> x + y }
c2 = { -> println("sup") }
c3 = { a, b, c -> }
```

Closures can be called with a comma-separated list of parameters just like normal functions, so the above closures could be used like:

```groovy
[in]> c1(3, 4)
[ou]> 7

[in]> x = 42
[ou]> 42

[in]> c0()
[ou]> 43

[in]> c1(-3, 6)
[ou]> 3

[in]> c2()
sup
[ou]> null

[in]> c3(19, "popty-ping", false)
[ou]> null
```

Groovy lets you play with closures in interesting ways. For instance, Groovy allows _partial application of closures_ -- which it calls "currying", acknowledging that this is not actually currying in the strict sense:

```groovy
[in]> x_pow_y = { x, y -> x**y }
[ou]> groovysh_evaluate$_run_closure1@15130002

[in]> x_pow_y(2, 3)
[ou]> 8

[in]> x_pow_3 = x_pow_y.rcurry(3)
[ou]> org.codehaus.groovy.runtime.CurriedClosure@1f6f0fe2

[in]> x_pow_3(2)
[ou]> 8

[in]> two_pow_y = x_pow_y.curry(2)
[ou]> org.codehaus.groovy.runtime.CurriedClosure@2591d23a

[in]> two_pow_y(3)
[ou]> 8
```

As seen above, we can send only the leftmost parameter (with `curry()`) or only the rightmost parameter (with `rcurry()`) and get back a new function which takes one fewer arguments. ([Here's a good explanation](https://stackoverflow.com/a/23438430/2925434) of the differences between currying and partial application if you're interested.)

You can also set an arbitrary parameter with `ncurry`:

```groovy
[in]> sum_abc = { a, b, c -> a + b + c }
[ou]> groovysh_evaluate$_run_closure1@26d028f7

[in]> sum_abc(2, 3, 4)
[ou]> 9

[in]> sum_a3c = sum_abc.ncurry(1, 3)
[ou]> org.codehaus.groovy.runtime.CurriedClosure@45c90a05

[in]> sum_a3c(2, 4)
[ou]> 9
```

Groovy offers lots of other cool features for closures, including [trampolining](https://en.wikipedia.org/wiki/Trampoline_(computing)) for tail-call optimization, memoization, and transforming regular functions into closures via method pointers, but one other small feature I want to take a look at here is function composition.

You've probably encountered function composition in your high school mathematics classes, or when using the pipe `|` operator in a terminal. Basically, a composition of functions works like the following:

```groovy
(f << g)(x) == f(g(x))
```

In Groovy, `<<` is the function composition operator, and it pipes the output of function `g` into the input of function `f`:

```groovy
[in]> f = { x -> x + 2 }
[ou]> groovysh_evaluate$_run_closure1@5db9f51f

[in]> g = { x -> x * 3 }
[ou]> groovysh_evaluate$_run_closure1@12f8682a

[in]> (f << g)(5)
[ou]> 17

[in]> f(g(5))
[ou]> 17
```

You can also compose functions in reverse order with `>>`:

```groovy
[in]> (f >> g)(5)
[ou]> 21

[in]> g(f(5))
[ou]> 21
```

Function composition makes it easy to chain functions together, creating reusable data manipulation pipelines. Plus, [it's neat](https://www.youtube.com/watch?v=DrQqajtiRt4)!

[[ back to Table of Contents ]](#toc)

<a name="groovy2"></a>
## \#17. [Groovy](https://github.com/apache/groovy) -- _easy regular expressions_

In my opinion, one of the places where Groovy most obviously outshines Java is in its [support for regular expressions](https://e.printstacktrace.blog/groovy-regular-expressions-the-definitive-guide/). It's not even a competition. Groovy has all sorts of extra [bits of syntax](https://dev.to/awwsmm/bits-of-syntax-assignment-2f5o) to help you define and use regex.

> If you're new to regex, or want a refresher, why not check out my interactive guide [20 Small Steps to Become a Regex Master](https://dev.to/awwsmm/20-small-steps-to-become-a-regex-master-mpc)

In Java, defining and using a regular expression is -- like most things Java -- [very verbose](https://www.vogella.com/tutorials/JavaRegularExpressions/article.html#pattern-and-matcher):

```java
import java.util.regex.Matcher;
import java.util.regex.Pattern;

public class Example {
  public void run() {
    String example = "The President of the United States of America";
  
    Pattern pattern = Pattern.compile("\\b[a-zA-Z]{1,3}\\b");
    Matcher matcher = pattern.matcher(example);
	
    while (matcher.find())
      System.out.println(matcher.group());
  }
}
```

Running the above code in the `jshell` would give:

```java
jshell> (new Example()).run()
The
of
the
of
```

There's a lot of ceremony for setting up and running a regular expression over a Java String. (And I made the example about as short as I could.) In Groovy, it's much simpler:

```groovy
example = "The President of the United States of America"
pattern = ~/\b[a-zA-Z]{1,3}\b/
matcher = example =~ pattern
```

We can then find all matches with

```groovy
[in]> matcher[0..-1]
[ou]> [groovier, better]
```

How simple is that? Above, we defined `pattern` using a _slashy string_, which is a string surrounded by `//` rather than by `""`. Slashy strings are [raw strings](https://wiki.c2.com/?RawStrings), in which escape sequences are ignored, so we don't need to "double-up" on the backslashes to get the [regex word boundary](https://stackoverflow.com/a/50634830/2925434) sequence (just `\b` instead of `\\b`).

We also used the _pattern operator_ `~` before the string, which transforms that string into a `Pattern` in a manner similar to `Pattern.compile()`. Then, we ran the expression on our example string with the _find_ operator `=~`, instead of running `pattern.matcher()` as we did in Java.

In Groovy, you can also use the presence or absence of a match as a booleean value...

```groovy
[in]> if ("The password is... PorkChop" =~ /(?i)porkchop/) {
[in]>   println "you're in"
[in]> } else {
[in]>   println "scram!"
[in]> }
you're in
```

...easily extract and assign several variables at once using Groovy's multiple assignment...

```groovy
[in]> (ghost1, ghost2, ghost3, ghost4) = ("Inky, Pinky, Blinky, and Clyde" =~ /[A-Z][a-z]*/)
[ou]> java.util.regex.Matcher[pattern=[A-Z][a-z]* region=0,30 lastmatch=Clyde]

[in]> println "Oh no, it's $ghost2, $ghost1, $ghost4, and uh... $ghost3?"
Oh no, it's Pinky, Inky, Clyde, and uh... Blinky?
```

...and [much more](https://jarombek.com/blog/jul-11-2018-groovy-regex)! By making regular expressions less verbose, Groovy is making them more accessible, and less anxiety-inducing for new devs.

[[ back to Table of Contents ]](#toc)

<a name="groovy3"></a>
## \#18. [Groovy](https://en.wikipedia.org/wiki/Apache_Groovy) -- _JSON-to-classes_

Love it or hate it, [JSON](https://en.wikipedia.org/wiki/JSON) is quickly becoming the de-facto standard for data transfer on the web. This simple text file format, which describes arbitrarily-nested objects of basic data types and arrays has quickly achieved widespread appeal because it is [easy to write, easy to read, and easy to parse](https://www.w3schools.com/js/js_json_xml.asp).

Although inspired by -- and named after -- the language, JavaScript Object Notation (JSON) was not strictly a subset of JavaScript [until 2019, when a new version of ECMAScript was released](https://github.com/tc39/proposal-json-superset). (JSON used to allow characters which were illegal in JavaScript objects, in particular.) JSON objects can now be quickly, easily, and safely parsed from text files and automatically translated into objects in JavaScript.

Groovy provides the same functionality, but on the JVM. Groovy's [built-in `JsonSlurper` class](http://docs.groovy-lang.org/2.4.0/html/gapi/groovy/json/JsonSlurper.html) allows JSON data to be automatically parsed from a simple string format into a fully-fledged Groovy object:

```groovy
[in]> slurper = new groovy.json.JsonSlurper()
[ou]> groovy.json.JsonSlurper@bea5941

[in]> result = slurper.parseText('{"person":{"name":"Guillaume","age":33,"pets":["dog","cat"]}}')
[ou]> [person:[name:Guillaume, age:33, pets:[dog, cat]]]

[in]> result.person.age
[ou]> 33

[in]> result.person.pets
[ou]> [dog, cat]

[in]> result.person.name
[ou]> Guillaume
```

Of course, it's possible to do this in plain Java, but as JSON is becoming more and more popular, there's more and more of an argument to be made for including it in a language's standard library, which Groovy has already done! And it "just works", right out of the box -- super easy!

[[ back to Table of Contents ]](#toc)

<a name="kotlin"></a>
## \#19. [Kotlin](https://kotlinlang.org) -- _JavaScript transpilation_

While we're on the topic of the web, it can sometimes be difficult for backend developers to showcase their work, or to easily create portfolios. Frontend devs have a huge canvas at their disposal -- the web browser -- which can be really difficult to access if you're not working in JavaScript or TypeScript.

Kotlin tries to [close the frontend / backend dev divide](https://www.reddit.com/r/Kotlin/comments/818mz4/kotlin_javascript_is_awesome/) a bit with its ability to compile not just to Java bytecode via the JVM, or to [over a dozen different native architectures](https://kotlinlang.org/docs/reference/native-overview.html) through LLVM, but also by [transpiling directly to JavaScript](https://kotlinlang.org/docs/tutorials/javascript/kotlin-to-javascript/kotlin-to-javascript.html), where you can run Kotlin in your browser!

Just [write a simple Kotlin function](https://superkotlin.com/kotlin-javascript/) like

```kotlin
import kotlin.browser.*
import kotlin.dom.*
fun main(args: Array<String>) {
    document.getElementById("tooltip")?.appendText("The first step")
}
```

...transpile, and you'll get JavaScript output that looks something like:

```kotlin
if (typeof kotlin === 'undefined') {
  throw new Error("Error loading module 'KotlinFunWeb'. Its dependency 'kotlin' was not found. Please, check whether 'kotlin' is loaded prior to 'KotlinFunWeb'.");
}
var KotlinFunWeb = function (_, Kotlin) {
  'use strict';
  var appendText = Kotlin.kotlin.dom.appendText_46n0ku$;
  function main(args) {
    var tmp$;
    (tmp$ = document.getElementById('tooltip')) != null ? appendText(tmp$, 'The first step') : null;
  }
  _.main_kand9s$ = main;
  main([]);
  Kotlin.defineModule('KotlinFunWeb', _);
  return _;
}(typeof KotlinFunWeb === 'undefined' ? {} : KotlinFunWeb, kotlin);
```

Showing off your Kotlin skills has never been easier! Here's a [template](https://github.com/bascan/kotlin-js-example) to get you started, and some larger examples (of a [password manager](https://github.com/rnentjes/simple-password-manager), a [digital bookshelf](https://www.raywenderlich.com/201669-web-app-with-kotlin-js-getting-started), and a [tracker of people currently in outer space](https://github.com/joreilly/PeopleInSpace)) for inspiration!

[[ back to Table of Contents ]](#toc)

<a name="kotlin2"></a>
## \#20. [Kotlin](https://github.com/JetBrains/kotlin) -- _coroutines_

Concurrent programming in Java is a terrifying thing for a newbie. When should I use [atomics](https://www.baeldung.com/java-atomic-variables)? And [`volatile`s](http://tutorials.jenkov.com/java-concurrency/volatile.html)? And should I [`synchronize`](https://www.javamex.com/tutorials/synchronization_concurrency_synchronized1.shtml) on this class? Or this block? Or `this`?

At best, you can end up with an application which isn't _currently_ crashing or deadlocking but which could break unexpectedly at any moment, without any easy way to even trace what went wrong. At worst, you could end up with silent race conditions that corrupt your data without alerting you to any problems at all!

Kotlin tries to ease this pain a bit with its [coroutines](https://kotlinlang.org/docs/tutorials/coroutines/coroutines-basic-jvm.html). Coroutines were proposed in the late 1950s as a sort of [counterpart to subroutines](https://en.wikipedia.org/wiki/Coroutine#Comparison_with_subroutines), instead of a parent-child relationship, where control passes from the (more central) parent to the (more peripheral) child, then back to the parent, coroutines introduce a symmetric relationship. A given coroutine can `yield` to another at any time. [A simple (pseudocode) coroutine](https://en.wikipedia.org/wiki/Coroutine) might look like

```
var q := new queue

coroutine produce
    loop
        while q is not full
            create some new items
            add the items to q
        yield to consume

coroutine consume
    loop
        while q is not empty
            remove some items from q
            use the items
        yield to produce
```

In the above example, the `produce` coroutine fills the `queue` until there's no more space, then `yield`s to `consume`, which empties the queue. These two couroutines bounce back and forth, yielding the program flow.

The main advantage of coroutines is that they're _asynchronous_. In the above example, the `produce` coroutine isn't "waiting" or "sleeping" while the `consume` coroutine is running, it's simply stopped. It's not using any resources. These two coroutines could be running on different threads or on the same thread.

Because coroutines and OS threads don't have a 1:1 relationship, coroutines are very lightweight. While your system might begin to balk if you try to create more than a few thousand -- or even a few hundred -- threads, [you can easily create millions of Kotlin coroutines](https://kotlinlang.org/docs/tutorials/coroutines/coroutines-basic-jvm.html) at once. Coroutines allow for an easy parallel, asynchronous division of labor spread evenly among your computer's resources.

> To learn more about different approaches to concurrent programming in Kotlin, check out this SO post on the [differences between threads and coroutines](https://stackoverflow.com/a/23436125/2925434), and this short blog post which compares and contrasts [actors and coroutines](https://medium.com/@jagsaund/think-of-actors-and-coroutines-as-two-different-things-7fbfdc8fc035).

[[ back to Table of Contents ]](#toc)

---
---

Do you know of any other cool features I neglected to mention above? Are any of the above features _also available_ in your language of choice? Let me know in the comments!

_People who viewed the above article also viewed:_

 - [me soliciting $ from Internet strangers](https://ko-fi.com/awwsmm)
 - [acid-washed Facebook](https://twitter.com/_awwsmm)
 - my other [Dev.To](https://dev.to/awwsmm) articles
 - [𝐭𝓲Ⓜ𝑒ⓒυβε](https://timecube.2enp.com/)

Thanks for reading!