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.
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.
Only languages with conventional C or Smalltalk based syntax and some functional "injections" have ever become popular.
(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.
This alone makes it considerably more low level than anything that runs on the JVM.
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.
[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.
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.
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.
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.
> 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.
The JVM would never know.
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)
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 () { });
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.
> 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.
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).
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.
Premature optimization of typing = complex text editor
Premature optimization of debugging = excessive unit tests or formalism
Premature optimization of product = coding features without feedback
I'm not a vim/emacs shortcut freak, but I do appreciate environments that don't make me use a mouse.
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.
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.
var x = 1
private var _x: Int = 1
def x: Int = _x
def x_= (value: Int) = {
if (value > 1337)
throw new ArgumentOutOfRangeException()
_x = value
}
foo("bar") * a
foo("bar") (a + b)
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.
greetABunchOfPeople people
people do
_ sayHello println greetABunchOfPeople = mapM_ (putStrLn . sayHello)
mapM_ is a function that takes two arguments.
mapM_ lambda 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$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 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.
Please share more. I'm interested. (Let me know if you can only share your experience via private channels).
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.
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.
foo.Sort(x.compare _)
class A {
private var _x = 0
def x = _x
def x_=(value: Int) { _x = value }
}
val a = new A
a.x = 5
println(a.x)This is not an improvement, it is an unnecessary complication.
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.
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.
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).
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.
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).
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.
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.
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.
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?
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.
Do you have any real examples of longer Scala code? I couldn't find any.
Kotlin will be the successor to Java.
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.
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 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.
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.
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.
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.