Xtend – Modernized Java
eclipse.org
eclipse.org
With Scala IDE I've only had painful experiences, plus I hate Eclipse with a passion - but folks keep telling me that it got better. Well, I don't really care as long as IntelliJ IDEA exists.
They are also extremely fast and responsive in fixing bugs of any kind. I personally couldn't be happier and other communities can only dream about such IDE support. Of course, if you compare IDEA's Java support with the Scala plugin, it's worse, but IDEA works better for Scala than Eclipse does for Java, like seriously ;-)
I think Scala is a good language, but maybe it has too many features for me. Xtend did not leave me a bad impression anyway :)
Because Xtend is statically typed, the Eclipse Xtend editor has quite an excellent autocomplete. For your cursors's location it can propose you a list of all valid keyword, methods names, filed names, local variable names, Class names, etc.
And by excellent I mean: Autocompletion will not forget things and it won't show invalid proposals. No guessing!
For Groovy this just isn't possible because it is mostly unknown to the editor which methods and fields an object has. It's only known at runtime.
It's true in general, but in most specific cases it is possible to statically analyse dynamic languages to the point of providing meaningful auto-completion. For example in Python-land there is Jedi (http://jedi.jedidjah.ch/en/latest/), and also commercial Komodo IDE and PyCharm. This is done through static analysis, so that no code is ever run for auto-completion.
So, while it's impossible in general case, it's perfectly possible to create useful auto-completion for dynamic languages. There are such tools for Python, JS and probably others as well.
Not that I'd argue C# isn't modern, it's in fact one of the most 'modern' languages I can imagine at the moment, but it's kind of wry that C# did such a good job of keeping current where Java lagged so terribly behind.
Not to mention CIL was designed to be a Common Intermediate Language from start so language interop is nicer (generics are a nice example)
Like what?
The CLR is unusable for dynamic languages for example. I was using Ruby back in the day, when both IronRuby and JRuby were active at the same time, with IronRuby/IronPython being developed by Microsoft ... there was no comparison to speak of, JRuby was beating the pants out of IronRuby in terms of everything.
The JVM can inline virtual method calls, the JVM can do escape analysis for getting rid of unneeded locks or to allocate short-term objects on the stack, the JVM can de-optimize previous optimizations in case assumptions have changed or in case it doesn't see a performance improvement, the JVM has a GC that can cope with the garbage produced by dynamic or FP languages. The JVM has invokeDynamic.
As a result we now have - JRuby, Scala, Clojure, Groovy, Jython, Kotlin, Rhino, Nashorn (as a new Java 8 thing) and many others, including a Haskell port. All of them with thriving communities.
> Not to mention CIL was designed to be a Common Intermediate Language from start
That was just marketing. The JVM's bytecode is actually better for other languages. At the very least, the debugging symbols are part of that bytecode and the format is documented.
Speaking of those, if anyone wants to try those languages on the jvm for web app development check out HiveMind (crudzilla.com)...I am the developer, it is the easiest platform so far for using JSR-223 to build web apps.
here's a quick gif demo: http://bit.ly/1k7nG2n
Generics in .NET combined with value types are much stronger than Java/Scala generics, there's no boxing/casting of value types.
Oh, but it does. The type constructor (e.g. List<T>) does end up documented in the bytecode. Both Scala and Java need this because the libraries are distributed as compiled bytecode.
> you can't use advanced Scala generics from Java
I cannot parse that. Of course you can use generified Scala classes and methods from Java. They get interpreted as Java wildcards for the co/contra-variance rules. For site-wide variance rules - Java just interprets those as being invariant. Because Scala does not reify generics, classes and methods defined in Scala are usable from Java - get it?
> I'm sure they could have erased the extra stuff on CIL
Except that it's a pain in the neck to do so. For your own standard library, sure it's not that big of a deal, but if you want to reuse .NET's standard library, good luck erasing those generics.
As a consequence, F# has 2 generics type systems in the same language, one for Hindley-Milner that is type-erased and one for interoperability with C# and OOP. And even so, this is limiting F#, as F# does not do higher kinded types or type-classes and the OOP variance rules are quire limited, but because it has to interoperate with .NET - it's already too complex and I'm not seeing it evolve towards something better (yes, I believe Scala's type system is much better, warts and all).
> Generics in .NET combined with value types are much stronger than Java/Scala generics, there's no boxing/casting of value types.
That's not true. Reified generics isn't the only solution to this problem you know. Scala can specialize the generic types for primitives ... http://www.scala-lang.org/api/2.10.4/index.html#scala.specia...
Apparently baking the generics into the generated bytecode has downsides in flexibility.
My understanding of 'type erasure' is that it is a compiler step, that un-does all the generic information.
This means that you could just ignore CLR generics, interop not withstanding, to get it to run.
Why would this prevent anything been ported?
For me, it's about the ecosystem. I do a fair bit of work on the CLR and JVM.
The JVM has the following advantages: open source, cross platform, free tooling[1], incredibly more mature 3rd party libraries, zero OS cost to deploy, architectures ready to roll out of the box.
A lot of the Java stuff I do is literally integrating some off the shelf bits that work 100% reliably first time and it's done. Compare to C# where I end up having to do a lot of leg work and navigating immature, abandoned or just broken open source projects.
[1] By the time I've bought VS Pro 2013 with MSDN, ANTS profiler, NCover, VisualSVN, I'm down a pile of cash.
Yes, yes, I know enterprise CTOs need a good slapping, but at least this gives their down-trodden devs an option.
As such, I think it will come under threat from Java 8 rather than Scala.
Checkout: https://github.com/pocorall/scaloid
You can do that in combination with IntelliJ IDEA for example, which has awesome support for both Scala and Android. Google's new Android Studio is actually the same as IntelliJ Android plugin that they distribute as part of their open-source distribution. It's also the best IDE ever.
I hereby suggest it be renamed "Coffee".
The current form of Xtend has been around for a few years now, and has steadily improved. Its origins go back many years, to the OpenArchitectureWare project where its predecessor (called Xpand) was used as a templating and model transformation language for the framework. Since oaw moved to the Eclipse foundation (5-6 years ago?), most of the tools have been dropped, reworked, or merged in with other Eclipse projects.
Out of all this reworking for the new generation of Xtext came Xbase, which is an expression language that you can just drop into your DSL and have pretty much the entire Java language available (type system, expressions, scoping, etc.). If you're doing serious modeling/DSL work, this is about as good as it gets without going to something like MPS (which is awesome, but has its own set of limitations). Xtend is essentially this Xbase language in stand-alone form, with a few other goodies. There is also another project called Xcore which lets you create EMF models in plain text, mixing behavior along with structure, and it uses Xtend/Xbase as well. This is one of the reasons why I'm not too worried about Xtend becoming "abandonware" or anything like that - its main components are pretty essential to some key projects in the Eclipse ecosystem.
So why wouldn't you just use (Scala, Groovy, etc.)? Well for one thing, I can (and have) bring Java developers up to speed on Xtend in about an hour (less if they know anything about functional programming). You can see some benefits in more concise code right away, and it only takes a couple days to get productive with it. No one can do that in Scala or Clojure. If you're looking for a strategic platform to build your next JVM architecture on - well, that's not really Xtend's place, you're looking for Scala or Clojure (hint - the latter). But there are a lot of projects where Xtend is a very nice fit, and as a bonus, I've found that developers who learn Xtend first have a much easier time learning a more "serious" language like Scala or Clojure later.
I have used Xtend a little (not in production) and it was interesting when first introduced. I suspect Java 8 will make it redundant.
This beats Ceylon by factor two (4,189 results) and is close to Kotlin (12,233 result).
JVM == Java and CLR == C# (or VB.NET for VB shops)
Given the size and skills of the said teams, usually you cannot sneak in alternative languages anyway.
So for many of us, regardless how much we like alternative languages, those are the ones we are allowed to play with.
During debugging, you can select for every stack frame if you want to see the Java code or the Xtend code. This makes sense since Xtend code gets compiled to Java code which then gets compiled to byte code.
If you do imperative programing in Xtend, there will be exactly one Java method for each Xtend method. I.e. the "Xtend stack trace" (if it would exist) is exactly the same as the Java stack trace.
If you do a more function style of programming and use lambda expressions, each lambda will be a anonymous class in Java 7 or older. So you'll see them in your stack trace. But I guess that you would also see them in Java 8.
Example 1: text-based preprocessors such as the ones you find in C or C++ are a nightmare for IDE developers. They turn static analysis into a game of guessing because your source code can manifest itself into too many variations.
Example 2: SQL: If a user wants to write "SELECT mycolumn FROM mytable;" but he/she has only written "SELECT " and now trigger auto-completion… it can not work, because the IDE has no idea from which table it can list the columns. If the language would have the syntax the other way around "FROM mytable SELECT mycolumn" auto-complete could easily propose the tables first and all the columns from a specific table later.
I think that if a company is open to using Java 8 + Lombok, then they should at least try out Scala / Kotlin (or even xTend) for comparison.
If compile times are what worries you, Kotlin seems to be on par with Java compilation times, although I don't think Kotlin is production ready yet. (and it misses some Java 8 / Scala goodies such as parallel collections etc... though I'm sure JetBrains will add it soon...)
These days, "modernized Java" would probably be Ceylon or Kotlin.
Think of XSLT. Every time you want to generate a "<" or ">" you need to escape it.
Think of PHP. Every time you want to embed a command you need at least two characters to escape it: <? ?>
Xtend choose «guillemets» because they're concise and very unlikely to occur in the string/text/file your generating. You might want to use UTF-8 or ISO-8859-1 encoding.
The templating engine is one of the parts carried over from the old Xpand project on which Xtend is based. Xpand's sole purpose was as a templating language for writing code generators in MDE projects, and as such they tried to make it easy to generate any kind of code, so they chose a non-ASCII delimiter.
It's really not a problem in practice - type < and then ctrl-space and code completion will fill it in for you. The only real gotcha is that you have to make sure your project is set to use UTF-8 encoding, which unfortunately is not the default setting in Eclipse.
Wikipedia has a nice list of key combinations for each OS/language/keyboard: http://en.wikipedia.org/wiki/Guillemet#Typing_.22.C2.AB.22_a...
Id rather improve on applications and libraries we already have.
Can you be more specific?
Also, working on tooling is way more interesting than working on apps...at least for me. There are actually hard problems to solve ;)