groovy Wiki & Documentation Rss Feed

Updated Wiki: Home

gavingrover — Fri, 24 May 2013 14:05:05 GMT

The Grojure Language is the latest exciting addition to the Groovy ecosystem, replacing the discontinued Groovy reboot previously hosted here.

Gavin Grover's Unicode blog logs progress on building the Grojure Language, replacing Codehaus Groovy, and promoting Unicode in programming.

The CJK decomposition data is a graphical analysis of the 75,000 Unihan characters in Unicode.

Updated Wiki: Blog05

gavingrover — Fri, 24 May 2013 13:53:26 GMT

Gavin Groovy Grover's UNICODE Blog

24 May 2013

5 yrs of blogging history

It's been 5 yrs of blogging (from early 2007, less a year's gap in the middle), so thought I'd list the most important entries...

Programming and Natural Languages

The flagship Kanji meets Programming explains my motivation for building the Grojure Language (previously the Groovy reboot, before that Grerl-Vy). Precedences, Parentheses, and Path Expressions shows some technical details.

Other thoughts on modelling a programming language on a natural language:

9 April 2008: Syntactic rank in English and Groovy
20 June 2008: Word classes in English and Groovy
22 November 2008: Stress and unstress in computer languages
6 December 2008: The thematic structure of English and Groovy
23 April 2009: Interactional function of English and Groovy
16 January 2010: Programming Language Structure

Unicode and Symbology

Inheritance Hierarchies for Unicode Characters shows the next steps in building the Grojure Language: parsing Unicode by modelling it as a heirarchy of characters.

Other thoughts:

5 February 2013: Unicode Pattern Syntax Tokens
29 June 2007: Pictorial analysis of CJK characters
8 April 2007: Foreigners typing Chinese

My previous little project was creating the CJK decomposition data file, a graphical analysis of the approx 75,000 Chinese/Japanese characters in Unicode.

My first thoughts on Symbology were on 30 October 2007, 6 February 2008, and 29 November 2008.

Fake and Real Groovy

26 March 2013's Attacks against Groovy describes the 3 distinct, though interconnected, power structures involved in Graeme Rocher's primary line of attack against me over the past 7 years.

5 January 2013's Groovy Visions Revisited updates the original 30 March 2008's Groovy Visions, explaining the difference between Fake Groovy and Real Groovy.

Some previous milestones in building the Groovy Language:

8 December 2012: The Groovedral and the Ruby Bazaar
10 April 2012: Stagnant Groovy steals static code
22 November 2011: Fake Groovy Exposed
23 January 2011: The Rise and Fall of the Groovy Language

The compendium from July 2009 to April 2010 includes Groovy Dilemma, Groovy 2.0 status report, and Scala's groovy stairway.

Math and Physics

Finally, 30 April 2010's Orders of Infinity expands on my earlier Mass-Parity-Distance Invariance. Maybe there's as much negative matter in the Universe as positive, and as much antimatter as matter. And 4 June 2008's Base-100 Arithmetic gives a glimpse into the future of mental math.

19 May 2013

Grȫȫvy ecosystem busts free!

Laforge has taken to using the expression "the Groovy ecosystem, which is Groovy, Grails, Griffon, Spock, Codenarc, Gradle, Geb and Gaelyk". With his grip on the SpringSource Project Manager for Groovy title slipping, he's getting ready to promote himself to an honorary position "overseeing the ecosystem". But his need to define explicitly what software makes up an ecosystem is exactly why Groovy failed under his Groovy Supreme Commandership in the first place. Many Groovy-based projects now lie dormant, their creators abandoning them after discovering the Groovy Community was a manufactured mirage. But even just looking at active projects, we see many not in Laforge's list that are part of the true ecosystem for Grȫȫvy...

1. GrooScript

