Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I've forked this question from a similar question I made in a comment I made to one of the many great answers I recieved. I was originally asking about AST macros, which mostly provoked very detailed and thoughtful responses from Lispers. Thanks.
Lazy Evaluation vs Macros
The question I made in a comment was whether project-specific DSLs are actually a good idea. Of course, this is completely subjective -- After all, when you are writing in a really expressive language, where do you draw the line between an expressive API and an actual DSL? For example, I think what most Rubyists call 'DSLs' are actually just well-designed APIs and nothing more.
Note that I say project-specific APIs. I don't think many will argue against using regular expressions or SQL where it makes sense to do so.
But despite this, I think we can all draw a vauge, hazy line between an API and a DSL. Of course they're both really APIs, but whatever.
On one extreme you have Lisp, where DSLs seem to be actively encouraged via macros. On the other you have the likes of Java where DSLs are pretty much impossible.
Proponents of DSLs would argue that they increase flexibility, expressiveness, and increase consistency (for example, a custom number object using the same operators as the language's own numbers).
Detractors would say that they can lead to sub-languages that nobody except the DSL writer knows, kills the point of having different programming languages in the first place, and leads to code nobody can understand because the way of interfacing with API is different.
I gotta say, I agree with both sides in many ways. Some Java APIs are just plain nasty due to the lack of expressiveness. Despite this, I can generally always work out what's going on without reading the documentation -- Which can't be said about custom DSLs in the slightest. Maybe DSL proponents argue that you should always read API documentation. I disagree, but I also digress.
But let's look at some of the big languages at the moment. C# and Java, namely. Neither of them really 'do' DSLs, yet they're massively popular. Is this precisely because they don't allow things like DSLs, allowing mediocre coders to churn out code that's still comprehensible?
Is the fact that DSLs allow mediocre coders to produce impenetrable garbage the reason why Lisp is not used as much as it should be, despite what a DSL can look like in the right hands?
There are of course arguments in favor of DSLs and against them, and there's of course a vague line between "a library" or "an API" and "a DSL". That part you've covered well in the question, so I'll avoid those subjective points and focus on just the question of whether they're a liability.
A good project to consider for this is Racket which puts language construction as its main feature. It's easy to slap up a language for any definition of "a language": DSL or not, made up from near scratch via an interpreter or (more commonly) done via macros that define the new language and possibly a parser for a different syntax. As a result, the Racket source tree has a bunch of languages -- some of them have fundamentally different execution semantics. Some examples:
Lazy Racket is what you'd expect the name to mean,
Typed Racket is a statically typed language,
Scribble is a language for writing documentation and other prose,
Slideshow is a language for writing ... slideshows,
RackLog/DataLog are languages that are even more different in both semantics and syntax.
In fact, making up languages is so easy in Racket, that you easily slap up a language even if it's something that fits a very limited use, or even just a single one. For example, we have such "small languages" that are used to create our web pages, decide which files are included in distributed installers, and many many more. See this tutorial for a description of how to come up with a language.
It's true that there's a fine line between a useful DSL that many people can use and one that only one person uses -- but still, the kind of abstractions that you can get when you define a language rather than a library are substantial, to the point that it's a useful concept even when it's a "one-man's language". One hard problem in this are is considering interoperability -- Racket allows each module to be written in it's own language, which brings up issues of what happens when several of these modules are supposed to talk to each other. For example, how does evaluation proceeds when there's interaction of functions in the lazy language and in the default one; or how does the typed make sure that it can interact with the default untyped language and still get the usual benefits of a statically typed language.
DSLs are widely used in Java. Just not 'internal' DSLs. Lisp has, unlike Java, several ways to alter the language syntax and semantics without writing a new external language. In Java, most DSLs are either external (often based on XML) or implemented with a pre-processor.
If you write a new programming language, also a domain-specific programming language, you need to:
specify it
document it
test it
make it robust
make it debuggable
make it efficient
... and more
Lisp is no magic bullet to do all that for you. What Lisp gives you is to include one or more DSLs directly into the language and it allows you to reuse or alter the Lisp facilities to implement parts of your new language.
Lisp had in its history a lot of languages implemented on top of it. Many of them were just research languages without too much effort to follow software engineering practices. Some of these languages had more effort put into them - for example because they were part of a product.
If you develop a language for your project, you need to make sure that you follow good software engineering practices and you have the resources to do so.
[This is an empirical question about the state-of-the-art: I am NOT asking if Java is cooler or less cool than the dynamic languages that work in the JVM.]
Aside from cases where performance is a main decision factor, do companies/developers still willingly chose Java over Groovy, JRuby or Jython?
Edit: If the answer is "yes," why?
Personal Note: The reason I am asking is that, while I do some subset of my professional work in Ruby (not JRuby, for now), in my personal projects I use Java. While I have written non-trivial apps in Groovy, I prefer Java, but I wonder if I should just get over it and do everything in Groovy. I like Java because I feel that static typing saves me time and aids refactoring. (No, I am not familiar with Scala.) However, I feel that this very empirical, on-topic programming question may inform my decision.
non-statically typed languages don't "scale" well in the maintenance sense. Up to a few tens of thousands of lines of code they are maintainable. Past that they just take more effort to maintain, re-factor or update. This is true of any of the non-static typed languages, Perl, Python, Groovy, Ruby etc. The tools for working with half a million lines of Python code vs the same number of lines of code in C/C++/Java just aren't there. Now it is true that Python is about 1/3 to 1/5 the number of lines of code as an equivalent Java program. So this is never going to be apples and oranges, but there is a cut off point where the number of lines of code in a non-static language will have diminishing returns on maintenance. And everyone knows that maintenance is where the true cost of a software project has always been.
Static typing still is a big thing.
While it has been argued over and over again and proponents of the dynamic approach say that the problems that dynamic typing bring can be reduced (or even eliminated) with sufficient unit tests.
I don't want to argue whether or not this argument is correct, so I'll assume that it is, for this answer.
In that case there is still one problem, which is that many shops don't have the procedures/know-how/rules/management to produce a sufficient number of high-quality unit tests.
And if I have to choose between dynamically typed code without unit tests and statically typed code without unit tests, I'll choose the statically typed one every day.
A similar issue exists with double dispatch:
In Groovy method calls are dispatched based on the actual types of the arguments at runtime (which is almost required, because the static type is unknown and/or Object most of the time). This means that there is no reliable way to know which method is called at any given point at the code, when faced with extensible class hierarchies.
Any code that calls a method with the signature foo(String) most of the time may suddenly call foo(Integer) or foo(SomethingElseEntirely) depending only on the actual type of the argument at runtime. In the Java language that can never happen, because the exact signature of the method to be called is decided at compile time.
Much like other "dynamic" language features, double dispatch is occasionally a very useful tool and the lack of it can produce some ugly constructs in Java, but it has its cost in that it makes it even harder to read, understand and reason about code.
Yes, obviously.
Why are companies still "willingly" using Java?
Because companies are inherently conservative. They don't change technologies because they're cool, or even groovy. They change, reluctantly, when there's a prudent reason to do so. Early adopters pay very heavy penalties for being early adopters.
Edit: this is not "inertia" in the pejorative sense, as in "no reason to avoid change except resistance to change", but in the sense of prudence. It is right for companies to not abandon what's working, until there's something that's provably better.
And not in the "makes developers happy because it's cool" sense of better, but in terms of more quickly and reliably meeting whatever business requirements drive development in the organization.
Java offers:
Large base of trained, experienced developers. It's hard enough finding people who are able to do software development well, without picking a language which hasn't been around as long. And training people in a new language is expensive, in both time and money.
Brand-name recognition and an easily proven track record of successfully completed projects. This is nothing to scoff at: if I tell upper management I'm beginning a project in some groovy new language they've never heard of, I have to educate them on it, and they'll rate that as a risk. With any "established" language, I can skip that step.
Well-established, mature support tools, and third-party support.
These advantages accrue to any comparison between a long-established language and a new one, not just Java and your list. I expect that one day, Groovy, et al, will be the established language, and there'll be people asking the same question about some newer, shinier language. This is the cycle. It's how it's been for longer than I've been in the business.
Aside from cases where performance is
a main decision factor, do
companies/developers still willingly
chose Java over Groovy, JRuby or
JPython?
Yes, and I believe the main reason is inertia, either on the part of the developer or the company:
Company: existing investment in Java (in terms of staff skills and infrastructure), the risks of change are perceived to outweigh the benefits
Developer: there are plenty of Java jobs available, so why bother learning another language?
Lack of available resources is probably another reason, though this is something of a chicken-and-egg problem (or a Mexican standoff, or a self-fulfilling prophecy, or something else). I imagine there are a lot of companies watching Groovy, Jython, etc. but waiting for them to become more widely adopted before taking the plunge. Obviously, by postponing adoption themselves, they're exacerbating this lack of resources problem.
Personal Aside
I spent the last year working as a Groovy/Grails developer. I recently changed jobs and am now working as a Java 1.4 developer and (compared to Groovy programming) it's about as pleasant as gouging your eyes out with a rusty spoon.
Static typing is great in that it facilitates compile-time checking and code analysis tools like FindBugs, but no way does it compensate for the massive amounts of (boilerplate) code it takes to accomplish the simplest of tasks when writing Java (particularly if you're using a version earlier than 1.5).
I can tell you what is going on in my company. Our current application is done in java, but we have started a transition to grails/groovy and this will most probably be the platform for the next generation of our products.
Since you are asking an empirical question, and I assume looking for empirical answers:
Aside from cases where performance is a main decision factor, do companies/developers still willingly chose Java over Groovy, JRuby or JPython?
Yes.
I don't think there is anything else to say.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am an experienced C++ programmer with average Python skills. The reasons I studied Python in the first place were:
to get a different perspective on programming (static vs dynamic, interpreted vs compiled, etc.)
to increase the breadth of projects that I can work on (Python allows me to do web development, develop for Symbian phones or knock up quick system administration scripts)
to complement my C++ skills.
I think that Python is great and I believe that I have achieved the above goals. I will continue to use it for small projects, scripts and web development.
I doubt that I can use it for medium to large projects though. While the dynamic typing is convenient, it allows a certain class of bugs that I find disturbing. Unit testing and linting can alleviate this problem, but static typing completely eliminates it.
After looking at some programming languages, I think that Scala looks like a good candidate:
I like the type inference and it runs on the JVM so it should be available wherever the JVM is available. I can also learn more about functional programming when using it.
But... I also have some doubts, and this is where I hope that the Stack Overflow community can help:
Portability: Linux and Windows at least I hope. What about mobile phones, is it possible to get it to run there?
C++ compatibility: can I mix C++ code with Scala? (JNI?)
Programming paradigm: I don't feel comfortable with switching to functional programming (FP) at this time. Can I use object oriented and procedural with some FP at first and then change the proportions as I learn?
Tool chain maturity: what's your experience with IDEs and debuggers? I'm using Eclipse right now and it seems OK.
Learning speed: considering my experience, how fast do you think that I can reach a workable level with Scala?
Deployment: how exactly do you deploy a Scala program? Is it a jar, is it an executable?
Finally, what do you think that are some of Scalas disadvantages?
Portability: Linux and Windows at least I hope. What about mobile phones, did anyone succeed in getting it to run there?
Yes. There is quite some movement about Scala on Android. As for J2ME, I saw something in that respect, but not much. There is some code pertaining to J2ME on the source code repository. I'm not sure how viable it is, but it looks to me that there isn't much demand for that.
I'll also mention that there is/was a pool on Scala-Lang about the desired target platforms, and J2ME was one of them, very low on the totem pole.
C++ compatibility: can I mix C++ code with Scala? (JNI?)
As well as you can mix C++ with Java, for whatever that is worth. If you haven't any experience with that, you can just read the Java resources, as anything in them will be applicable with Scala with no changes (aside Scala syntax).
Programming paradigm: I don't feel comfortable with switching to FP at this time. Can I use OO and procedural with some FP at first and then change the proportions as I learn?
Definitely, yes. Scala goes out of it's way to make sure you don't need to program in a functional style. This is the main criticism of Scala from functional folks, as a matter of fact: some do not consider a language functional unless it forces the programmer to write in functional style.
Anyway, you can go right on doing things your way. My bet, though, is that you'll pick up functional habits without even realizing they are functional.
Perhaps you can look at the Matrices series in my own blog about writing a Matrix class. Even though it looks like standard OO code, it is, in fact, very functional.
Tool chain maturity: what's your experience with IDEs and debuggers? I'm using Eclipse right now and it seems ok.
IDEA (IntelliJ), NetBeans and Eclipse all have good support for Scala. It seems IDEA's is the best, and NetBeans/Eclipse keep frog-jumping each other, though NetBeans has certainly been more stable than Eclipse of late. On the other hand, the support on Eclipse is taking a very promising route that should produce results in the next 6 months or so -- it's just that it's a bumping route. :-)
Some interesting signs of Scala tooling for these enviroments is the fact that the Eclipse plugin in development uses AOP to merge more seamlessly with the whole IDE, that the NetBeans plugin is being completely rewritten in Scala, and that there's a Scala Power Pack on IDEA that supports, among other things, translating Java code into Scala code.
The EMACS folks have extensive tools for Scala as well, and lots of smaller editors have support for it too. I'm very comfortable with jEdit's support for small programs and scripts, for instance.
There is also good Maven support -- in fact, the standard way to install Lift is to install maven, and then build a Lift archetype. That will pull in an appropriate Scala version. There's an scala:cc target that will do triggered recompilation as well.
Speaking of recompilation, neither Maven, and particularly nor Ant do a good job at identifying what needs to be recompiled. From that problem sprung SBT (Simple Build Tool), written in Scala, which solves that problem through the use of Scala compiler plugin. SBT uses the same project layout as Maven, as well as Maven/Ivy repositories, but project configurations are done in Scala code instead of XML -- with support for Maven/Ivy configuration files as well.
Learning speed: considering my experience, how fast do you think that I can reach a workable level with Scala?
Very fast. As a purely OO language, Scala already introduces some nice features, comparable to some stuff that's present in C++ but not Java, though they work in different fashion. In that respect, once you realize what such features are for and relate them to C++ stuff, you'll be much ahead of Java programmers, as you'll already know what to do with them.
Deployment: how exactly do you deploy a Scala program? Is it a jar, is it an executable?
The same thing as Java. You can deploy JARs, WARs, or any other of Java targets, because the scala compiler generate class files. In fact, you use Java's jar to generate a Scala's JAR file from the class files, and the Maven targets for Lift support building WAR files.
There is an alternative for script files, though. You can call "scala" to run Scala source code directly, similar to a Perl of Shell script. It can also be done on Windows. However, even with the use of a compilation daemon to speed up execution, start up times are slow enough that effective use of Scala in a heavy scripting environment needs something like Nailgun.
As for Scala's disadvantages, take a look at my answer (and other's) in this Stack Overflow question.
Scala is an evolving language well worth to invest in, especially if you are coming from Java world. Scala is widely covered at Artima. See this article from Bill Venners and also read about Twitter and Scala.
Regarding your questions:
Java can run wherever there is a JVM. No luck with the mobile phones however. You need a full JRE, not the subset that is available there.
This is possible with JNI. If something is possible with Java, then it is possible with Scala. Scala can call Java classes.
Functional programming is a strong point of Scala - you do need to learn it. However you could also start using it without taking full advantage of it and work your way with it.
There is a plug-in of Eclipse. It is not best, but it will do the job. More details here.
If you are experienced, I would say really fast. I recommend that you find a book to start with.
See this faq entry for deployment.
Programming paradigm: I don't feel comfortable with switching to FP at this time. Can I use OO and procedural with some FP at first and then change the proportions as I learn?
Scala has full support for imperative programming, writing programs with no FP elements in it is a breeze (however, FP is useful and worth learning anyway).
Learning speed: considering my experience, how fast do you think that I can reach a workable level with Scala?
Quickly. There is a number of interesting features in Scala that may be not familiar to people coming from a C++, Java environment, like for example some of the features of the typing system. Some argue that the fact that there is a lot to learn in Scala before you know all of it is a problem with the language; I disagree. The presence of those feature is an advantage of the language. The more features the merrier. After all, you don't have to use them all at once, just like you don't have to buy everything that is being sold in the store.
Learning speed: considering my experience, how fast do you think that I can reach a workable level with Scala?
I also come from a C++ background, one thing I noticed is that since you will write a lot less code as compared to C++ for a comparable task, your learning will be expedited as you will get more done in the same time period. This was the same phenomenon that I experienced with Ruby.
Actually - if I were you - I'd study programming paradigms instead of languages. Of course you have to study an example language to study the paradigm. Knowing the drawbacks & benefits of different paradigms enables you to view your problems from a different side and makes you a better programmer (even in the languages you already know).
Picking up a language of a paradigm already known is a relativly easy task if needed. Since Scala is FP (at least you mentioned it) and C++/Python is OOP, it's a good language for you, I'd say.
You should register for this course by the Creator of Scala himself.
https://www.coursera.org/course/progfun
James Strachan (productive Java open source developer, for those not in the loop) has an interesting discussion of Scala here, and why he feels it's a progression from Java (the langauge, not the platform).
Scala looks like it's gaining a lot of traction. I don't think it's a flash in the pan, and is currently on my list of languages to learn (partly for the functional aspect)
Here's an anecdotal evidence regarding learnability of Scala.
In our company, we got several interns from U.Waterloo. They were told to write in Scala; never saw it before.
They picked up Scala and Lift remarkably fast; now they are producing Scala code; it may be not perfect, but nobody's perfect.
So, the fact that a manager does not know Scala may be not the best argument when you decide on adoption.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I have to write a prototype app for an engineering company. Most of the work is calculating various engineering properties (I'm talking pipes and real things here, not software engineering).
However, there will also have to be a GUI for:
parameter entry
displaying results
some basic diagramming
The calculation work at the moment doesn't involve complex math elements (no matrices at the moment), just logs, square roots, relatively simple formulae. Later I will have to do some:
curve fitting
numerical approximation
I was wondering if Java has been used for real world engineering apps?
Are there libraries available for this sort of thing?
Or am I better off writing in MatLab and then connecting to the code through Java?
Also open to other languages (although we are a Java shop).
I have some experience of both Matlab and of Java for scientific/engineering type codes. Yes, Java is used for real-world scientific and engineering codes, and yes there are libraries available. You can certainly do what you want using either so I'm not sure that you could sensibly distinguish between the two on the sole basis of your current requirements. I'd ask myself the following questions:
How good am I at programming advanced mathematical operations? Operations such as function minimisation, differential equation solvers, matrix algebra. If the answer is not very then lean towards Matlab which will provide all of these out-of-the-box (though you may need additional toolboxes). If you opt for Java, make sure you are very comfortable with floating-point arithmetic and dealing with the sorts of errors which occur when you use it.
Do I want to code everything in Java, everything in Matlab, or am I happy to use both and to wrestle with, say, a Java GUI on a Matlab engine ? I think you can do much better (in a vague sense) GUIs with Java than with Matlab, but Matlab's GUI facilities are good enough for most of its users that the added complexity of integrating Matlab with Java is not worth tackling. But then many Matlab users are not software engineers.
What speed of development do I need for the prototype work ? If you were equally skilled in Java and in Matlab then I'd guess that you could do it quicker in Matlab, because the numeric stuff is already provided, you could concentrate on the GUI. But if you are a skilled Java programmer coming newly to Matlab you might decide to stick with what you know.
How will I develop and deploy the production app if the prototype is successful ? If Matlab doesn't fit your deployment ideas then learning it and forgetting it may not be rewarding.
Finally, since you solicit other language recommendations: forget Java, forget Matlab, forget Python, forget R, use Mathematica, it's way more fun and very powerful.
This sounds like a job for Matlab: you don't give any reason not to use it. There's some code for evaluating Matlab expressions from Java: http://www.cs.virginia.edu/~whitehouse/matlab/JavaMatlab.html
I have done some work where I had to reimplement Matlab code in Java so it is certainly possible. The Java code can end up being quite verbose compared to the Matlab original due to Matlab being able to operate directly on matrices/arrays etc.
Some math libraries that you might want to look at to see if they support the functionality you are looking for:
Commons Math
Colt
JSci
I guess that Java would be a good choice, even though it is not considered a typical language for rapid application development.
Pros:
versatile GUI toolkit for desktop applications in standard library (Swing),
(relatively) cross-platform,
great libraries, e.g. from Apache; a great math library to look at would be colt; for charts and diagrams, you may like jfreechart ..
Cons:
"not so rapid" prototyping capabilities
Further reading:
Technical Java: Applications for Science and Engineering
Python has several decent GUI toolkits as well as NumPy, and is easy and fun to write in.
This depends mainly on how easy it will be in your environment to include the mathlab or other math engine in your product. If this is easy, I would suggest to use mathlab, but if not, e.g. you have licensing issues or deployment issues, you are probably better of just using plain Java code.
You may also want to consider R language.
I would do a search for software that's written to do piping calculations. This problem has been done. (As you've noted, the calculations need not be difficult.) At a minimum I'd recommend that you know what's available to you, how much it would cost, and where the break even point was for development costs.
A commercial product will have one huge advantage over anything you'll write: It will have a larger user community that's been banging on it and finding bugs for a longer period of time than your prototype. That's worth something as well.
What's your opportunity cost? What else could you have done with the development time that would drive more revenue?
Don't forget numpy or scipy. Both allow you to call fast matrix libraries from Python.
I'm developing a LoB application in Java after a long absence from the platform (having spent the last 8 years or so entrenched in Fortran, C, a smidgin of C++ and latterly .Net).
Java, the language, is not much changed from how I remember it. I like it's strengths and I can work around its weaknesses - the platform has grown and deciding upon the myriad of different frameworks which appear to do much the same thing as one another is a different story; but that can wait for another day - all-in-all I'm comfortable with Java. However, over the last couple of weeks I've become enamoured with Groovy, and purely from a selfish point of view: but not just because it makes development against the JVM a more succinct and entertaining (and, well, "groovy") proposition than Java (the language).
What strikes me most about Groovy is its inherent maintainability. We all (I hope!) strive to write well documented, easy to understand code. However, sometimes the languages we use themselves defeat us. An example: in 2001 I wrote a library in C to translate EDIFACT EDI messages into ANSI X12 messages. This is not a particularly complicated process, if slightly involved, and I thought at the time I had documented the code properly - and I probably had - but some six years later when I revisited the project (and after becoming acclimatised to C#) I found myself lost in so much C boilerplate (mallocs, pointers, etc. etc.) that it took three days of thoughtful analysis before I finally understood what I'd been doing six years previously.
This evening I've written about 2000 lines of Java (it is the day of rest, after all!). I've documented as best as I know how, but, but, of those 2000 lines of Java a significant proportion is Java boiler plate.
This is where I see Groovy and other dynamic languages winning through - maintainability and later comprehension. Groovy lets you concentrate on your intent without getting bogged down on the platform specific implementation; it's almost, but not quite, self documenting. I see this as being a huge boon to me when I revisit my current project (which I'll port to Groovy asap) in several years time and to my successors who will inherit it and carry on the good work.
So, are there any reasons not to use Groovy?
There are two reasons I can think of not to use Groovy (or Jython, or JRuby):
If you really, truly need performance
If you will miss static type checking
Those are both big ifs. Performance is probably less of a factor in most apps than people think, and static type checking is a religious issue. That said, one strength of all of these languages is their ability to mix and match with native Java code. Best of both worlds and all that.
Since I'm not responsible for your business, I say "Go for it".
If you use Groovy, you're basically throwing away useful information about types. This leaves your code "groovy": nice and concise.
Bird b
becomes
def b
Plus you get to play with all the meta-class stuff and dynamic method calls which are a torture in Java.
However -- and yes I have tried IntelliJ, Netbeans and Eclipse extensively -- serious automatic refactoring is not possible in Groovy. It's not IntelliJ's fault: the type information just isn't there. Developers will say, "but if you have unit tests for every single code path (hmmmm), then you can refactor more easily." But don't believe the hype: adding more code (unit tests) will add to the safety of massive refactoring, but they don't make the work easier. Now you have to hand fix the original code and the unit tests.
So this means that you don't refactor as often in Groovy, especially when a project is mature. While your code will be concise and easy to read, it will not be as brilliant as code that has been automatically refactored daily, hourly and weekly.
When you realize that a concept represented by a class in Java is no longer necessary, you can just delete it. In Eclipse or Netbeans or whatever, your project hierarchy lights up like a Christmas tree, telling you exactly what you've screwed up with this change. def thing tells the compiler (and therefore your IDE) nothing about how a variable will be used, whether the method exists, etc. And IDEs can only do so much guessing.
In the end, Java code is filled with "boilerplate," but it's been kneaded into its final form after many refactorings. And to me, that's the only way to get high-quality, readable code for future programmers, including when those future programmers are you-in-the-future.
Two reasons why Scala might be a compelling alternative to Groovy:
Performance on par with Java
Static typing without clutter
One of the biggest things you lose when you use dynamic languages, especially in a large codebase is the ability to use an IDE to re-factor. Languages that allow dynamically adding code to objects simply can't be parsed by today's IDEs to allow the kind of easy refactoring methods you can get from Eclipse, etc. for Java, C++, etc.
It's not really a case of "Dynamic languages are better than Static". Use what's best for you. The really cool thing about Groovy in particular is you can mix and match Java and Groovy in the same project, and it all runs on the VM. Yes, Scala is another example.
I think the biggest issue is lack of IDE support compared to java, however the plugins for Eclipse and Netbeans are getting better all the time. Also, if I remember correctly Groovy does not support anonymous inner classes if you really need them for some reason. I would personally choose Groovy anytime though.