Hacker News new | past | comments | ask | show | jobs | submit login
Eclipse launches new language to cut down Java boilerplate - Extend (eclipse.org)
391 points by dnene on Nov 4, 2011 | hide | past | web | favorite | 221 comments

I'm pretty disappointed in the discussion that has gone here. There's been so much argument over things that don't matter much in the end, like whether or not optional semicolons and parenthesis are a good thing. These things are so superficial! It makes me believe that few people appreciate what actually makes a language good or bad.

The fact that Xtend can be easily translated to Java source code is a big sign that it probably won't have any dramatic impact on your productivity. I think the comparison that has been made between Xtend and Coffeescript is most accurate. Xtend will likely be more pleasant to work in than Java, but it won't be a game changer in terms of what you can accomplish with it. Still many people are happy with Coffeescript, and if Xtend does thing right many people might be happy with it as well.

And, I'm pretty sure David Pollak is the only Scala evangelist who is worried Scala won't or shouldn't overtake Java. Everyone else seems to be committed to making Scala a better and better out-of-the-box experience, and there continues to be initiatives and commercial investment in improving things like IDE support, documentation, coding standards, training opportunities, and more.

> The fact that Xtend can be easily translated to Java source code is a big sign that it probably won't have any dramatic impact on your productivity.

It appears to be common Hackernewserthink that "productivity" equals "the ability to write code as fast as possible". Beyond the first few weeks of coding, you'll spend much more time reading code and refactoring it.

What Xtend offers is an object model and type system that anyone with Java experience can understand right away, but with significantly more readability. This means better maintainability, which means a significant productivity increase once you're past the "hack away, guys!" stadium.

Coffeescript has exactly the same major advantage over JavaScript. The point is that because CoffeeScript/Xtend so closely mimic their target language, there are no leaky abstractions, so no thinking-in-two-worlds headaches. Yet, the code becomes significantly more readable, which matters.

These developments really are major. There's a reason so many more people use CoffeeScript than, say, ClojureScript or GWT. The only reason why the same wouldn't happen with Xtend in the Java world is non-technical: too many Java shops are conservative and afraid of change, even change as low-barrier as Xtend.

They should've called it "Coffee", though.

> It appears to be common Hackernewserthink that "productivity" equals "the ability to write code as fast as possible". Beyond the first few weeks of coding, you'll spend much more time reading code and refactoring it.

And even more time thinking.

This is one of the reasons I never understood the obsession many people have with vim/emacs/whatever shortcuts and the like, for me they are distractions from what is really important: thinking about what code does and what it should do.

Fun fact: Ken Thompson doesn't touch-type, and a couple other amazing hackers I know are the same. I suspect this might even be a benefit as it encourages them even more to think before they type.

These things are a form of "premature optimization," which I think anyone can be misguided into, but which younger/less experienced programmers are particularly prone to, because they naturally tend to have uneven skill development, so they'll try to build from strengths before branching out.

Premature optimization of typing = complex text editor

Premature optimization of debugging = excessive unit tests or formalism

Premature optimization of product = coding features without feedback

Having typed since I was 5, I think while typing, and going back and forth in code is the same as thinking for me. I'd expect that most of these amazing hackers are from the era where they wouldn't see a keyboard until being 16 or 18.

I'm not a vim/emacs shortcut freak, but I do appreciate environments that don't make me use a mouse.

And more specifically: It appears to be common Hackernewserthink that "productivity" equals "the ability to type code as fast as possible".

The fact that Xtend can be easily translated to Java source code is a big sign that it probably won't have any dramatic impact on your productivity

I do not believe that there is any evidence for this statement.

Translating ARM assembly language into opcodes is orders of magnitudes easier than translating Xtend into Java, yet I would argue that even that had a dramatic impact on my productivity back when I was doing such things. If Xtend introduces proper closures just that right there will improve productivity.

However, if I were to accept your premise that easy translation implies little value added, then I would have to point out how wonderful it is that we live in a time where we regard writing a parser for a language like Xtend and the requisite bits of goo to spit out java is considered "easy".

The evidence for this statement best comes from a research paper* that attempts to formalize language expressibility . According to their formalization, language features are classified as macro expressible if they can be implemented in terms of local syntax transformations of other language features. The paper shows that expressivity, power, and conciseness come the most from those features that are not macro expressible. Yet, none of Xtends features seem to be in that category.

Since most languages don't have macros or compiler plugin frameworks, there can still be great value in adding macro expressible features, but, as I said in my previous post, these are less likely to be game changers in terms of productivity. These are the kinds of features that IDEs can make up for with templates and code generators. As an example, an anonymous class might be bulky, but it essentially provides the same feature set as a closure and the IDE is good at writing most of the boilerplate for you.

*see www.ccs.neu.edu/scheme/pubs/scp91-felleisen.ps.gz

"The paper shows that expressivity, power, and conciseness come the most from those features…"

I do not accept your implicit claim that a language must be more expressive, powerful, or concise to be more productive.

As a counter-argument for the expressive claim, consider a language that required one to prefix each line with the number of non-blank characters it contains. I am fairly sure I would be more productive using a preprocessor that computed those prefixes for me. Real world examples of the same are the abolishment of line numbers in Basic, assemblers that know about structure offsets, the C preprocessor, and type inference. Each, I think, helped increase productivity.

'Power' cannot be a factor at all, as basicly all programming language are equally powerful; there are no degrees of Turing completeness.

That leaves conciseness. I do not think that claim would need debunking, but for completeness: if that helped productivity, everybody would use single-character variable and function names (should mostly be possible in languages that allow Unicode source code), and program in APL or perl.

There are no real Turing-complete languages, as Turing-completeness requires infinite hardware. And certainly there are degrees of incompleteness, expressed by which programs run out of memory faster.

local syntax transformations

This is the key concept, and I disagree with you that this is all Xtend is. Its why I think you are wrong. Specifically, the Xtend transformation is adding information to the java code it generates that it must infer from the Xtend source code. It is precisely not a local syntax transformation.

I think you are assuming that because they make it look easy, that all it is is another macro language with, as you say, local syntax transformations.

You misunderstand what a local syntax transformation is. A syntax transformation is just a function that takes syntax as input and returns syntax as output. The function can be arbitrarily complex, even "inferring" things from the input syntax.

The key point is whether the transform is local or global. An example of a global transform is turning a program into continuation-passing style because it must change every function definition and function call in the program.

The transforms that Xtend is doing appear to be local. Converting closures to anonymous inner classes is a local transformation. Their "type inference" isn't real whole-program type inference, it just saves keystrokes within certain expressions. The fact that they can show you the underlying Java code that each new feature turns into indicates that the transforms are local.

Also, these types of transformations really are trivial in languages with full-featured macro systems (like most LISP dialects).

The referenced paper is way over my head, so I'll just say where I'm having difficulty and perhaps you can help me out.

Java doesn't have closures. Xtend does. Closures seem to me to satisfy the paper's definition of providing greater expressibility. Certainly, I've done a lot of C# and Java, and having closures in C# has greatly influenced how I write code.

And yet closures appear to be what you claim is a local syntax transform, and therefor can not add any expressibility to the language.

I am confused.

Update: I didnt downvote you btw.

Java's anonymous inner classes basically work like closures, except that they require that you mark some variables as final and that you have to write a lot of boilerplate. My underbelly feeling is that xtend's closures merely compile to those.

Often, such closures are enough. E.g. with Google Guava's predicates and filter/map methods, you can do with Java (guava + anonymous inner classes) what LINQ enables in C# (System.Linq + lambda expressions). The Java version has a lot more line noise than the C# version, however, which is what Xtend fixes.

I love it.

And C++ classes merely compile to C methods with mangled names that also take a pointer to a C struct, the first member of which is a pointer to an array of such functions, and whose remaining members are the fields.

