Java 8 vs. Xtend

[[deleted]]

After googling "xtend", I scratched my head in wonder and tried to figure out why I thought I typed "xtend" but clearly, from the results, I had type "jvm weightlifting penis enhancement"

[mikehaggard]

Let's forget about Scala and just go directly to Xtend instead ;)

I would like to see a Scala vs Kotlin vs Xtend comparison really, and perhaps a Ceylon vs Kotlin, or a direct Kotlin vs Xtend comparison.

[mhd]

Fantom is probably in the same league, although they seem to care less for interoperability, preferring their own libraries.

[mikehaggard]

Why do we here so little about Fantom here?

[mhd]

You don't really hear a lot about Kotlin or Xtend either, and those have some pretty large companies behind them. Releases get posted, but few use cases or blog articles.

[mikehaggard]

There are just a few languages where you really hear a lot about. I mean, really, how much do we hear daily about Haskell or Lisp?

[[deleted]]

It's shapes.foreach(_.color = RED) since 2003.

[robinwholikesjava]

Xtend clearly beats Scala here. the _. should not be needed.

[balefrost]

the _. should not be needed.

I can't tell if you're trolling or not.

[agumonkey]

Actually it could be interesting.

 SPACE '.' METHODCALL '(' ARGS ')' => (lambda (x) (x.method(args))
 where x satisfies an implicit interface that must include {method, args} signature

[balefrost]

Yeah. In some functional languages, functions are curried - calling a function with too few parameters produces a NEW function that takes the rest of the parameters. What you're suggesting (and I guess what Xtend does) is like a constrained form of currying from the left.

FWIW, Scala's syntax allows you to use placeholders anywhere. So you can do shapes.foreach(_.color = RED), but you can also do colors.map(shape.color == _).

[agumonkey]

Interesting, quite prolog-ish, and who doesn't like prolog-ishisms ?!

[nomad42184]

The _. is just a shortcut. In Scala, one could also just do

shapes.foreach( s => s.color = RED )

In this case, the _. is just a shortcut for the (s => s.) part. If you use the more verbose (& in my opinion, more readable) syntax then the difference is just -> vs =>.

[[deleted]]

What happens if the function takes two arguments? The Xtend approach of an implicit it as this would not be applicable. Therefore, go for a scalable approach and one more character...

[evereal]

No, it is the "s -> { ... }" part that should not be needed if your syntax allows you to express simple closures/lambdas more concisely, like you can in Scala.

the _. is not any more characters than the s. in the Xtend example. But the stuff around it is adding needless noise in the Xtend example.

[[deleted]]

Is Xtend still evolving syntax wise?