Groovy Language

Updated Wiki: Blog05

gavingrover — Sat, 15 Jun 2013 07:54:27 GMT

Gavin Groovy Grover's UNICODE Blog

15 June 2013

Groovy's 100 roadmaps

As Groovy nears its 10th birthday this coming 29 August 2013, other Groovy milestones lurk nearby. The 100th binary release of Groovy (2.0.6) occurred last 21 December 2012, the northern winter solstice. An hour afterwards, the 100th source release of Groovy (2.1.0-beta-1) occurred. Another milestone is the 100th roadmap which will soon be published. Looking at the changes between the last few roadmaps gives a glimpse of the politics behind roadmap changes...

Last year on 21 June 2012, another solstice, the roadmap listed Groovy 3.0 as having a new MOP, an Antlr 4 grammar, and retrofitted Java 8 closures.

On 27 June 2012, Jochen Theodorou updated the roadmap moving the new grammar to Groovy 4.0, adding the years 2013 to Groovy 3.0 and 2014 to Groovy 4.0. Perhaps he thought he could force some funds out of Rocher by subordinating the grammar rewrite to the MOP rewrite in the roadmap.

On 27 Sep 2012, Laforge listed Groovy 2.1, adding it before Groovy 3.0, skuttling Theodorou's weak attempt at getting the new MOP green-lighted.

The next major change happened 3 roadmaps later on 25 Jan 2013 when Laforge released Groovy 2.1, removing it from the anticipated Groovy releases.

2 roadmaps later on 6 Feb 2013, Laforge added Groovy 2.2 with release date mid 2013, again skuttling Theodorou's attempt to work on a new MOP, and changed the release date of Groovy 3.0 to end 2013. He also qualified New meta-object protocol with dedicated to fully leverage "invoke dynamic".

On 16 May 2013, a week before the Gr8te conference in Copenhagen, Laforge made further changes in the 99th version of the roadmap to show off his P.M. chops, being threatened by Rocher's power plays. He sniped at Theodorou, undoing his change from a year earlier, moving the Antlr 4 rewrite back to Groovy 3.0, and changed the Feature set labels to Feature set for consideration. Laforge also shunted the release dates for all pending releases: Groovy 2.2 from mid 2013 to Q3 2013, Groovy 3.0 from end 2013 to Q1 2014, and Groovy 4.0 from 2014 to Q1 2015.

What trick is Laforge going to make for the 100th version of the roadmap in what should really be a celebration?

8 June 2013

grOOvy goes wayward

The parts of grOOvy that developers find most praiseworthy are the those which were added in the first year of its life. Witness this comment yesterday by Clojure guru Stuart Holloway:

"I am finding Groovy to be a great way to show code to Java programmers -- collection literals, dynamic typing, and closures take most of the pain out of reading Java. Thanks to everyone who puts effort into making Groovy!"

All these features were mentioned in James Strachan's historic announcement almost 10 years ago:

"We're starting simple with the nice tuples, sequences, maps from python & closures from ruby and being concise & dynamically typed with a java-look-and-feel though where we end up is anyones guess right now."

6 months later, the spec was begun so many implementations of gr©Øvy would be built:

"its the EG's responsibility to make a great spec and a reference implementation and TCK. Its up to others to create different implementations if they want to. e.g. the Servlet / JSP / JSTL JSRs created RIs which many people still use today - but then vendors and other open source projects came along and tried to do better."

But on 6 Dec 2004, Guillaume Laforge took over, instituting the cathedral through a series of announcements such as:

"We don't grant CVS access to everyone. Groovy hackers need to show their abilities and enthousiasm by writing one or several patches for new features, or for fixing some bugs."

So Groovy ended up as a cathedral enslaved to Grails (and its build tool Gradle). I'm presently digging through the early history of the Groovy Language to see when and how it lost its way, and 6 Dec 2004 seems to be the infamous day! It was on this day that the spec got skuttled so no other open source project could come along and do better, the language got hijacked for a MOP and Grails, and the AST transform hooks got created to snare in developers like Alex Tkachman to create plugins that would later be laundered. It was on 6 Dec 2004 the events leading to Groovy's imminent death were set in motion.

Having accepted the reality of grÔÔvy's path to the grave, I've begun on its replacement language: Grojure. It uses the slower Kern combinator parsers for now while it's still finding its grammar. It picks up where the original Groovy-1.0-beta-10 grammar left off, including Chris Poirier's heredocs which were dropped. It features Java-style operators and path expressions, collection and map literals, and closure syntax. It will add Unicode symbols as part of the core language for more tersity, though all language functionality will be available using ASCII only syntax so developers can embrace Unicode at their own pace.

Grojure will bring Groovy back from its grave, and with 110,000 Unicode symbols in its grammar instead of just 96 ASCII ones, will be boundlessly better!

4 June 2013

Grails Deception

Last month, Grails despot Graeme Rocher announced, using doublespeak, that Grails will become a distribution channel for SpringSource software only. To quote him, minus the fluff, with commentary...

Grails is at an inflection point in its history. Application architectures are changing. The traditional model that the Servlet era APIs were designed for is becoming valid for fewer and fewer cases. Mobile and Rich web apps are driving this revolution. Grails is not the only framework that will need to adapt to this new world. Every current popular web framework is going to have to make changes to support new architectural styles.

Here, Rocher is redefining Grails to mean something more than what it currently bundles, namely, an MVC framework around Spring, Tomcat, and Hibernate.

Unlike many frameworks that only provide the View/Controller layer, Grails provides significant amounts of value beyond serving up GSP views. Grails is one of the few proven “full stack” environments used to build real world applications and adopted by thousands of developers world wide. They adopt it because it provides the out-of-the-box experience developers seek, including a compelling plugin eco-system.

Rocher latches onto the "full stack" mantra (the latest marketing fad for web tools), embellishes it with "few" without naming those few others, and claims it's "proven" without offering any proof.

Many Grails plugins are not tied to any particular architectural style. Persistence is a key area, and GORM has evolved from being based on Hibernate into supporting NoSQL databases like MongoDB, Neo4j and Amazon DynamoDB.

By listing Hibernate as only one of many databases, Rocher is announcing its relegation from Grails core. Hibernate is controlled by JBoss, not SpringSource.

To adapt and evolve to this new world, Grails is going to have to change and that is why we are starting work on Grails 3.0 towards the 3rd quarter of this year. Grails 3.0 will be a reinvention of the framework that you love, and we will be making some hard decisions about what we support in terms of backwards compatibility. With Grails 3.0 we plan to allow the creation of applications in different architectural styles. Servlet API applications will always be supported, but we plan to make “create-app” extensible, so that Grails can be used to create a range of types of applications (Batch, NIO, Netty, “static void main” etc.).

Rocher says "will be making", but he's already made these hard decisions. Grails will be muscling in on the territory of IDE's.

This will involve splitting Grails out further into a more modular system. The default plugins installed for a Servlet applications will be different for those for a Batch or Netty application. Packaging types will differ (WAR vs JAR vs ?). Even the set of command line commands you get at build time will differ based on the type of application you want to create.

Hibernate will be relegated to a plugin module because it isn't SpringSource-controlled. And will enabling servlet apps be actively developed anymore or left to stagnate?

All of this will require refactoring and changes to our current build system (a shift to Gradle) and significant extensions to the plugin API. However, I believe we can make Grails applicable to a range of new use cases and create compelling environments that our users enjoy.

Gradle may even be bundled with Grails. The Grails download size was increased from 50Mb to 115Mb in v2.2 when the documentation was bundled with the core distribution instead of being offered separately. Will Gradle bloat it even further?

Right now in Grails 2.3 we are laying some of the ground work for Grails 3.0 by making available APIs and tools that will be applicable in Grails 3.0 as well (The async and eventing APIs, new REST APIs forked execution everywhere etc.). All in all, it is an exciting time to be working on Grails, and I look forward to feedback from the community on our current direction.

Rocher cynically elicits "feedback", but look how he responded to Alex Tkachman's "feedback" on Groovy's sloooooooooooooow dynamically-typed run times. He employed someone to launder the code.

vinay, a month ago − I feel grails 3 should be built on top of vert.x, which will give it async and clustering support and lot more.