If you (or GP) are going to argue that C++ is no more productive than C simply because cfront turns C++ into C, then I think theory has gotten in the way of reality.

I think the key difference is if the language feature automates a kind of abstraction that was manual in the other language. For example, one can write object-oriented programs in C, but you have to do it all yourself. And C++ programs can, as you pointed out, be translated to equivalent C programs. But classes and objects in C++ are language level abstractions that don't exist in C. In that regard, I agree with you: if you want to do OO programming, one can be more productive in C++ than C.

I have read much detail about Extend, but to me, the key question becomes: does it have language level abstractions that Java does not? I think closures and anonymous functions qualify, but I don't know if they're enough to make that much of a difference.

But what I've seen of Extend, with the exception of closures and anonymous functions, it doesn't actually have any new abstractions. It just cleans up the syntax.

It doesn't have any new abstractions except for those two really useful ones. Oh, ok, but it other than those it doesn't have any new ones. =)

Eh. I was arguing the direct opposite. I have the feeling that you're just looking to pick a fight.

Closures are code+data and objects are also code+data, so adding closures to a language with an object system does not increase expressibility.

The main difference is that with closures you write the code and the data part (the environment) is captured implicitly, whereas with objects, both the code and data are explicit. This makes it possible to convert a closure into an object, and an object into a closure, without having to change the whole program.

It is a little more difficult to go from closures to objects because you have to find the free variables and make them explicit, but it still isn't a global transformation. If you want to see how to implement objects with closures, check out SICP.

It's all code plus data. I can implement any java, C#, Xtend feature in C or assembly language, but by your argument that makes C# no more expressive then C.

If this is your argument, then it would appear that your argument is that the entire class of imperative languages are a waste of time and we should all be using lisp or scala.

Back in the real world, I find C# to be more productive than C, because I am able to express myself more succinctly. Xtend seems to do that for java. In the imperative world, your definition of expressibility is insufficient to determine increases in productivity.

The question isn't whether or not feature A can be implemented in language X, it is whether or not it has to be implemented as a local or global transformation. This is what the paper cited above defines as expressibility: adding a feature that requires a global transformation increases expressibility.

I made no claims about whether or not more or less expressibility is a good thing or how it relates to productivity. Nothing in my responses has anything to do with whether or not functional or imperative styles are better in terms of productivity or maintainability. In fact, by the definition in the paper, adding imperative features to a functional language increases expressibility. Also, adding goto to a language increases expressibility, so it is not a metric that is solely related to maintainability and productivity.

I am not arguing that Xtend is a bad idea at all, in fact I think it's a great idea. The whole reason people like languages with powerful macro systems is that they can implement features that Xtend gives to Java in the language itself, rather than having to wait for a new language implementation.

First, the fact that this language is coming from the Eclipse team suggests to me that they are probably not limited to macro transformations, at least at a fundamental level. The main reason Java folks like Eclipse is that it has a global understanding of Java code (this is why plugins for text editors tend to flat out suck compared to real Java IDEs, they are mostly dealing with local information), and I'd imagine that people working on an IDE that made non-local code comprehension a core focus of the product would make sure they're able to extract that information fairly easily from a language that they designed themselves.

