Gavin Grover's GROOVY Wikiblog

See later entries

6 February 2013

Unicode Pattern Syntax Tokens

Each of the million-plus Unicode characters has about 50 properties associated with it. Most of them can change between different versions of Unicode or for defining private-use characters, except for six of them:
  • Name (na)
  • Jamo Short Name (jsn)
  • Canonical Combining Class (ccc)
  • Decomposition Mapping (dm)
  • Pattern Syntax (PatSyn)
  • Pattern White Space (PatWS)
The first four will change from their default to a lifelong value for newly assigned characters, though. The other two, Pattern Syntax and Pattern White Space properties, both boolean values, will never change even when the character is being newly assigned. Only 11 characters have the PatWS property so they're not as interesting as those with the PatSyn property, 2760 of them, 296 of which are still unassigned in Unicode 6.1.

The unassigned characters are given the PatSyn property by defining all characters in certain blocks (rather than characters) as having the PatSyn property:
  • 2190..21FF; Arrows
  • 2200..22FF; Mathematical Operators
  • 2300..23FF; Miscellaneous Technical
  • 2400..243F; Control Pictures
  • 2440..245F; Optical Character Recognition
  • 2500..257F; Box Drawing
  • 2580..259F; Block Elements
  • 25A0..25FF; Geometric Shapes
  • 2600..26FF; Miscellaneous Symbols
  • 2700..27BF; Dingbats
  • 27C0..27EF; Miscellaneous Mathematical Symbols-A
  • 27F0..27FF; Supplemental Arrows-A
  • 2800..28FF; Braille Patterns
  • 2900..297F; Supplemental Arrows-B
  • 2980..29FF; Miscellaneous Mathematical Symbols-B
  • 2A00..2AFF; Supplemental Mathematical Operators
  • 2B00..2BFF; Miscellaneous Symbols and Arrows
  • 2E00..2E7F; Supplemental Punctuation
From these, 30 exceptions (0x2776..0x2793) are subtracted, and 150 are added. The added exceptions include the ASCII symbol and punctuation characters often used for syntax in programming languages.

According to Unicode standard annex 31: "With a fixed set of whitespace and syntax code points, a pattern language can then have a policy requiring all possible syntax characters (even ones currently unused) to be quoted if they are literals. Using this policy preserves the freedom to extend the syntax in the future by using those characters. Past patterns on future systems will always work; future patterns on past systems will signal an error instead of silently producing the wrong results."

