Diverse versioni sono state rilasciate tra il e il Dopo varie beta e release candidate numerate 1. Nel , Groovy ha vinto il primo premio al premio per l'innovazione JAX Nel , Grails, un framework web Groovy, ha vinto il secondo premio al premio per l'innovazione JAX Nell'agosto VMware ha acquisito SpringSource. Strachan aveva lasciato il progetto silenziosamente un anno prima del rilascio di Groovy 1.
Pivotal ha cessato di sponsorizzare Groovy e Grails da aprile Some of the contributors you see in this list are still actively using Groovy or contributing: Jim White for example is famous for his contributions on the scripting sides of the language. Roshan Dawrani is one of the few guys capable of opening cryptic code and fixing bugs.
Jeff Brown is a name you should know, since he is now a key member of the Grails team. If you know Groovy, you must know Peter, the father of the famous Spock testing framework which just reached 1. I never stopped and actually I started contributing back then.
This year is also the year when James Strachan wrote a very famous quote about Groovy. This quote is probably the most innapropriately used quote about Groovy of all time, because it was done by its creator, but remember that James left the project in !
First of all James says nothing about the language itself here. Groovy today is nothing close to what it was when James left the project, thanks to the lead of Guillaume Laforge and incredibly talented people like Paul King, Jochen Theodorou and all the contributors listed on this page. Groovy and Scala both have their communities, but also different use cases.
In the end of , another important milestone occurred for project, with VMware acquiring SpringSource. Groovy reaches 1. With command chain expressions, native JSON support and performance improvements, Groovy put the bar very high in terms of integration in the Java ecosystem.
With cross-compilation and by the use of the very same class model, Groovy is at that date the best language for scripting on the JVM.
It is so good that a lot of people start to see it as a better Java and want to use it as a first class language. However, being dynamic, Groovy is still a problem for a category of users…. In , I became a committer to the Groovy project. As I said, I had contributed several fixes or features for Groovy 1. So this is basically the first time you see my name on the contributors list, but you can see that I am ranking 1 and I have never lost that ranking since then.
It surprised me too, but there is a very good reason for that. In october , in addition to being a committer, I also became paid to work on Groovy. I entered the club of lucky people being paid to work on open-source software. It was sincerely a dream, and I will never be enough thankful to Guillaume Laforge for giving me this opportunity. He changed my life and I think I became a better developer thanks to him.
VMware was my employer back then, and while I had never worked on a language before, Guillaume trusted my skills and proposed to me to work on something that would dramatically change the language : a static type checker. I also worked on the infrastructure of the language, starting from the migration to GitHub. It was an important move to make: as you can see, there was a very limited set of committers to Groovy.
It was the year Groovy 2. As you can see, I am still ranking 1 and Paul King, an unpaid contributor, is 2. This tells you the importance of community! Groovy 2 is a major change in the language, because it introduced both optional type checking and static compilation.
For the first time, Groovy was able to provide at compile time the same level of feedback that Java would have. Some people wanted to kill me for having introduced that into the language. Without this, some people would have abandonned Groovy in favor of other JVM languages like Scala, while now in Groovy you can have the same level of performance as Java, with type safety, powerful type inference, extension methods, functional style programming and without the boilerplate.
Pascal does since an amazing job in helping us filtering JIRA issues, writing bugfixes, reviewing pull requests and lately writing documentation. One thing is clear: with groovy, scala, jruby, and jython all on the rise, the future is polyglot. I still like Groovy and Ruby and JavaScript ; they are all good dynamically typed languages.
Folks hacking web applications often tend to prefer dynamically typed languages. So whether its on the browser JavaScript - and sometimes server side too or in web frameworks like Grails Groovy or Rails Ruby they are very popular approaches. The future is definitely polyglot. If you're hacking a simple MVC web app this probably isn't a big deal; but I don't tend to hack on those that much these days.
Whats surprised me with Scala is that I've found I actually prefer static typing with type inference to dynamic typing. I'm not saying I'm only ever gonna use Scala for everything; I still use other languages when they make sense - but mostly I'll be trying to use Scala for as much code as I can as it has all the benefits of static typing, many of the benefits of dynamically typed languages concise elegant code with little noise , is amazing at writing DSLs and opens the door to functional programming pattern matching, for comprehensions, immutable state etc while still being a much better OO language than Java e.
I love the traits in Scala. The future is certainly polyglot - we'll never all agree on one language and there are wide range of use cases. We can probably all agree Java the language is just about at the end of its road; bar a few little tweaks its in maintenance mode. Neil said: "As for the readability of lambda expressions, experience there has also shown it to be a significant improvement over the alternatives currently available in Java. I would like to have had functions in Java like in C , Scala, Groovy, etc.
Why do I have to "become" the compiler every time I have to understand a new code-base? My experience has shown that when applications break and I get called in to figure out what's going on, the less variable parts you have to take into account the quicker you find the bugs. I expected you would "moderate" your comments above everything Readability for me is more about "least effort to understand".
I do in fact have spend sometime programming in Groovy and I'm now getting into Scala. I also hope to get into Clojure after that. I'm open-minded but, I'm still not satisfied with some of their compromises.
That's all. Tasos apologies if you thought my tone was patronising. You said "issues in Java will not be solved by unreadable code structures closures or lamdas " I took it to mean you found them unreadable - hence my comment that sticking to Java rather than moving to the various languages which make heavy use of them.
I was thinking of you and your ability to read the code; not attempting to patronise. Languages are very subjective things; what suits one person, their mental models and fashions doesn't suit another. Or maybe you still don't like them despite this new experience? I can say as a Java developer I definitely feel like Groovy and Scala are the two prime contenders for becoming a second "complement" language to Java - which realistically in my shop I don't see going away for awhile.
I don't mean to make this a flame war but I think the obvious questions are: a. Are there use cases where Groovy is still a good choice over Scala? What are they? For example for a. I tend to feel it is and maybe that's a compelling advantage in some cases And regarding b.
More simply and generally: Are people saying there's nothing that Groovy can do which Scala can't do presumably with faster performance and similar lines-of-code counts?
Darren great comment! Scala is also marginally better at writing DSLs too e. You can create builders in Scala in a similar way e. So in general I think the languages are both better than Java!
With so much of this lower level infrastructure written in java, with Groovy just providing the glue, the performance story for Grails can be a perfectly good one right? But are you saying that despite it's relative immaturity and lack of popularity, the potential for better IDE support and performance in Scala should make people take Scala with Lift seriously as an alternative to Groovy On Grails?
But Grails has to be more mature than Lift right? Or is that an unfair question? It's a critical one for my shop though Darren Like anything performance depends on what you're doing. Grails certainly can perform adequately for many use cases yes - but would you want to write all of your business logic in Groovy if performance was important? But as you say, most of the code is really Java. I certainly don't wanna start a Grails v Lift flamewar though!
Both are good frameworks; Grails is probably a little more mature - they both have good things about them. I'm personally a big fan of the Lift templating approach; it lets you have simple HTML templates with no code at all; then write many custom tags in a single statement often spread over a few lines, one per tag in Scala code.
Clearly, Scala is a replacement for Groovy. It is unclear that there is a compelling reason to drop Java and all of its support for Scala. However, there are some types of code that clearly will be easier in Scala. I am going to start using Scala for some of these tasks and see where it takes me. One small comment on the issue of the complexity of languages and Scala in particular.
Early in our book, we call Scala a language for "professional developers". I'll take the blame for this one Put another way, there is not much "accidental" complexity.
Hi Dean, That's a bit surprising because it seems to me that Scala is the opposite of a "professional language", if you take the meaning literally: right now, very few people who code in Scala are paid for it, they are more doing it as a hobby.
Cedric Sounds a bit of a pulled-out-your-ass statistic to me :. Then most folks in the lift community tend to be building web apps for money. I myself get paid to hack Scala too BTW. Folks tinker with every programming language; I'm not sure if more or less folks proportionally are paid versus tinker in Scala versus other emerging languages on the JVM.
I've been closely following Groovy development since pre I've been burned by the breaking changes leading to 1. IMHO, the main pros are the learning curve Java-like syntax helps a lot here and dynamic typing. Before discovering Scala, I really believed that Groovy would have a great future, and I've sold this idea to many colleagues.
Closures feel natural in Groovy as opposed to Java , Groovy Console is great for quick prototyping, etc. In fact, I think if Sun had hired a couple of full-time Groovy developers 2 years ago, Groovy would be in position to "compete" against Ruby today. We've been spoiled by Eclipse, and I'm currently more productive with Java on Eclipse than with Groovy on [ insert great text-editor here ]. I've never done a "real world project" using Groovy or any other dynamically typed language , but I'm leading an experimental Grails project.
My pet peeve with Grails are the ginormous stack traces, that have very little to to with the actual error. Too many layers of abstraction magic that suddenly pop up. Sadly, the Groovy Eclipse plugin is stagnating again The "nightly build" update site doesn't even have a Grails plugin anymore, but it seems like this time rewrite from scratch?
I'll give Lift a try; maybe Scala will give me what Groovy still hasn't been able to deliver. James: just compare the job offers for Scala with other languages. It's pretty obvious that Scala is still in the very early adopter phase. I've read about Scala last year while I was looking for a alternative to Java.
Do you think anyone can use Scala as it is today as a simpler alternative in the enterprise? Even if the person doesn't know Java? TJGodel Sure! There's no reason why you can't just pick up Scala having no real Java knowledge.
I recommend one of the books I reference on this blog post, they pretty much describe the whole language without much reference to Java the language. Thanks James!! I'm excited about Scala I'm going to get started.
I have tried over a few years to get excited about learning Java, but I just didn't like all the hoops a person had to jump thru to program in Java.
Scala is very elegant and clean. It seems like I can focus on what I want the program to do instead wasting huge amount of time syntax.
I'm still only through chapter 2 of "Programming Scala" but i've already come across a several things that have been bothering me. Please understand i'm a complete noob to Scala. Parsing sometimes trumps language consistency. A fixed maximum for Tuples, Products, and Funtions seems unusual.
It's unusual that there is a fixed maximum for a language feature. It seems like a random decision. Why not 23 or 17 or 26? Also, why differentiate Tuples from Lists.
Like i said, i suspect this'll become more clear as i read more. It seems too many language decisions are based on easing parsing, overriding what would be a more consistent language. I can't remember the examples but i think there were at least two in just the first two chapters.
So far, i still much prefer groovy. Mostly for one of the same reasons i like javascript. I love languages in which documents can be presented in a subset of the language itself. The limit of 22 is arbitrary, I think. They had to pick a limit because all the "N" variants are defined explicitly as separate types.
Of course, if you have 22 function arguments, tuple elements, etc. I think of tuples as a convenience for certain contexts, but I guess they aren't really intended to be used like lists. A tuple in scala is immutable and each position in the tuple can have a different static type. So its kinda like an argument list to a method in Java code - its typically a small-ish size, its fixed at runtime both in size and in the types at each position.
I'd be a little worried if someone was using a tuple of greater than 10 to be honest, so the fixed limit isn't really a big deal in practice. The compiler could code generate tuple implementations at runtime for larger tuple sizes - but its highly unlikely they would be that useful in practice.
Not sure I follow that one; what do you mean by document? I think you alpha-programmer, framework developing types underestimate the performance boost of dynamically typed languages.
I love typing grails console and prototyping anything I want and getting immediate feedback. Or groovyConsole and prototype basic things there. Where I live, most companies use Java and Struts and I'm lucky to have been given the freedom to migrate the shop to Groovy for Web development.
However both are available in Scala as well as Groovy and Ruby and other languages too. So I'm sure you could experience a similar productivity boost in Scala once you've learnt it as you experience in Groovy - with the added benefits of static typing.
Scala is intriguing. My efforts to learn Scala led me to your blog. Thanks for the insights. You can have a repl in Scala, but it ends up being a lot more limited. For example, you can't reopen classes in Scala's repl and add more methods to them; once you've defined a class, it takes over that name and previous versions are not accessible. I haven't played with Scala's repl much, but I'm sure there are many other such limitations, since Scala has no interpreted mode and no open classes.
But then even in dynamically typed languages, it can get kinda tricky changing anything anywhere in code while keeping live objects around which were created with older versions of the code though Ruby definitely copes with this better than quite a few other dynamic languages.
Be that as it may; I see this more as a tooling issue than as a criticism of the language. Using JavaRebel it's pretty much possible to do anything to anything with any language, so I don't really consider that a way to excuse Scala's staticness limiting the more dynamic features people love about Groovy or Ruby.
Scala can do a lot, but it's not a dynamic language. Charles - noone is claiming that scala is dynamically typed :. Its just within the confines of static typing you need to implement things differently to dynamic languages e. JavaRebel, structural typing, traits and implicits instead of open types and catching missing method declarations in Ruby. But like anything in IT; there are trade offs. A slightly vague question but: With both Scala and Groovy attempting to be "a better java", and especially in the enterprise that being a difficult thing, is there any chance the Scala and Groovy camps could work together and synergize more on syntax or features?
Broadly: Could Groovy have been the interpreted dynamic version of Scala? More concretely: There's a tradition of interpreted languages being written in lower level languages, e. Perl or Ruby initially in C, Groovy in java. But in a different world, if Groovy had been designed after Scala was already available, might it have evolved as more of a true hybrid of this "type inferencing static language" which is Scala, and the truly dynamically typed language which Groovy is today.
And by this I mean that right now, though you can optionally specify types in Groovy, you don't get any performance benefits you just get some run-time type checking right But it seems like - ideally - those optional type specifications would have allowed Groovy to generate smarter byte code that was closer to what java or scala is doing.
A true hybrid of dynamic and static typing where you can choose the greater run-time flexibility of a dynamic language or the greater performance benefits of static typing as you wish by just including or omitting the types I guess I'm probably underestimating the technical challenges behind this - mostly I just hate the thought of giving up my time investment in Groovy, and in some ways actually feel there being two choices - Groovy and Scala - is actually going to further delay adoption of either - since enterprises seem so afraid of choosing something which may or may not be the "winner" five years from now One of the really interesting things about Scala is that its a very scalable language - its easy to use a library to extend the language into other areas via DSLs and so forth.
So it might be interesting adding some of Groovy's other features as a Scala library? I wonder if someone should create a concise syntax for dynamic method invocation? Then whenever you really want to use a dynamic method invocation rather than relying on type inference, you could go dynamic. Am not sure how concise it would look though. XPath is quite concise James: "Then whenever you really want to use a dynamic method invocation rather than relying on type inference, you could go dynamic.
As for your other point, this is the direction that Fan took by offering a different syntax for dynamic invocation: foo. Cedric sorry I should have used the phrase "static typing" not "type inference" hence your confusion. I'd not had enough coffee! BTW I mentioned this idea in passing on twitter - implementing dynamic typing in a library for scala, and someone's created an implementation already I wonder if we can improve the syntax any from this Thanks for posting this James!
I've used bits of your work over the years remember Jelly? Hopefully you'll continue your advocacy and we can all benefit from the future growth. For me, Scala's appeal is its native support for mixins stackable traits , something that I've spent a lot of time replicating via bytecode gen in Java.
Once you get used to code reuse in this way, there's no going back. I think it makes Scala an easy sell. Hi James, Great post and great comments all around. Certainly made me wanting to find out more. A fixed set of standards some good, some bad, some ugly that did not evolve too radically also helped gained traction in the enterprise environment. A lot of enterprise decisions are based on product in this case Java language stability; of technology and arguably more importantly, the organization backing that product.
With the acqusition of Sun, the backing that enterprises look out for is basically pulled from under Java. When I say backing, I meant the paradigm of growing Java as an open language platform as opposed to developing it like a typical Oracle application. Yes there may be a scramble for a javac replacement.
But how does Scala address the concerns of enterprise biz? Technically Scala, Groovy, Ruby etc may be superior, but I feel that unless there is a big push marketing, evanglising, support, open standards etc by an enterprise-strength player into the enterprise, there will never be a language revolution like what we saw in the adoption of Java.
I agree completely. My opinion is that anyone that thinks Scala is too complex hasn't given it a fair chance. The bottom line is that it will simplify your code. It also doesn't stink of the maintainability issues associated with any large Ruby code base don't even get me started on performance. First of all, sorry for my bad english. To the people who think Scala is difficult to learn or hard to read.
In my opinion, it is because your way of thinking has adapted to Java. I had no problems with learning Scala, as it was my first programming language. GUIs are more complex than the command line; they will never catch on. I've heard the same sort of arguments against compiled languages vs. These are reactionary arguments, and they are always wrong -- which is not to say that the conclusions are necessarily wrong, but the logic is. All of these "complexities" were technical advances that furthered fundamental software design principles, some of which weren't widely recognized until after the advances had been made.
Scala offers a remarkable number of these advances in a language carefully designed to be scalable and pragmatic -- ignore it at your own peril. Well, I believe Scala has the potential to be the replacement for Java language, however the reality is it is not gonna happen unless there is something out there which can replace the Whole Java EE and all related technologies using scala I mean it is not all about language capabilities and simplicity I bet many of those organizations who have decided to go with Java EE to implement their huge systems would never have done that if it was just all about simplicity and productivity The big pity is I really think Scala has everything that it takes to be the next face for Java Technology and makes Java stands a head and shoulder above all other rivals again after a few years falling behind; however the reality is nobody is gonna ditch the whole Java EE and all well-proven related frameworks and start using a framework like Lift to implement their big systems, but if there was something like 'Scala Enterprise Edition' then it would be too hard to say no to it, since it would mean that you would get all good qualities that you could have achieved using classic Java EE plus improved productivity, testability and maintainability and more importantly having happier programmers since they would be able to indulge their inner curiosity and creativity without screwing thing up or falling behind schedule since they would be working with a nice, conscious and flexible language.
Coming from lots of Perl experience, I have no issue reading Scala, Ruby, Python code at the first glance. So Java folks, printing out "Hello World" isn't always System.
Amir very good point. A lot of enterprises like the appeal of Java EE. Though increasingly those same enterprises often are happy to go the Spring route instead these days too or other open source frameworks.
The nice thing is you can use Scala and Java EE or Spring and Scala makes both of them better; though quite a lot of Java EE and Spring is a bit redundant or could be done so much better with real functions in Scala. Though gradually lots of things are improving. Scalate is now much better than JSP. They are doing a wonderful job!
Father isn't those who create, but those who make you son grow. IMO Groovy will be the long term replacement for Java because today just because it innovate! Groovy breaks the trade-off "dynamic language vs. James, it is really very strange situation, usually language creator is more optimistic about the result of his work.
0コメント