Gavin Grover's GROOVY Wikiblog

See later entries

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.

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?

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 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

...and 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.

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?

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

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.

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.

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.

Post removed because it's been superceded.

Post removed because it's been superceded.

See earlier entries

Last edited Feb 10 at 11:20 PM by gavingrover, version 31


No comments yet.