Archive of Groovy Language blog entries 1 Jan - 12 July 2012

This blog is conceptually separate from the rest of the Groovy Language site, and is only hosted here, with gratitude to Microsoft and Codeplex, because the original Gavin "Groovy" Grover's Blog at blogspot has been blocked by the Chinese Firewall.

See entries from 13 July 2012 onwards.

12 July 2012

Specifying dynamic Groovy

Groovy 0.5 is now available for download, still an alpha release, but all supplied code is now fully functional on both the JVM and the CLR. A sample batch file is provided, showing versions clojure-1.4.0 for Java 7 on the JVM, and clojure-clr-1.4.0-Debug-4.0 on the CLR. Groovy 0.5 runs about 3 times slower on the CLR as on the JVM. It took a bit of fiddling to get it working on both platforms, but all subsequent additions to the Groovy Language reboot will be targetted and tested for both versions.

It's now important to write a spec for the Groovy Language, so I'm reorienting my blog towards this. In 2003, James Strachan wanted a dynamic language specifically for the Java platform. Laforge and Champeau have moved Groovy down the abstraction stack by making it statically compile for the JVM, soon by default, as dictated by VMWare's business policy for Grales. This spec will move Groovy up the abstraction stack by leaving out VM-specific details. The JVM was the only game in town 10 years ago when Groovy was born, but now it's been bought by evil Oracle, Microsoft's CLR is of equal value. So I'll spec Groovy as a multi-platform language, and the Groovy reboot will follow this spec.

Jochen Theodorou started a thread on semantic changes for Groovy 3, so we'll use these discussions as well as the current dynamic behavior of Groovy 2.0 to slowly develop the spec. Jochen, however, is restricting the discussion to the semantics only, but we'll look at both semantics and syntax. Why not? Every change requested by the Groovy User Community will be considered. Users should be treated with respect, not bullied. Here's a rough summary of current discussions on that thread. Because Laforge has abandoned a Groovy Spec after 8 years of neglecting JSR-241, then I'll need to take the lead in specifying the Groovy Language.

5 July 2012

Groovy's Broken Closures

Groovy creator James Strachan wrote (see below): no other dynamic language I'm aware of has any concept of Groovy's dynamic name resolution; names are always statically bound to objects in a sensible way in all dynamic languages I'm aware of (lisp, smalltalk, python, ruby etc). Groovy threw away decades of language research and development with respect to name resolution across the language as a whole.

So how did the Codehaus implementation of the Groovy Language get its broken closures?

2nd Groovy conference

Groovy hero Jeremy Rayner, the primary author of Groovy's current parser, provides clues in his writeup of the 2nd Groovy Developers Conference on 28 Nov 2005. Present were Jeremy, James, Jochen Theodorou, John Wilson (a.k.a. Tug), and Guillaume Laforge. Wrote Jeremy:

The discussion soon turns into a heated debate over the treatment of vanilla names.

