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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
> 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.
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).
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.
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..
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.
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.
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.
> 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]
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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).
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.
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.
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
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.
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.
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.
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.
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.
While we're at it, let's switch to haskell (delete the unnecessary people argument):
greetABunchOfPeople = mapM_ (putStrLn . sayHello)
Explanation:
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.
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.
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.
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.
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.
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.
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.
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 ]
persons.filter(predicate)
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.
> 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?)
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.
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."
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.
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.
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.
228 comments
[ 71.9 ms ] story [ 4507 ms ] threadJava seems to be going through a period of experimentation, and alternative Java-like and JVM languages. Interesting times.
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.
It seems like a great gateway drug for Scala.
[1] https://github.com/danielribeiro/HelloScalaOnAndroid
[2] http://news.ycombinator.com/item?id=3198154
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.
Is legal java legal xtend ?
Can we expect something like http://js2coffee.org
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.
Only languages with conventional C or Smalltalk based syntax and some functional "injections" have ever become popular.
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.
- 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.
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.
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.
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.
Kotlin will be the successor to Java.
Do you have any real examples of longer Scala code? I couldn't find any.
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.
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]
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.
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.
== in Java is identity, in Groovy it is .equals() Inner classes are not supported.
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?
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.
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.
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.
This is not an improvement, it is an unnecessary complication.
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.
Of course, Java doesn't have method reference types. But it's an ambiguity worth bearing in mind.
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.
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 ';'.
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.
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'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.
I think that Kotlin could be the Java successor that Scala never will be.
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.
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.
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.
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.
First thing I thought when I saw the website: "Oooh look, Twitter Bootstrap"
http://confluence.jetbrains.net/display/Kotlin/Welcome
Also:
http://news.ycombinator.com/item?id=2784086
mapM_ is a function that takes two arguments.
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.
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.
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.
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.
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.
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.
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...
These things are important. Where're the docs?
> 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?)
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."
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.
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.