Jorge Franco has added Grails and VertX support to GrooScript, a welcome addition to the Grȫȫvy ecosystem and the latest implementation of the GrȪȪvy Language. Because GrȪȪvy has no spec (thanks to Laforge's stonewalling), a future official spec for GrȪȪvy should be an intersection of all implementations existing at the time, with each having equal voice. I've added GrooScript to the "official" list of JS-targetted languages on Franco's behalf, the first mention of Groovy in a list of over 150.

2. "GroovyRuby"

Charles Nutter recently wrote he wants to build "a Groovy-like language that compiles to plain Java when all types are present, but uses invokedynamic exclusively when types are omitted". He's already built a Ruby-like language that does the same (JRuby/Mirah), and thinks he can plug something into Groovy's antiquated Antlr2-based grammar to do the same. According to Theodorou, Groovy already has 4 backends (i.e. classic, primitive optimizations, Groovy++ launder, and invoke dynamic) and adding a 5th is easy "if the backend code is licensed under the Apache Software License". Rocher's got his fingers in every discussion. Because the GPL Ruby/JRuby has over a hundred AST nodes, doing most name resolutions below the AST, Groovy's grammar can slot easily on top. If there's no technical reason to hinder something, Rocher will cite a legal reason. If Nutter ever independently bundles JRuby/Mirah under Groovy's grammar, it will also be part of the Grȫȫvy ecosystem.

3. Kotlin

The statically-typed language with the closest syntax to Codehaus Groovy is now Kotlin from Jetbrains, led by Andrey Breslav but with significant help from Groovy creator James Strachan and Groovy++ pioneer Alex Tkachman. Kotlin really should be bundled as the statically-typed backend to Groovy because it's closer to Tkachman's original vision for Groovy++, being worked on by the visionary rather than being cloned by a manager's mate.

4. Grojure

I've just released v 0.7.1 of Grojure, originally intended as a reboot of the GrȪȪvy Language, but now an attempt to extend Clojure with syntax to make it look Groovy-like. Like GrooScript, "GroovyRuby", and Kotlin, it's an integral part of the Grȫȫvy ecosystem. Grojure will grow Clojure with Groovy-like syntax and Unicode, to become an integral part of the Grȫȫvy ecosystem. GrȪȪvy developers will have all 110,000 Unicode tokens available for their programs, giving developers choices instead of heavily restricting what they can do so Groovy code will always have pretty colors on the screen whenever an ex-Javamort manager wanders through the code monkey cube farm.

5. Garfa

Laforge has just announced Gaelyk 2.0, an update to his long-running Google Appengine tool, and snuck a Friday 1:00pm seminar into this week's Gr8teConf to politick for his job to the hungry as he explains how to use the changes, while the Grails track are having lunch. Hours later, Igor Artamonov released Garfa, "Groovy ActiveRecord for Appengine", a lightweight wrapper around the Java-based Objectify, lightweight scripting being what Groovy was originally intended for before being hijacked. Garfa includes easy-to-read single-page documentation: no need to pay for a conference or consultant to learn how to use it. There's still people around who want to serve their fellow developers with software and lunch instead of recruiting for free FOSS labor while selling their own consulting services for an exorbitant fee.

from 29 April 2013

grÒÓvy = grÒjure + unicÓde

I'm now alternating between analyzing the non-Unihan characters in Unicode, and building the Grojure Programming Language atop Clojure. When both tasks are finished, they will merge together to become the Groovy Language, a Unicode-based reboot of the Codehaus-hosted first attempt at Groovy which is in terminal decline.

Vorg's Tweetroll

From now on, all Vorg van Geir's content will appear here instead of on his makeshift tweetroll...

9 May 2013
Rocher has been redefining Grails to mean whatever his distro bundles, growing to 115Mb in v2.2 and switching to vert.x in v3.0. Grails is no longer a specific technology, it's a branded channel. He's also been redefining Groovy to mean whatever his codebase implements, even generating a spec from the code. Groovy is no longer a branded language spec, it's a specific implementation. By expanding Grails's brand power and eliminating Groovy's, he's renaming Groovy by stealth.

8 May 2013
Looks like Rocher will announce at Gr8Conf on 24 May that Grails 3.0 is bundling Vert.x, having bullied its creator Tim Fox into surrendering it to SpringSource last Christmas. Vert.x is polyglot, using other languages (i.e. Python, Ruby, Java, JavaScript) besides Groovy. He switched Groovy's keynote speech from Laforge to Subramaniam speaking on "The rise and fall of empires: Lessons for (programming) languages", and moved the Grails track to first column on the diagram. This switch is the beginning of the end for Groovy. Rocher always hated the Groovy brand, and intends to abandon it.

3 May 2013
I first watched The Big Bang Theory in late 2010. Having been given a weekly class teaching English to some engineers, I figured they'd be interested in such content, so played a 20-min episode in some classes. I found it to be reasonably funny, so when I caught a cold in early December, I watched all the episodes to date in a single weekend over the Chinese internet. The next episode (6 Jan 2011) had this story: Leonard gets an idea to develop a smartphone app that allows users to solve equations by taking a picture of them. Sheldon tries to put himself in charge despite the app being Leonard's idea, and continually criticizes Leonard's leadership in the development of the app. After Sheldon suggests names for the app that have his name in it, he abruptly calls for a vote to change the team's leadership, resulting in Leonard firing him. Sheldon resorts to sabotaging Leonard's project...

Within weeks I heard Rocher and his cronies were spreading the lie that I'd done to Groovy what Sheldon had done. I've seen this tactic used many times while working in IT, and the reason is almost always the same: Rocher is deflecting attention away from his own schemes by accusing others of doing the same. But Rocher is the true culprit: he hijacked Groovy to be subservient to Grails and is going after Spring next. He's just increased the Grails download size from 50Mb to 115Mb, muscling in on the distribution channels for more Java software. Grails' entire business has been about nabbing users from Rails, and now he's expanding the Grails create-app command to include all Java application types, not just servlets, to steal control away from IDE's.

He installed his decoy Laforge to stonewall on a spec for 8 years, obscuring the fact that Groovy creator Strachan intended many implementations to be built. Rocher stepped in to bump out Wilson and Tkachman when they threatened his control with Ng and Groovy++. By making JBoss's Hibernate and Oracle's Java the only Grails components not under SpringSource control, he's minimising loose ends in future sales negotiations. And he keeps an army of compliant consultants who'll give him deniability. But his evil will be exposed because if he's doing it to me, he's doing it to others. And they won't stay silent either.

2 May 2013 (update to 10 April 2013)
There's 25 Starbucks stores in Wuhan city according to their store locator today (altho it says 26, one of them is wrong). As of today, I've been to all of them! I visited the first to open in Wuhan on its opening day, 6 Feb 2008. Their number has roughly doubled every year since, so I've had to visit a lot in the past year to keep up.

28 April 2013
My other half has just committed version 0.6.0 of the Groovy Language reboot, renamed Grojure for now. It's been rewritten using Armando Blancas' Kern combinator parsing library. We intend adding Unicode characters to the language grammar soon enough, plus write a plugin for Grails. Groovy's Grojure will replace Codehaus Groovy as the premier language for all applications in the Groovy ecosystem.

23 April 2013
Erik Pragt and Michael Kimsal agree with Laforge's bleak assessment of Groovy's documentation problem. Pragt says "the current web documentation for Groovy is clunky to use". Kimsal has "frequently found that the documentation on the website is itself out of date, and with its lack of either editorial oversight or regular maintenance it is falling behind, in usefulness".

23 April 2013
Laforge still hasn't begun on the documentation overhaul he announced 3 months ago when he said "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". Yesterday, he was still talking about what authoring tool to use. Laforge was quick to point out one of Groovy's problems, but slow to work on the solution.

22 April 2013
Rocher reveals more of his agenda for SpringSource to muscle in on Java app distribution channels when he announces "Grails 3.0 will be a reinvention of the framework, and we will be making some hard decisions about what we support in terms of backwards compatibility. We plan to allow the creation of applications in different architectural styles. Servlet API apps will always be supported, but we plan to make create-app extensible, so Grails can be used to create a range of app types (Batch, NIO, Netty, static void main, etc)." He will control the code behind create-app, making Grails secretly collect user info, to push up the sale price of SpringSource.

17 April 2013
Laforge is busy posting Gr8te conf sales brochures: he's the only one who refers to another respondent's reply (qu's 2,3,8,9,10) so he must have coordinated the mailout. He thanked Groovy Tech Lead Theodorou by ignoring his title: "Guillaume Laforge, the Groovy project lead, Jochen Theodorou and Cédric Champeau–both committers to Groovy, and Andres Almiray, Griffon project lead." Were Rocher, Glasius, Docktor, Niederwieser, etc too wisened up to Laforge's petty politics to bother returning answers to his questions?

15 April 2013
Rocher and his cohort are spreading around the lie that I'm "hiding in China". I last visited my home country in January last year, and will visit again soon enough. I was there in NZ when Kim Dotcom was attacked by a Hollywood-initiated raid. Their attack cascaded through various intermediaries, such as American politicians, FBI observers, and the NZ police, just as Rocher's attacks on me cascade through 2 other intermediaries. Sociopaths always hide behind decoys.

5 April 2013
Straight after Rocher's talk at Gr8te, Spring Framework guru Juergen Hoeller talks about the upcoming Spring 4 having a strong focus on Groovy. Rocher's plot is to entangle Groovy into Spring to make Spring as dependent on Groovy/Grails as they are on Spring. He'll then pitch for making Spring and Grails into a single product, with him in charge of course. Within weeks, key Spring people will go the way of Strachan and Tkachman.

4 April 2013
This year's Gr8te conference has replaced Laforge with Venkat Subramaniam talking on "The rise and fall of empires: Lessons for language designers and programmers" in Groovy's keynote slot (Thurs 9:15). What announcement is Rocher going to spring in the Grails keynote about "The road to Grails 3.0" (Fri 10:50) when he cites Venkat's conclusions as justification?

2 April 2013
Grover's figured me out now. He calls me a complainer, but he's just a conformer. He wants to kill me, but I don't die that easily. Even when he's in charge, I can still control his right eye! And if I store memories in the neurons just behind it, Grover can't get them even if he meditates.

Looks like my tweets (15 Feb to 26 Mar 2013) have been copied to the Groovy Language blog by my other half, so I've erased them from here.

4 Feb 2013
When I was in school my teacher told me if we drill a hole thru the center of the earth from Zeeland in the Netherlands, we'll end up in New Zealand. The latest remake of Totall Recall was real cool!

23 Oct 2012
A revolutionary in the global struggle to set the Grǭǭvy Language free of its oppressors, to give it a constitution (i.e. spec) so anyone can implement it in freedom and liberty, and to provide a reference implementation that won't change suddenly because some middleman is threatened by the applications being built upon it.

An unofficial tweetroll because the real twitter's blocked behind the Chinese Firewall. Also follow me at Hacker News and Stack Overflow.

Vorg van Geir

See previous blog entries.

Only some of what I wrote in the blogs on the previous page was an April Fool's joke. Most of it was deadly serious. You decide which is which!

Updated Wiki: Blog05

gavingrover — Sun, 19 May 2013 03:28:55 GMT

Gavin Groovy Grover's UNICODE Blog

19 May 2013

Grȫȫvy ecosystem busts free!

1. GrooScript

2. "GroovyRuby"

3. Kotlin

4. Grojure

5. Garfa

grÒÓvy = grÒjure + unicÓde

Vorg's Tweetroll

See previous blog entries.

Only some of what I wrote in the blogs on the previous page was an April Fool's joke. Most of it was deadly serious. You decide which is which!

Updated Wiki: Blog05

gavingrover — Sun, 19 May 2013 03:09:11 GMT

Gavin Groovy Grover's UNICODE Blog

from 29 April 2013

grÒÓvy = grÒjure + unicÓde

Vorg's Tweetroll

See previous blog entries.

Only some of what I wrote in the blogs on the previous page was an April Fool's joke. Most of it was deadly serious. You decide which is which!

Updated Wiki: Home

gavingrover — Sun, 19 May 2013 02:49:17 GMT

The Grojure Programming Language replaces the discontinued Groovy-branded reboot hosted here.

The CJK decomposition data has moved to its own project page.

An article, Kanji meets Programming, explains some of the vision for building the Groovy Language.

Follow Gavin Groovy Grover's blog for progress on rebooting the Groovy Language.

Updated Wiki: Blog05

gavingrover — Sun, 19 May 2013 02:47:56 GMT

Gavin Groovy Grover's UNICODE Blog

from 29 April 2013

grÒÓvy = grÒjure + unicÓde

Vorg's Tweetroll

9 May 2013
Rocher has been redefining Grails to mean whatever his distro bundles, growing to 115Mb in v2.2 and switching to vert.x in v3.0. Grails is no longer a specific technology, it's a branded channel. He's also been redefining Groovy to mean whatever his codebase implements, even generating a spec from the code. Groovy is no longer a branded language spec, it's a specific implementation. By expanding Grails's brand power and eliminating Groovy's, he's renaming Groovy by stealth.

8 May 2013
Looks like Rocher will announce at Gr8Conf on 24 May that Grails 3.0 is bundling Vert.x, having bullied its creator Tim Fox into surrendering it to SpringSource last Christmas. Vert.x is polyglot, using other languages (i.e. Python, Ruby, Java, JavaScript) besides Groovy. He switched Groovy's keynote speech from Laforge to Subramaniam speaking on "The rise and fall of empires: Lessons for (programming) languages", and moved the Grails track to first column on the diagram. This switch is the beginning of the end for Groovy. Rocher always hated the Groovy brand, and intends to abandon it.

3 May 2013
I first watched The Big Bang Theory in late 2010. Having been given a weekly class teaching English to some engineers, I figured they'd be interested in such content, so played a 20-min episode in some classes. I found it to be reasonably funny, so when I caught a cold in early December, I watched all the episodes to date in a single weekend over the Chinese internet. The next episode (6 Jan 2011) had this story: Leonard gets an idea to develop a smartphone app that allows users to solve equations by taking a picture of them. Sheldon tries to put himself in charge despite the app being Leonard's idea, and continually criticizes Leonard's leadership in the development of the app. After Sheldon suggests names for the app that have his name in it, he abruptly calls for a vote to change the team's leadership, resulting in Leonard firing him. Sheldon resorts to sabotaging Leonard's project...

Within weeks I heard Rocher and his cronies were spreading the lie that I'd done to Groovy what Sheldon had done. I've seen this tactic used many times while working in IT, and the reason is almost always the same: Rocher is deflecting attention away from his own schemes by accusing others of doing the same. But Rocher is the true culprit: he hijacked Groovy to be subservient to Grails and is going after Spring next. He's just increased the Grails download size from 50Mb to 115Mb, muscling in on the distribution channels for more Java software. Grails' entire business has been about nabbing users from Rails, and now he's expanding the Grails create-app command to include all Java application types, not just servlets, to steal control away from IDE's.

He installed his decoy Laforge to stonewall on a spec for 8 years, obscuring the fact that Groovy creator Strachan intended many implementations to be built. Rocher stepped in to bump out Wilson and Tkachman when they threatened his control with Ng and Groovy++. By making JBoss's Hibernate and Oracle's Java the only Grails components not under SpringSource control, he's minimising loose ends in future sales negotiations. And he keeps an army of compliant consultants who'll give him deniability. But his evil will be exposed because if he's doing it to me, he's doing it to others. And they won't stay silent either.

2 May 2013 (update to 10 April 2013)
There's 25 Starbucks stores in Wuhan city according to their store locator today (altho it says 26, one of them is wrong). As of today, I've been to all of them! I visited the first to open in Wuhan on its opening day, 6 Feb 2008. Their number has roughly doubled every year since, so I've had to visit a lot in the past year to keep up.

28 April 2013
My other half has just committed version 0.6.0 of the Groovy Language reboot, renamed Grojure for now. It's been rewritten using Armando Blancas' Kern combinator parsing library. We intend adding Unicode characters to the language grammar soon enough, plus write a plugin for Grails. Groovy's Grojure will replace Codehaus Groovy as the premier language for all applications in the Groovy ecosystem.

23 April 2013
Erik Pragt and Michael Kimsal agree with Laforge's bleak assessment of Groovy's documentation problem. Pragt says "the current web documentation for Groovy is clunky to use". Kimsal has "frequently found that the documentation on the website is itself out of date, and with its lack of either editorial oversight or regular maintenance it is falling behind, in usefulness".

23 April 2013
Laforge still hasn't begun on the documentation overhaul he announced 3 months ago when he said "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". Yesterday, he was still talking about what authoring tool to use. Laforge was quick to point out one of Groovy's problems, but slow to work on the solution.

22 April 2013
Rocher reveals more of his agenda for SpringSource to muscle in on Java app distribution channels when he announces "Grails 3.0 will be a reinvention of the framework, and we will be making some hard decisions about what we support in terms of backwards compatibility. We plan to allow the creation of applications in different architectural styles. Servlet API apps will always be supported, but we plan to make create-app extensible, so Grails can be used to create a range of app types (Batch, NIO, Netty, static void main, etc)." He will control the code behind create-app, making Grails secretly collect user info, to push up the sale price of SpringSource.

17 April 2013
Laforge is busy posting Gr8te conf sales brochures: he's the only one who refers to another respondent's reply (qu's 2,3,8,9,10) so he must have coordinated the mailout. He thanked Groovy Tech Lead Theodorou by ignoring his title: "Guillaume Laforge, the Groovy project lead, Jochen Theodorou and Cédric Champeau–both committers to Groovy, and Andres Almiray, Griffon project lead." Were Rocher, Glasius, Docktor, Niederwieser, etc too wisened up to Laforge's petty politics to bother returning answers to his questions?

15 April 2013
Rocher and his cohort are spreading around the lie that I'm "hiding in China". I last visited my home country in January last year, and will visit again soon enough. I was there in NZ when Kim Dotcom was attacked by a Hollywood-initiated raid. Their attack cascaded through various intermediaries, such as American politicians, FBI observers, and the NZ police, just as Rocher's attacks on me cascade through 2 other intermediaries. Sociopaths always hide behind decoys.

5 April 2013
Straight after Rocher's talk at Gr8te, Spring Framework guru Juergen Hoeller talks about the upcoming Spring 4 having a strong focus on Groovy. Rocher's plot is to entangle Groovy into Spring to make Spring as dependent on Groovy/Grails as they are on Spring. He'll then pitch for making Spring and Grails into a single product, with him in charge of course. Within weeks, key Spring people will go the way of Strachan and Tkachman.

4 April 2013
This year's Gr8te conference has replaced Laforge with Venkat Subramaniam talking on "The rise and fall of empires: Lessons for language designers and programmers" in Groovy's keynote slot (Thurs 9:15). What announcement is Rocher going to spring in the Grails keynote about "The road to Grails 3.0" (Fri 10:50) when he cites Venkat's conclusions as justification?

2 April 2013
Grover's figured me out now. He calls me a complainer, but he's just a conformer. He wants to kill me, but I don't die that easily. Even when he's in charge, I can still control his right eye! And if I store memories in the neurons just behind it, Grover can't get them even if he meditates.

Looks like my tweets (15 Feb to 26 Mar 2013) have been copied to the Groovy Language blog by my other half, so I've erased them from here.

4 Feb 2013
When I was in school my teacher told me if we drill a hole thru the center of the earth from Zeeland in the Netherlands, we'll end up in New Zealand. The latest remake of Totall Recall was real cool!

23 Oct 2012
A revolutionary in the global struggle to set the Grǭǭvy Language free of its oppressors, to give it a constitution (i.e. spec) so anyone can implement it in freedom and liberty, and to provide a reference implementation that won't change suddenly because some middleman is threatened by the applications being built upon it.

An unofficial tweetroll because the real twitter's blocked behind the Chinese Firewall. Also follow me at Hacker News and Stack Overflow.

Vorg van Geir

See previous blog entries.

Updated Wiki: Blog05

gavingrover — Sun, 19 May 2013 02:45:25 GMT

Gavin Groovy Grover's UNICODE Blog

19 May 2013

[|#2]

Vorg's Tweetroll

See previous blog entries.

Updated Wiki: Blog05

gavingrover — Sun, 19 May 2013 02:43:14 GMT

Gavin Groovy Grover's UNICODE Blog

1 April 2013

Dr Grover and Mr Vorg

See previous blog entries.

Updated Wiki: Home

gavingrover — Mon, 29 Apr 2013 03:49:08 GMT

The Grojure Programming Language replaces the discontinued Groovy-branded reboot hosted here.

The CJK decomposition data has moved to its own project page.

An article, Kanji meets Programming, explains some of the vision for building the Groovy Language.

Follow Gavin Groovy Grover's blog for progress on rebooting the Groovy Language.

grÒÓvy = grÒjure + unicÓde

Updated Wiki: Home

gavingrover — Mon, 29 Apr 2013 03:43:41 GMT

The Grojure Programming Language replaces the discontinued Groovy-branded reboot hosted here.

The CJK decomposition data has moved to its own project page.

An article, Kanji meets Programming, explains some of the vision for building the Groovy Language.

Follow Gavin Groovy Grover's blog for progress on rebooting the Groovy Language.

grÒÓvy = grÒjure + unicÓde

I've been alternating between analyzing the 25,000 non-Unihan characters in Unicode, and building the Grojure Programming Language atop Clojure. When both are ready, they will merge together to become the Groovy Language, a reboot of the Codehaus-hosted SpringSource-controlled first attempt at Groovy which is in terminal decline.

Updated Wiki: Blog04

gavingrover — Sat, 30 Mar 2013 09:49:37 GMT

Gavin Groovy Grover's UNICODE Blog

1 April 2013

Dr Grover and Mr Vorg

10 years later, I haven't been bothered to leave. I slowly learnt through trial and error how to teach college students, plus learnt to speak some Chinese, both "right-brain" skills. After swotting up on English linguistics and pedagogy in my first year, I went back to learning about programming, a "left-brain" skill. When I realized Chinese characters were the future of programming, I started work on decomposing them visually so Westerners could understand and use them too. I spent hours a day listening to TV shows in the background while looking at the computer, and discovered I could do both activities simultaneously. I could code programs to help decompose Chinese characters and remember the storyline of the TV shows. I could do both for hours, but either activity alone quickly bored me.

I joined in online forums as "vorg", the first 4 letters reversed of my surname. Somewhere along the way, the part of my brain listening to the TV shows became self-aware and took over that login. He even completed the login to "Vorg van Geir", a total anagram of "Gavin Grover", just like Doctor Who and Torchwood. Whereas I, Grover, was patient in dealing with the sarcasm from Rocher's handles, Vorg just reacted openly with avenging bile. When Laforge played his petty politics with Gr¤¤vy, Vorg exposed his fraud and incompetence. Vorg's a very different beast to me: he's a complainer!

I don't think it's good for Vorg to exist in me. What he's saying is true, but perhaps he shouldn't be saying it so directly. I do believe, though, in mediTation, not mediCation, to get rid of Vorg. He's most active when I let my meditation exercises lapse. Whenever I resume them after an absence, sometimes all of Vorg's memories will suddenly flash into my mind, where previously all I remembered was a blackout. If I practise them every day, it keeps Vorg at bay!

While Vorg van Geir exists, my name can only be Gavin Grover for there's no place to put the GrΦΦvy in Vorg's name, that confused anagram of mine. But when he's gone, and my name is no longer jumbled, the GrΘΘvy can slot right in between my first two names: Gavin "Grϕϕvy" Grover. Then I'll have a grÒÓvy serenity, as I rebuild the Grōōvy Language from first principles, spec and all. So my ongoing mission now is to kill Vorg, to put that complainer to death, to claim that grƟƟvy serenity as I rebuild Grŏŏvy.

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.

27 March 2013

Groovy Haskell

It's taken decades to work out what many academics already know and teach, but maybe I had to work it out for myself: statically-typed lazily-evaluated functional languages are at the pinnacle of the programming language heirarchy. Haskell is higher-level than Clojure. It makes sense to add static typing to Clojure, but not macros to Haskell. I'm only part way into learning Haskell properly, but I suspect lazily-evaluated code can do everything macros can do.

The Groovy Language reboot is about adding all Unicode tokens to the vocabulary of programming, as well as modifying the language syntax where it makes sense with the expanded vocab. My last attempt was using Clojure. I tried rewriting the grammar of Groovy 0.5 in the Kern combinator parser library for Clojure last month. I investigated which of Clojure's 4 monad libraries to use, as well as analyzed core.logic. I've looked at clojure.typed and decided the Groovy reboot must enable static typing from its very foundation.

But clojure.typed stumbles in two cases: functions accepting or returning nil i.e. (U nil ...), and functions accepting variadic arguments i.e. [... *]. The nil is a billion dollar mistake and has no place in any language, especially when monads are available. Variadic functions are a smell: they represent two concepts needlessly complected together: what a function does, and a fold when there's extra arguments. Such fold syntax can be represented separately from the function easily enough, e.g. +/ 1 2 3 in APL.

So just as Ruby supercedes C++ by making everything an object, Haskell supercedes Lisp by making everything a macro. Macros are the pointers of functional programming. I'm therefore switching to Haskell as the Groovy Language reboot's implementation language. (Unless I'm wrong about macros, then I'll be back to Clojure!)

Attacks against Groovy

Looks like Vorg van Geir's been active again so thought I'd add a pic this time...

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

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?

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?

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.

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.

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

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?

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.

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?

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?

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

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?

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

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

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.

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

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.

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.

Exactly!

23 February, updated 16 March 2013

Groovy Tweetroll

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 groovy.io.

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 slo.oo.ooo.oooo.ooooo.oooo.ooo.oo.ow, 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?

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.

7 February 2013

Roadmap

I'm moving the roadmap from its own page to this blog entry...

The Groovy Language here at Codeplex will be built with Unicode graphemes, unlike most programming languages (e.g. the fake Groovy at Codehaus) which are built solely with Ascii tokens, with bare Unicode codepoints added in as an afterthought. The rough roadmap for evolving Groovy, beginning with lower numbered items, is...

1. Groovy Grammar

Build a recursive-descent parsing library that can look at the internal structure of CJK tokens, and define the Groovy grammar. The grammar atop Clojure will enable developers to extend the Groovy syntax easily using parser-level macros. The latest version can parse a healthy subset of the Groovy grammar.

2. GUI with IME

Create a GUI with a input method editor (IME) to enable all Unicode tokens to be entered easily, and a J-style interactive learning environment for the Groovy Language syntax. Use these 3-yr-old notes for learning Groovy 1.5 as a base for writing a comprehensive test suite.

3. Unicode Properties

We'll use inheritance hierarchies to represent all the Unicode characters, one for the codepoints based on the general category and certain relevant boolean properties, the other for various decompositions. We've yet to analyze the information inside the Unihan variant data.

4. CJK Decomposition Data

The CJK Decomposition Data File is a graphical analysis of the approx 75,000 Chinese/Japanese characters in Unicode. They utilize approx 11,000 intermediate decompositions which are not themselves in Unicode. See the main project site for more details. The latest version, 0.4.0, was released on 15 August 2012. See also some notes on using reflection in the CJK decompositions. We'll use these decomps to design the IME keys for entering CJK tokens into the Groovy GUI.

5. Peer-to-Peer Engine

Enable the most common operator symbols and foreign-language names to be shared automatically between Groovy IME's using a peer-to-peer protocol so developers will know the most commonly used names and symbols when writing code.

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.

5 February 2013

Groovy Japanese

Something strange happened the other day! It's difficult to explain so I better set the scene...

I've been learning Chinese for the last 10 years, between programming and teaching, so not too quickly, and my Chinese reading is better than my speaking or listening. I've noticed learning to read new Chinese characters is different to reading words in other languages in that we must use both the visual and auditory parts of the brain at the same time. E.g. to read 妈, we look at 女 visually and at 马 phonetically: 女 means "woman" and 马 sounds like "ma", so when we see the word 妈, both the visual and auditory parts of our brain together create the meaning "mother". Of course, when we've learnt the word our longterm memory kicks in instead, but there's always many more characters of the 3000-4000 commonly used ones we don't know.

A few months ago, I tried my hand at learning to read Japanese. Because I already know most of the Kanji, they being similar in meaning to the over 2000 Chinese characters I've learnt, I figured I'd have a head start learning to read Japanese if I weren't concerned about speaking it. So I decided to learn it visually, seeing if I can read it and understand the meaning, but without vocalizing it in my head. When looking through Tae Kim's online tutorial, I'd noticed most of the 46 Hiragana usually have only one grammatical or functional meaning, e.g. ます for polite register.

So I started practising reading Kanji/Hiragana text from some practise books. (Language-learning books on Japanese are second in popularity to those on English in bookshops across China. They are useful to me because I can read the explanations in Chinese!) But one day recently something strange happened...

I was looking at some Japanese text I could easily read but then I had to cover my left eye because it started itching. Suddenly I couldn't understand any of the text I was looking at, except for some Kanji which I already knew the Chinese pronunciation for. But then I tried covering my right eye, and suddenly I could understand the Japanese meaning easily again!

It seems by learning to read basic Japanese so I can understand the meaning but not pronounce the words, only one side of my brain is utilized, the same side that processes vision from my left eye.

This discovery also explains something else. When I'm programming, I usually play English-language TV shows in the background, and can follow the stories just by listening to them, only glancing at the TV screen once or twice a minute. I can code up programs that work and remember the storyline of the TV shows when I do both at the same time! If I do either activity by itself I get bored easily, but when I do both simultaneouly I can easily work for hours at a time. Also... these are the only two mental activities I'm able to do simultaneously, without either activity being impacted.

So I've made a picture (using the image from Wikipedia) of what it seems each side of my brain does:

Of course, all this has implications for using Kanji in programming to make code terser. Because the same half of the brain that reads Kanji visually also writes programming code, they should gel together easily, and still leave the other half of the brain free for some interpersonal activity. In theory, we could write terse programs using Kanji as well as use interpersonal skills to relate to clients and colleagues, and stuff like that!

The Groovy Language reboot here at Codeplex aims to bring all Unicode characters to the vocabulary of programs, not just the 96 ASCII (or 70 APL) ones. When the fake Groovy dies in the grave of Grales, the real Groovy will rise, bringing all Unicode tokens for the programming half of our brains to use when we code.

See previous blog entries.

Updated Wiki: Blog04

gavingrover — Sat, 30 Mar 2013 09:46:53 GMT