class MyScript{
  String toString(){
    return "foo"
  void run(){
      //does this call MyScript.toString() or myList.toString() ?
Tug argues the enclosing object instance should listen for and consume names prior to the lexical scope. (i.e. above example would call myList.toString()). James argues that the default should be lexically bound to the current context (i.e. above example would call myScript.toString()), and if the object instance was needed to be referred to that some form of syntax could be constructed to allow this.

Day Two starts out more productive, ... ... ... However the discussion soon gets round to the topic of Builders (a.k.a. Markup) and again the name resolution and scoping bear comes up to bite us again.

We have Tug and Guillaume firmly on the side of Builders being in charge of everything defined within the markup delimiters. James argues that markup is fundamentally broken and some kind of syntactic clue that we are suddenly entering a different 'markup world' where normal resolution and scoping doesn't apply. For some reason, that I cannot fathom, Tug and Guillaume both seem vehemently opposed to any indication in the code that we are in a Builder section. This includes both the suggestion of a 'with' keyword or .{ notation to indicate to the reader of the code that something different is about to occur.

String toString() {
  return "foo"
  panel() {

//or the even clearer...
with( swingBuilder.frame() ){
    button( toString() )
We were all fairly happy that the Builder could be responsible for name resolution inside it's own block (e.g. the swingBuilder instance would be responsible for how it treats toString() inside), but what seemed to really be a sticking point was the important fact that due to the dynamic nature of the name resolution/scoping within this block, some visual clue to the reader of the program was necessary.

James argued for, and I agree that, the use of some kind of syntactic indication was vital to ensure that the Groovy language was sane, predictable and maintainable. Thus implying to any compiler, IDE, or human reader that the block of code was not a true lexical closure, but some other construct which was dynamic in it's very nature, and thus warnings, code completion and everything else specification related did not apply, as the responsibility would lie with the implementation of the builder.

I'm sad to report that no agreement was reached on this matter. Not so much which syntax would be useful, but actually whether we should have any syntax denoting the difference between a true lexical Closure and one of these Builder blocks. The historical reasons go back to Builder blocks looking just like Closures, and I'm afraid this long standing mistake must be removed from the language before any true progress can be made, as no sensible specification rules can be applied while the dichotomy exists.

I headed back to London with a very disappointed James Strachan, the language which has some of the finest minds, and most exciting ideas now faces a pivotal point in its life, and I'll do everything I can to ensure that clarity over dynamism wins the day.

Strachan's final ever email

Two days later on the Groovy mailing list, James wrote in response to Laforge's statement that the upcoming MOP can solve the name resolution problems in closures:

> Especially since the MOP and the introspection API can solve all these problems without introducing another syntax change which would definitely break more code in production than bring more advantages.

The MOP and introspection APIs do NOT solve the horribly broken name resolution rules in the current RI of Groovy, which is why I created the name resolution proposal to fix name resolution rules for closures and builders - introducing a syntactic difference so we can have proper name resolution mechanism for each concept in the language. Though it seems you don't think we have any name resolution issues which is making it a bit hard to discuss the problem in the first place

Notice James was still refering to Codehaus Groovy as an "RI", a reference implementation for a Groovy Language standard, of which many implementations would be built, just like with Ruby and Python.

Later that day, James Strachan made his *last ever posting to the Groovy mailing list*:

for closures its only the outer class which should be used to resolve names - that's what closures are - their vanilla names are bound, always, to the outer lexical scope. Any other concept like dynamic vanilla name resolution is not a closure. Now I'm not saying we can't support other ideas and concepts; its just they are not closures.

And: no other dynamic language I'm aware of has any concept of dynamic name resolution in the way you suggest; names are always statically bound to objects in a sensible way in all dynamic languages I'm aware of (lisp, smalltalk, python, ruby etc). I see no argument yet for why we have to throw away decades of language research and development with respect to name resolution across the language as a whole - though I'm more than happy to innovate within a subset of the language (e.g. inside Markup sections). The only sensible solution I see is to ensure that the Markup name resolution mechanism is restricted to Markup sections.

And his very last sentence ever at the end: It just feels totally wrong to break Closures across the entire language just because of some use cases for Markup.

When Ruby copied the markup concept a year later, they did it correctly, so their closures are still real closures. Groovy's "closures" eventually got a name resolution field, with possible values like DELEGATE_THEN_OWNER, OWNER_THEN_DELEGATE, DELEGATE_ONLY, and OWNER_ONLY, of which DELEGATE_THEN_OWNER, indicating dynamic field resolution, is the default.

And despite there being many ex-developers and ex-despots in the Codehaus developers roll, James is unique in having been stripped totally of his commit privileges.

Why'd he do it?

What was the reason Laforge didn't want to fix Groovy's broken closures? He'd written that fixing the syntax would "definitely break more code in production than bring more advantages". Laforge was showing concern for existing production users, even though there weren't really any at that time because Grails 0.1 wasn't released until 3 months later. We can see more clues in his later postings...

A few months ago, Groovy hero Russel Winder, co-developer of Groovy's gpars, asked on the mailing list:

Looking at, the section on "Free variables" specifically states that Closures employ lexical binding, i.e. are closures. The examples work because the examples are such that they work. However Groovy doesn't actually create lexically scoped closures. The question is whether to make Groovy 2.0.0 do what the documentation (and the rest of the planet) expect of [Cc]losures or whether to correct the documentation for what Groovy actually does?

Laforge replied: Correct the documentation! Changing even just the naming of what people are used to use for 8+ years, that's more painful for everybody. Only perfectionists care of the few differences with "real closures" (TM). In the end, Groovy is for pragmatic people more than for language theorists.

Russel replies:

> Changing even just the naming of what people are used to use for 8+ years, that's more painful for everybody.

So fix the problem. Groovy 2.0 is the place to do it. There is an ideal opportunity. The MOP is changing in a breaking way between 1.8.x and 2.0.x so fix the problem. In any case I bet 99% of scripts won't notice but those 1% will make all the difference between Groovy still being around and having traction once the Java / Scala / Kotlin / Ceylon war really gets started.

> Only perfectionists care of the few differences with "real closures" (TM).

I do not believe that to be the case.

> In the end, Groovy is for pragmatic people more than for language theorists.

This I think is a very inappropriate stance. It translates to "we don't care about the rest of the world or CS theory we want to be a blue collar, insular ghetto of hackers". Still, it is your show.

Russel and Jochen continued that thread discussing the technical issues of how to fix the closures.

In his email discussions, both 6 years ago and nowadays, Laforge shows an intolerance to any changes to Groovy, just wanting to keep the status quo, even when moving Groovy from version 1.x to 2.0. I suspect he's Rocher's lackey, treating Groovy as just one part of Grails, and not changing anything in Groovy unless it's needed for Grails in some way.

But there weren't any Grails users in Dec 2005, the time of the 2nd Groovy developers meeting. Why else would Laforge be "vehemently opposed" to fixing closures in Groovy? This was about a year after I myself first discovered the Groovy Language. I believe he was trying to get rid of James Strachan, stirring up any arguments to wear him down. James wanted closures fixed, so Laforge wanted them to stay broken: it's that simple.

I've seen this behaviour many times in IT workplaces. It most often comes from "programmers" without aptitude, such as Laforge. He wanted to take over a growing open source project from someone else, so snuck in, stuck around, then struck. Et tu Laforge. The cost is broken closures in Codehaus Groovy, having "thrown away decades of programming language research and development", and "not caring about the rest of the programming world or Computer Science theory". Guillaume Laforge has ruined the Groovy Programming Language.

12 July 2012

Update to Groovy's Broken Closures

In this 4 yr old blog and comments, Guillaume Laforge and Cedric Champeau collude to influence Java's closure syntax. They want -> instead of => giving 2 reasons:
  • the => separator can be confusing e.g. {int x, int y => x >= y}
  • Groovy uses -> and more and more people are using Groovy

Java guru Neal Gafter replied: There is Groovy and Ruby (1.9+) and ML and Haskell on the one hand using ->; but C# and Scala on the other using =>. I don't think the number of users familiar with one notation or the other is a key metric for a decision.

Earlier this year, Oracle/Sun finally announced the decision to use C# and Scala's syntax, but they use the -> symbol in all their example code, e.g. (int x, int y) -> x >= y. Why was this? Did Laforge pester and pester and pester and pester and pester and pester and pester them, even dragging in "allies" like Champeau?

Groovy will probably need to support both its broken closures and Java 8's lambdas in its syntax. If Java 8 had copied C# and Scala's syntax and lexical symbol =>, Groovy's lambdas would be more visually distinct from its broken closures. Not only did Laforge cause the problem of Groovy's broken closures, but he could also be ruining the most viable solution to the problem.

1 July 2012

"Groovy Won"? , ...

Groovy's poised to jump back onto the Tiobe top 50 again this month (July 2012), perhaps even winning a top spot in the 21-to-50 table. The Tiobe programming language rankings give a month-by-month ranking of language popularity, but there's a huge margin of error. Useful information can be derived from its listings though...

To calculate the rankings for a month, early the following month Tiobe run searches through the top searchable websites, currently 7 of them. Often a few searches are used, e.g. "snobol programming" and "snobol language". Only one engine's result is used, the highest. They're then multiplied by a heuristically chosen weighting to account for other uses of a common word, e.g. perhaps "U programming" is multiplied by 75%. The final results for each language are then ranked.

Groovy first entered the top 50 about 7 years ago, and sat around #45 for quite a while. It dropped out again once or twice. In late 2010, Jochen Theodorou volunteered his services to Tiobe to "fix their algorithm". The following month, Groovy started rising rapidly, reaching #25 in March 2011. The following month, Tiobe suddenly increased the number of search engines used from 4 to 7. A few languages slipped a little, others rose, but Groovy was spectacular in dropping from #25 to #65 in a single month! It remained out of the top 50 for 8 months until December 2011. It rose again slowly, reaching #28 two months ago, then slipped out of the top 50 again in June 2012.

Many of the languages, especially those below the top 15 or so, have backers who try to game the rankings. The gamers only need to fool one search engine to get the language up. They'll target the easiest-to-fool engines, e.g. Baidu rather than Google. They could target more than one if the following month is considered an important month, but generally the more engines they target, the more effort it takes. So gamers will likely be contrarian, looking for the engines backers of other languages aren't targeting in that month.

Because of this backdoor way of gaming Tiobe through manipulating search engines, the ranking below #15 generally have a huge margin of error. But when something sudden happens, like search engines being added unannounced, that's when the bare truth emerges. Groovy's ranking straight after the increase to 7 engines, in April 2011, is the most accurate ranking of the languages possible. Groovy's longterm ranking, devoid of any ranking games, is #65.

Doubtless, certain websites have more weighting than others with various engines, e.g. an article on InfoQ will be worth far more than a personal blog entry. And that's the logic behind VMWare's Groovy P.M. Guillaume Laforge's 2nd-to-last posting about Groovy on 30 Nov 2011, the day just before Tiobe starts searching: to get Groovy back onto the Tiobe top 50 after 8 months off it. It was all part of selling as many seats as possible to the Gr8te conference in Copenhagen in early June. Laforge didn't bother with his Baidu-or-whatever search engine fiddling for June - he no longer needed to promote the Gr8te conference, or maybe he was too busy - so Groovy dropped off again.

But Groovy 2.0's just been released, and Rocher's put Laforge on some sort of performance evaluation for Groovy 2 downloads. And that's the logic behind Laforge's recent spate of end-of-month postings, on infoQ, Jaxenter, h-online, and wherever else he's been: to boost Groovy back onto Tiobe. I'm sure Laforge has become quite skilled at gaming Tiobe now, after all the practice. Groovy's might even "win" the place above its "competitors" Scala, Clojure, Kotlin, etc for July. But with a bare truth ranking of #65, it will have "won" nothing at all.

29 June 2012

Promoting Groovy 2, ...

EMC/VMWare manager Guillaume Laforge has just announced the official release of Groovy 2. He submitted this quarter's allotment of Groovy copy to InfoQ, and linked to it from his blog, the Groovy/Grails/etc mailing lists, a DZone notice, and a Hacker News submission. Laforge and Codehaus control many of these sites. The content on InfoQ and DZone are tightly monitored on behalf of IT businesses. And to manage opinion on Hacker News, three new users (gr8ful, nithril, glaforge) were created just to comment on Groovy 2.

Groovy 2 at Reddit.jpg But in the programming wild, the story's different. A submission to _Proggit_, the programming subreddit, brought zero interest within 24 hours, on a week day at that. I submitted that reddit link without telling anyone. When there's no email or twitter nudges by Laforge and sockpuppets to vote up Groovy somewhere, it comes in at 0 votes, with no comments. With 375,000 subscribers, as audited by reddit, Proggit's a lot more difficult for Laforge to fool with smoke and mirrors. Even more difficult to fool is OReilly's annual worldwide Groovy book sale (all titles) total of 1205 books, far lower than Clojure's and Scala's. Laforge's claims contain unproven numbers and no names.

Invoke-dynamic a phantom?

The InfoQ article about Groovy 2.0 revealed some truth about Groovy that had been obscured until now. The static checking and compilation featured first in the article, eight times the space given to the invoke-dynamic changes much further down. The invoke-dynamic blurb says "In our testing, we noticed some interesting performance gains in some areas, whereas other programs could run slower than when not using the invoke dynamic support. The Groovy team has further performance improvements in the pipeline for Groovy 2.1 however, but we noticed the JVM isn’t yet finely tuned and still has a long way to go to be fully optimized." Is invoke-dynamic really shipping in this release of Groovy? Is Jochen Theodorou really still full-time on building Groovy, or has Laforge finally replaced him with Champeau?

The Groovy 2.0.0 distro file has two separate jars, one enabling static compilation, the other enabling invoke-dynamic on JDK 7. We can use one or the other, but not mix statically compiled code and code using invoke-dynamic in the same compilation. The reason Graeme Rocher gave 6 months ago for not using Alex Tkachman's Groovy++ for static compilation was "The Groovy team, myself included, have reviewed the code of Groovy++ and believe that most of it will need to be rewritten and rearchitected because it has to take into account how it'll play with the upcoming invoke dynamic support, the static type checking, the existing primitive optimizations, etc."

And yet here we are, with VMWare's version of static compilation, still not playing well enough with invoke dynamic to be shipped in the same jar. Rocher's reason for booting Alex Tkachman was a fabrication. They just wanted to launder the Groovy++ code he wrote and bring it into their own cathedral. Rocher and VMWare want tight control of Grales, and all the software it depends on. Groovy 2.0 is not much more than Groovy 1.8 and Groovy++ shipped together, something Groovy champion Alex Tkachman was providing a year ago, and I was providing with GRegexes thrown in too. Rocher and Laforge are open source thieves.

Groovy 3 tasks canned?

Within a day of my previous post suggesting VMWare won't pay for the 3 tasks slated for Groovy 3, the Codehaus Groovy roadmap changed delaying one of them: "Rewrite the Groovy grammar from scratch with Antlr 4 (moved to Groovy 4.0 in 2014)". Champeau emailed regarding Java 8 lambdas: "Lambdas in Java 8 and Closures in Groovy are two very different beasts. Lambdas in Java 8 must be assigned to interfaces and cannot be "manipulated" like the closures from Groovy. We must support both or we'll loose very useful features.", casting doubt on another Groovy 3 task. The remaining task, the rewritten MOP in Groovy 2.0, was delayed repeatedly for 5 years, then finally shunted from Groovy 2.0 to Groovy 3.0. We'll never see a new MOP.

I suspect Theodorou started the Groovy 3 mailing thread to drum up Groovy community support for continued VMWare backing. Notice Russel Winder, Dierk Koenig, and Paul King never commented. They know Laforge has already decided to dilute Jochen's importance to Codehaus Groovy. Groovy will splinter into separate preconfigured distros, one of them with static compilation turned on by default. They'll then promote this product as the "preferred" download of Groovy, to compete with Kotlin, Ceylon, and Scala, with Champeau as Tech Lead for this distro. Finally, Champeau will displace Jochen completely.

Groovy vs Grails

The Groovy Language is rebooting atop Clojure. After all, Groovy's just a syntax. VMWare decided to tie it to the JVM to make Grales faster, but the reboot will abstract away both the JVM and the CLR. No static compilation nonsense here. Real Groovy will move Groovy forward, up the abstraction stack, not downwards like Laforge and Champeau's latest trick.

Xiangqi.jpg We'll also be straight up about who the real villain of the Groovy Language is. Laforge is just a puppet installed by Grales P.M. Graeme Rocher as a decoy. Laforge stabbed Strachan in the back in 2005, but got knifed himself by Rocher afterwards. Rocher also took calls from busybody Australians around 2007 to attack my involvement in Groovy, instead of saying "Sorry, we don't do that here". So if Rocher wants attack, I'll attack.

But he didn't know what game was playing. He thought it was chess on the squares of an 8x8 board. Surely he didn't think I jumped from city block to city block like Spiderman? No, I took the tram riding on the streets in between, like in Chinese Chess, or Xiangqi. And with the Melbourne city loop now enclosing the Docklands extension, the Chu River Han Border is in play. The grid is 9x10 edges. Evil Grales is black on top, underdog Groovy is red underneath. And like Simba, the real Groovy Language, built atop Clojure, will eventually smash the prison Grales has put it in. Rocher will be roadkill: I shall be avenged!

27 June 2012

Groovy 3...

Jochen Theodorou has just begun a discussion on semantic changes for Groovy 3, "which is supposed to get released next year". He adds "Vmware has no problem so far in letting me do that new MOP and paying me for it ;)".

The Codehaus Groovy roadmap lists 3 features slated for Groovy 3:
  • New Meta-Object Protocol
  • Rewrite the Groovy grammar from scratch with Antlr 4
  • Retrofitting Groovy closures to accomodate JDK 8 upcoming closures for interoperability

I have serious doubts whether VMWare will pay for any of these features to be added to Codehaus Groovy. To see why, it's best to look at what they paid for to be added to Groovy 2.0.0:
  • Jochen transferred back into fulltime programming to optimize numerical objects by changing them into primitives (No longer is everything an object.)
  • Cedric employed to add static type checking and compilation (from Alex Tkachman's Groovy++)
  • Jochen then adding invokedynamic bytecode optimizations (perhaps helped by Charles Nutter's JRuby)

Each of these changes made Codehaus Groovy faster in some way. They were sponsored by Grales P.M. Graeme Rocher simply to make Grales faster too. None of the proposed Groovy 3 features make it faster. The new MOP was postponed from Groovy 2 under the pretext of renumbering Groovy from version 1.9. Laforge writes "The MOP needs to be rewritten", but Rocher's already decided VMWare only pays for things that make Grales faster, and that's why the puppet project manager of Groovy didn't write "VMWare is paying to rewrite the MOP" and why Theodorou wrote "Vmware has no problem so far".

Rocher will cancel the budget with a single internal VMWare announcement. Theodorou will be sidelined into consulting, and Laforge will keep Champeau to speed up the static compilation. Rocher has always considered Groovy to be "part of Grails". After dropping "Groovy" from the name of "Grails" in 2006, Rocher and Laforge promoted it to be the equal of Groovy, refering to them as "Groovy 'n' Grails". Rocher then privately commanded everyone working on Grails to mispronounce the duo as "Groovy on Grails", implying Groovy isn't even the equal of Grails, but subservient to it.

Also canceled will be the Groovy grammar rewrite from Antlr 2 to 4. Why wasn't the grammar rewritten in Antlr 3 when it came out? The Groovy grammar in Antlr 2 is a mess and can't be changed easily. That's why Jochen wrote "Those who want some syntactic changes, sorry, they will not be part of
that GEP" for semantic changes, and why they only add new features to Groovy using annotions instead of new syntax. But the grammar won't be rewritten because it already works and wouldn't be faster. VMWare want an ROI before they spend money.

That leaves "Retrofitting Groovy closures to accomodate JDK 8 upcoming closures for interoperability". Why not just use Java 8 closures? Why not just use the new closure methods in the Java 8 collections instead of the Groovy DGM? I.e. Java 8's forEach instead of Groovy's each, filter instead of findAll, map instead of collect, or reduce instead of inject. There's no point using Groovy closures and the DGM if they're retrofitted with Java 8's.

The work that's really going to be done on Groovy 2.0.0 is at the bottom of that roadmap page, i.e. "Other topics we could consider for Groovy 2.x and beyond". It'll be done slowly of course, by staff working on their own time and other "sucker" contributors Laforge can rustle up. Slowly, but fast enough to make it look like Groovy is still an active project, although its only purpose is to prop up Grales and get consulting contracts for VMWare.

27 June 2012

...and "Groovy 4"

I'm releasing another "alpha" version of the Groovy Language reboot, i.e. version 0.4. It's at the condition after I rewrote the parser to use what I call "Groovy Tuples". The accompanying Groovy grammar is really just a sample demo for the rewritten parser.

Groovy Tuples

It's best to explain how the tuples work by showing them within the context of the Groovy syntax (altho they're actually implemented in Clojure). A tuple exists at the same conceptual level as the null/object distinction. When a variable is null, it has no objects. A variable may instead have one object of some type. Tuples therefore allow a variable to have more than one object in a certain sequence. So how are tuples in Groovy different to vectors or lists?

Because tuples are at the same conceptual level as null, a tuple sequence cannot contain a null. Any nulls listed in a tuple sequence will vanish. Because tuples are at the same conceptual level as an object, a tuple sequence must contain two or more objects: a single object in a sequence will auto-unbox to become the object itself. A tuple sequence cannot contain other tuple sequences: a tuple sequence inside another will auto-flatten within its containing sequence.

In the Groovy reboot, we show a tuple sequence by separating objects with commas. Because the comma is at a low precedence, they're usually shown surrounded by parentheses. Null has syntactic shortcut (). So...

assert null == ()
assert (5) == 5
assert (1, (2, 3), 4) == (1, 2, 3, 4)
assert (1, null) == 1
assert (1, (null, 2), 3) == (1, 2, 3)
assert ((null, null), 1, 2) == (1, 2)

Tuples elements are refered to by 1-based subscripts, after a dot(.). This is similar to Scala tuples, or regex groups. A zero-subscript returns the entire tuple. A subscript that's too high returns null. So...

def a= ("abc", "def", "ghi")
assert a.2 == "def"
assert (7).1 == 7
assert a.0 == a
assert a.4 == null

I developed Groovy Tuples because their behavior was the best way to model values in a parser combinator sequence. The repetition-based combinators work best by passing out a vector, and the alternator simply selects one value. The sequence combinators are more complex, and can have skipping, peeking, peek-not, in-place value modification, monadic binding, and nested matching. Groovy Tuples are the simplest way to pass along the matched and processed values.

Codehaus Groovy finally implemented a watered-down version of tuples in version 1.6 where the tuple syntax could only be on the left-side of an assignment. Codeplex Groovy is bringing the full monty!

Future platforms

I've decided to change direction for the Groovy reboot. "Groovy 4" (i.e. reboot version 0.4) begins to use the CLR as an equal platform to the JVM, via both Clojure and ClojureCLR. I'm now looking at how to integrate JavaScript generation via ClojureScript. Rocher dropped the ball when he abandoned client-side JS-generation in Grales 1.2. In fact, he dropped the Groovy ball when he renamed Groovy on Rails to Grales.

This reboot will use ClojureScript to run atop Noir and Ring to provide RJS-style JavaScript generation for the browser. The package will be named groovy.onrails, and will never be renamed. The real Groovy Language will surplant both Codehaus Groovy and Rocher's Grales. Grales is the true enemy of the Groovy Language, enslaving Codehaus Groovy to its needs and installing a puppet project manager to run the cover-up. Real Groovy here at Codeplex will set Groovy free!

Default method names

Groovy 4 uses the same method names from Codehaus Groovy, e.g. collect, inject, each, groupBy. But Java 8's new closure-based collection methods have different names, and will supercede Groovy's next year. So I'm abandoning Codehaus Groovy's names and switching to the names used in Clojure, transforming them algorithmically to the Java/Groovy style, e.g. instead of Groovy's bitwiseNegate, use Clojure's bit-not transformed to bitNot. I'll build Groovy by making stepwise diffs to the Clojure syntax and names, until it's Groovy-like in syntax and semantics.

Standard semantics

Of course, we need to know what Groovy's desired behavior is, both Groovy 2 now, and what Groovy 3 would be had Jochen received funding to build it. Laforge dropped the ball when he abandoned JSR-241 after stringing everyone along for 8 years. So I'm taking up the baton! I'm now Groovy Language Spec Lead, doing the task Rocher and Laforge hijacked while they called me a terrorist. I'll be on the Groovy mailing lists a lot, finding out developers' takes on what Groovy, both 2 and 3, should be doing. I know some VMWare managers won't want me there, but I've had to do this before in paid IT jobs, e.g. taking over after-hours support duties from people who make a lot of extra money from their employers fixing stage-managed problems.

I'm not targeting any particular standards body, as I feel the Groovy Language should have a fully spec before choosing any particular body to submit to. Any man and his company can create a submission like a JSR when they have nothing to submit.


Finally, since discovering Clojure as a language platform, with its concurrency and macros, and realizing I can build any language syntax on top of it, I'll be inclusive rather than exclusive about what to put in there. Because that's the spirit of Groovy. Before the Rocher/Lafauge hijacking, Groovy was spreading its wings, destined to be a groovy language for many apps in a bazaar, like Perl allowing apps in CPAN to thrive independently, or Ruby's Matz happy to let Rails be under someone else's control, or other implementations of Ruby to be built. But when Groovy++ and GRegexes similarly utilized Groovy's annotation hooks, those VMWare managers ruthlessly brought them under their own control, murdering the very ecosystem they professed they were nurturing.

The Groovy Language reboot will spec Groovy, and build a ref impl and test kit. Groovy will be set free from the darkness that is Grales.

22 June 2012

ClojureCLR for the Groovy reboot

The upcoming version 0.4 of the Groovy Language reboot will run on both the JVM and CLR. It runs atop Clojure, on both these platforms. The code for both is the same: the only difference is the first parameter passed when calling it, whether "JVM" or "CLR", which is read into a dynamic variable:

(ns groovy)
(def ^:dynamic *clojure-platform* (first *command-line-args*))

All calls to Java or .NET utility methods are passed through macro calls which chose between platforms. Some samples:

(defmacro jvm-or-clr? [jvm clr]
  `(condp = groovy/*clojure-platform*
    "JVM" ~jvm, "CLR" ~clr))

(defmacro buffered-writer [fn]
    `( ( ~fn))
    `(System.IO.StreamWriter. ~fn System.Text.Encoding/UTF8 512)))

(defmacro regex? [param]
    `(= (class ~param) java.util.regex.Pattern)
    `(= (class ~param) System.Text.RegularExpressions.Regex)))

(defmacro to-string [param]
    `(.toString ~param)
    `(.ToString ~param)))

(defmacro parse-integer [x]
    `(Integer/parseInt ~x)
    `(System.Int32/Parse ~x)))

(defmacro parse-hex [x]
    `(Long/parseLong ~x 16)
    `(System.Int64/Parse ~x System.Globalization.NumberStyles/HexNumber)))

(defmacro parse-long [x]
    `(Long/parseLong ~x)
    `(System.Int64/Parse ~x)))

(defmacro parse-double [x]
    `(Double/parseDouble ~x)
    `(System.Double/Parse ~x System.Globalization.CultureInfo/InvariantCulture)))

(defmacro big-integer [x]
    `(new java.math.BigInteger ~x)
    `(System.Int64/TryParse ~x)))

I'm not releasing Groovy 0.4 until it's ready for beta. It's still experimental for now and I don't see much point releasing any more "alpha" versions.

Perhaps one day the Clojure and ClojureCLR teams will get together and begin work on a similar abstraction to the underlying platform. I'm hesitant, however, to approach them directly about this. Perhaps it's the bad memories I have of the nast dished out my way by Rocher and Laforge back in 2006 when I joined the Codehaus Groovy mailing list.

26 June 2012

Correction to "Groovy 2.0.0 Imminent"

I inadvertently left out a name in my acknowledgement below of those who upgraded Groovy to version 2.0.0. I only acknowledged:
  • invokedynamic: Jochen Theodorou
  • static compilation: Alex Tkachman, Roshan Dawrani, Cedric Champeau
  • modularization: Paul King

But now I've realized because the VMWare managers employed Cedric to clone Alex and Roshan's Groovy++ codebase, then they probably told Jochen to copy invokedynamic straight out of JRuby, which was the first dynamic language to implement it. Perhaps he didn't want to, but because VMWare pay his salary, Jochen would have looked inside the JRuby codebase when the pressure was on. So here's the updated acknowledgements:
  • invokedynamic: Charles Nutter, Jochen Theodorou
  • static compilation: Alex Tkachman, Roshan Dawrani, Cedric Champeau
  • modularization: Paul King

15 June 2012

Groovy 2.0.0 imminent

Groovy 2.0.0 RC-3 is out. Gratulations to those involved in the heavy-duty coding and testing involved, such as Jochen Theodorou putting in invokedynamic, Alex Tkachman, Roshan Dawrani, and Cedric Champeau enabling static type checking and compilation, and Paul King modularizing Groovy. It's also good to see the VMware managers abandoning their plan to make Groovy 2.0.0 "first ever version of Groovy to be released at a conference" at Gr8te in Denmark. Product quality is far more important than marketing timelines.

The full cost of getting EMC/VMware to employ an extra person to clone Groovy++ is becoming evident. When Cedric Champeau began work there, a change in management policy over Codehaus Groovy slipped through unannounced. Guillaume Laforge changed his long-standing title from "Groovy Project Manager; Head of Groovy Development at VMware; JSR-241 Spec Lead" to simply "Groovy Project Manager at VMware". The Groovy Language implementation hosted at Codehaus is now an official VMware project: Laforge sold out Codehaus Groovy to a big corporation in return for a funded worker more compliant than Jochen Theodorou.

The other change is Laforge dropping any pretence at Groovy being a Java Community Process standard. The JSR status has changed to Dormant, the Codehaus despotry being unwilling to meet Oracle's transparency requirements. Noone's bothered to answer anything on the Groovy JSR mailing list for years. No public discussion about these management changes took place on any Groovy mailing list. It was all just shoved through by Rocher and Laforge in secret.

Last week, Laforge desperately left this comment to deflect some grumbling about Codehaus Groovy's reliability for production use: "Groovy is used in financial institutions (insurance companies, banks, hedge funds, literally manipulating millions of dollars/euros every day), for scientific simulations (nuclear, bio-medical), high-traffic and highly dynamic websites (thanks to Grails), in the travel business, in patent offices, and many more use cases. These are just some I know about personally, although they're not necessarily publicized, but Groovy's really been used successfully for very serious use cases, for a fair number of years already."

The only part of this statement that can be proven is "Groovy is used in ... dynamic websites (thanks to Grails) ...". These types of statements Laforge frequently makes is typical of paid consultants at corporations like EMC/VMware. (Though if Groovy WAS used to control the Mars Rover as suggested by Laforge last month, that might explain a few things. Let's just hope Groovy isn't being used for those nuclear simulations.) If anything, Groovy's uptake has fallen further over the last few months. Groovy fell out of the Tiobe Top 50 yet again this month (June 2012).

After Rocher and Laforge's treachery became evident, Tkachman put the Groovy++ sources online at version 0.9 to make it easy to be copied by Champeau, Alex considering this more important than petty squabbles with the Codehaus cartel. Alex Tkachman is a hero of the Groovy Language ecosystem. I'd built a combinator parsing library called GRegexes using Groovy++, and have also put the source and documentation online to maybe help someone at VMware build one atop Groovy 2.0.

Also on googlecode are source and binary backups of betas 1 to 10 of Codehaus Groovy 1.0 because I suspect someone intends to remove them from the Codehaus Groovy distribution archive. Many good features were removed from Groovy after 1.0-beta-10, and someone at VMware wants to hide them from Groovy users. Features such as Groovy hero Chris Poirier's heredocs, standard in other scripting languages like Python, Ruby, and PHP. Laforge said he removed them because they weren't "nice on the eye", but he was probably sending Poirier a nasty message.

Also congratulations to the Griffon and Gradle teams for their marketing-based 1.0 releases of their Groovy-based products. Griffon is a clone of Grales for Swing instead of webpages, and Gradle is a Groovy-based build tool used to build Groovy, Grales, and Griffon. Also in the Gr8te portfolio are Spock, a Groovy-based testing tool used by Groovy programs, and Codenarc, a Groovy-based compilation tool for enforcing code standards in Groovy programs. It all sounds like old-fashioned brand diversification to me. How much of the ecosystem is real?

18 May 2012

GroovyCLR being "announced"

Hot info just in... Rocher and Laforge intend "kicking off" a CLR-based version of Groovy. They've realized their mantra about "alternative JVM languages Clojure, Groovy, and Scala" now has a hollow ring to it since evil Oracle's takeover of Java. Clojure and Scala can now both compile to the CLR. Microsoft did some nasty stuff with Java in the nineties and stuffed up Vista, but their work with C# and the CLR shines compared to Oracle's business practices.

Managed programming languages nowadays need to diversify their VM platform. Python, Ruby, Clojure, Scala, and Fantom all target both the JVM and CLR. JVM language Kotlin can also be compiled to JavaScript, as can Clojure and Fantom. Python and Ruby also natively compile. Groovy stands with Ceylon as being single-platform. The original Grails 1.3 roadmap did have a JS-based Groovy planned, but that was quietly dropped when noone was willing to do the work.

So Rocher and Laforge are planning to "announce" a CLR version of Groovy. But they don't really intend to actually produce any deliverable. It's just an announcement, similar to the JSR 241 standard announced in 2004. They feature the JSR prominently in their bios, but haven't done any work on it since. They plan doing the same with a CLR version of Groovy so they can promote Groovy as "multi-platform", but not produce any of its reality. Perhaps Rocher will also "re-announce" GroovyJS for Grails.

18 May update to 29 April 2012
When Laforge released his buggy "Mars Rover" tutorial on slideshare, he wrote "The snippets use the images frame border in Apple Keynote. I use a monospaced font just like in an IDE, and color the keywords. Sometimes I use a local copy of the groovy web console, publish my scripts locally, copy'n paste the rendered HTML in my Keynote slides, and it just works nicely." Laforge's "management" of Groovy reflects the typical "flip a startup" mentality, where if the business looks good to an investor, it doesn't matter if it's making money. To Laforge, if the borders, fonts, and colors look good, it doesn't matter if the code produces the correct result. Laforge writes "...and it just works nicely." He certainly wasn't talking about running the code. In Laforge's mind, "works" means "looks impressive to the paying audience at a conference". In the minds of Hickey and Odersky, "works" means "the code produces the correct result when run". The mantra alternative JVM languages Clojure, Groovy, and Scala isn't listing three equals. It's marketing a parasite language feeding off the quality of the other two.

29 April 2012

Groovy Mars Rover

VMware P.M. for Codehaus Groovy, Guillaume Laforge, has just released a tutorial on building a DSL in Groovy, themed "Going to Mars with Groovy" on Slideshare. I've transcribed it for those interested because the sample code from the slides can't be copied and pasted, which I suspect was the reason it was released on Slideshare. The number of errors in those code samples was astounding. I've fixed all these in the transcription:
  • p.17 needs the package mars statement
  • On p.40, we still need to import mars.Robot into integration.groovy
  • p.45 needs 2 imports
  • The example on p.50 doesn't work
  • p.53 needs 3 imports, p.54 needs 5 imports, p.57-63 needs 3 imports, p.64 needs 1 import
  • p.64 also needs a println, with parens
  • p.71 needs 2 imports
  • I couldn't get the approach using a base script class on p.72 working, so I left it out
  • On p.84, DistanceUnit should be the constructor name
  • p.85 needs an import
  • On p.87, all three constructor calls should be DistanceUnit not Distance, and 2 imports added
  • p.95 needs the import, p.96 needs 4 imports, p.97 needs an import
  • p.98 has missing: a >>> b // a.rightShiftUnsigned(b)
  • p.106-108 has the wrong method name
  • p.119 needs the two extra fields in Robot class
  • p.120 has extra }] in the example
  • p.151 currentThread should be a method call, not field
  • p.153 has O.1 instead of 0.1, and I still couldn't get that code working

I was active on the Groovy mailing list for years before I realized Laforge was one of those "programmers" who neither have any aptitude for coding nor enough discipline to test properly, relying on others to clean up after them. Although I've seen one or two in most places I've worked, it came as a shock to realize an open source programming language was being managed by one of them.

Why this now?

I'm scratching my head over why these slides were released at such a time as now. Laforge's M.O. is to wait till after a conference, perhaps even 6 months after, before releasing any slides, not a month before.

Perhaps he was saying he doesn't care about showing code full of errors to Groovy programmers because those who care about such things aren't in his target demographic for conference attendees. That makes sense. These things are basically corporate junkets for brogrammers more interested in Copenhagen's nightlife than staying after 5:00pm for a Hackerthon, which has been downgraded to a single-line mention in the agenda after such little interest last year.

The tag "JSR Spec Lead" is missing from his bio on page 3. Perhaps he's saying he'll drop the JSR fiction in an instant if anyone actually comes close to building another implementation of Groovy, which I'm doing atop Clojure. Then there's the reference to "Groovy Power!™ " near the end. Is he saying they'd dual-brand Groovy alongside a trademarked name to prevent better implementations gaining traction? "Power™ to the despots, not to the community of users."

Or maybe he's saying he writes the slides other speakers use in their presentations, because Groovy's a cathedral and he's the priest who controls the public facades. Perhaps he's released it to somehow cover his behind later on when Rocher leads a VMware witch-hunt asking why the Grails track had virtually all the conference attendees. With a year-on-year book sale decline of over 50%, only 600 hard-copy books on Groovy are projected to be sold this year: 2 a day, worldwide!

Laforge relies on trademarks, contracts, patents, and trade secrets to squeeze every euro he can from the Groovy Language, promoting it with glitzy slides of untested code developers can't even copy and paste. Groovy needs to go back to its open source origins, free of trademarks and patents, free of management frauds, back to the techos who actually wrote it.

23 April 2012

Groovy Bait-and-Switch

Gr8Conf.bmp The agenda for EMC/SpringSource's annual Gr8te conference has just been updated. Jochen Theodorou, the person who built most of the Groovy Language at Codehaus, has just been added to the list of speakers, billed as the very last speaker at 5:00pm on Friday 8 June. Why so late in the conference, and why at the last minute?

The answer's obvious: he's not really going to be there! SpringSource's had trouble filling seats before the "early-bird deadline", so they've changed the agenda to make the Groovy half look more technical. The reason Jochen's last is because "he needs to rush in from some other appointment". Shortly after lunch on Friday, Laforge will announce his bait-and-switch: "Jochen can't make it, but by 5:00pm you'll be too tired for a technical talk anyway, so I'll give another, lighter, one".

Laforge's first talk on Thursday entitled "Groovy Update: what's new in 1.8 and what's coming in 2.0" is billed as the "first time a version of Groovy is being released at a conference". What other secretly planned bait-and-switches are we going to see? A new logo, chucking out the present one chosen by community vote? Groovy being renamed and dual-branded, showing contempt for its origins? Groovy switching from being a dynamic language to a static one, without any public discussion on the mailing lists? Hold on, wait, that last one's already happened, as well as the version number changing from 1.9 to 2.0 without any public discussion, provoking much community ill-feeling.

What you won't hear from Lt Laforge is what happened to the promises in his talk 12 months ago entitled "Groovy Update: what's new in 1.8 and what's coming in 1.9". What happened to the grammar upgrade from Antlr 2.7 to 4.0, what happened to Groovy's modularization, what happened to version 1.9 altogether? You won't hear why Laforge is promised a JSR spec with Groovy 2.0 but hasn't delivered one.

What you also won't hear from Laforge is how they got a funded worker to launder Alex Tkachman's Groovy++ codebase for inclusion into "Groovy 2.0". Jochen wrote in a lengthy comment "Then about Cedric. We already tried once to hire someone and it failed because of the inflexibility a big company like Vmware has. We could this time make it only because we had quite a bit luck with the timing and because we used the post someone just left and rerouted some resources." I've worked in IT shops for 15 years, plus experienced how Rocher and Laforge operate, and I can confidently suggest it wasn't luck, but they muscled out some SpringSource employee to make way for their own, just like they stabbed Groovy creator James Strachan in the back in 2004-2005, easing him out and removing his commit privileges so they could take over.

What you might hear from Laforge is a new spin on why Groovy book sales have fallen to 1205 worldwide, far lower than Clojure's and Scala's. The mantra "use Hadoop for big data, Groovy for DSL's, and Spring for webapps" has been mysteriously popping up in blog comments lately. They're now spinning Groovy as a DSL language mainly for embedding inside other non-language software products, and therefore its popularity is better measured by Grales and Gradle book sales. However, that spin doesn't explain why book sales for Lua, a language that can ONLY be embedded inside other software, is also much higher than Groovy's.

When open source software suddenly gets renumbered to version 2.0, discussions and decisions no longer take place in public forums, and conferences get promoted as places to witness new releases, something has gone wrong. And that something can't be fixed with new logos and numbering schemes and names. The people who built Codehaus Groovy should be put first. Techo Jochen Theodorou should be speaking first at the conference, not a manager-recruiter taking up both tracks at a two-track conference. Alex Tkachman should be presenting on Groovy++, not have his work obfuscated and rebranded. Paul King should be the one presenting on what's new in 1.8, as he wrote most of it. Creator James Strachan should be invited to close, not a fraud baiting people into a second talk by promising another speaker.

Most people paying for seats at that Gr8te conference are Grales developers who just want to build better websites more productively. Given two tracks to choose from, they'll choose the Grales sessions. Offering two tracks this year could expose the serious imbalance between Grales on the one hand, and Groovy, Griffon, Gradle, Spock, Codenarc, and Gaelyk on the other. Could this two-track conference be part of a plot by Rocher to kick Laforge out the door?

10 April 2012

Stagnant Groovy steals static code

A look at OReilly's programming language book sales for 2011 gives the true state of Groovy's popularity. In the treemap, the square size shows market size, while the background color shows percentage change from previous year. Both Scala and Clojure have green "increasing share" squares, while nearby Groovy has a much smaller, red "decreasing share" square. Because people actually need to pay OReilly for the book, it's much more difficult for Laforge to cheat than Tiobe, which only takes half his day creating websites, generating cycles of links, producing online verbiage, submitting pages to search engines, and other weasle work.

In the rankings where people have to put their money where their mouth is, Groovy is ranked as a minor language, below the large, major, mid-major, and mid-minor categories, shipping a worldwide total of 1205 books in 2011, down from 2523 books in 2010. Averaged among the 9 titles, that makes about 130 books per year per title, worldwide, or about 11 a month. It all makes Laforge sound pretty silly when he claims in Nov 2011 "a pretty pessimistic estimate would lead me to think we have at least half a million Groovy users out there! It could possibly be more than twice that number". Groovy is stagnant at best, but these numbers suggest its userbase half-life is one year. People aren't taking it seriously anymore. A recent Hacker News poll didn't bother listing it in its 35 chosen languages until all Laforge's logins one by one requested it. The summary graph didn't bother including it.

A static mode for Groovy

In November 2009, Laforge wrote in response to Alex Tkachman's call for a static mode for Groovy: All this idea of a "static groovy" mode has been debated so many times in the past on the mailing-list that I'm lazy reiterating all the bad points about it. Just a one minute search brought me numerous threads on the topics, on the challenges and issues about this static groovy idea:
And I'm sure there are even older threads on the topic.

Even in the copious Todo-list from Groovy DevCon 6 in May 2011 there's no mention of a static mode for Groovy. One year later, almost nothing from that Todo-list has been implemented but there's a static mode coming for Groovy 2.0 "early this year". So what the heck changed?

What changed was Alex Tkachman, to whom Laforge wrote he's "lazy reiterating all the bad points about" a static mode for Groovy, went out and built one called Groovy++. And so it was there! Groovy developers voted to bundle it into the Groovy distro at Codehaus. But Rocher and Laforge greedily saw some code that added functionality to Groovy and proceded to steal it. Rocher wrote "The Groovy team, myself included, have reviewed the code of Groovy++ and believe that most of it will need to be rewritten and rearchitected" before inclusion into the Codehaus Groovy distro. Despite their cynical offer to include Tkachman in a rewrite team, he declined. They'd already hired a mate 2 months earlier to clone and obfuscate the Groovy++ code. Laforge didn't even possess the programming chops to pull off a simple code launder.

That's why a static mode is being added to Groovy 2.0 and not an upgrade from Antlr 2 to 4, or the cancelled Groovy 2.0 MOP rewrite, or the long attempted modularization, or the other stuff from DevCon 6 months earlier: because there was something there to steal from.

Every year SpringSource holds the European leg of the Gr8te conference, this year 6th-8th June in Denmark. And every year, about 2 months before, the Groovy "Project Manager" begins his marketing activities: gaming Tiobe rankings, dumping tutorial links onto DZone, using different aliases to spread the meme "alternative JVM languages Clojure, Groovy, and Scala" around blog comments to make Codehaus Groovy sound respectable, without explaining why Clojure and Scala each have 2 big green boxes and Groovy one tiny red box in OReilly's computer language book sales.

5 March 2012

Groovy and Gr8te differences

Laforge at Codehaus is again requesting Google Summer of Code workers to do work "that benefits the Groovy ecosystem", but he really means "that brings profit to the Gr8te business". Groovy and Gr8te overlap a little, but are essentially different concepts...

Groovy & Gr8te.jpg

Groovy and Gr8te are different and Laforge only cares about Gr8te. If Laforge really cared about the Groovy Language, he'd submit a request for a Google S.O.C student to make a spec of the 2.0-beta grammar and semantics, so Codehaus could have all 3 components for their JSR to make Groovy a standard: a written spec, a reference implementation, and a test compatibility kit. But we won't be seeing such a request to the Google S.O.C program because Laforge doesn't want a Groovy Language standard, using the 8 year old inactive JSR for nothing more than giving himself an authoritative title to fool others.

And even if Laforge did request a student for this project, he'd only do it for show, giving the student the runaround, getting them to do other work, and scuttling any progress towards making Groovy a standard. Someone who cared about the real Groovy ecosystem would encourage other implementations, just as there are of Python and Ruby. But Laforge doesn't care about Groovy, he only cares about quarterly returns from the Gr8te business to get his cut from SpringSource.

27 Feb 2012

Groovy Language v0.2 Released

Groovy Language v0.2 is released, implementing a working subset of the Groovy Language syntax in Clojure 1.3. Functionality includes:
  • integer, decimal, hex, and octal literals, with i,L,f,d,g postfixes
  • GStrings with unlimited levels of embedding
  • list and map literals using [] and [:] syntax, and subscripting
  • closures and methods implemented as Clojure fns
  • closures with implied it parameter
  • full path expression syntax, with trailing closure params
  • implied semicolons at the end of lines
  • arithmetic operators == != > < >= <= <=> * / % + - ++ --
  • all-new /% operator for intdiv returning tuple of quotient and remainder
  • boolean operators ! && ||, plus all-new ^^ for logical xor
  • bitwise operators ~ & ^ | << >>
  • single- and multi-line comments
  • def command implemented as Clojure def/ns-unmap and defn macros
  • println and assert as paren-free command expressions
  • if and while statements, with break and continue
  • throw and try statements, with catch and finally clauses
  • switch statement (with compulsory break ending each case)
  • for statement, both :/in and semi-colon versions
  • creating existing classes with new keyword
  • calls to Clojure methods implemented as calls on a string
  • imports
  • package statement
  • some GDK methods collect, inject, groupBy, findAll, each, join

class, interface, and enum definitions aren't yet implemented, nor are annotations or generics. We're aiming for the functionality of the original Codehaus Groovy 1.0 for the eventual 1.0 version of this reboot of the Groovy Language.

Why does it exist?

The Groovy Language syntax is groovy, and the JVM is cool, but the first implementation of Groovy was hijacked by corporate interests and milked for profit. After much protest and many attempts to correct this, the fake Groovy has now been abandoned to the cartel, and this second real Groovy Language begun, implemented in Clojure and therefore targeting the CLR and JavaScript as well.

When I recently made a short enquiry about the Groovy Language spec on the Codehaus mailing list, Jochen Theodorou and Paul King both made lengthy replies, trying to rope me into working on a new Antlr-based parser for Codehaus Groovy, avoiding making any commitment to a coming spec, probably after being briefed by Laforge. Jochen and Paul have both invested technically in Groovy, and are called despots, but don't hold any real power over what happens. They're pawns of Groovillains Rocher and Laforge.

Rocher last contributed something significant to the Groovy codebase over 5 years ago, the ExpandoMetaClass, which is really just a thin layer above Groovy's MetaObjectProtocol system built by someone else. Anyone else would have happily passed on the baton when moving on, but Rocher's building a business empire based on Grales consulting, getting as much control as he can over constituent technologies used by Grales.

Laforge wrote some methods for GroovyDefaultMethods to get accepted as a despot, then cut a deal whereby Jochen does all the technical work and Laforge the weasel work: administrative, marketing, recruiting, promotion, facilitative, project management, basically anything to avoid cutting code and writing tests. He and Rocher also do stuff they don't tell Theodorou and King about, thuggishly protecting SpringSource's business interests.

So I know from experience that if I agreed to work with Theodorou on rewriting Antlr, I'd be a victim of the Groovillains later on when I've done the work. Anyway, I've lost any motivation to work on Codehaus Groovy having experienced enlightenment working with Clojure: all programming languages need list-based macros. So as owner of the Groovy Language brand, I've rebooted it, rewriting it atop Clojure.

The intention is to extend the current Ascii-only Groovy Language grammar with one based on all the Unicode tokens, including the 75,000 CJK tokens. Of course, Unicode is complex, so I need to analyze it well before committing to particular Groovy grammar extensions or input method keystrokes. Unicode/Unihan is the problem space I'm solving with Clojure for the Groovy Language. Clojure is the tool, Unicode is the task, and Groovy is the tale.

11 Feb 2012

Groovy Deception

Recently (8 Feb 2012) Codehaus Groovy project manager Guillaume Laforge wrote "Groovy's been ranging between the 30th to 50th ranks in the past months and years in the TIOBE index. Last month, we ranked 36th. And this month (February 2012), we have a nice surprise by becoming 28th! We're not yet in the top 20, but that's nice nonetheless.

That said... don't believe too much in such rankings, as the figures are quite volatile for languages with "low" percentages. They put several significant digits in the percentage, whereas the method for calculating them is quite arbitrary, can be cheated, etc. On one month Groovy could be ranked in the 30th something, and the next beyond 50th... so it's not very precise. Anyhow, it's always pleasing to see us gaining some more ranks there".

Laforge is lying when he writes "Groovy's been ranging between the 30th to 50th ranks in the past months and years in the TIOBE index". Groovy's been ranging between 25th and 65th. After reaching 25th in March 2011, it suddenly dropped to 65th in April 2011, and remained below 51st for 8 months until November 2011. During 2010, it was also below 51st place for many months.

Laforge is deflecting attention from himself when he writes "the method for calculating the rankings ... can be cheated". When he posted some replies to his own questions on the last day of Nov 2011 to InfoQ, he probably flooded the 7 search engines used by TIOBE with the link. Thus Groovy re-entered the top 50 in Dec 2011. If he sent Jochen Theodorou to SpringSource to "fix" their algorithm again this year, that would explain the further rise to 28th place.

There is an alternative reason why Groovy's ranking increased further this year (Jan & Feb 2012). I rebooted the Groovy Language in December, beginning a rewrite in Clojure. If Clojure also increased its ranking during Jan & Feb 2012, then wouldn't that suggest the further rise is due to the Groovy reboot I've started. Let's take a look...

tiobe 2012-02.bmp

Groovy and Clojure rising together! No wonder Laforge released a user-list mail to deflect attention from the real reason Groovy's been rising again during 2012. Laforge doesn't want Groovy users finding out about a better implementation of Groovy in the works.

Laforge's other posting on the same date reveal why Laforge cheated Groovy back onto the TIOBE index now after not caring for 8 months: creating "buzz" to sell seats to the Gr8te conferences midyear, and clawing the highest cut from other speakers.

Scuttling the Groovy Language Standard

In fact, Laforge's deception runs far deeper. In March 2011, he updated the 8-year old inactive JSR at Oracle saying the Groovy Language Standard would arrive with Groovy version 2.0 by the end of 2012. Then in November 2011, he renumbered Groovy 1.9 to version 2.0, provoking much community ill-feeling, and slating its release in early 2012. A query about it on Stack Overflow brought the predictable defensiveness from the IT-Industrial Complex.

The deceit Laforge is going to pull is to update the JCP saying version 2.0 is renumbered to 3.0, which Codehaus will subsequently delay well beyond the end of 2012, and so further dragging along the Groovy Language Standard. James Strachan made clear the responsibility of the JSR expert group is "to make a great spec and a reference implementation and TCK. Its up to others to create different implementations if they want to". I'm creating another implementation of Groovy, but Laforge and Codehaus have kept the JCP inactive to prevent other implementations of Groovy being built, showing comtempt for the Oracle JCP process.

Laforge doesn't want Codehaus Groovy to compete with other implementations using a standard because it'll fall like a house of cards. The only real progress on Codehaus Groovy for the last 6 months is to steal Alex Tkachman's Groovy++ codebase, rename it Grumpy, shuffle its contents around, remove the copyright notices, and give a job to a mate. By the time Codehaus Groovy 2.0 is released, it'll do the same as what the Groovy 1.8 / Groovy++ joint distro did 12 months earlier. Instead of cutting some code and building some tests to improve Groovy at Codehaus, Laforge is stealing other people's booster extensions and stopping better implementations being built.

Kapitan Rocher and his Lt Laforge have no intention of ever creating a Groovy Language Standard: the Oracle JCP is just a marketing ploy to flog their own butchered implementation and Grales. Their behaviour is an abuse of the Java Community Process, and the Groovy Language community.

Older Blog Entries

See older blog entries until December 2011.

Last edited Sep 25, 2012 at 8:20 AM by gavingrover, version 28


No comments yet.