There's no vinay on the Grails mailing list. This top comment must be Rocher, saying he's already decided to bundle Vert.X in Grails 3. Vert.X is SpringSource-controlled, having been stolen from creator Tim Fox last Christmas vacation.

In this blog entry, Rocher presents some falacious reasoning about why Grails 3 will drop Hibernate and add Vert.X in its core distribution. But he's really just spinning a cover story for turning Grails into a distribution channel for SpringSource software only (primarily Groovy, Spring, Tomcat, and Vert.X), while dropping everything significant not controlled by SpringSource (e.g. Hibernate). By embracing all of SpringSource's product offerings, he's pitching for a higher rung on the corporate ladder and a bigger cut when SpringSource is sold to Oracle later on.

Do you really believe someone who spins stories so callously to his customers wouldn't also run a smear campaign against perceived threats through intermediaries or use virus-based online surveillance? His claims of being stalked sound hollow next to the bare-faced lies on his blog.

29 May 2013

A GrȎŎvy Decade

Groovy's 10th birthday is only a few months away, so let's look at Groovy's timeline. The picture shows some well-known milestones, but there's so much more to see in the gaps, all obvious in hindsight but difficult to discern at the time. We see a story of two coups: Strachan was toppled by Laforge, then he by Rocher...

Strachan began Groovy as a portmanteau of various languages in 2003, even getting a JSR spec voted in by the IT business community. I remember the excitement when I first joined the ecosystem. But Laforge came along and fashioned it solely after Ruby, muscled out Strachan and Rose, brought in Rocher and Theodorou, and started retrofitting Groovy with a MOP so a Rails clone would run on it, however slowly. Rocher began building Grales as a wrapper around Spring and Hibernate, incorporated G2One to muscle in on the consulting and conference market for those products, ruthlessly dealt with threats such as Wilson and myself, and got bought by SpringSource and VMWare.

This was a low time in my life with Groovy. I fruitlessly tried rebuilding it atop other platforms. At times I even just tried to annoy the Groovy developers, then eventually gave up. But in mid-2009 Strachan made his famous statement renouncing what Groovy had become, then Tkachman starting building Groovy++ as a statically-typed plugin. My inspiration renewed, I returned to the ecosystem to build Gregexes atop Groovy++, looking toward the day when a Groovy Platform would ship with all the best Groovy plugins bundled.

But Rocher didn't want a bazaar: he employed Champeau to launder Tkachman's code, had Laforge stonewall on a spec after Oracle threw them out of the JSR process, sent solicitors to Tim Fox's home last Christmas vacation to steal the Vert.X open source project, and doublespeaks his intention to stall further MVC development in Grales. Instead, he's turning Grales 3.0 into a branded distribution channel for other SpringSource software, scuttling the glorious Groovy name.

The second decade of Groovy will feature a third coup: Grojure will free Groovy from the vicelike grip of Grales by being what Groovy should have become the first time around.

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 — Sat, 15 Jun 2013 07:51:18 GMT

Gavin Groovy Grover's UNICODE Blog

15 June 2013

Groovy's 100 roadmaps

As Groovy nears its 10th birthday this coming 29 August 2013, other Groovy milestones lurk nearby. The 100th binary release of Groovy (2.0.6) occurred last 21 December 2012, the northern winter solstice. An hour afterwards, the 100th source release of Groovy (2.1.0-beta-1) occurred. Another milestone is the 100th roadmap which will soon be published. Looking at the changes between the last few roadmaps gives a glimpse of the politics behind roadmap changes...

Last year on 21 June 2012, another solstice, the roadmap listed Groovy 3.0 as having a new MOP, an Antlr 4 grammar, and retrofitted Java 8 closures.

On 27 June 2012, Jochen Theodorou updated the roadmap moving the new grammar to Groovy 4.0, adding the years 2013 to Groovy 3.0 and 2014 to Groovy 4.0. Perhaps he thought he could force some funds out of Rocher by subordinating the grammar rewrite to the MOP rewrite.

On 27 Sep 2012, Laforge listed Groovy 2.1, adding it before Groovy 3.0, skuttling Theodorou's weak attempt at getting the new MOP green-lighted.

The next major change happened 3 roadmaps later on 25 Jan 2013 when Laforge released Groovy 2.1, removing it from the anticipated Groovy releases.

2 roadmaps later on 6 Feb 2013, Laforge added Groovy 2.2 with release date mid 2013, again skuttling Theodorou's attempt to work on a new MOP, and changed the release date of Groovy 3.0 to end 2013. He also qualified Meta Object Protocol with dedicated to fully leverage invoke-dynamic.

On 16 May 2013, a week before the Gr8te conference in Copenhagen, Laforge made further changes to show off his P.M. chops, being threatened by Rocher's power plays. He sniped at Theodorou, undoing his change from a year earlier, moving the Antlr 4 rewrite back to Groovy 3.0, and changed the Feature set labels to Feature set for consideration. Laforge also shunted the release dates for all pending releases: Groovy 2.2 from mid 2013 to Q3 2013, Groovy 3.0 from end 2013 to Q1 2014, and Groovy 4.0 from 2014 to Q1 2015.

What trick is Laforge going to make for the 100th version of the roadmap in what should really be a celebration?

8 June 2013

grOOvy goes wayward

The parts of grOOvy that developers find most praiseworthy are the those which were added in the first year of its life. Witness this comment yesterday by Clojure guru Stuart Holloway:

"I am finding Groovy to be a great way to show code to Java programmers -- collection literals, dynamic typing, and closures take most of the pain out of reading Java. Thanks to everyone who puts effort into making Groovy!"

All these features were mentioned in James Strachan's historic announcement almost 10 years ago:

"We're starting simple with the nice tuples, sequences, maps from python & closures from ruby and being concise & dynamically typed with a java-look-and-feel though where we end up is anyones guess right now."

6 months later, the spec was begun so many implementations of gr©Øvy would be built:

"its the EG's responsibility to make a great spec and a reference implementation and TCK. Its up to others to create different implementations if they want to. e.g. the Servlet / JSP / JSTL JSRs created RIs which many people still use today - but then vendors and other open source projects came along and tried to do better."

But on 6 Dec 2004, Guillaume Laforge took over, instituting the cathedral through a series of announcements such as:

"We don't grant CVS access to everyone. Groovy hackers need to show their abilities and enthousiasm by writing one or several patches for new features, or for fixing some bugs."

Grails Deception

Last month, Grails despot Graeme Rocher announced, using doublespeak, that Grails will become a distribution channel for SpringSource software only. To quote him, minus the fluff, with commentary...

Grails is at an inflection point in its history. Application architectures are changing. The traditional model that the Servlet era APIs were designed for is becoming valid for fewer and fewer cases. Mobile and Rich web apps are driving this revolution. Grails is not the only framework that will need to adapt to this new world. Every current popular web framework is going to have to make changes to support new architectural styles.

Here, Rocher is redefining Grails to mean something more than what it currently bundles, namely, an MVC framework around Spring, Tomcat, and Hibernate.

Unlike many frameworks that only provide the View/Controller layer, Grails provides significant amounts of value beyond serving up GSP views. Grails is one of the few proven “full stack” environments used to build real world applications and adopted by thousands of developers world wide. They adopt it because it provides the out-of-the-box experience developers seek, including a compelling plugin eco-system.

Many Grails plugins are not tied to any particular architectural style. Persistence is a key area, and GORM has evolved from being based on Hibernate into supporting NoSQL databases like MongoDB, Neo4j and Amazon DynamoDB.

By listing Hibernate as only one of many databases, Rocher is announcing its relegation from Grails core. Hibernate is controlled by JBoss, not SpringSource.

To adapt and evolve to this new world, Grails is going to have to change and that is why we are starting work on Grails 3.0 towards the 3rd quarter of this year. Grails 3.0 will be a reinvention of the framework that you love, and we will be making some hard decisions about what we support in terms of backwards compatibility. With Grails 3.0 we plan to allow the creation of applications in different architectural styles. Servlet API applications will always be supported, but we plan to make “create-app” extensible, so that Grails can be used to create a range of types of applications (Batch, NIO, Netty, “static void main” etc.).

Rocher says "will be making", but he's already made these hard decisions. Grails will be muscling in on the territory of IDE's.