That aside (since I agree that most of what they're doing appears to be fairly local, at the moment), what are the features that you miss in Java anyways, as compared to something like Ruby or Python, once you add closures and a bit of syntax sugar to cut out boilerplate? Past that, I can't think of much that people actually use day-to-day (and no, callcc doesn't count) in Ruby or Python that's not already possible in Java, albeit with a little more line noise. Can you?

When I look at code across many languages, the thing that makes Java code stand out as particularly clumsy is that it forces a lot of local verbosity, and that functional programming is very clumsy due to the lack of closures (though it's possible if you're willing to swallow your pride and endure some pain).

The single thing I would say Java is missing, from the perspective of a beginner, is the ability to change code while running it. Eval and Exec are useful functions, and there is no way to replicate them in Java.

Lists in Java are an unholy pain that redefine cruelty in an entirely new way. You can't make a list, to the best of my knowledge, that accepts arbitrary inputs. Does the utter lack of a slice operator count for the addition of multiple lines of code to replace what is normally three or four characters?

Please, tell me how. This is an honest question. I have been learning Java since school started, and I miss my functional techniques.

Another issue is that UI tools like WindowBuilder Pro won't work well with the generated Java code which will likely end up getting overwritten by the Xtend builder. Mmm. But it wouldn't have worked anyway without the conversion!

HN is the wrong forum to discuss this. Many people here are not the target audience who don't use Java and have a preconceived dim view of it.

(I'm expecting downvotes but whatever.)

What's the right forum for this, then?

You're right. HN is predominantly fashion lead hipsters (No offense).

Oh, it looks like Xtend is to Java as Coffeescript is to Javascript. Although I'm sceptical about it compiling to Java source.

Java seems to be going through a period of experimentation, and alternative Java-like and JVM languages. Interesting times.

It is also great for using with Android/GWT. Scala can be both used with Android[1] and GWT[2], but it is not a walk in the park.

It seems like a great gateway drug for Scala.

[1] https://github.com/danielribeiro/HelloScalaOnAndroid

[2] http://news.ycombinator.com/item?id=3198154

I agree. I use Scala for a personal Android app. Once you get over the antbuild and proguard hurdle - agree its no walk in the park - its smooth sailing. Scala meshes well with the android libraries and is fast. Although it gets highly wonky if you need to add a library that is not a jar but instead a package.

The major downsides which are super troublesome are that it takes 2 minutes to build each time - even for trivial changes and I have to debug the old school way with messages.

You can speed up the build time a lot by preinstalling Scala on the phone or emulator. This will allow you to skip the Proguard step. Here's how you do it http://zegoggl.es/2011/07/how-to-preinstall-scala-on-your-an...

One of the nice things about compiling to Java source is that it allows you use it with GWT. The only downside that I can see is that there might be constructs that you can't express in Java that you would want in a new language (note that you're fine with ones that you can technically express in Java but are just ugly, like closures). There are probably not very many of them, though.

Well, scala can be used with gwt: https://github.com/scalagwt

It was documented on scala, page, but now you have to use the google cache to see this: http://webcache.googleusercontent.com/search?q=cache:wqqu7uQ...

Exciting! Thanks for the link.

I didn't notice any mention of taking care of the primitive/object divide. That would be high on my wish list.

From a quick scan of the Xtend page, it seems to be fairly backwards compatible with Java source code.

It would be nice to at least have the option to compile to bytecode, but this is a good start. I'm hoping it was just a decision to get the language out there and drum up interest before taking on a bigger project, and a 'real' compiler is on the way.

This one in particular is interesting since it seems to be an attempt to catch up with some of the rapid development C# has made. The Java platform is great, but the language has visibly been allowed to grow moss lately.

Legal JavaScript is legal coffeescript.

Is legal java legal xtend ?

Can we expect something like http://js2coffee.org

Sorry to be pedantic. In JavaScript:

    (function () { });
Would definitely not be valid CoffeeScript. Invalid keyword `function`.

scala's own evangelists are worried that scala won't overtake java: "...Scala (the language, the tool-chain, the ecosystem, nothing about Scala) is not mature enough to be a Java replacement and barring an order of magnitude or two more investment into Scala commercialization, I don't see Scala becoming a Java replacement"[1]. this is despite seeing twitter and foursquare adopt scala at scale. and Scala's team, Odersky et al, are credible. they've already been through the extend java approach[2]. it didn't work. i see no reason xtend will be any different.

  [1] http://www.infoq.com/articles/barriers-to-scala-adoption
  [2] http://www.artima.com/scalazine/articles/origins_of_scala.html
anyway, i think the biggest problems with java are lack of first class functions, and no tools to enforce or nudge towards referential transparency. If Xtend helps with this, their page sucks because i skimmed it and i can't tell. verbosity and syntactic sugar seems to be the focus and incremental improvements typically aren't worth the inherent risk of changing pieces of our stack.

edit: xtend does seem to have first class functions per below, so my argument is weakened. i'll leave this post for discussion though since its going through some pretty wild vote swings.

  val predicate = [ Person person | "Hans" == person.name ]

My understanding is that the primary group of Scala evangelists are aiming for Scala adoption through promotion direct to enterprises as a blanket solution to every market, without any real effort to promote Scala at grass roots or toolchain levels.

Correctly some other prominent Scala community members are concerned that this approach can easily lead to high profile failures in Scala adoption and that is a death blow when a language/platform is in infancy and that they should narrow their initial promotion to a few key markets and grow from there.

Java has first class functions. They're just called something else and contain a few more characters to create them.

I don't understand why some people consider this to be a massive hurdle...

This basically looks like Kotlin, except it explicitly compiles down to Java.

I'm not sure how I feel about this. Pre-Kotlin, I would have thought "hey, neat", but now it seems like we're on the verge of a number of half-supported half-hearted attempts at being Java.next, each with their own pros and cons. I wish that IDEA and Eclipse could have worked together on this.

It's a pity everyone gets so worked up over trivial things like parens - Clojure is a beautiful language that absolutely deserves to be the next big language on the JVM. Yes, it offers a different programming paradigm from Java, but perhaps to make any genuine headway in the future we need a clean break from Object Orientation and it's muddled conflation of identity and state.

Trust that I, a programmer who cut his teeth on LISP, offer this brutal truth in a spirit of compassion:

LISP is the second-oldest HLL there is. As a syntax and a way of structuring code, S-expressions have been around since before the vast majority of software developers were born. Despite what one might be read to believe in reading the self-promoting protestations of Paul Graham, it has never gained much traction outside a few ivory tower settings. If it were going to take the world by storm, it should have done so by now.

The syntax is a major stumbling block for the vast majority of programmers, including a number of very smart people. This is not because of some failing on the part of said programmers. It is a simple by-product of the fact that its primary design goal was not to be a language in which humans can conveniently arrange and express their thoughts. It just wasn't; this was an era where coding in machine language was still common, and where the things language designers could dream up were severely limited by the rudimentary parser and compiler technology of the time.

As time passed and technology permitted, almost all the world came to settle on a certain principle in language design: Things that behave differently should look different. This is not trivial. It is a principle that is guided by the fact that human brains are designed to distinguish things by shape first and foremost. Parsing is more difficult and time-consuming, and so languages that minimize the amount of parsing that humans must perform will be easier for humans to use. There is but one remaining community which holds out against this simple truth: LISPers.

With modern technology we have a new crop of languages, ML and its descendants such as Scala, which adopt and expand on the principles that made LISP stand out so many decades ago. And they have the added advantage of being designed such that different things look different, and so people tend to have an easier time using them. And we see rapid adoption of these languages, and popular opinion agreeing that they are Good and have much to offer. Thus the key thing which makes LISP great finally sees vindication in the world at large, and the idea that LISP championed, the idea that processes are primarily composed of verbs rather than nouns, becomes transcendent.

And yet, there are still so many LISPers who continue to hold out, and refuse to accept this victory, because it is a victory that lacks S-expressions and their trademark parentheses.

And yet, they think it is everyone else who is irrationally hung up on syntax.

Are you absolutely sure that Clojure can fit all problem domains? Clojure might be great for MapReduce type of programming. Does it fit a typical Accounting, CRM, Claim management (those kind of business-y app) software projects?

Actually, I really am sure Clojure will fit in all of those problem domains. Indeed, I'm pretty sure that if you experienced a well-written Clojure accounting app, you'd wonder why people bothered with Java.

The parentheses are only one hurdle that Clojure makes you jump over, though. The other is Functional Programming.

I read an article here or on Proggit a few weeks ago by a (semi-professional?) game programmer who reviewed his own attempts at writing a real-time arcade-type game (PacMan?) in a functional language. Yes, he got the thing working and it even performed decently but he was irritated that if he really stuck with the paradigm of not having alterable state, some small changes to his app's functionality would entail changes in all kinds of places in the source.

Happily, Clojure gives you explicitly alterable state and a bucketload of mechanisms for working with those. But still, after months of practice I still struggle to get my head wrapped around FP. Typical business software programmers (as I picture them) might have similar troubles.

Would like to see the code if you have the example. Would be a very interesting case-study as to why Functional fits such problem domain as opposed to OOP because this would open a new perspective.

Please share more. I'm interested. (Let me know if you can only share your experience via private channels).

Sadly, I can't share any code, but here's my basic observations: First, calling a standard Java object from Clojure is extremely painless. It's a bit more complex if you're dealing with listeners, but in general terms a java object is a java object without very much getting in the way. This means that all of your favourite GUI libraries are usable without modification.

Second, as Carl pointed out, Clojure does have state, it's just tightly controlled. So tightly controlled that multi-threaded programming is much easier. There's some things that I'd like on top of what it does, but it's very powerful and useful.

Thirdly, I'm not denying that thinking functionally takes a while, but as you develop the skill, it's amazing how many things actually look pretty stateless. I've met actuaries who use F# for all of their calculations. Equally, converting game state to a 3d scene graph is a pretty stateless process (although I've yet to meet anyone who's actually getting paid to do functional game programming).

Hope that is interesting. Will be glad to share more.

Even though Kotlin is still essentially vaporware for those outside Jetbrains, we know that it'll have at least decent (if not great) IDE support right off the bat when the alpha/beta is released.

I think that Kotlin could be the Java successor that Scala never will be.

Please please please baby jesus let me have a dollar every time someone says 'Language X, not language Y is the java successor'

The difference is that we won't have an Emacs/Vim plugin for years and years after it's initial release. Plus, it's not a dynamically typed language and not Scala

IIRC, JetBrains will also be providing an Eclipse plugin (though turning it over to the community after initial dev).

This reminds me quite a bit of Groovy, just with a different compiler back end (outputting Java source instead of bytecode). However, this makes me wonder what the point is. Groovy is more-or-less source compatible with Java already (a valid Java program is also a valid Groovy program), so I'm not sure what Extend brings to the table.

> a valid Java program is also a valid Groovy program), so I'm not sure what Extend brings to the table.

Groovy is dynamically typed, not statically typed. Though a month ago Springsource/EMC hired someone to build a static type checker (called Grumpy) for Groovy (http://www.jroller.com/melix/entry/groovy_static_type_checke...) with the usual solicit for free labor by spinning the "open source" tale.

Presumably they heard about Xtend from the same place Jboss/Redhat and Jetbrains did. Hence the recent avalanche of announcements regarding Ceylon, Kotlin, and Grumpy.

I agree, I don't see a reason to switch from Groovy. I don't see the Scala or Clojure people switching, either. But even if you're just trying to convince Java developers, Groovy's ecosystem (including Grails) is hard to beat.

And actually, I'm using Groovy++ (http://code.google.com/p/groovypptest/), which addresses the concerns about static typing, inference, and performance, all for the cost of an extra jar. It's really surprising how few people - even Groovy programmers - have heard of this. I think it really ought to be included in the core language.

>I don't see a reason to switch from Groovy

> Groovy's ecosystem (including Grails) is hard to beat

Are you part of Groovy's echo system too?

It's statically typed so will presumably be as fast as Java while being nicer to use.

A valid Java program is not always a valid Groovy program - see http://groovy.codehaus.org/Differences+from+Java

== in Java is identity, in Groovy it is .equals() Inner classes are not supported.

So, "Extend is for the Java Programmer". I'm curious to see how this will turn out as there are some pretty cool features in this language. (Particularly the multiple dispatch, closures and type inference). However, any Java programmers could have made the switch to Clojure or Scala to keep working with the JVM. But, Extend is different in that it generates Java code instead of JVM. So, I'm wondering who will use that.

- Java programmers who are still stuck with old version: Even though they'd dream about using this, I'm guessing that won't compile to java 1.4/1.5.. right?

- Java programmers who already switched to high level language on top of jvm (Scala, clojure, etc.): Maybe the few who are still with Eclipse would switch back.. but I guess the majority of programmers in this scenario wouldn't want to switch.

- Java programmers who refuse, for various reasons, to learn newer languages/tools: Since it's still Java.. and still in Eclipse, it might be easier for them to give it a try? But then, if they refused to switch to newer language, it might be surprising to see them switch to Extend.

I'm a bit puzzled (as you can see). Personally, if I have to use the jvm, I'd go with clojure all the way.

  > Java programmers who already switched to high level language on top of jvm (Scala, clojure, etc.) ... Java programmers who refuse, for various reasons, to learn newer languages/tools
that's still a fairly risky approach. these new tools are, well, new. Reminds me of this quote: "One founder wanted to negotiate out of having to pay $10K in lawyer fees. Said just because it was always done that way doesn’t mean we had to do it that way this time. Turns out that person wanted to rewrite the book of convention on every decision he made. I can’t tell you that’s why his company failed but it sure didn’t help."[1]

Lots of people have shipped multi-million dollar systems in Java. Not so many people have done it in clojure. Tone check: my next job will probably be in scala or clojure, its just not necessarily the answer to everything. See my comment above in this thread where I quote two scala evangelists talking about how scala's future is uncertain.[2]

  [1] http://permanentrecord.firstround.com/2011/10/31/term-sheet-negotiation-tells/
  [2] http://news.ycombinator.com/item?id=3198120

It may also be a better option for developers who are in less control of their language/platform.

Large companies/teams come to mind, who want to avoid individuals using languages unfamiliar to the rest of the group (making it harder for others to maintain). The "compiles to readable java code" may be what convinces someone who would otherwise be against something like Scala.

Not saying it's 100% rational, that I agree with the position, or is a large market, but I can imagine it applying to certain groups. There's a certain comfort in knowing that at the end of the day you still have Java code.

Scala and Clojure both involve lots of new ways of thinking. This is why I like them. I suspect it is also a reason many hesitate to try or switch to them. People say you can use Scala as basically java with less boilerplate, but if you want to read other people's code, you need to understand a whole lot of new concepts. With Clojure there's no pretending you won't need to learn a bunch of new concepts. With Xtend however, the changes are limited enough that it can be a palatable first step for the hesitant.

Java 1.6 is 5 years old. If you're the kind of company that couldn't upgrade to it in the last 5 years, it's probably too big of a leap to adopt this.

Sadly, often time you'll have clients that use older version and you need to stay backward compatible for them.

  > If you're the kind of company that couldn't upgrade to Java 1.6 in 5 years
it doesn't always work like that. imagine a very rich customer who has all sorts of proprietary customizations to all of their software investments. millions of LOC. nobody's gonna port that shit off of java 1.5, and they told ya to deploy in their existing server environment, and ya do it because, well, they're rich.

There is no porting to be done between 5 and 6.

" However, any Java programmers could have made the switch to Clojure or Scala to keep working with the JVM"

Clojure is a nonstarter for the vast majority of Java programmers for obvious reasons, and Scala has a perception problem.

> for obvious reasons

As someone from outside the Java universe, I'd like to learn more about those reasons and why they are obvious.

I'd wager Clojure and its Lispy roots is way too foreign-looking for most Java programmers. And to be honest, the functional programming paradigm is pretty hard to grasp when you've never seen it before, and requires some effort to get proficient in (and more thought, but I don't want to be derogatory against Java programmers).

The problem is education, they still teach java like it is programmed 10 years ago.

The vast majority of Java developers are very, very comfortable with static typing and the most advanced IDEs in software development.

Clojure with its s-expressions and dynamic typing is going nowhere except for some small, high-brow teams...just the way it is.

Scala lost its opportunity a while back with its perception problem and lack of IDE support.

Can you please explain the Scala's perception problem?

I can tell why I (a java programmer who slowly moves to Clojure) didn't go the Scala route. Because every time I've seen code sample comparisons, the clojure one was shorter then the java original and the scala was longer. Plus it's foreign enough from java... so if I do it, better to go all the way and make it worth it.

I'm surprised how is that even possible? You can probably translate every Java file, line-by-line into Scala. Then remove the redundant type declarations and you're already shorter. Then you can actually rewrite it to something less imperative and still shorter.

Do you have any real examples of longer Scala code? I couldn't find any.

Well downvoting instead of providing an example to the claim is a bit cheap...

As I didn't delve into scala I can't really offer examples. But this was the impression I was left with when reading code samples 2-3 years ago. I think it was collections-related? I know it doesn't make much sense, and I do intend to revisit scala sometimes, but this is the impression me, a novelty-seeking programmer was left with when researching jvm languages.

Kotlin will cure the Scala curse. Scala is history...no matter what Odersky and pals try to recover it from. Scala is history...it's time to market and bad perception...adios..

Kotlin will be the successor to Java.

Fair enough, s-expressions are foreign to most developers, but dynamic typing? JavaScript/ECMAScript is one of the most widely used languages in the world. Dynamic typing and even first class functions are something most developers should be very comfortable with.

>> Java developers are very, very comfortable with static typing and the most advanced IDEs in software development.<<

Java's IDEs just cut down the boilerplate and scutwork involved in dealing with Java. They can even make Java usable. That is, in fact, an advanced and challenging task.

I have discovered that my corner store sells a commercial IDE for Lisp that accomplishes the same thing -- eliminating all the garbage involved in Java programming. It's called a notepad and pen. Combined with a Lisp, it surpasses all the features of Eclipse that eliminate busy work, duplication, and waste.

And it executes code about as fast as a JVM straining under Eclipse, too.

<b>However, any Java programmers could have made the switch to Clojure or Scala to keep working with the JVM.</b>

A lot of Java programmers can't stand Clojure and Scala. It's not like functional languages have any real adoption (> 5%) in the industry...

Scala is not really functional. Or at least it doesn't force you to write anything in a functional way.

I'd say it's about as functional as Python... which did get a lot of traction lately in various different places.

Eclipse is painful to use, just switching to using IntelliJ Idea IDE I have felt a lot more productive. I still have to use both since my company's "official" IDE is Eclipse and if I'm working on a problem where another developer might be looking at something with me I have to use it or they'll get really uncomfortable. The auto-completion in IntelliJ and better responsiveness of the UI make it a much better expiernece IMO. I really think one of the main problems with Java IS Eclipse, if more Java dev's used a better IDE I can't help but wonder if things like this wouldn't be thought of as being as necessary

I _just_ started on Java on eclipse, after 4 years of _IDE-less_ coding in python.

Care to tell me what you find better in IntelliJ, as compared to eclipse, so that I dont waste a lot of my time with Eclipse? :-)

* There are memorable keyboard shortcuts for everything. * It can generate comparatively more code for you. * It's faster, though I fear it's working on losing this advantage. * The autocomplete is smarter, and has a few different options.

I started using IntelliJ a few years ago, when I came onto a Java project after several years using vim and Python, and I'm convinced it made the transition a lot less painful.

The difference between IntelliJ and Eclipse may be smaller than it feels to me now--IntelliJ is what I'm used to, after all, so using Eclipse involves adjusting to a subtly different interface--but I'd still say it's worth a try. There's a free version, so there's not really anything to lose.

Eclipse crashes on me or freezes up frequently despite using a quad-core brand-new laptop with 8gb memory. The UI frequently becomes unresponsive. Anything to do with IO such as opening files, having maven pull in a bunch of files, etc is horribly slow and usually causes the app to freeze.

As far as I know it doesn't offer variable suggestion, in IntelliJ you just type the first letter or 2 and it immediately suggests any variables you have in scope, I find this invaluable as it really speeds up writing code sometimes. Overall, I find it simpler whereas Eclipse is just kind of a free-for all where you need to make use of a patchwork of plugins to be successful. IntelliJ is written by one company so I just always get the feeling it has a better "engine" underneath it.

Half the developers on my team curse Eclipse and say they hate it but none have switched to using another IDE except me, the others are too set in their ways, I get the feeling its firmly embedded amongst a certain generation of Java dev's but if you're just starting out (I'm also pretty young relatively speaking) I'd recommend considering using another IDE.

Eclipse does offer variable suggestion/completion using Ctrl+Space. Works for class names, variables, method names etc. Camel Case search is another nice feature. I personally use SpringSource STS (especially for the Groovy support). And btw, IDEA freezes up as much as Eclipse does. It's more of a problem with desktop Java applications, than with a specific IDE.

I've never had IDEA freeze on me. Eclipse may offer those (I wasn't aware of it) but you would have to tinker around to configure it, I really prefer simplicity to a mountain of configuration to get it working the way I want. Eclipse is more of a platform, its great for some things since companies have built plugins for all sorts of things (like the Drools visual editor, for example), its fine for this sort of thing but as a regular code editor I find I prefer to use something that is more simplified and limited, not something that is essentially trying to be a platform.

You know that when even Eclipse is coming out with an updated JVM/Java.next language that Java proper has some major issues.

The biggest issues are less about syntax and more about having to restart containers etc again and again.

But everyone except Play! and a few others seems to be jumping the new syntax bandwagon.

Being a php/python/Java developer I'm afraid I'd trade all improvements after generics for a no restart required jvm

Depending on why you're restarting your VM, you may want to check out the DCEVM: http://java.net/projects/dcevm

It lets you do arbitrary hotswapping of code, rather than only swapping method bodies. Not appropriate for production at this point, but you can install it on top of any Java 6 version prior to update 26 (not sure about Java 7); it's pretty useful for doing rapid iterations during development of large-scale server apps or swing applications.

Does anyone have the documentation or tutorial for DCEVM? I've looked at it from time to time but never able to figure out how to use it. There's no doc beside the jar file.

Sorry for the late reply (didn't see the question until now). The DCEVM is just a patched version of the JVM dll/so file that allows the normal hotswap mechanism (triggered by JVMTI) to accept arbitrary class changes, rather than just method body changes. There's no additional mechanism or API, it just makes the already-existing mechanism for hotswapping better. To install it, you just run the installer jar and point it to your jdk. To use it, you just trigger a hotswap as you normally would, which generally means starting your program in debug mode via an IDE, and having the IDE automatically swap changes for you as classes change locally. If you want to do hotswapping without the IDE, that's a bit trickier. Technically, you can write your own JNI code to directly hook into JVMTI and trigger a hotswap (which is what we actually do with our development platform at Guidewire), but the easiest way to do it is generally just to use the debug capabilities of the IDE.

If your biggest issue with java is about restarting containers/redeploying your app, you should check out JRebel (http://zeroturnaround.com/jrebel). It's a tool (javaagent) that will pick up changes you make to your code and introduce them in your running application. Unlike Play! it supports your application server and your framework stack.

Also it supports picking up changes in the configuration of major frameworks, like spring, for example.

Basically, with JRebel you can develop in java as you would do in python :)

disclaimer: I'm employed by the company that develops JRebel, but this fact doesn't make it any less awesome.

No, no, no. Our fancy, schmancy IDEs can produce the code for us, but we still have to read the Java boilerplate.

Reading Java can be the hardest part about working with it.

When working with Haskell and discussing why you would want to use let vs. where or if vs. guards, Bryan O'Sullivan explained it to me by borrowing a term from journalism: Don't bury the lead.

You want to put what the function does right at the top. The first thing it should tell you is that it prints hello for each person in a list. Then you can put the details of how that's done in definitions below. It allows you to write functions so that they are easy to read and so that the structure of the semantics are separate from the implementation details and the requirements of the system.

Java's rigid boilerplate has always stood in the way. It would be like if every newspaper article had to list all of its sources, with full names and titles at the start of an article and then had to list events in chronological order. They would be mind-numbing to read. Sometimes I just want a good juicy sound byte right in the first sentence so I know why I should be interested.

Are you implying that there was still someone on our side of the 50th percentile of programmers who didn't know that?

While it bothers me that it's Yet Another JVM Language when we have too many anyway, this is exactly what I want from a "blub" language. It adds the syntactic sugar that I care about, but since it compiles to java rather than the JVM, I can actually debug it, and stack traces make sense. It has IDE support.

In my personal projects, I love playing with the newest technology. However, when I'm in the enterprise, the point of the language is to communicate effectively to another programmer the intention of the code, because that code will outlive my time at the company. This looks perfect for that purpose.

Parenthesis for method invocations are optional, if the method does not take any arguments.

obj.compute instead of obj.compute()

That seems silly. The optional semicolons also irritate me.

----------------- (Added)

I imagine a committee of Java developers, in a penthouse boardroom at Oracle, meeting with management to discuss Java's descent into disuse.

"Lets make Java more concise," suggests a senior developer.

"Yes! Lets get rid of the parenthesis like Ruby!"

"And the semicolons like Javascript."

All falls silent. Everyone stares at the programmer.

"But... But..." stammers an important board member. "I thought we needed those."

"We could make them optional."

"Yeah, we'll be multi-paradimatic like Perl!"

And so Extend was born. A cargo cult at its best.

That's what Scala already does: if a method does not take any args then the parentheses aren't necessary.

To quote Odersky: "This convention supports the uniform access principle which says that client code should not be affected by a decision to implement an attribute as a field or method."

It makes sense if you want to implement something that may be a field but needs to be computed.

How do you differentiate between referencing a method, and calling the method? I.e., foo.Sort(x.compare)?

I think the idea of computed fields implemented via methods is better represented via C#-style properties, although I'd prefer to be able to access their methods directly, when suitable.

You'd use an underscore to form a partially applied function:

    foo.Sort(x.compare _)
And Scala's getters and setters are essentially equivalent to C#'s properties:

    class A {
        private var _x = 0
        def x = _x
        def x_=(value: Int) { _x = value }

    val a = new A
    a.x = 5

So instead of a simple, uniform rule that () invokes a function, and no-() references the function, you add yet a third syntax?

This is not an improvement, it is an unnecessary complication.

That's not the same thing. You obviously use partial application only if the function takes params. And I just can't see why you'd like to pass a reference on a parameter-less function.

Closures don't need to take parameters to be useful, but you're missing the point.

There is a simple, unambiguous rule -- () calls, no-() references. In order to... what? save two keystrokes? -- you have added a strange corner case, and then tacked on a new bit of punctuation for partial application. Though now it seems you're adding the rule that functions without parameters can't be referenced.

This takes a simple yes-or-no rule and adds edge cases for no reason. Two keystrokes on the occasional parameterless function call is not a real savings, and you've just made it harder for someone reading the code to spot all the function calls.

This fundamentally makes no sense. Why would this be a good idea?

There's no ambiguity when you're using closures. Concerning partial function application, you need a special syntax anyway (unless you consider all functions to be curried by default). You don't do that to save keystrokes, you omit parenthesis because "All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation."

I used scala for a while, I admit there's a whole bunch of features that can get you confused. This takes 30s to spot.

This feature, which Delphi has, can be problematic - if you're assigning a method to a method reference variable, it's not always clear if you intend to assign the method itself, or the return value of the method (which may itself be a method reference).

Of course, Java doesn't have method reference types. But it's an ambiguity worth bearing in mind.

There is nothing wrong with optional semi-colons. In most cases, the parser doesn't need them, and the programmer doesn't want to type them. But they're useful in some cases for disambiguation, especially in a language like Xtend that doesn't use an explicit return. E.g.

    foo("bar") ;
    (a + b)
The semicolon is necessary for disambiguation in a case like this, but there is no reason to require the programmer to put in semicolons everywhere. I think the operator precedence hierarchy and optional parens to override it is way more complicated, but people seem to deal with it fine.

"The semicolon is necessary for disambiguation in a case like this..."

This is why semicolons should be mandatory or illegal. The whole "optional semicolon" thing is a mis-feature designed by language committees that can't make a decision. One's codebase becomes a mismash of lines with and lines without semicolons, sprinkled in as magic to make the compiler happy.

There are plenty of interesting language features which are useful -- support for "optional semicolons" isn't one of them. The feature needs to die, and people should just choose to use a language that suits their need to type -- or not type -- a ';'.

We should also use a fully-parenthesized prefix syntax so we don't get a mishmash of lines with and without parentheses used to override operator precedence!

I agree Javascript's "automatic semicolon insertion" is a terrible feature, but largely because the description is so hard to understand that programmers don't know when the semicolon is required.

In an expression-oriented language, like Xtend seems to be, the rule for when you need a semicolon is simple. The parser makes the longest legal expression it can, if that's not what you mean, then add a semicolon. It's no harder to understand than the lexer equivalent (the lexer makes the longest token you can, if you want to resolve the ambiguity insert a space), or the operator precedence rule (the parser will interpret infix operations using this precedence table, if that isn't what you mean use parentheses).

Matlab, for example, doesn't require commas to separate list elements, and doesn't require but allows semicolons at the end of lines, and nobody complains.

Sorry for not understanding, but can you explain what the ambiguity is here?

A C-like parser will keep parsing an expression as long as it's legal. Take:

    foo("bar") * a
It will parse the call to 'foo', then see the '*' which is an infix operator and parse the whole thing as a multiplication expression. In most C-like languages, '(' is both a prefix operator (for grouping) and an infix operator (for function calls). So:

    foo("bar") (a + b)
Is ambiguous if you don't require semicolons to separate expressions. The parser will parse the call to foo, then see the '(' and parse that as a call to the value returned by 'foo'. To stop that, you use the semicolon to stop parsing one expression, so the next '(' is treated as a prefix operator.

Wow, yes of course. For some reason I thought Xtend was whitespace sensitive, so just having a newline was enough.

Talking about cargo cult, they added "def" to function definitions making it more verbose actually.

That's probably to make it easier to parse with type inference, since right now it's the type name that start's a method definition

Seriously, I was thinking, WTF? Increased verbosity and then it isn't even a full word like "define", it's verbose and then abbreviated. Are they just trying to make Javathon at any price?

Ruby does not get rid of semicolons or brackets. Heck, you can write Java/C++ style curly brace code in Ruby if you wanted.

Of course, if you did write Java/C++ style curly brace code in Ruby, those of us who like Ruby would bring out the pitchforks.

At least then vim would understand it and you wouldn't have to deindent every 'end' yourself. It would be nice to be able to use % and some other stuff that you get with most other languages.

The fact is that the visual style of a language is trivial to get used to. Breaking my text editor is a real issue though.

vim does understand Ruby. As soon as I type end, it automatically de-indents the line 2 spaces. Put this in your ~/.vimrc:

    filetype plugin indent on

also matchit.vim to do %-bouncing between keyword/end pairs

Making the parenthesis optional makes it harder to differentiate between taking a method reference and the return value.

It's pandering to hipsters. Parenthesis are just to obvious.

Optional parenthesis if no argument is given was already a feature of at least pascal in the seventies.

All those new "cool and innovative" languages are just rediscovering it after almost a decade of everything with C syntax.

Not that it's bad or anything, it's just my OCD tingling.

Well, Ruby does go beyond this: optional parenthesis with or without arguments. Of course, no public instance variables, like Smalltalk and Scala, makes this possible.

IMHO, it's less readable, and more ambiguous. Is it a variable or a function? Who knows!

This is actually half of the value of it. It allows you to easily change the implementation without breaking the public semantics. Generally speaking, the first-pass practice in Scala is to use public fields and to make them vals (final/C# readonly). Where you need to provide mutability, you use a var. But due to C#-esque properties, you can go from

  var x = 1
to (not great code, but illustrative of the point)

  private var _x: Int = 1
  def x: Int =  _x
  def x_= (value: Int) = {
      if (value > 1337)
          throw new ArgumentOutOfRangeException() 
      _x = value
The convention is to use empty parents after zero-argument functions that have side effects, much like the ! in Scheme.

Cargo cult is actually your argument, i.e thinking you need the parenthesis and the semicolons, just because Java always had them...

The point is removing them accomplishes little and adds ambiguity. There's something to be said about not changing things that adds no value; momentum and familiarity are valuable features, even if technically they're not needed.

This trend of trying to strip programming languages down to their "essence" is a fools errand and the pendulum will swing back eventually (not fast enough in my opinion).

I wish they'd taken it just a little further and made surrounding brackets optional (using indentation instead). I.e.

  def greetABunchOfPeople(List<String> people)


  greetABunchOfPeople List<String> people
      println pers.sayHello

You still have a dot in there!

    greetABunchOfPeople List<String> people
        people do
            _ sayHello println

You left a type in there!

    greetABunchOfPeople people
        people do
            _ sayHello println

While we're at it, let's switch to haskell (delete the unnecessary people argument):

  greetABunchOfPeople = mapM_ (putStrLn . sayHello)

mapM_ is a function that takes two arguments.

  mapM_ lambda list
It calls lambda on each element on list.

In the greetABunchOfPeople definition, notice we only gave mapM_ 1 argument instead of 2. That means greetABunchOfPeople would have to take an extra argument for the call to execute.

  greetABunchOfPeople $MISSING$ = mapM_ (putStrLn . sayHello) $MISSING$

You beat me to it.

What I love about the Haskell version is it says only exactly what needs to be said.

sayHello - get the hello message for something. putStrLn - send something to stdout mapM_ - Do these things in sequence, I don't care about the result.

Together they say take a list of people, get their greeting strings and print them to stdout in order. It's hard to say it more succinctly without making things confusingly implicit.

I don't know, but, often get irriated by the usage of "closures" when it means "anonymous function/expression".

  > The term closure is often mistakenly used to mean anonymous function. This is probably because most languages implementing anonymous functions allow them to form closures and programmers are usually introduced to both concepts at the same time. An anonymous function can be seen as a function literal, while a closure is a function value. These are, however, distinct concepts. A closure retains a reference to the environment at the time it was created (for example, to the current value of a local variable in the enclosing scope) while a generic anonymous function need not do this.

You don't have to assume that they actually mean anonymous functions. There's no real reason why the Xtend compiler couldn't translate closures to Java objects.

But by closure I usually refer to the definition of some Lisp books:

  >> a closure is a collection of closed-over variables retained by a function.
I don't really dig deep for what the constructs would produce in memory, but they should be some lambda expression.

Agreed. As I've written here previously:


A longer explanation:


Check out xtext which this is based on. Is even more interesting: Define a grammar and it will generate an editor with code completion etc. For a full programming language (as opposed to a small DSL) its important to be able to "debug at the level of the abstraction" as Dave Thomas (not pragprog Dave) says. This looks like it generates code, so you can't do that.

What is Xtend supposed to provide that Scala doesn't already provide? It looks like their setting out to solve a subset of the problems that Scala deals with already.

Unlike Scala it compiles down to Java. Depending upon how readable and sane the generated code is, I could see people working in organizations where Java is mandated write code in Xtend and then commit the generated Java code or use the generated code as base for code that get committed to official channels. Although I'm skeptical of how readable the Xtend generated Java is.

Doing so would mean it would need to be super friendly going the other direction. It'd be really annoying working in one language, compiling to java, having someone modify that java, and then needing to read and work through everything in java now.

by the looks of it, a decent IDE perhaps.

I've found the open source version of intellij + scala plugin most impressive. Reliable code completion and everthing i've come to expect from a java IDE. I've had much less success with scala plugins for Eclipse and Netbeans. Without the intellij plugin for Scala I wouldn't have chosen Scala.

Full blown first class Eclipse Java IDE integration PLUS a nice, conservative syntax that is not Scala.

First thing I thought when I read the headline: "Oh boy, half ass Kotlin, here we come".

First thing I thought when I saw the website: "Oooh look, Twitter Bootstrap"

Meh. I don't understand what is so bad about Java.

Yes, there's boilerplate, which can addressed with the right development tools.

New languages are a good thing. But a language whose sole purpose is to remove boilerplate from Java, does not really get us anywhere.

Much of the time, I'd agree. But working on a large system in Java, I repeatedly see a few places where Java's boilerplate overwhelms the code I actually care about.

Operations on collections:

  List<String> result = new ArrayList<String>();
  for (String word : words) {
  return result;
Accessor methods:

  private String name;

  public String getName() {
    return name;

  public void setName(String name) {
    this.name = name;
And arithmetic on user-defined types:

  new Dollars(15).plus(new Dollars(25)).times(new Percentage(80))
This bulky, uninformative, junk code is a real barrier to readability, and these are just simple examples. Sure, it's possible to work around it, and to keep the badness contained, but it still means time wasted for anyone who needs to maintain it.

We started writing some code in Groovy on our large Java project at work a few months back, and it's been a revelation. Groovy feels like a bit of a hack in all kinds of ways, but we're still delighted with it, because being able to say:

  return words.collect { word -> word.toUpperCase() }

  String name

  (new Dollars(15) + new Dollars(25)) * new Percentage(80)
just makes it _so much easier_ to see what's going on at a glance. Maybe if I were on a different sort of project -- one where I spent less time maintaining old code, or working with collections of data -- reducing boilerplate would seem like less of a big deal. As it is, though, it has seriously improved my quality of life. If Xtend can bring that kind of improvement to more people, I'm all for it.

With a bit of code:

  public interface Functor<T> {
    T apply(T v);

  public class Util {
    public static <T> List<T> collect(List<T> l, Functor<T> f) {
      List<T> result = new ArrayList<T>();
      for (T v : l) {
      return result;
You can write:

  List<String> l = ...;
  Util.collect(l, new Functor<String>() {public String apply(String v) {return v.toUpperCase();}});
Not as concise, but not that horrible either. :)

I never quite liked operator overloading, because of infix notation all operators need to retain their precedence.

New languages are not a good thing.

think of extend as one of the development tools, then

If you have to program in the Java ecosystem, not only "a language whose sole purpose is to remove boilerplate from Java" helps you tons, but it gets you to a lot of places.

Very cool. One nitpick (unless the video glossed over the details) is that the double arrows in the video for "personToGreet" looks weird because it's not a basic key on the keyboard.

No problem, when you hit Ctrl+Space on the Eclipse editor it completes with a pair (opening and closing) these "chevrons"

And in other editors on non-Macs, using the US-International keyboard layout gets you guillemets (their proper name) with `AltGr-[` and `AltGr-]`. On Macs, they are `Option-\` and `Shift-Option-\` (not quite as good, but still there).

On the new switch statement:

> Type guards let you switch (or match) for types, which is much nicer and less errorprone than the usual lengthy instanceof-cascades we write in Java.

Ruby can do this too, but it never seemed like a really good idea where I've seen it. The new switch() is better (equals!!), but this particular use case seems so out of place in an OO language like Java.

Using «» for interpolation is also a big jump when Eclipse still defaults to MacRoman. (Or have they changed it recently?)

The reason I never used Java is that every time I tried to learn it I would get type errors. So in order for my programs to work I needed to constantly define what type things were. The other big problem I had was whenever I tried to follow examples they didn't work because there is an arcane system of importing libraries or knowing some long function name. The language doesn't seem to have any universal functions. You have to import everything. If this changes any of that then I might use it. I really like the idea of programs being able to run on any operating system. Oh one more thing is the eclipse IDE seems to have so many different set ups and ways to download it how can you know which is the right one?

1. Java is a statically typed language so yes, the types need to be defined and known at compile time. Some people like static typing, others not so much. If you fall into the second group, there's a whole lot of dinamically typed languages you can try out.

2. Java is also object-oriented. This means that, in java, all the functions are methods of objects. There are no 'universal' functions which are not attached to objects in any way. Again, some people think that the object-oriented approach is a good thing which more accurately describes the world we live in, and some don't [1]. It's up to you to decide whether you think OO is a good or a bad thing.

3. Regarding Eclipse.. Go to http://eclipse.org/downloads/, choose the installation which suits you best (if you're going to do some standard java development, then obviously you'll choose the first installation, 'Eclipse IDE for Java developers'). If you later wish to develop for other languages (or write enterprise java apps), no problem, Eclipse is very extensible so you can always include the appropriate plugin in your current Eclipse installation.

[1] http://www.google.com/search?q=object-oriented+programming+s...

(5 years from today) Extend is too low level ... I think we need another meta language on top of it.

what's wrong with that?

Exactly. It would be nice if someday someone realized a language shouldn't be constantly trying to teach the programmer something about computers. The best language would do as much of the work as possible by having a default for everything and by assuming as much as can be assumed. The point is not to reaffirm over and over what a variable is and how it is stored. We should learn that once in a text book and then get some work done. If you are designing programming languages for a living then maybe you should be concerned with that. This is called division of labor.

Quick, list reasons I should use this over Mirah.

Because there's like 3 dudes (maybe a half a dude if you think full-time) that are working on Mirah.

Mirah is cool, but from what I've seen Charlie still has to work on JRuby fulltime and there's no IDE support.

Jetbrains has pull, and I believe Kotlin will be the language that knocks Java down finally.

There's an assumption that compiling to Java source will make this easy for Java developers to transition to, which I believe is completely misguided. If you edit the generated java source you give up the ability to use Xtend at that point; if you don't then it's no different to using a language which compiles directly to jvm bytecodes. Their example of being able to debug through the generated java sounds like a drawback to me: you have to maintain two models of the program in your head instead of one. Much easier to debug through the original source!

I applaud any effort to cut down on the amount of boilerplate required in java though.

My favorite features du jour are missing, generics on value types and structs.

Operator overload would be nice.

But I don't think declaring variables whose type can be inferred from the right side of the attribution, semicolons or parentheses for parameterless methods are the biggest problems with Java.

Isn't that restricted by the JVM?

It's syntax. You could simply define a rule that the compiler, when facing objects that do not natively (as in vanilla Java) support operator X would have the .operatorX method used instead.

The JVM would never know.

How can we honestly accept anything coming from the people who gave us eclipse? What a giant stinky pile of pooh that turned out to be.

I think that the current stewards of the java language are actually going down the most helpful/likely to succeed path to helping fix java by fixing java. What a novel f-ing concept. As much as it can be anyway, and despite the serious reservations of the giant doucheball they inherited with most of oracle. (despite Larry himself possibly being a pretty cool/legit engineer himself)

When I read the title, I hoped they had built a replacement for the tedious XML declaration of plug-ins, with Commands and Workbench Core Expressions and all that.

(Example: http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclips... )

Am I right that Eclipse Xtend is just not targeted towards extending Eclipse at all, despite the name?

As far as I can tell it's only shipped as an Eclipse plugin. Are there any plans for a standalone Xtend compiler that doesn't depend on Eclipse?

"multi-line string literals" are very useful, because they enable you to create DSLs that are easy to use. As in the example, you can have HTML; or XML; or make up any language you want.

Of course, it doesn't help you implement it (you'll have to parse the string yourself); but it makes it usable. A downside is that it makes that code hard to understand for developers unfamiliar with the specific DSL.

I'm surprised there's been no mention of Lombok (http://projectlombok.org/) since the goals seem to be the same. Lombok of course, is not a language but just a set of annotions and annotation processors to handle the code generation behind the scenes. Will have to look at this more closely to see how the two compare...

Good use of Twitter's css framework, bootstrap. Makes it much easier to launch a website with a decent UI without too much thought.

I noticed how they literally took the bootstrap front page and changed a few images and the text. Fast indeed. http://twitter.github.com/bootstrap/

I'm actually kind of worried about what the generated Java code will look like. From what I can see from the greeter example, it's.. well, not very pretty. It certainly looks nothing like what one would normally write if one was writing pure Java code. Imagine having to maintain that.

I 'm pretty sure you would maintain the extend code. Otherwise your doing it wrong :P

In that case, what's the use of compiling to java source code, why not compile directly to bytecode?

I tried out Xtend, but got stuck on a deal killer: no apparent support for defining static fields or methods.


I'm sorry to say, but I think the Go programming language has just been owned by this Extend programming language for Java. Go missed the boat when it did not include some minimum class support to appease the developers used to Java, C++, and so on.

I develop with Eclipse and MDD at my day job, Go in my side projects. I'll definitely evaluate Extend for the day job enterprisey stuff, but in Go, I don't miss the class hierarchy at all; I find it very refreshing.

Go is cool. Go isn't too fast and doesn't have as much tool support as Java/Xtend. Go may be great if you're doing network programming on Linux. Like many tools originating from Unix environments, the cross-platform support may not be a top priority.

You're set as you already use Eclipse. :-)

Go's cross-platform portability is quite good, writing portable Go code is infinitely easier than writing portable C or C++ code, and probably as easy or more than Java.

One of the reasons Go programmers love it because it does not appease Java and C++ developers.

On the other hand Go for the most part appeases C developers quite nicely.

Isn't comparing Go to Xtend something like comparing apples to oranges? The first one is a language that can be used for low-level development. The other one provides a nicer syntax and some cool features for Java. If anything, it can be compared to Cofeescript which basically does the same thing for Javascript.

It's not an easy comparison to make, yes. But Go isn't really that low level. It has garbage collector, type inference, unique concurrency support that hides threads... And it's provided on App Engine.

App Engine also supports Python and Java. I figure folks could use Xtend to write Java web apps that cut some of the boilerplate and perhaps even deploy to App Engine, for instance. Giving folks an alternative to going with Go as a static typed language.

Perhaps Xtend using Java source-code as an intermediate medium confuses people a little. Using Eclipse to program using Xtend/Java may just be too seamless for it not to matter much after you've grown used to it.

Go still compiles to native code and provides direct control over the memory layout of your data structures.

This alone makes it considerably more low level than anything that runs on the JVM.

Does this remind anyone of Borland era ? At least for now it is an editor centered solution.

No one else is upset about the HTML 2.0 doctype on the examples page? WHERE IS THE OUTRAGE? http://www.eclipse.org/Xtext/xtend/#templateexpression

How do I make it work with mvn?

I don't see any mention on how to build outside the IDE (say, on a CI server). Are there Ant tasks? Maven/Tycho integration?

These things are important. Where're the docs?

I like seeing the JVM becoming a platform. Even if this particular language looks a bit silly compared to the others.

According to that page, their new switch expression is very egelent.

> compiles to readable Java code

[insert your favorite Ratfor joke here]

Building a language on top of java is a deadend.

Granted Im not the target market, but Implicit returns do not seem like a good idea.

Yeah, is there precedent for that? It looks fucking nutty. Can you do it in the middle of the function!? So odd. There's a lot of cruft in java, but I'm not sure the return statement is even on the list of things I'd bother attacking.

Functions in mathematics sets a good precedent for lack of a return keyword.

Where did you see that it says you can do it in the middle of a function? I understood it implicitly returns the last expression.

As far as a precedent, lisp does it that way, and it may be older than the existence of the return statement. Any language that lacks statements usually does it this way.

Lisp, Dylan, Smalltalk, ML, Haskell, CoffeeScript, and Dart all have various levels of implicit return. It makes sense in a language where there are no statements, just expressions.

Generally code is written to not need to return from the middle of a function. This is only really inconvenient in loops, and at least Dylan, Lisp, and Smalltalk make some provision for an "early return."

Someone said Dylan so I just respond...my favorite language of all times :)

This looks to be an also-ran related to the Project Kotlin that JetBrains launched some time ago:




okay folks..

Quick explanation..

Its a text based java dsl..so in other words I could develop in xtend an android application model that covers my dev use cases and than have an Eclipse plugin that is for that model.

Does not look impressive to a Pythonista. yawn

Scala had its chance, and it didn't work...no matter what Martin and his boys, and his minions want.

Kotlin will take over Java. That is fact. Mark my words on 11/05/2011.

You've repeated those sentiments up and down this thread. Personally I don't see much difference between the two, even syntactically. I've seen scala starting to get a foothold at my organisation, but haven't heard of anyone discussing Kotlin. What is also interesting is doing a trends search for scala jobs at indeed.com It looks like Scala has started to get a small but very rapidly growing slice of the job market

you can dress up a pig...

yet another Scala

It's not just Scala, it's Groovy, BeanShell, Factor (JFactor now), Fantom, Frege, Kotlin, Ceylon, Stab, Gosu, Mirah, and that's not counting all the ported versions of Ruby, Python, Lisp (Clojure) and so on.

What you haven't written a JVM language yet? It used to be you weren't a proper programmer until you'd gotten fed up and written your own CMS or web framework. Now I guess everyone has to have their own programming language.

It's not so surprising.

You remove one of the major pain points of developing your own language (platform/libraries), thus reducing the costs of writing your own language, which shifts the industry to a point where there are more languages.

Sidenote: JFactor is an outdated implementation and I haven't heard anything about it being revived. Factor has compiled to native code for years now.

Clojure is not a proted Lisp. Clojure is a new language that is just as diffrent from any other Lisp as Groovy is diffrent from Ruby or Scala from ML.

Scala has a time to market and a perception problem. Look for Kotlin to be the Scala that Scala never will be.

There was a recent survey which asked java devs which jvm languages they were taking a serious look at. Scala came out on top with groovy as the runner up. Kotlin was an also ran. Survey results: aftershox.com/wp-content/uploads/2011/10/JVM_Survey_Responses.png

I don't know what your beef with Scala is, but you're seriously deluded.

Your problem is that you think that Scala can overcome its perception problem. No, it can't. Scala is history and will never be anything. Look to Kotlin.

Erm, you're an idiot.

You're talking about perception problems like everyone knows there is one.

You do realize Scala is being used everywhere right? Twitter, Linked In, Meetup, foursquare, etc, etc. The list is endless.

TL:DR; your vaporware language isn't anything new or exciting. Let me know when it actually exists.

Scala, Clojure and all other functional languages are --and will continue to be for the foreseeable future--, non mainstream.

Only languages with conventional C or Smalltalk based syntax and some functional "injections" have ever become popular.

this is stupid

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact