This is my impression, too. I think Groovy's "static" features are a reaction to a lot of developers realizing that "statically typed" doesn't necessarily mean that the language has to be as cumbersome and verbose as Java.
Imho, there is just no reason for building/using/preferring a dynamically typed language, except when the language designer lacks the necessary abilities to build a sound and coherent type system.
Scala has none of Groovy's drawbacks, a lot of benefits combined with a clear roadmap -- and most importantly: The determination to not only get something working, but also to get it right.
Meanwhile, the language gets more consistent and polished with every release.
The static features of Groovy 2.0 are actually a reaction to users demand and wishes.
You can read the article to have a more elaborate explanation of this, but in a nutshell, our users want to be able to type check their code especially when Groovy's used as a kind of "scripted Java" as they expect the same feedback as the java compiler provides. Especially when Groovy is used "à la" Java rather than to rely on its useful dynamic features. And our users are also interested about pure raw speed for computations, or avoid being subject of monkey patching, hence why static compilation matter in some situations.
I don't want to enter into polemical arguments here, as I have nothing against Scala, on the contrary. But your arguments about type systems vs dynamicity or supposed Groovy's drawbacks don't really seem to be factual and backed by any concrete claims or analysis. So I won't comment on that.
Maybe the Scala examples you think of indulge in quite a bit of destructive updates?
Functional programming style tends to generate lots and lots of objects which die very young. Garbage collectors must be tuned for that. At least they should be generational. Mayhaps Dalvik's current GC is not?
> Functional programming style tends to generate lots and lots of objects which die very young.
Well, there is a lot of Scala code out there doing exactly that.
HotSpot has no problems with short-lived objects in pretty much all its garbage collectors while Dalvik's GC is just a lot less sophisticated and mature.
So I mainly agree with you, but the proposition of
Language allows producing lots of short-lived objects
+ Dalvik sucks
------------
Programs in that language have to be slow
doesn't hold in my opinion, as seen in the differences between Scala and Clojure.
> Well, there is a lot of Scala code out there doing exactly that.
I talked about specific examples that I don't even know of. I don't know Scala enough to know whether non-destructive updates are the default. Are they? What about the core libraries?
I agree your proposition in fixed width font does not hold. I was merely asserting this one:
Program P produces lots of short-lived objects
+ Dalvik sucks (or is tuned for long lived-objects)
-------------------------------------------------
Program P have to be slow
Clojure still generates a lot more garbage, especially during bootstrap. This can be seen easily with VisualVM on the desktop, comparing hello world in the two languages.
Scala generates a lot less garbage, by construction. A lot of that has to do with its compilation model, which is a lot closer to Java's than Clojure's is.
Clojure just assumes the JVM can deal with it, and desktop ones do just fine, hence why no one noticed.
You're missing the point. The problem is that as an author you have to implement an interface which is probably completely unrelated to what your class is doing, otherwise you get punished by bad performance.
Scala solves this problem nicely with traits, btw.
I may also be missing the point but what prevents you from putting a count method on an enumerable with a default implementation which does the same?
In terms of .Count() which will attempt to call ICollection.Count you can create the same thing as an extension method or a default implementation on Enumerable.
Either way you do it you will have ambiguity regarding time complexity.
Extension methods have the advantage that the langauge designers _could_ have left .Count() off IEnumerable and then people who wanted to use it could implement it themselves and those worried about the ambiguity wouldn't have to risk people enumerating their collection needlessly.
The problem with extension methods over default implementation interfaces is that the code regarding a class can be distributed in several (potentially non-obvious) locations and it reduces portability.
The advantage is that you can extend a class or an interface you don't own, and you can have implementations specific to a given namespace.
So for a (poor) example you might extend float so you could convert an angle to a 2d unit vector, but only in given bits of your program you want to be converting between angles and vectors.
> I may also be missing the point but what prevents you from putting a count method on an enumerable with a default implementation which does the same?
Isn't that exactly what we're talking about?
The huge difference between C#'s extension methods and traits is that the first one is statically dispatched, the second one dynamically.
This means classes with a better implementation can just override Count() and suffer none of the problems of the extension method approach.
Scala also offers implicits to "enrich" existing types, slightly comparable to Extension methods, but a lot more general.
Whereas extension methods only support some ad-hoc "addition" of members to existing types, Scala's implicits allow you to use these methods to implement new interfaces -- and isn't that the reason why you add methods in the first place: to implement interfaces?
> So for a (poor) example you might extend float so you could convert an angle to a 2d unit vector, but only in given bits of your program you want to be converting between angles and vectors.
> This means classes with a better implementation can just override Count() and suffer none of the problems of the extension method approach.
Instance methods are bound before extension methods, if someone provides an implementation of Count() in a subclass it'll be invoked instead (provided your reference is typed appropriately). More narrow extension methods are bound before general ones, so you can even "override" within extension methods.
Scala has some neat stuff, but it's not Java 8 so I don't see how it's relevant.
> Btw, C# has some limited form of implicits, too, but I haven't seen any serious usage of them for a while.
That's exactly the issue I'm talking about: you can't “enforce” the static type, so different methods get called depending on whether you pass List foo = MyList(...) or MyList foo = MyList(...), which is acceptable for static methods, but a source of bugs when they can be made to look like instance methods.
> Scala has some neat stuff, but it's not Java 8 so I don't see how it's relevant.
Java's default methods are basically Scala's traits (just made a bit more cumbersome to make Java developers feel right at home), so what I said about traits applies to “interfaces with default methods”, too.
Not sure about the health care system, but the non-socialist portion of the US education system is the best in the world, and only the socialist portion of it is terrible. I find those to be reasonable grounds to dislike socialism.
To call any of those "socialist", when the paid-by-the-student cost has skyrocketed and the paid-by-the-government cost has plummeted, is a bit of a stretch.
Fair point, but they were world-class universities when the government subsidized them, too. There's no inverse correlation between government support of a university and academic quality, being my point.
Imho, there is just no reason for building/using/preferring a dynamically typed language, except when the language designer lacks the necessary abilities to build a sound and coherent type system.
Scala has none of Groovy's drawbacks, a lot of benefits combined with a clear roadmap -- and most importantly: The determination to not only get something working, but also to get it right.
Meanwhile, the language gets more consistent and polished with every release.