This will involve splitting Grails out further into a more modular system. The default plugins installed for a Servlet applications will be different for those for a Batch or Netty application. Packaging types will differ (WAR vs JAR vs ?). Even the set of command line commands you get at build time will differ based on the type of application you want to create.

Hibernate will be relegated to a plugin module because it isn't SpringSource-controlled. And will enabling servlet apps be actively developed anymore or left to stagnate?

All of this will require refactoring and changes to our current build system (a shift to Gradle) and significant extensions to the plugin API. However, I believe we can make Grails applicable to a range of new use cases and create compelling environments that our users enjoy.

Right now in Grails 2.3 we are laying some of the ground work for Grails 3.0 by making available APIs and tools that will be applicable in Grails 3.0 as well (The async and eventing APIs, new REST APIs forked execution everywhere etc.). All in all, it is an exciting time to be working on Grails, and I look forward to feedback from the community on our current direction.

Rocher cynically elicits "feedback", but look how he responded to Alex Tkachman's "feedback" on Groovy's sloooooooooooooow dynamically-typed run times. He employed someone to launder the code.

vinay, a month ago − I feel grails 3 should be built on top of vert.x, which will give it async and clustering support and lot more.

29 May 2013

A GrȎŎvy Decade

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

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

Fake and Real Groovy

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

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 — Sat, 15 Jun 2013 07:45:53 GMT

Gavin Groovy Grover's UNICODE Blog

15 June 2013

Groovy's 100 roadmaps

As Groovy nears its 10th birthday this coming 29 August 2013, other Groovy milestones lurk nearby. The 100th binary release of Groovy (2.0.6) occurred last 21 December 2012, the northern winter solstice. An hour afterwards, the 100th source release of Groovy (2.1.0-beta-1) occurred. Another milestone is the 100th roadmap which will soon be published. Looking at the changes between the last few roadmaps gives a glimpse of the politics behind roadmap changes...

Last year on 21 June 2012, another solstice, the roadmap listed Groovy 3.0 as having a new MOP, an Antlr 4 grammar, and retrofitted Java 8 closures.

On 27 June 2012, Jochen Theodorou updated the roadmap moving the new grammar to Groovy 4.0, adding the years 2013 to Groovy 3.0 and 2014 to Groovy 4.0. Perhaps he thought he could force some funds out of Rocher by subordinating the grammar rewrite to the MOP rewrite.

On 27 Sep 2012, Laforge listed Groovy 2.1, adding it before Groovy 3.0, skuttling Theodorou's weak attempt at getting the new MOP green-lighted.

The next major change happened 3 roadmaps later on 25 Jan 2013 when Laforge released Groovy 2.1, removing from the anticipated Groovy releases.

2 roadmaps later on 6 Feb 2013, Laforge added Groovy 2.2 with release date mid 2013, again skuttling Theodorou's attempt to work on a new MOP, and changed the release date of Groovy 3.0 to end 2013.

On 16 May 2013, a week before the Gr8te conference in Copenhagen, Laforge made further changes to show off his P.M. chops, being threatened by Rocher's power plays. He sniped at Theodorou, undoing his change from a year earlier, moving the Antlr 4 rewrite back to Groovy 3.0, and changed the Feature set labels to Feature set for consideration. Laforge also shunted the release dates for all pending releases: Groovy 2.2 from mid 2013 to Q3 2013, Groovy 3.0 from end 2013 to Q1 2014, and Groovy 4.0 from 2014 to Q1 2015.

What trick is Laforge going to make for the 100th version of the roadmap in what should really be a celebration?

8 June 2013

grOOvy goes wayward

The parts of grOOvy that developers find most praiseworthy are the those which were added in the first year of its life. Witness this comment yesterday by Clojure guru Stuart Holloway:

"I am finding Groovy to be a great way to show code to Java programmers -- collection literals, dynamic typing, and closures take most of the pain out of reading Java. Thanks to everyone who puts effort into making Groovy!"

All these features were mentioned in James Strachan's historic announcement almost 10 years ago:

"We're starting simple with the nice tuples, sequences, maps from python & closures from ruby and being concise & dynamically typed with a java-look-and-feel though where we end up is anyones guess right now."

6 months later, the spec was begun so many implementations of gr©Øvy would be built:

"its the EG's responsibility to make a great spec and a reference implementation and TCK. Its up to others to create different implementations if they want to. e.g. the Servlet / JSP / JSTL JSRs created RIs which many people still use today - but then vendors and other open source projects came along and tried to do better."

But on 6 Dec 2004, Guillaume Laforge took over, instituting the cathedral through a series of announcements such as:

"We don't grant CVS access to everyone. Groovy hackers need to show their abilities and enthousiasm by writing one or several patches for new features, or for fixing some bugs."

Grails Deception

Last month, Grails despot Graeme Rocher announced, using doublespeak, that Grails will become a distribution channel for SpringSource software only. To quote him, minus the fluff, with commentary...

Grails is at an inflection point in its history. Application architectures are changing. The traditional model that the Servlet era APIs were designed for is becoming valid for fewer and fewer cases. Mobile and Rich web apps are driving this revolution. Grails is not the only framework that will need to adapt to this new world. Every current popular web framework is going to have to make changes to support new architectural styles.

Here, Rocher is redefining Grails to mean something more than what it currently bundles, namely, an MVC framework around Spring, Tomcat, and Hibernate.

Unlike many frameworks that only provide the View/Controller layer, Grails provides significant amounts of value beyond serving up GSP views. Grails is one of the few proven “full stack” environments used to build real world applications and adopted by thousands of developers world wide. They adopt it because it provides the out-of-the-box experience developers seek, including a compelling plugin eco-system.

Many Grails plugins are not tied to any particular architectural style. Persistence is a key area, and GORM has evolved from being based on Hibernate into supporting NoSQL databases like MongoDB, Neo4j and Amazon DynamoDB.

By listing Hibernate as only one of many databases, Rocher is announcing its relegation from Grails core. Hibernate is controlled by JBoss, not SpringSource.

To adapt and evolve to this new world, Grails is going to have to change and that is why we are starting work on Grails 3.0 towards the 3rd quarter of this year. Grails 3.0 will be a reinvention of the framework that you love, and we will be making some hard decisions about what we support in terms of backwards compatibility. With Grails 3.0 we plan to allow the creation of applications in different architectural styles. Servlet API applications will always be supported, but we plan to make “create-app” extensible, so that Grails can be used to create a range of types of applications (Batch, NIO, Netty, “static void main” etc.).

Rocher says "will be making", but he's already made these hard decisions. Grails will be muscling in on the territory of IDE's.

This will involve splitting Grails out further into a more modular system. The default plugins installed for a Servlet applications will be different for those for a Batch or Netty application. Packaging types will differ (WAR vs JAR vs ?). Even the set of command line commands you get at build time will differ based on the type of application you want to create.

Hibernate will be relegated to a plugin module because it isn't SpringSource-controlled. And will enabling servlet apps be actively developed anymore or left to stagnate?

All of this will require refactoring and changes to our current build system (a shift to Gradle) and significant extensions to the plugin API. However, I believe we can make Grails applicable to a range of new use cases and create compelling environments that our users enjoy.

Right now in Grails 2.3 we are laying some of the ground work for Grails 3.0 by making available APIs and tools that will be applicable in Grails 3.0 as well (The async and eventing APIs, new REST APIs forked execution everywhere etc.). All in all, it is an exciting time to be working on Grails, and I look forward to feedback from the community on our current direction.

Rocher cynically elicits "feedback", but look how he responded to Alex Tkachman's "feedback" on Groovy's sloooooooooooooow dynamically-typed run times. He employed someone to launder the code.

vinay, a month ago − I feel grails 3 should be built on top of vert.x, which will give it async and clustering support and lot more.

29 May 2013

A GrȎŎvy Decade

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

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

Fake and Real Groovy

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

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 — Sat, 15 Jun 2013 07:43:47 GMT

Gavin Groovy Grover's UNICODE Blog

15 June 2013

Groovy's 100 roadmaps

As Groovy nears its 10th birthday this coming 29 August 2013, other Groovy milestones lurk nearby. The 100th binary release of Groovy (2.0.6) occurred last 21 December 2012, the northern winter solstice. An hour afterwards, the 100th source release of Groovy (2.1.0-beta-1) occurred. Another milestone is the 100th roadmap which will soon be published. Looking at the changes between the last few roadmaps gives a glimpse of the politics behind roadmap changes...

Last year on 21 June 2012, another solstice, the roadmap listed Groovy 3.0 as having a new MOP, an Antlr 4 grammar, and retrofitted Java 8 closures.

On 27 June 2012, Jochen Theodorou updated the roadmap moving the new grammar to Groovy 4.0, adding the years 2013 to Groovy 3.0 and 2014 to Groovy 4.0. Perhaps he thought he could force some funds out of Rocher by subordinating the grammar rewrite to the MOP rewrite.

On 27 Sep 2012, Laforge listed Groovy 2.1, adding it before Groovy 3.0, skuttling Theodorou's weak attempt at getting the new MOP green-lighted.

The next major change happened 3 roadmaps later on 25 Jan 2013 when Laforge released Groovy 2.1, removing from the anticipated Groovy releases.

2 roadmaps later on 6 Feb 2013, Laforge added Groovy 2.2 with release date mid 2013, again skuttling Theodorou's attempt to work on a new MOP, and changed the release date of Groovy 3.0 to end 2013.

On 16 May 2013, a week before the Gr8te conference in Copenhagen, Laforge made further changes to show off his P.M. chops, being threatened by Rocher's power plays. He sniped at Theodorou, undoing his change from a year earlier, moving the Antlr 4 rewrite back to Groovy 3.0, and changed the Feature set labels to Feature set for consideration. Laforge also shunted the release dates for all pending releases: Groovy 2.2 from mid 2013 to Q3 2013, Groovy 3.0 from end 2013 to Q1 2014, and Groovy 4.0 from 2014 to Q1 2015.

What trick is Laforge going to make for the 100th version of the roadmap in what should really be a celebration?

8 June 2013

grOOvy goes wayward

The parts of grOOvy that developers find most praiseworthy are the those which were added in the first year of its life. Witness this comment yesterday by Clojure guru Stuart Holloway:

"I am finding Groovy to be a great way to show code to Java programmers -- collection literals, dynamic typing, and closures take most of the pain out of reading Java. Thanks to everyone who puts effort into making Groovy!"

All these features were mentioned in James Strachan's historic announcement almost 10 years ago:

"We're starting simple with the nice tuples, sequences, maps from python & closures from ruby and being concise & dynamically typed with a java-look-and-feel though where we end up is anyones guess right now."

6 months later, the spec was begun so many implementations of gr©Øvy would be built:

"its the EG's responsibility to make a great spec and a reference implementation and TCK. Its up to others to create different implementations if they want to. e.g. the Servlet / JSP / JSTL JSRs created RIs which many people still use today - but then vendors and other open source projects came along and tried to do better."

But on 6 Dec 2004, Guillaume Laforge took over, instituting the cathedral through a series of announcements such as:

"We don't grant CVS access to everyone. Groovy hackers need to show their abilities and enthousiasm by writing one or several patches for new features, or for fixing some bugs."

Grails Deception

Last month, Grails despot Graeme Rocher announced, using doublespeak, that Grails will become a distribution channel for SpringSource software only. To quote him, minus the fluff, with commentary...

Grails is at an inflection point in its history. Application architectures are changing. The traditional model that the Servlet era APIs were designed for is becoming valid for fewer and fewer cases. Mobile and Rich web apps are driving this revolution. Grails is not the only framework that will need to adapt to this new world. Every current popular web framework is going to have to make changes to support new architectural styles.

Here, Rocher is redefining Grails to mean something more than what it currently bundles, namely, an MVC framework around Spring, Tomcat, and Hibernate.

Unlike many frameworks that only provide the View/Controller layer, Grails provides significant amounts of value beyond serving up GSP views. Grails is one of the few proven “full stack” environments used to build real world applications and adopted by thousands of developers world wide. They adopt it because it provides the out-of-the-box experience developers seek, including a compelling plugin eco-system.

Many Grails plugins are not tied to any particular architectural style. Persistence is a key area, and GORM has evolved from being based on Hibernate into supporting NoSQL databases like MongoDB, Neo4j and Amazon DynamoDB.

By listing Hibernate as only one of many databases, Rocher is announcing its relegation from Grails core. Hibernate is controlled by JBoss, not SpringSource.

To adapt and evolve to this new world, Grails is going to have to change and that is why we are starting work on Grails 3.0 towards the 3rd quarter of this year. Grails 3.0 will be a reinvention of the framework that you love, and we will be making some hard decisions about what we support in terms of backwards compatibility. With Grails 3.0 we plan to allow the creation of applications in different architectural styles. Servlet API applications will always be supported, but we plan to make “create-app” extensible, so that Grails can be used to create a range of types of applications (Batch, NIO, Netty, “static void main” etc.).

Rocher says "will be making", but he's already made these hard decisions. Grails will be muscling in on the territory of IDE's.

This will involve splitting Grails out further into a more modular system. The default plugins installed for a Servlet applications will be different for those for a Batch or Netty application. Packaging types will differ (WAR vs JAR vs ?). Even the set of command line commands you get at build time will differ based on the type of application you want to create.

Hibernate will be relegated to a plugin module because it isn't SpringSource-controlled. And will enabling servlet apps be actively developed anymore or left to stagnate?

All of this will require refactoring and changes to our current build system (a shift to Gradle) and significant extensions to the plugin API. However, I believe we can make Grails applicable to a range of new use cases and create compelling environments that our users enjoy.

Right now in Grails 2.3 we are laying some of the ground work for Grails 3.0 by making available APIs and tools that will be applicable in Grails 3.0 as well (The async and eventing APIs, new REST APIs forked execution everywhere etc.). All in all, it is an exciting time to be working on Grails, and I look forward to feedback from the community on our current direction.

Rocher cynically elicits "feedback", but look how he responded to Alex Tkachman's "feedback" on Groovy's sloooooooooooooow dynamically-typed run times. He employed someone to launder the code.

vinay, a month ago − I feel grails 3 should be built on top of vert.x, which will give it async and clustering support and lot more.

29 May 2013

A GrȎŎvy Decade

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

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

Fake and Real Groovy

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

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 — Sat, 15 Jun 2013 07:34:58 GMT

Gavin Groovy Grover's UNICODE Blog

15 June 2013

Groovy's 100 roadmaps

----------------------------------------------------------------------

Last year on 21 June 2012, another solstice, the roadmap listed Groovy 3.0 as having a new MOP, an Antlr 4 grammar, and retrofitted Java 8 closures.

----------------------------------------------------------------------

On 27 June 2012, Jochen Theodorou updated the roadmap moving the new grammar to Groovy 4.0, adding the years 2013 to Groovy 3.0 and 2014 to Groovy 4.0. Perhaps he thought he could force some funds out of Rocher by subordinating the grammar rewrite to the MOP rewrite.

----------------------------------------------------------------------

On 27 Sep 2012, Laforge listed Groovy 2.1, adding it before Groovy 3.0, skuttling Theodorou's weak attempt at getting the new MOP green-lighted.

----------------------------------------------------------------------

The next major change happened 3 roadmaps later on 25 Jan 2013 when Laforge released Groovy 2.1, removing from the anticipated Groovy releases.

----------------------------------------------------------------------

2 roadmaps later on 6 Feb 2013, Laforge added Groovy 2.2 with release date mid 2013, again skuttling Theodorou's attempt to work on a new MOP, and changed the release date of Groovy 3.0 to end 2013.

----------------------------------------------------------------------

On 16 May 2013, a week before the Gr8te conference in Copenhagen, Laforge made further changes to show off his P.M. chops, being threatened by Rocher's power plays. He sniped at Theodorou, undoing his change from a year earlier, moving the Antlr 4 rewrite back to Groovy 3.0, and changed the Feature set labels to Feature set for consideration. Laforge also shunted the release dates for all pending releases: Groovy 2.2 from mid 2013 to Q3 2013, Groovy 3.0 from end 2013 to Q1 2014, and Groovy 4.0 from 2014 to Q1 2015.

What trick is Laforge going to make for the 100th version of the roadmap in what should really be a celebration?

8 June 2013

grOOvy goes wayward

The parts of grOOvy that developers find most praiseworthy are the those which were added in the first year of its life. Witness this comment yesterday by Clojure guru Stuart Holloway:

"I am finding Groovy to be a great way to show code to Java programmers -- collection literals, dynamic typing, and closures take most of the pain out of reading Java. Thanks to everyone who puts effort into making Groovy!"

All these features were mentioned in James Strachan's historic announcement almost 10 years ago:

"We're starting simple with the nice tuples, sequences, maps from python & closures from ruby and being concise & dynamically typed with a java-look-and-feel though where we end up is anyones guess right now."

6 months later, the spec was begun so many implementations of gr©Øvy would be built:

"its the EG's responsibility to make a great spec and a reference implementation and TCK. Its up to others to create different implementations if they want to. e.g. the Servlet / JSP / JSTL JSRs created RIs which many people still use today - but then vendors and other open source projects came along and tried to do better."

But on 6 Dec 2004, Guillaume Laforge took over, instituting the cathedral through a series of announcements such as:

"We don't grant CVS access to everyone. Groovy hackers need to show their abilities and enthousiasm by writing one or several patches for new features, or for fixing some bugs."

Grails Deception

Last month, Grails despot Graeme Rocher announced, using doublespeak, that Grails will become a distribution channel for SpringSource software only. To quote him, minus the fluff, with commentary...

Grails is at an inflection point in its history. Application architectures are changing. The traditional model that the Servlet era APIs were designed for is becoming valid for fewer and fewer cases. Mobile and Rich web apps are driving this revolution. Grails is not the only framework that will need to adapt to this new world. Every current popular web framework is going to have to make changes to support new architectural styles.

Here, Rocher is redefining Grails to mean something more than what it currently bundles, namely, an MVC framework around Spring, Tomcat, and Hibernate.

Unlike many frameworks that only provide the View/Controller layer, Grails provides significant amounts of value beyond serving up GSP views. Grails is one of the few proven “full stack” environments used to build real world applications and adopted by thousands of developers world wide. They adopt it because it provides the out-of-the-box experience developers seek, including a compelling plugin eco-system.

Many Grails plugins are not tied to any particular architectural style. Persistence is a key area, and GORM has evolved from being based on Hibernate into supporting NoSQL databases like MongoDB, Neo4j and Amazon DynamoDB.

By listing Hibernate as only one of many databases, Rocher is announcing its relegation from Grails core. Hibernate is controlled by JBoss, not SpringSource.

To adapt and evolve to this new world, Grails is going to have to change and that is why we are starting work on Grails 3.0 towards the 3rd quarter of this year. Grails 3.0 will be a reinvention of the framework that you love, and we will be making some hard decisions about what we support in terms of backwards compatibility. With Grails 3.0 we plan to allow the creation of applications in different architectural styles. Servlet API applications will always be supported, but we plan to make “create-app” extensible, so that Grails can be used to create a range of types of applications (Batch, NIO, Netty, “static void main” etc.).

Rocher says "will be making", but he's already made these hard decisions. Grails will be muscling in on the territory of IDE's.

This will involve splitting Grails out further into a more modular system. The default plugins installed for a Servlet applications will be different for those for a Batch or Netty application. Packaging types will differ (WAR vs JAR vs ?). Even the set of command line commands you get at build time will differ based on the type of application you want to create.

Hibernate will be relegated to a plugin module because it isn't SpringSource-controlled. And will enabling servlet apps be actively developed anymore or left to stagnate?

All of this will require refactoring and changes to our current build system (a shift to Gradle) and significant extensions to the plugin API. However, I believe we can make Grails applicable to a range of new use cases and create compelling environments that our users enjoy.

Right now in Grails 2.3 we are laying some of the ground work for Grails 3.0 by making available APIs and tools that will be applicable in Grails 3.0 as well (The async and eventing APIs, new REST APIs forked execution everywhere etc.). All in all, it is an exciting time to be working on Grails, and I look forward to feedback from the community on our current direction.

Rocher cynically elicits "feedback", but look how he responded to Alex Tkachman's "feedback" on Groovy's sloooooooooooooow dynamically-typed run times. He employed someone to launder the code.

vinay, a month ago − I feel grails 3 should be built on top of vert.x, which will give it async and clustering support and lot more.

29 May 2013

A GrȎŎvy Decade

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

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

Fake and Real Groovy

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

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 — Sat, 15 Jun 2013 07:32:40 GMT

Gavin Groovy Grover's UNICODE Blog

15 June 2013

Groovy's 100 roadmaps

--------------------------------------------------------------------------------

Last year on 21 June 2012, another solstice, the roadmap listed Groovy 3.0 as having a new MOP, an Antlr 4 grammar, and retrofitted Java 8 closures.

--------------------------------------------------------------------------------

On 27 June 2012, Jochen Theodorou updated the roadmap moving the new grammar to Groovy 4.0, adding the years 2013 to Groovy 3.0 and 2014 to Groovy 4.0. Perhaps he thought he could force some funds out of Rocher by subordinating the grammar rewrite to the MOP rewrite.

--------------------------------------------------------------------------------

On 27 Sep 2012, Laforge listed Groovy 2.1, adding it before Groovy 3.0, skuttling Theodorou's weak attempt at getting the new MOP green-lighted.

--------------------------------------------------------------------------------

The next major change happened 3 roadmaps later on 25 Jan 2013 when Laforge released Groovy 2.1, removing from the anticipated Groovy releases.

--------------------------------------------------------------------------------

2 roadmaps later on 6 Feb 2013, Laforge added Groovy 2.2 with release date mid 2013, again skuttling Theodorou's attempt to work on a new MOP, and changed the release date of Groovy 3.0 to end 2013.

--------------------------------------------------------------------------------

On 16 May 2013, a week before the Gr8te conference in Copenhagen, Laforge made further changes to show off his P.M. chops, being threatened by Rocher's power plays. He sniped at Theodorou, undoing his change from a year earlier, moving the Antlr 4 rewrite back to Groovy 3.0, and changed the Feature set labels to Feature set for consideration. Laforge also shunted the release dates for all pending releases: Groovy 2.2 from mid 2013 to Q3 2013, Groovy 3.0 from end 2013 to Q1 2014, and Groovy 4.0 from 2014 to Q1 2015.

What trick is Laforge going to make for the 100th version of the roadmap in what should really be a celebration?

8 June 2013

grOOvy goes wayward

The parts of grOOvy that developers find most praiseworthy are the those which were added in the first year of its life. Witness this comment yesterday by Clojure guru Stuart Holloway:

"I am finding Groovy to be a great way to show code to Java programmers -- collection literals, dynamic typing, and closures take most of the pain out of reading Java. Thanks to everyone who puts effort into making Groovy!"

All these features were mentioned in James Strachan's historic announcement almost 10 years ago:

"We're starting simple with the nice tuples, sequences, maps from python & closures from ruby and being concise & dynamically typed with a java-look-and-feel though where we end up is anyones guess right now."

6 months later, the spec was begun so many implementations of gr©Øvy would be built:

"its the EG's responsibility to make a great spec and a reference implementation and TCK. Its up to others to create different implementations if they want to. e.g. the Servlet / JSP / JSTL JSRs created RIs which many people still use today - but then vendors and other open source projects came along and tried to do better."

But on 6 Dec 2004, Guillaume Laforge took over, instituting the cathedral through a series of announcements such as:

"We don't grant CVS access to everyone. Groovy hackers need to show their abilities and enthousiasm by writing one or several patches for new features, or for fixing some bugs."

Grails Deception

Last month, Grails despot Graeme Rocher announced, using doublespeak, that Grails will become a distribution channel for SpringSource software only. To quote him, minus the fluff, with commentary...

Grails is at an inflection point in its history. Application architectures are changing. The traditional model that the Servlet era APIs were designed for is becoming valid for fewer and fewer cases. Mobile and Rich web apps are driving this revolution. Grails is not the only framework that will need to adapt to this new world. Every current popular web framework is going to have to make changes to support new architectural styles.

Here, Rocher is redefining Grails to mean something more than what it currently bundles, namely, an MVC framework around Spring, Tomcat, and Hibernate.

Unlike many frameworks that only provide the View/Controller layer, Grails provides significant amounts of value beyond serving up GSP views. Grails is one of the few proven “full stack” environments used to build real world applications and adopted by thousands of developers world wide. They adopt it because it provides the out-of-the-box experience developers seek, including a compelling plugin eco-system.

Many Grails plugins are not tied to any particular architectural style. Persistence is a key area, and GORM has evolved from being based on Hibernate into supporting NoSQL databases like MongoDB, Neo4j and Amazon DynamoDB.

By listing Hibernate as only one of many databases, Rocher is announcing its relegation from Grails core. Hibernate is controlled by JBoss, not SpringSource.

To adapt and evolve to this new world, Grails is going to have to change and that is why we are starting work on Grails 3.0 towards the 3rd quarter of this year. Grails 3.0 will be a reinvention of the framework that you love, and we will be making some hard decisions about what we support in terms of backwards compatibility. With Grails 3.0 we plan to allow the creation of applications in different architectural styles. Servlet API applications will always be supported, but we plan to make “create-app” extensible, so that Grails can be used to create a range of types of applications (Batch, NIO, Netty, “static void main” etc.).

Rocher says "will be making", but he's already made these hard decisions. Grails will be muscling in on the territory of IDE's.

This will involve splitting Grails out further into a more modular system. The default plugins installed for a Servlet applications will be different for those for a Batch or Netty application. Packaging types will differ (WAR vs JAR vs ?). Even the set of command line commands you get at build time will differ based on the type of application you want to create.

Hibernate will be relegated to a plugin module because it isn't SpringSource-controlled. And will enabling servlet apps be actively developed anymore or left to stagnate?

All of this will require refactoring and changes to our current build system (a shift to Gradle) and significant extensions to the plugin API. However, I believe we can make Grails applicable to a range of new use cases and create compelling environments that our users enjoy.

Right now in Grails 2.3 we are laying some of the ground work for Grails 3.0 by making available APIs and tools that will be applicable in Grails 3.0 as well (The async and eventing APIs, new REST APIs forked execution everywhere etc.). All in all, it is an exciting time to be working on Grails, and I look forward to feedback from the community on our current direction.

Rocher cynically elicits "feedback", but look how he responded to Alex Tkachman's "feedback" on Groovy's sloooooooooooooow dynamically-typed run times. He employed someone to launder the code.

vinay, a month ago − I feel grails 3 should be built on top of vert.x, which will give it async and clustering support and lot more.

29 May 2013

A GrȎŎvy Decade

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

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

Fake and Real Groovy

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

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 — Sat, 15 Jun 2013 07:29:32 GMT

Gavin Groovy Grover's UNICODE Blog

15 June 2013

Groovy's 100 roadmaps

Last year on 21 June 2012, another solstice, the roadmap listed Groovy 3.0 as having a new MOP, an Antlr 4 grammar, and retrofitted Java 8 closures.

On 27 Sep 2012, Laforge listed Groovy 2.1, adding it before Groovy 3.0, skuttling Theodorou's weak attempt at getting the new MOP green-lighted.

The next major change happened 3 roadmaps later on 25 Jan 2013 when Laforge released Groovy 2.1, removing from the anticipated Groovy releases.

grOOvy goes wayward

The parts of grOOvy that developers find most praiseworthy are the those which were added in the first year of its life. Witness this comment yesterday by Clojure guru Stuart Holloway:

"I am finding Groovy to be a great way to show code to Java programmers -- collection literals, dynamic typing, and closures take most of the pain out of reading Java. Thanks to everyone who puts effort into making Groovy!"

All these features were mentioned in James Strachan's historic announcement almost 10 years ago:

"We're starting simple with the nice tuples, sequences, maps from python & closures from ruby and being concise & dynamically typed with a java-look-and-feel though where we end up is anyones guess right now."

6 months later, the spec was begun so many implementations of gr©Øvy would be built:

"its the EG's responsibility to make a great spec and a reference implementation and TCK. Its up to others to create different implementations if they want to. e.g. the Servlet / JSP / JSTL JSRs created RIs which many people still use today - but then vendors and other open source projects came along and tried to do better."

But on 6 Dec 2004, Guillaume Laforge took over, instituting the cathedral through a series of announcements such as:

"We don't grant CVS access to everyone. Groovy hackers need to show their abilities and enthousiasm by writing one or several patches for new features, or for fixing some bugs."

Grails Deception

Last month, Grails despot Graeme Rocher announced, using doublespeak, that Grails will become a distribution channel for SpringSource software only. To quote him, minus the fluff, with commentary...

Grails is at an inflection point in its history. Application architectures are changing. The traditional model that the Servlet era APIs were designed for is becoming valid for fewer and fewer cases. Mobile and Rich web apps are driving this revolution. Grails is not the only framework that will need to adapt to this new world. Every current popular web framework is going to have to make changes to support new architectural styles.

Here, Rocher is redefining Grails to mean something more than what it currently bundles, namely, an MVC framework around Spring, Tomcat, and Hibernate.

Unlike many frameworks that only provide the View/Controller layer, Grails provides significant amounts of value beyond serving up GSP views. Grails is one of the few proven “full stack” environments used to build real world applications and adopted by thousands of developers world wide. They adopt it because it provides the out-of-the-box experience developers seek, including a compelling plugin eco-system.

Many Grails plugins are not tied to any particular architectural style. Persistence is a key area, and GORM has evolved from being based on Hibernate into supporting NoSQL databases like MongoDB, Neo4j and Amazon DynamoDB.

By listing Hibernate as only one of many databases, Rocher is announcing its relegation from Grails core. Hibernate is controlled by JBoss, not SpringSource.

To adapt and evolve to this new world, Grails is going to have to change and that is why we are starting work on Grails 3.0 towards the 3rd quarter of this year. Grails 3.0 will be a reinvention of the framework that you love, and we will be making some hard decisions about what we support in terms of backwards compatibility. With Grails 3.0 we plan to allow the creation of applications in different architectural styles. Servlet API applications will always be supported, but we plan to make “create-app” extensible, so that Grails can be used to create a range of types of applications (Batch, NIO, Netty, “static void main” etc.).

Rocher says "will be making", but he's already made these hard decisions. Grails will be muscling in on the territory of IDE's.

This will involve splitting Grails out further into a more modular system. The default plugins installed for a Servlet applications will be different for those for a Batch or Netty application. Packaging types will differ (WAR vs JAR vs ?). Even the set of command line commands you get at build time will differ based on the type of application you want to create.

Hibernate will be relegated to a plugin module because it isn't SpringSource-controlled. And will enabling servlet apps be actively developed anymore or left to stagnate?

All of this will require refactoring and changes to our current build system (a shift to Gradle) and significant extensions to the plugin API. However, I believe we can make Grails applicable to a range of new use cases and create compelling environments that our users enjoy.

Right now in Grails 2.3 we are laying some of the ground work for Grails 3.0 by making available APIs and tools that will be applicable in Grails 3.0 as well (The async and eventing APIs, new REST APIs forked execution everywhere etc.). All in all, it is an exciting time to be working on Grails, and I look forward to feedback from the community on our current direction.

Rocher cynically elicits "feedback", but look how he responded to Alex Tkachman's "feedback" on Groovy's sloooooooooooooow dynamically-typed run times. He employed someone to launder the code.

vinay, a month ago − I feel grails 3 should be built on top of vert.x, which will give it async and clustering support and lot more.

29 May 2013

A GrȎŎvy Decade

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

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

Fake and Real Groovy

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

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 — Fri, 07 Jun 2013 22:53:58 GMT

Gavin Groovy Grover's UNICODE Blog

8 June 2013

grOOvy goes wayward

The parts of grOOvy that developers find most praiseworthy are the those which were added in the first year of its life. Witness this comment yesterday by Clojure guru Stuart Holloway:

"I am finding Groovy to be a great way to show code to Java programmers -- collection literals, dynamic typing, and closures take most of the pain out of reading Java. Thanks to everyone who puts effort into making Groovy!"

All these features were mentioned in James Strachan's historic announcement almost 10 years ago:

"We're starting simple with the nice tuples, sequences, maps from python & closures from ruby and being concise & dynamically typed with a java-look-and-feel though where we end up is anyones guess right now."

6 months later, the spec was begun so many implementations of gr©Øvy would be built:

"its the EG's responsibility to make a great spec and a reference implementation and TCK. Its up to others to create different implementations if they want to. e.g. the Servlet / JSP / JSTL JSRs created RIs which many people still use today - but then vendors and other open source projects came along and tried to do better."

