2

I'm seeking a programming language (i.e.: compiler and IDE software package) that introduces modern convenience concepts like implicit conversions, assignment/call fungibility, mix-ins, extension methods, function culling, pattern matching from Kotlin and Scala, BUT is fully backward-source-compatible with Java.

Meaning of "backward-source-compatible": I can take legacy Java code and work with at as-is in the new language, and ONLY add advanced features in specific spots where I want it.

Historic parallel: when people decided to add object-oriented features to the C Language, they took two different approaches. One (C++) emphasized backward compatibility. Another (Objective C) did not. In my mind, Objective C is to C as Kotlin and Scala are to Java; and C++ is to C as Unknown language X is to Java.

As an additional nitpicky requirement, this should look like a real language, not annotation soup like Project Lombok.

One gripe that I have with languages like Kotlin and Scala, is that they introduced gratuitous changes such as changing declarations from Type name to name: Type. I say gratuitous because they are functionally equivalent and ergonomically inferior (one extra character at every declaration). They break compatibility, without providing any additional benefit.

I am very knowledgeable of the Java ecosystem. I expect, if a language meeting my requirements exists, it is probably a very obscure project by one brilliant person somewhere out there. Does it exist?

0

Xtend may be what you are looking for. It is NOT backwards compatible in the sense that valid Java is not valid Xtend, but IS compatible in the sense that mixed Java/Xtend projects are a very normal thing, and both can interoperate without problems (unlike Scala which can interoperate, but quickly has unwieldy cryptic names on the Java side). Xtend is basically syntactic sugar for Java, and has valid Java code as intermediate compilation product.

For example, this is an example from the documentation:

package com.acme

import java.util.List

class MyClass {
  String name

  new(String name) {
    this.name = name
  }

  def String first(List<String> elements) {
    elements.get(0)
  }
}

There are already several smaller things going on here in terms of syntax:

  • constructors go by the keyword new
  • methods/constructors have default visibility public
  • fields have default visibility private
  • return statements are optional, in that case the last expression defines the return value

Further features:

  • val and var are used in variable definitions, like in Scala (yay type inference)
  • override is an actual keyword, not an optional annotation
  • Extension methods, which allow more fluid call chains instead of deeply nested function calls.

(There is also a context menu entry in the xtend eclipse plugin which can transform Java classes to xtend code, if you want that).

  • Better, but not 100% there... +1 for extension methods, making override a keyword, optional return statements, but -1 for changing the constructor syntax. That "def" keyword for methods is most baffling, as it just adds more typing and visual noise, compared to plain Java. – Alex R Nov 30 '18 at 16:06
  • @AlexR I think the def serves to be able to omit the return type. The return type can be omitted if the compiler can infer it. I barely have any return types declared in my codebase. :-) – kutschkem Nov 30 '18 at 16:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.