There are, of course, many other symbol and punctuation characters in Unicode that aren't Pattern Syntax characters, and more can be added that can't become Pattern Syntax characters (unless they're encoded in one of the remaining 296 unassigned Pattern Syntax slots). The only language I know of that utilizes Unicode's pattern syntax invariance is XML 1.0, 5th edn. Perhaps the Groovy Language reboot will be the first Turing-complete language to do so.

47 of the 2464 assigned Pattern Syntax are canonically equivalent to other forms, so can be ignored. 45 of those decompositions are to some other Pattern Syntax character followed by nonspacing mark 0x338( ̸ ), e.g. ≠ is = then mark ̸ . The other two, 0x2329 and 0x232A, are singleton decompositions to 0x3008(〈) and 0x3009(〉), both also Pattern Syntax characters.

Within the assigned pattern characters, perhaps the second most important distinction are the bidi-mirroring glyphs, those with the bmg property, each of which must be swapped for its complement when used within a right-to-left rendering context, such as within Arabic and Hebrew text. There are 144 pairs of them, such as ( and ), or [ and ]. Because such pairs are used extensively in programming languages, with balancing often required to make language syntax more readable, they are an important subset of the Pattern Syntax characters.

Perhaps another important subset of the Pattern Syntax are the 161 bidi-mirrored characters, those with the bidim property, unmatched characters which must be mirrored when rendering, e.g. ∁ ∂ ∃ ∑ . A further subset could be characters that would be bidi-mirrored but aren't because they're already symmetrical, e.g. ∀ ∩ ∪ . They're not indicated by any specific property, but must be guessed at based on their physical proximity to related bidi-mirrored characters in the Unicode database, e.g. ∃ is bidi-mirrored so ∀ must be symmetrical. Perhaps a specific property in a future version of Unicode would be nice.

There's many other Pattern Syntax characters that aren't symmetrical but also aren't mirroring or mirrored in a right-to-left rendering context because they're considered to be pictorial or ornate characters, including those for box-drawing and all the arrows, such as 0x2190(←) and 0x2192(→). Unlike the Pattern Syntax property, the bidi properties of a character can change in future versions of Unicode, but for now we can't use ← in programming and expect it to be rendered as → when we change the naming language to Arabic or the thematic ordering of the referents. So languages that use arrows in their syntax, such as Scala, aren't future-proofed. Perhaps a future version of Unicode would add more mirroring pairs.

In designing the Groovy reboot, we do have 305 bidi-mirroring or -mirrored symbols to choose from, so not being able to use the arrows isn't a big deal. We just need to be aware of our choices, and not make syntactic mistakes, as did the first bootup of Groovy when its project managers committed to treating every Unicode token above 0xFF as an identifier character :-(

The Groovy Language reboot will utilize the full power of Unicode in both its syntax and its vocabulary.

1 April 2017; updates and replaces earlier posts from 1 April 2013, viz, Dr Grover and Mr Vorg and Groovy Japanese.

The 3 faces of Gav

I now know there's three different personalities in me...

1. the original timid one

There's the personality I was born with -- you can call him Pat Lagh. He was very shy, an oldest child whose 5 next younger siblings were all boys, and going to a boys only high school for 6 years. This one unquestioningly accepted other people's authority, and cluelessly studied and worked in the Down Under IT industry. He went through a typical burnout in his late twenties, but usually managed to keep up just enough to survive.

2. the rebellious one

A second personality sprouted up, at first in spurts while tired or drunk, but eventually taking over for longer periods, and calling himself Vorg van Geir. He was the opposite of Lagh. Instead of being patient in dealing with the sarcasm from Rocher's handles, Vorg reacted openly with avenging bile. When Laforge played his petty politics with Gr¤¤vy, Vorg exposed his fraud and incompetence. Vorg was a very different beast -- a complainer! What he was saying is true, but most others felt he shouldn't be saying it so directly.

3. the composite late bloomer

But a new personality emerged which was a composite of the other two. When Pat had tried meditation to get rid of Vorg, sometimes all of Vorg's memories would suddenly flash into his mind where previously all he remembered was a blackout. But Pat's temperament is also being fired up by Vorg's, but not so much as to lose his own. This new one is Gavin "Groovy" Grover. Like Mrs White and Miss Black being supplanted by Jane Gray in the movie, he will completely replace Pat and Vorg.

30 March 2013

CRIMEAn Computing with Groovy

A little over 20 years ago, I took my first real trip abroad to the magical land of India for 3 months. The first part was on an overlander truck from Chennai to Mumbai, then I launched out on my own taking in Delhi and Calcutta and many places in between. The many written languages of India fascinated me. Virtually every sign was written in 4 scripts: Latin (for English), Devanagari (for Hindi), Arabic script, and whatever the local script for the state was. In Unicode, 9 primary scripts are represented for the Indian languages: Devanagari, Bengali, Gurmukhi, Gujarati, Oriya, Tamil, Telegu, Kannada, and Malayalam. Some are used to write more than one Indian state language.

10 years ago, I moved here to China to teach English. Again, I was enchanted by the Chinese script, leading me to spend years analyzing the structure of the 85,000 Unihan (and Hangul) characters in Unicode. This has led me to look at the other 25,000 characters in Unicode, a far more complex task despite their much smaller number, and I'm still at it. The 95 ASCII keyboard characters familiar to English-speakers are just a very small number of them. The traditional view of IT has Silicon Valley at the center of an area reaching westward to roughly Japan and Australia, and eastward to roughly Germany and Israel. But even when we consider the less familiar Japanese kana, Greek alphabet, and Hebrew abjad, we still have a very small number of those 25,000 other Unicode characters.

To really understand them, we must understand the world outside the traditional IT area. I have a mission to fully understand them, and eventually introduce them to the world through the Groovy Language reboot: a mission I call Crimean Computing (CRIMEA = China, Russia, India, Middle East, and Africa). By using all Unicode tokens in programming languages, the rest of the world will program in their own scripts. Just as the Crimea in the Ukraine is far from Northern California, so also CRIMEAn computing is far from ASCII-based computing.

Post removed because it's been superceded.

Attacks against Groovy

attacks on Groovy.jpg

26 March 2013

There's 3 distinct but interconnected power structures involved in Graeme Rocher's primary line of attack against me over the past 7 years...

First, his control over Grails. Grails is now owned (via contributors contracts) by SpringSource, itself owned by VMWare, which is in turn majority owned by EMC. Because Grails is the primary app Groovy is used for, he also controls Groovy, and all other apps Groovy is used for. He uses the legal (e.g. VertX thuggery), marketing (e.g. SpringG2X conferences), public relations (e.g. The Theorists), and financial (e.g. Laforge's employment) resources of EMC/VMWare to protect his control. He exercises soft control over Grails programmers worldwide to influence their behavior (e.g. "people from Grover's home country should be doing something about him or else Grails gigs might dry up").

Second, the property market Down Under. A primary means of profit for most people in Melbourne and New Zealand is investment in residential property. To make the market go up, they vote for the governments that welcome in the international students who rent the apartments and the immigrants who buy the houses. The flow-on effect creates jobs in education and tourism too. When one of their own might jeopardize the gravy train, they keep an eye on him, even bending laws if necessary. The many Grails programmers Down Under can influence the behaviour of those with connections to China.

Third, Chinese desire to go overseas. Mainland Chinese are playing both sides of the coin, attempting to rise in the heirarchies of their home country and seeking to emigrate or send their families to America and Australia for much the same reason Europeans and others went. It's therefore easy for many in English-speaking countries to social engineer situations in China, presenting themselves as having some sort of authority in society to imitate the heirarchical nature of Chinese society. Most moves against me in China have as their origin such social engineering, which ultimately source back to Rocher.

Of course, Rocher utilizes other lines of attack (e.g. online monitoring), and never letting his right-hand man know what his left-hand man is doing. But his con flogging a lookalike soundalike of Rails is doomed: the real Groovy language is coming! Developers will know it's real by comparing it to Rocher's fake one.

23 March 2013

I've been poking around online looking back at the time of Rocher's hijack of the Groovy Language. Unlike nowadays, he didn't make much effort to hide his true nature. He begins one post: "Well it looks like Alex Blewitt has taken the time to excrete some more complete and utter rubbish all over the blog-o-sphere. Clearly, Alex got screwed over big time by the Geronimo guys and is feeling rather, well, left out and hence has chosen to vent his anger on the projects that James Strachan has participated in."

Whereas Alex wrote a fairly technical discussion about Groovy and Scala, Rocher responded with a personal attack, projecting his own motives for doing things onto someone else. For Rocher is the one who excretes rubbish on the net, such as that blog entry under his own name, and hundreds since under pseudonyms now he's cleaned up his public image.

Rocher is the one who vents his anger. When Groovy's creator was delayed at an airport, he headed into a netbar to get ideas for a JVM-based scripting language, and Groovy was the result. When Groovy's hijacker was delayed at an airport (same link as above), he spewed out a whole pageful of anger at British Airways.

And Rocher is the one who screws people over bigtime. Tkackman and Wilson and Strachan and myself are just the most vocal ones. Many more left Groovy silently. And I haven't looked at Grails. The technical gurus behind the Spring Framework are next in line to be devoured as Rocher continues his rampage to control a Spring Stack around Grails, then cash out, screwing over everyone below him in the pyramid.

16 March 2013

Groovy Debates

Sometimes I have conversations with myself over the future direction of the Groovy Language...

face right.jpg

Groovy was birthed in 2003, had its hijack completed by 2007, and has been in a slow terminal decline ever since. Do you really think you're able to revive it?

face left.jpg

I've accepted reality. I'm no longer reviving it, I'm now rebuilding it from scratch, spec and all. Is there any reason I can't?

face right.jpg

Many are saying you're not just rebuilding Groovy, but actively tearing down the existing one. Should you really be openly attacking Rocher and his decoy Laforge? If you sabotage his income potential, he can easily do the same to you.

face left.jpg

Just what can they do they haven't already been doing for a long time? 5 years ago, I was told a college didn't renew my teaching contract because an overseas Chinese from Australia rang its president and said bad things about me. 10 years ago, someone put ads about me in newspapers in Taiwan at least twice. 15 years ago, someone from Auckland rang around at least 2 (probably more) IT recruiters in Sydney slagging me off. I've only been doing openly for 2 years what they've been doing in secret for much longer.

face right.jpg

But isn't 15 years ago long before Rocher even knew about you?

face left.jpg

It seems he got contacted by busy-bodies from Melbourne around 2006. Instead of telling them he doesn't do stuff like that, he joined in and eventually became chief instigator in targetting me. Shouldn't I be attacking him back?

face right.jpg

Why are you picking on Rocher and Laforge only? After all, it sounds like you have a whole handful of people who've been slagging you. You should be attacking them too.

face left.jpg

BTW, the real target is "Scar" Rocher only. Laforge is just the middleman he stuck between himself and me. Sociopaths always hide behind others. Anyway, I can't play any others because there's only room for two players on a Chinese Chess board. Don't you know what Rocher's done to the Groovy brand?

face right.jpg

Rocher tried to rename the Groovy Language. He changed the name of Groovy on Rails to Grails in early 2006 to get rid of the Groovy part of the name, pretending to comply with Heinemeier-Hansson's request to not use Rails in the name. In late 2007 he tried to rename the Groovy Language as well but Laforge wouldn't let him. Why are you so concerned about the Groovy brand?

face left.jpg

Are you kidding? Groovy's my middle name. Why shouldn't I be?

face right.jpg

I've since discovered Groovy is nothing special, just a clone of Ruby with Java keywords and syntax instead. Groovy/Ruby appealed when all I knew was Java and VBA, but I've since moved up the blub heirarchy. I now know the pinnacle of programming is Clojure, Haskell, and APL. Clojure has the concurrency and macros, Haskell has the static typing and terse syntax, and APL has the large vocabulary of symbols. What use is Groovy now?

face left.jpg

Good point. But you listed not one but three languages at the top of the heirarchy. Haskell and Clojure can both easily be extended to use the APL symbols, and even many more symbols and tokens from Unicode. I'm having troubles, however, understanding how to merge together the best of Clojure and Haskell. Neither clojure.typed.core nor Template Haskell quite feel right, and rebuilding the Groovy Language is my ongoing attempt to get it right...

face right.jpg

(interrupting) But you haven't explained why you want to call it Groovy when there's already a programming language with that name.

face left.jpg

The name of what I'm building is the Groovy Language. "Groovy" is an adjective and the only other well-known language using an adjective is Basic, the language I'm most eager to avoid following in any way.

face right.jpg

Groovy and Groovy Language are the same thing. You're still using the name of an existing language.

face left.jpg

The fake Groovy at Codehaus is in terminal decline, and is unlikely to even exist in its present name and form very much longer, so when the real Groovy Language at Codeplex is finally ready, utilizing every Unicode token, it'll be the only game in town with that name.

face right.jpg

Touche! And that's why you haven't wanted the fake Groovy to change its name. In order for developers to really know that the upcoming Groovy Language is real, there must first be a fake one to compare it with.

face left.jpg


23 February, updated 16 March 2013

Groovy Tweetroll

16 Mar 2013

Corger's monthly comparison of programming languages for Feb 2013 is out - you know the one, showing StackOverflow (tag and synonyms applied count) and GitHub (lines changed) on x and y axes with a logarithmic scale, featuring Groovy in the center of the second-tier cluster (though also featuring Cobol nowhere in the top 84 languages used). This link is going to be liberally dumped around by handles controlled by someone trying to up the registrations for the upcoming European Gr8te Conference.

I've already exposed how Stack Overflow is being gamed by someone for questions tagged Groovy. So I took a brief moment to check out Github...

I clicked on the languages tab from Github's explore page and saw that Groovy is the 22nd most popular language. I found the 23rd most popular, which is Clojure, then clicked on the most watched tab for each. Each listed the 200 most watched projects, so I've listed the info (starred and forked) for the top 10, plus every 20th. The results speak for themselves...

No Gvy name Gvy starred Gvy forked Clj name Clj starred Clj forked
1 asgard 755 101 leiningen 2175 370
2 glu 362 45 clojurescript 1812 193
3 grails 340 75 compojure 1392 108
4 gradle-android-plugin 212 59 clojure-koans 1035 484
5 geb 204 50 overtone 884 118
6 Ratpack 199 37 incanter 866 140
7 gaelyk 189 39 ring 800 150
8 grails-doc 138 118 noir 760 105
9 twitter-bootstrap-scaffold 137 79 aleph 747 52
10 groovy-wslite 119 21 cascalog 714 88
20 maven2gradle 64 19 Korma 444 79
40 grails-spring-security-ui 44 31 cheshire 264 18
60 grails-executor 33 6 pinot 193 11
80 mongodb-grails 26 4 clutch 150 30
100 zkui 22 9 lib-noir 120 15
120 grails-oauth 19 14 lein-droid 105 7
140 spock-grails 17 5 clojure-tco 93 3
160 grails-remote-control 15 2 clojurejs 81 10
180 CodeNarc 13 10 waltz 74 11
200 siloe 12 11 zookeeper-clj 69 6

This Github data shows Clojure way ahead of Groovy in developer interest and forking, whereas the Github Lines Changed shows Groovy ahead! How does this happen? The reason's simple: the Github Lines Changed data is being used to measure popularity in a poll. The very act of measuring it changes the data itself because someone exists who's using the poll data to present Groovy in a certain way.

After Groovy dropped from #25 to #65 in a single month (April 2011) on TIOBE when they suddenly changed their measuring metrics, the data from Stack Overflow started being gamed a month later, with many made-up questions starting to appear every day. It seems someone may have started gaming Github at the same time, specifically to target this Corger poll, which gets linked to frequently on Reddit and DZone, especially before a Groovy/Grails conference.

If want to see it for yourself, though, you'd better be quick! Now that I've published this measurement, there's someone out there who wants to change it with meaningless updates on Github. It's amazing what middlemen will do to justify their existence.

7 Mar 2013
Seems the Groovy documentation effort has been cancelled. Champeau let slip that "neither he, Jochen, Guillaume or Paul will have time to work on ... a planned rewrite of GroovyDoc for Groovy 2.2".

In other news... Laforge leaked that "down the road, there's going to be a big Spring + Groovy theme in the next major Spring framework versions". Laforge is probably going public on something the Spring developers have only tentatively agreed to, a cheap negotiation tactic. What's really happening is Rocher's building a Grails-Spring stack, to fight the TypeSafe stack created by former SpringSource CEO Rod Johnson, who jumped a sinking ship to become TypeSafe board chair last year. The "big Spring + Groovy theme" Laforge is pestering for (anything beats cutting code or building tests or writing doco) is a snipe at Arjen Poutsma's Spring Scala project.

Rocher intends being the boss of this planned Grails-Spring stack. No longer needing the fiction of Groovy being an independent open source project, he'll then fork both Groovy and GPars, rename it all to SpringLang or something, then bring back some of Theodorou, Champeau, King, Pech, and Winder (he'll ditch Laforge) on his own terms, playing them off against each other. This is the true nature of the community that underlies Rocher's Groovy/Grails ecosystem. Grails is now a 115Mb download, and Gradle a 50Mb download: their real purpose is to take over the primary distribution channels of existing Java software, then bring in the bucks for those at the top of the pyramid scheme when SpringSource and Gradleware are flipped to the likes of Oracle.

4 Mar 2013
I took another look at Laforge's deceitful email announcing Groovy's "documentation effort and site design" last month. After the saccharine-sick marketing blurb in the first paragraph, he wrote:

"... However, one area where the Groovy project can do better is with its documentation. For instance, if you read the recent DrDobbs editorial, there were some valid points made on this topic. And it's true that our documentation can be greatly improved. Despite its 1000+ pages of wiki content, it's hard to find the information you're looking for, it's of very uneven quality and style, lots of pages are outdated or show samples with mistakes in them, and there are also holes for features not covered or not explained in details. We're launching an effort towards overhauling our documentation and web presence. And I'd love if you could take part in that effort, even if only by telling us about your expectations regarding the website, the documentation, etc., or even by helping us authoring content, of course. For the website, we'll need ..." [bolding as in original].

Notice the switch? Look at what Laforge bolded:
  • first, he accepted Binstock's criticism of Groovy's lack of proper documentation
  • then, he announced he's launching an overhaul of Groovy's documentation and web presence
  • finally, he moved his reference to the website before "the documentation, etc"
Everything he's written since talks about the website redesign before the documentation work. Non-technical phoney managers like Laforge are always pushing through their own agendas at the expense of what's really required.

1 Mar 2013
Laforge has just published a plan of what he wants the Codehaus grbdvy website and documentation to look like, with fish hooks for unpaid volunteers disguised as requests for feedback. Yep, the Groovy 3 MOP rewrite and Groovy 4 Antlr upgrade have been cancelled, all the "full-time developers" are being charged out to clients full-time instead, and the "project manager" has intensified his marketing and recruiting activities (recruiting for unpaid volunteers, that is).

With all VMWare funding for developers turned off and no fresh-of-the-boat programmer volunteers on hand, Laforge is hiding his lack of any technical talent behind non-technical "progress" such as the website redesign, learning mind map software (a project plan with dates and dependencies was too much to master), and deceitful marketing talk, such as this classic: "we'll be contacting you guys to see who would be interested in participating in case studies to chat about why you are using Groovy, why you chose that technology, in which context, what benefits did you gain, what you would like to see improved, etc."

18 Feb 2013
Jochen Theodorou wrote, probably on behalf of Laforge: "I think there should be a webpage dedicated to make projects using Groovy known. ... I would also like to include blogs, articles and tutorials, plus a comfortable way to search." The first to reply was GrooScript creator Jorge Franco Leza, asking "When I do some release in my little project, what I do? where do I announce that?". Because GrooScript implements Groovy rather than uses the SpringSource/Codehaus version, would it be allowed on Jochen's page? What about when my own reboot of Groovy atop Clojure, currently at v 0.5, is ready for beta testing? In fact, someone just happens to be prototyping such a new Groovy website now - what a coincidence!?! Just who controls what projects and tutorials get added to the site?

All the latest sudden activity expanding Groovy's web presence happens around now every year. The European Gr8te conference is coming in May, and Laforge needs to get Groovy back into the search engines, back onto the rankings like the Tiobe Top 50, so claims about Groovy's popularity sound more plausible when selling seats. And Laforge wants the linked websites to generate revenue for Codehaus and SpringSource. The top 3 links in Google for "groovy programming" include a comprehensive 5-yr old tutorial I wrote on Groovy 1.5 for non-Java programmers. Because each page packs in a lot of info, that's less Google Ads revenue for Codehaus. Laforge intends spoiling that link under cover of his documentation rewrite, to nudge up content-sparse pages he controls, like

Instead of rehashing his old line about Groovy making programming fun on ad-heavy webpages, or showing off endless pictures of abacuses and looms in powerpoints on DSL's, Laforge should be writing actual content to help developers be productive. If he really wanted Groovy to be fun, he'd be shouting the groovy growl, the ooooooo, and the veeeeey! But to Laforge, Groovy is just an opportunity to extract revenue from corporates giving their developers a Copenhagen beer junket, and to promote his own name to IT shops in case SpringSource's new owner retrenches everyone who can't pass a basic programming aptitude test.

17 Feb 2013
Word's out the business line VMWare wants to exit is SpringSource with Cloud Foundry stripped out. Seems Rocher's been telling Oracle and JBoss if they buy SpringSource, he can cripple the static compilation mode in Groovy and nudge developers towards Java or Ceylon. So if you use the new CompileStatic mode in Groovy, not only is it buggy but it might not even be supported soon.

16 Feb 2013
Groovy 2.1, although officially released, is still in unofficial beta testing for inclusion in Grails 2.3, to be released in May 2013 for the SpringSource European Gr8te conference, just as Groovy 2.0's official release was just an extended beta test for Grails 2.2. Groovy was long ago hijacked by Rocher to snare programmers into Grails conference seats. Expect to see Groovy 2.2 renamed to version 3.0 "to sync the version number with Grails 3". But really it's all about further delaying the MOP rewrite from Groovy 3 to 4 without the outcry when it was delayed from Groovy 2 to 3. Rocher's more interested in pocketing the money from flogging Grails conferences and consulting than investing in a proper MOP or grammar in Groovy so it can be more than a has-been language. And Laforge does whatever Rocher tells him to - the price of a single-track speaking slot in the conferences. No-one would listen to Laforge speak if Rocher was speaking at the same time in the other room.

15 Feb 2013
Looks like Rocher's just cancelled the Groovy MOP rewrite, through his paid proxy Laforge talking about an unscheduled v 2.2 release, as predicted by my other half. The rewrite was just an empty promise to string along developer Jochen Theodorou all these years. Rocher's management of Groovy/Grails is all about investing as little as possible to squeeze out as much as possible.

13 February 2013

Groovy Buzzwords

Laforge reacted to Binstock's analysis by announcing a "documention effort and site redesign": "Groovy is a very mature and widely used language on the Java platform, with hundred thousands of developers worldwide. It's stable and fast, flexible and readable, has got plenty of interesting use cases (DSLs, testing...), is feature-packed, and it's got a very rich ecosystem of successful projects (Grails, Gradle, Griffon, Spock, Geb, Gaelyk, to name but a few). However, one area where the Groovy project can do better is with its documentation."

Let's look at the truth behind all this verbiage...

Documentation effort and site redesign: Laforge is redesigning the website, perceiving Groovy's problem as an image problem, but hiding it behind a "documentation effort". The website was redesigned a mere 15 months ago. Before then the documention contents were one click away, but were split into four separate pages, each two clicks away, much less convenient for Groovy users but it meant more GoogleAds revenue for Codehaus and more users needing consultancy services from SpringSource. Laforge is just pretending to care about documentation.

Groovy is a very mature language on the Java platform: Groovy is declining, at the end of its life. When GPars was released at version 1.0 after being bundled in Groovy for years, it was also announcing its own end-of-life. SpringSource and Codehaus are now milking Groovy for all they can get.

Groovy is widely used, with hundreds thousands of developers worldwide: All claims, no proof. Whenever challenged, Laforge says his clients don't want to be named. More likely he doesn't want them poached by someone who hasn't signed his contracts.

Groovy is fast: Dynamically compiled Groovy is, as Binstock was careful to point out.

Groovy is stable: Statically compiled Groovy is bug-ug-ugg-uggy. Only last week, a serious static compilation bug in Groovy 2.1.0 was reported. Although officially released in June 2012, Groovy 2.0 really wasn't released for production use until it was bundled as part of Grails 2.2 in Dec 2012. The 6 months from June to December was unofficially just more beta-testing with a larger base of users, namely those who download standalone releases of Groovy. Grails, however, doesn't use any of the static compilation features in Groovy 2.0. All the testing of Groovy 2.0 was just to make sure the inclusion of static compilation in Groovy didn't break any of its dynamic compilation use in Grails. On the day after the Grails 2.2 release came the first beta of Groovy 2.1, which has since been officially released standalone, but hasn't yet shipped with Grails. Once again, Groovy's timeline is determined solely by the needs of Grails.

Groovy is flexible: Laforge is just spewing buzzwords here. To me, flexible means unhindered by syntax contraints. Clojure allows easy code reorganization and macro-level syntactic manipulation, far more flexible than Groovy.

Groovy is readable: Some people find the indention used by Python and Haskell most readable, while others find the balanced brackets used by C, Java, Javascript, Scala, Groovy, and PHP more readable. Groovy 0.5 here at Codeplex is a proof-of-concept prototype showing how Groovy-style syntax can easily be built atop Clojure, which, unlike Groovy, also runs atop the .NET and Javascript platforms. Why be constrained by Groovy's Antlr 2.7 based grammar when we can write our own atop Clojure?

ChineseCheckers.png Groovy has got plenty of interesting use cases (DSLs, testing): DSL is just another buzzword. Dropping semicolons, commas, and parentheses from a syntax doesn't a DSL make. IDE's put them in automatically without needing to type them anyway. Virtually every language has testing frameworks.

Groovy is feature-packed: More "features" means more need for consultants and conferences. Some old features such as interceptors no longer work properly. Many new features, such as static compilation and invoke dynamic, are not production ready. In both Groovy 2.0 and 2.1, the code using invoke-dynamic is bundled in a separate jar-file which only runs on Java 7. Grails and Gradle don't bundle this other invoke-dynamic jar file, and don't intend to for Grails 2.3 and Groovy 2.1. The Groovy roadmap claims a new MOP will be written atop this invoke-dynamic jarfile, and ship as the sole jar in Groovy 3, but every time in the past when Theodorou's started on the MOP, he's been redeployed. I don't believe Rocher intends to pay for it. Even if it was done, how long would it take? Other statically-typed JVM languages like Scala, Kotlin, and Ceylon are coming quickly. Scala is rising, Kotlin has IntelliJ as a delivery channel, and Ceylon has JBoss backing it.

Groovy's got a very rich ecosystem of successful projects (Grails, Gradle, Griffon, Spock, Geb, Gaelyk, to name but a few): Only 2 of these have any traction in industry, and even Gradle's uptake is iffy. If there were any other successful projects, Laforge would've mentioned them.

One area where the Groovy project can do better is with its documentation: What Laforge should have said was "Because I can't code, I should've made myself useful by writing documentation instead. I never did, and accept responsibility for Groovy's failure in this area." But Laforge is even incapable of writing correct documentation, as shown by his buggy Mars Rover attempt, let alone accepting responsibility for it. Laforge is second only to Rocher for causing Groovy's terminal decline.

7 February 2013

Groovy Confusion

Once again, mixed messages are coming out regarding the Codehaus version of the Groovy Language.

On 26 June 2012, Tech Lead Jochen Theodorou announced he was beginning work on Groovy 3, kicking off a discussion thread with 90 replies. I asked if Groovy 3 will contain a new MOP, to which Guillaume Laforge replied with the passive voice "The MOP needs to be rewritten". But the MOP rewrite wasn't begun.

On 11 January Jochen announced "I will now start the implementation of the new MOP". Graeme Rocher said he wanted binary compatibility and ability to run old compiled Groovy code. Suspecting Rocher was setting up the cancellation of the MOP rewrite, I asked if VMWare's not willing to pay for Jochen to rewrite the MOP if it doesn't do exactly what the current one does? Rocher got defensive with the impersonal "the new MOP needs writing".

A week ago, VMWare told the US SEC they intended retrenching 900 workers and exiting some business lines. They didn't say if they would trim up SpringSource before they sell it to JBoss, or if they would sell it to Oracle as a white elephant ripe for trimming.

Two days ago, Laforge dug into his posting quota on InfoQ to announce Groovy 2.1's release a week late (perhaps he was too busy being re-interviewed for his own job, and traded in a real developer like Champeau to save his own skin). Even though Laforge didn't do any technical work on Groovy 2.1, he kept on refering to "we", putting people off by not acknowledging any of the actual programmers such as Jochen or Fred Janon in the InfoQ article or the linked-to release notes. Laforge also put people off with meaningless marketing talk, such as "Groovy 2.1’s distribution bundles the recently released GPars 1.0". Groovy has bundled the latest version of GPars for years. When GPars changed its version number to 1.0, both Groovy 2.0.x and 2.1 upgraded to it like they always had.

Yesterday, Dr Dobbs editor Andrew Binstock wrote some pessimistic views on Codehaus Groovy's future. He was diplomatic, though, e.g. "Keying off ideas prototyped by Alex Tkachman, the Groovy team added static typing". That's putting it nicely. Unfortunately, he also neglected to mention Theodorou's name anywhere, the technical guru who did most of the work, even though he managed to mention project manager Laforge. I suspect Laforge sent him some Q&A copy regarding Groovy 2.1, but Dr Dobbs isn't InfoQ. Binstock instead published an analysis. His conclusion...

"[Groovy is] a language primed to be a major player. There is the conundrum. The endless variety of features requires considerable documentation, which is simply not available, especially for the advanced features that give Groovy much of its benefit. And so, if you jump in today, you'll find the language is easy to learn, but hard to master. Fortunately, this limitation is not incurable. However, time is of the essence as Groovy's principal competitor for the hearts and minds of Java developers — Scala — has a small, laser-focused company behind it, which revs the product frequently and generates considerable documentation. If Groovy acts soon, it can retain leadership among Java alternatives. If not, it will have to resign itself to being an also-ran."

Binstock misses the point of Grails and Groovy's business model. A lack of usable documentation means developers must pay for SpringSource consultants and seats at conferences, where lots of money is made and divvied up. By throwing in endless features, they increase the complexity of Groovy and the need for consultants from the supply side, just as the lack of documentation creates the need for conferences from the demand side. The Groovy "Bible" didn't bring in much profit for its authors so why should they bother with a 2nd edn? Grails and Groovy is about making money now for those involved, not investing it. Even the "groovymag" charges money for an online subscription, while the "Week with Scala" is free!

If someone seriously creates independent doco for Groovy, the next version of Groovy changes slightly to lessen the value of the doco and increase the need for a consultant or conference. They keep a tight gateway over their test suites. I've experienced this first-hand. When I was writing free online doco for Groovy 5 yrs ago, sociopath Rocher just couldn't relate as an equal partner to me in a bazaar. He just had to prod people into targeting me, eventually destroying my desire to make Groovy simple to use, so he could keep as much of the take as possible at the top reaches of the cathedral.

Binstock does correctly conclude Groovy will soon be an also-ran because of that business strategy. Rod Johnson, former CEO of Grails company SpringSource, is now leading the board of that laser-focused Scala company. He no doubt understands the value of "taking a cut of a huge pie" instead of "owning all of a tiny pie", and is investing in growing Scala instead of strangling it. The project managers behind Groovy, Rocher and Laforge, are probably incapable of changing their ingrained habits to steer Groovy in a new direction. They will, however, take something else away from Binstock's analysis: that Groovy needs a new name for version 3. Yes, they'll see a brand perception problem, rather than a widely recognized lack-of-documentation problem, and they'll get busy creating a new imagery for Groovy, instead of making it easy for people to master.

Post removed because it's been superceded.

See earlier entries

Last edited Mar 29 at 6:01 AM by gavingrover, version 21


No comments yet.