But on 6 Dec 2004, Guillaume Laforge took over, instituting the cathedral through a series of announcements such as:

"We don't grant CVS access to everyone. Groovy hackers need to show their abilities and enthousiasm by writing one or several patches for new features, or for fixing some bugs."

Grails Deception

Last month, Grails despot Graeme Rocher announced, using doublespeak, that Grails will become a distribution channel for SpringSource software only. To quote him, minus the fluff, with commentary...

Grails is at an inflection point in its history. Application architectures are changing. The traditional model that the Servlet era APIs were designed for is becoming valid for fewer and fewer cases. Mobile and Rich web apps are driving this revolution. Grails is not the only framework that will need to adapt to this new world. Every current popular web framework is going to have to make changes to support new architectural styles.

Here, Rocher is redefining Grails to mean something more than what it currently bundles, namely, an MVC framework around Spring, Tomcat, and Hibernate.

Unlike many frameworks that only provide the View/Controller layer, Grails provides significant amounts of value beyond serving up GSP views. Grails is one of the few proven “full stack” environments used to build real world applications and adopted by thousands of developers world wide. They adopt it because it provides the out-of-the-box experience developers seek, including a compelling plugin eco-system.

Many Grails plugins are not tied to any particular architectural style. Persistence is a key area, and GORM has evolved from being based on Hibernate into supporting NoSQL databases like MongoDB, Neo4j and Amazon DynamoDB.

By listing Hibernate as only one of many databases, Rocher is announcing its relegation from Grails core. Hibernate is controlled by JBoss, not SpringSource.

To adapt and evolve to this new world, Grails is going to have to change and that is why we are starting work on Grails 3.0 towards the 3rd quarter of this year. Grails 3.0 will be a reinvention of the framework that you love, and we will be making some hard decisions about what we support in terms of backwards compatibility. With Grails 3.0 we plan to allow the creation of applications in different architectural styles. Servlet API applications will always be supported, but we plan to make “create-app” extensible, so that Grails can be used to create a range of types of applications (Batch, NIO, Netty, “static void main” etc.).

Rocher says "will be making", but he's already made these hard decisions. Grails will be muscling in on the territory of IDE's.

This will involve splitting Grails out further into a more modular system. The default plugins installed for a Servlet applications will be different for those for a Batch or Netty application. Packaging types will differ (WAR vs JAR vs ?). Even the set of command line commands you get at build time will differ based on the type of application you want to create.

Hibernate will be relegated to a plugin module because it isn't SpringSource-controlled. And will enabling servlet apps be actively developed anymore or left to stagnate?

All of this will require refactoring and changes to our current build system (a shift to Gradle) and significant extensions to the plugin API. However, I believe we can make Grails applicable to a range of new use cases and create compelling environments that our users enjoy.

Right now in Grails 2.3 we are laying some of the ground work for Grails 3.0 by making available APIs and tools that will be applicable in Grails 3.0 as well (The async and eventing APIs, new REST APIs forked execution everywhere etc.). All in all, it is an exciting time to be working on Grails, and I look forward to feedback from the community on our current direction.

Rocher cynically elicits "feedback", but look how he responded to Alex Tkachman's "feedback" on Groovy's sloooooooooooooow dynamically-typed run times. He employed someone to launder the code.

vinay, a month ago − I feel grails 3 should be built on top of vert.x, which will give it async and clustering support and lot more.

29 May 2013

A GrȎŎvy Decade

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

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

Fake and Real Groovy

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

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 — Fri, 07 Jun 2013 22:53:26 GMT

Gavin Groovy Grover's UNICODE Blog

8 June 2013

grOOvy goes wayward

The parts of grOOvy that developers find most praiseworthy are the those which were added in the first year of its life. Witness this comment yesterday by Clojure guru Stuart Holloway:

"I am finding Groovy to be a great way to show code to Java programmers -- collection literals, dynamic typing, and closures take most of the pain out of reading Java. Thanks to everyone who puts effort into making Groovy!"

All these features were mentioned in James Strachan's historic announcement almost 10 years ago:

"We're starting simple with the nice tuples, sequences, maps from python & closures from ruby and being concise & dynamically typed with a java-look-and-feel though where we end up is anyones guess right now."

6 months later, the spec was begun so many implementations of gr©Øvy would be built:

"its the EG's responsibility to make a great spec and a reference implementation and TCK. Its up to others to create different implementations if they want to. e.g. the Servlet / JSP / JSTL JSRs created RIs which many people still use today - but then vendors and other open source projects came along and tried to do better."

But on 6 Dec 2004, Guillaume Laforge took over, instituting the cathedral through a series of announcements such as:

"We don't grant CVS access to everyone. Groovy hackers need to show their abilities and enthousiasm by writing one or several patches for new features, or for fixing some bugs."

Grails Deception

Last month, Grails despot Graeme Rocher announced, using doublespeak, that Grails will become a distribution channel for SpringSource software only. To quote him, minus the fluff, with commentary...

Grails is at an inflection point in its history. Application architectures are changing. The traditional model that the Servlet era APIs were designed for is becoming valid for fewer and fewer cases. Mobile and Rich web apps are driving this revolution. Grails is not the only framework that will need to adapt to this new world. Every current popular web framework is going to have to make changes to support new architectural styles.

Here, Rocher is redefining Grails to mean something more than what it currently bundles, namely, an MVC framework around Spring, Tomcat, and Hibernate.

Unlike many frameworks that only provide the View/Controller layer, Grails provides significant amounts of value beyond serving up GSP views. Grails is one of the few proven “full stack” environments used to build real world applications and adopted by thousands of developers world wide. They adopt it because it provides the out-of-the-box experience developers seek, including a compelling plugin eco-system.

Many Grails plugins are not tied to any particular architectural style. Persistence is a key area, and GORM has evolved from being based on Hibernate into supporting NoSQL databases like MongoDB, Neo4j and Amazon DynamoDB.

By listing Hibernate as only one of many databases, Rocher is announcing its relegation from Grails core. Hibernate is controlled by JBoss, not SpringSource.

To adapt and evolve to this new world, Grails is going to have to change and that is why we are starting work on Grails 3.0 towards the 3rd quarter of this year. Grails 3.0 will be a reinvention of the framework that you love, and we will be making some hard decisions about what we support in terms of backwards compatibility. With Grails 3.0 we plan to allow the creation of applications in different architectural styles. Servlet API applications will always be supported, but we plan to make “create-app” extensible, so that Grails can be used to create a range of types of applications (Batch, NIO, Netty, “static void main” etc.).

Rocher says "will be making", but he's already made these hard decisions. Grails will be muscling in on the territory of IDE's.

This will involve splitting Grails out further into a more modular system. The default plugins installed for a Servlet applications will be different for those for a Batch or Netty application. Packaging types will differ (WAR vs JAR vs ?). Even the set of command line commands you get at build time will differ based on the type of application you want to create.

Hibernate will be relegated to a plugin module because it isn't SpringSource-controlled. And will enabling servlet apps be actively developed anymore or left to stagnate?

All of this will require refactoring and changes to our current build system (a shift to Gradle) and significant extensions to the plugin API. However, I believe we can make Grails applicable to a range of new use cases and create compelling environments that our users enjoy.

Right now in Grails 2.3 we are laying some of the ground work for Grails 3.0 by making available APIs and tools that will be applicable in Grails 3.0 as well (The async and eventing APIs, new REST APIs forked execution everywhere etc.). All in all, it is an exciting time to be working on Grails, and I look forward to feedback from the community on our current direction.

Rocher cynically elicits "feedback", but look how he responded to Alex Tkachman's "feedback" on Groovy's sloooooooooooooow dynamically-typed run times. He employed someone to launder the code.

vinay, a month ago − I feel grails 3 should be built on top of vert.x, which will give it async and clustering support and lot more.

29 May 2013

A GrȎŎvy Decade

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

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

Fake and Real Groovy

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

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 — Tue, 04 Jun 2013 00:35:05 GMT

Gavin Groovy Grover's UNICODE Blog

4 June 2013

Grails Deception

Last month, Grails despot Graeme Rocher announced, using doublespeak, that Grails will become a distribution channel for SpringSource software only. To quote him, minus the fluff, with commentary...

