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.
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.
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.
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".
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
(I'm expecting downvotes but whatever.)
Java seems to be going through a period of experimentation, and alternative Java-like and JVM languages. Interesting times.
It seems like a great gateway drug for Scala.
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.
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...
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.
Is legal java legal xtend ?
Can we expect something like http://js2coffee.org
(function () { });
[1] http://www.infoq.com/articles/barriers-to-scala-adoption
[2] http://www.artima.com/scalazine/articles/origins_of_scala.html
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 ]
persons.filter(predicate)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.
I don't understand why some people consider this to be a massive hurdle...
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.
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.
I think that Kotlin could be the Java successor that Scala never will be.
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.
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.
> Groovy's ecosystem (including Grails) is hard to beat
Are you part of Groovy's echo system too?
== in Java is identity, in Groovy it is .equals() Inner classes are not supported.
- 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
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=3198120Large 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.
> If you're the kind of company that couldn't upgrade to Java 1.6 in 5 years
Clojure is a nonstarter for the vast majority of Java programmers for obvious reasons, and Scala has a perception problem.
As someone from outside the Java universe, I'd like to learn more about those reasons and why they are obvious.
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...
I'd say it's about as functional as Python... which did get a lot of traction lately in various different places.
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? :-)
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.
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
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.
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.
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.
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.
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.
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.
Of course, Java doesn't have method reference types. But it's an ambiguity worth bearing in mind.
foo("bar") ;
(a + b)
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 ';'.
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.
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).
def greetABunchOfPeople(List<String> people)
people.forEach
println(sayHello) > 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.http://news.ycombinator.com/item?id=2303548
A longer explanation:
>> a closure is a collection of closed-over variables retained by a function.
First thing I thought when I saw the website: "Oooh look, Twitter Bootstrap"
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.
Operations on collections:
List<String> result = new ArrayList<String>();
for (String word : words) {
result.add(word.toUpperCase());
}
return result;
private String name;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
new Dollars(15).plus(new Dollars(25)).times(new Percentage(80))
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)
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) {
result.add(f.apply(v));
}
return result;
}
}
List<String> l = ...;
Util.collect(l, new Functor<String>() {public String apply(String v) {return v.toUpperCase();}});
I never quite liked operator overloading, because of infix notation all operators need to retain their precedence.
> 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?)
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...
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.
I applaud any effort to cut down on the amount of boilerplate required in java though.
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.
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)
(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?
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.
http://longpants2.posterous.com/first-experience-with-eclips...
You're set as you already use Eclipse. :-)
On the other hand Go for the most part appeases C developers quite nicely.
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.
These things are important. Where're the docs?
[insert your favorite Ratfor joke here]
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.
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."
http://confluence.jetbrains.net/display/Kotlin/Welcome
Also:
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.
Kotlin will take over Java. That is fact. Mark my words on 11/05/2011.
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.
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.