Grails is at an inflection point in its history. Application architectures are changing. The traditional model that the Servlet era APIs were designed for is becoming valid for fewer and fewer cases. Mobile and Rich web apps are driving this revolution. Grails is not the only framework that will need to adapt to this new world. Every current popular web framework is going to have to make changes to support new architectural styles.

Here, Rocher is redefining Grails to mean something more than what it currently bundles, namely, an MVC framework around Spring, Tomcat, and Hibernate.

Unlike many frameworks that only provide the View/Controller layer, Grails provides significant amounts of value beyond serving up GSP views. Grails is one of the few proven “full stack” environments used to build real world applications and adopted by thousands of developers world wide. They adopt it because it provides the out-of-the-box experience developers seek, including a compelling plugin eco-system.

Many Grails plugins are not tied to any particular architectural style. Persistence is a key area, and GORM has evolved from being based on Hibernate into supporting NoSQL databases like MongoDB, Neo4j and Amazon DynamoDB.

By listing Hibernate as only one of many databases, Rocher is announcing its relegation from Grails core. Hibernate is controlled by JBoss, not SpringSource.

To adapt and evolve to this new world, Grails is going to have to change and that is why we are starting work on Grails 3.0 towards the 3rd quarter of this year. Grails 3.0 will be a reinvention of the framework that you love, and we will be making some hard decisions about what we support in terms of backwards compatibility. With Grails 3.0 we plan to allow the creation of applications in different architectural styles. Servlet API applications will always be supported, but we plan to make “create-app” extensible, so that Grails can be used to create a range of types of applications (Batch, NIO, Netty, “static void main” etc.).

Rocher says "will be making", but he's already made these hard decisions. Grails will be muscling in on the territory of IDE's.

This will involve splitting Grails out further into a more modular system. The default plugins installed for a Servlet applications will be different for those for a Batch or Netty application. Packaging types will differ (WAR vs JAR vs ?). Even the set of command line commands you get at build time will differ based on the type of application you want to create.

Hibernate will be relegated to a plugin module because it isn't SpringSource-controlled. And will enabling servlet apps be actively developed anymore or left to stagnate?

All of this will require refactoring and changes to our current build system (a shift to Gradle) and significant extensions to the plugin API. However, I believe we can make Grails applicable to a range of new use cases and create compelling environments that our users enjoy.

Right now in Grails 2.3 we are laying some of the ground work for Grails 3.0 by making available APIs and tools that will be applicable in Grails 3.0 as well (The async and eventing APIs, new REST APIs forked execution everywhere etc.). All in all, it is an exciting time to be working on Grails, and I look forward to feedback from the community on our current direction.

Rocher cynically elicits "feedback", but look how he responded to Alex Tkachman's "feedback" on Groovy's sloooooooooooooow dynamically-typed run times. He employed someone to launder the code.

vinay, a month ago − I feel grails 3 should be built on top of vert.x, which will give it async and clustering support and lot more.

29 May 2013

A GrȎŎvy Decade

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

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

Fake and Real Groovy

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

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 — Tue, 04 Jun 2013 00:31:35 GMT

Gavin Groovy Grover's UNICODE Blog

4 June 2013

Grails Deception

Last month, Grails despot Graeme Rocher announced, using doublespeak, that Grails will become a distribution channel for SpringSource software only. To quote him, minus the fluff, with commentary...

Grails is at an inflection point in its history. Application architectures are changing. The traditional model that the Servlet era APIs were designed for is becoming valid for fewer and fewer cases. Mobile and Rich web apps are driving this revolution. Grails is not the only framework that will need to adapt to this new world. Every current popular web framework is going to have to make changes to support new architectural styles.

Here, Rocher is redefining Grails to mean something more than what it currently bundles, namely, an MVC framework around Spring, Tomcat, and Hibernate.

Unlike many frameworks that only provide the View/Controller layer, Grails provides significant amounts of value beyond serving up GSP views. Grails is one of the few proven “full stack” environments used to build real world applications and adopted by thousands of developers world wide. They adopt it because it provides the out-of-the-box experience developers seek, including a compelling plugin eco-system.

Many Grails plugins are not tied to any particular architectural style. Persistence is a key area, and GORM has evolved from being based on Hibernate into supporting NoSQL databases like MongoDB, Neo4j and Amazon DynamoDB.

By listing Hibernate as only one of many databases, Rocher is announcing its relegation from Grails core. Hibernate is controlled by JBoss, not SpringSource.

To adapt and evolve to this new world, Grails is going to have to change and that is why we are starting work on Grails 3.0 towards the 3rd quarter of this year. Grails 3.0 will be a reinvention of the framework that you love, and we will be making some hard decisions about what we support in terms of backwards compatibility. With Grails 3.0 we plan to allow the creation of applications in different architectural styles. Servlet API applications will always be supported, but we plan to make “create-app” extensible, so that Grails can be used to create a range of types of applications (Batch, NIO, Netty, “static void main” etc.).

Rocher says "will be making", but he's already made these hard decisions. Grails will be muscling in on the territory of IDE's.

This will involve splitting Grails out further into a more modular system. The default plugins installed for a Servlet applications will be different for those for a Batch or Netty application. Packaging types will differ (WAR vs JAR vs ?). Even the set of command line commands you get at build time will differ based on the type of application you want to create.

Hibernate will be relegated to a plugin module because it isn't SpringSource-controlled. And will enabling servlet apps be actively developed anymore or left to stagnate?

All of this will require refactoring and changes to our current build system (a shift to Gradle) and significant extensions to the plugin API. However, I believe we can make Grails applicable to a range of new use cases and create compelling environments that our users enjoy.

Right now in Grails 2.3 we are laying some of the ground work for Grails 3.0 by making available APIs and tools that will be applicable in Grails 3.0 as well (The async and eventing APIs, new REST APIs forked execution everywhere etc.). All in all, it is an exciting time to be working on Grails, and I look forward to feedback from the community on our current direction.

Rocher cynically elicits "feedback", but look how he responded to Alex Tkachman's "feedback" on Groovy's sloooooooooooooow dynamically-typed run times. He employed someone to launder the code.

vinay, a month ago − I feel grails 3 should be built on top of vert.x, which will give it async and clustering support and lot more.

There's no vinay on the Grails mailing list. This top comment must be Rocher, saying he's already decided to bundle Vert.X in Grails 3. Vert.X is SpringSource-controlled, having been stolen from creator Tim Fox last Christmas vacation.

In this blog entry, Rocher presents some falacious reasoning about why Grails 3 will drop Hibernate and add Vert.X in its core distribution. But he's really just spinning a cover story for turning Grails into a distribution channel for SpringSource software only (primarily Groovy, Spring, Tomcat, and Vert.X), while dropping everything significant not controlled by SpringSource (e.g. Hibernate). But embracing all of SpringSource's product offerings, he's pitching for a higher rung on the corporate ladder and a bigger cut when SpringSource is sold to Oracle later on.

Do you really believe someone who spins stories so callously to his customers wouldn't also run a smear campaign against perceived threats through intermediaries or use virus-based online surveillance? His claims of being stalked sound hollow next to the bare-faced lies on his blog.

29 May 2013

A GrȎŎvy Decade

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

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

Fake and Real Groovy

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

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 — Wed, 29 May 2013 13:42:58 GMT

Gavin Groovy Grover's UNICODE Blog

29 May 2013

A GrȎŎvy Decade

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

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

Fake and Real Groovy

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

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 Release: DEPRECATED - use Grojure Language instead (May 19, 2013)

gavingrover — Fri, 24 May 2013 14:06:11 GMT

Dud download to indicate this site is deprecated in favor of the Grojure Language.

Released: DEPRECATED - use Grojure Language instead (May 19, 2013)

Fri, 24 May 2013 14:06:11 GMT

Dud download to indicate this site is deprecated in favor of the Grojure Language.

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

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

Fake and Real Groovy

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

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

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.

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!

Created Release: DEPRECATED - use Grojure Programming Language (May 19, 2013)

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

Dud download to indicate this site is deprecated in favor of Grojure Programming Language.

Released: DEPRECATED - use Grojure Programming Language (May 19, 2013)

Sun, 19 May 2013 02:54:44 GMT

Dud download to indicate this site is deprecated in favor of Grojure Programming Language.