Gavin Grover's GROOVY Wikiblog

See later entries

Page 5 Contents

May 2016

GrȌŐvy Timeline Updated

(duplicated from entry at gavingroovygrover.tumblr.com)

My official and personal history of Groovy diagram (below) has been updated, incorporating what’s happened over the past 3 years. Of note are:
  • Laforge seizes control of Groovy for the JVM from his co-despots, buying the groovy-lang.org domain to replace Groovy at Codehaus, and setting up his own personal user mailing list
  • VMware retrenches its Groovy and Grails staff, with Groovy then using Apache to keep up the appearance of community control
  • The Groovist Manifesto is issued, so Groovy will only be worked on by its technical people, is not influenced by software bundling it, and becomes standardized
  • Apache Groovy maintains its “popularity” by plugging its non-Turing Complete use for 10-liners in Gradle and Android build scripts
  • Grolang for the Go platform is launched, featuring Kanji for Go keywords and special identifiers (currently in Qu), and slots for over 1 million Unicode codepoints (currently in UTF-88)

groovy timelines.jpg

26 June 2013

GrȌŐvy Timeline

As part of my series on Grȍővy's history in the leadup to its 10th birthday, I've finished off my earlier timeline diagram by adding my own personal involvement in Grȍővy (see it just below). It's now easy to delineate the first two eras of Grȍővy, as well as predict the third...

1. Strachan Era

In August 2003, James Strachan announced Grȍővy. He passed the baton on in small steps, first by letting Guillaume Laforge take over as publicity lead and Jochen Theodorou as technical lead after JSR-241 was voted in in April 2004, then by withdrawing after DevCon2 in December 2005, then finally by renouncing his involvement in Grȍővy in July 2009. From announce to renounce was 6 years, a time for Grȍővy's growth.

2. Tkachman Era

After Grȍővy 1.6 enabled addins via AST transforms, in mid 2009 Alex Tkachman began building Grȍővy++, a booster addin for statically compiling Grȍővy code. In late 2011, SpringSource employed Cedric Champeau to launder most of the code and release it as Grȍővy 2.0 in mid 2012. In mid 2013, Champeau began laundering the remainder of Grȍővy++, its Traits, for release as Grȍővy 2.2. This story arc has continued for 4 years so far, and may continue for 1 or 2 more before Grȍővy's imminent death becomes apparent to all.

3. Grover Era

Then my reboot of Grȍővy will come alive, bringing all Unicode tokens to the language, enabling terser expression of ideas in a groovy syntax. Presently at version 0.9.0, Grojure, built atop Clojure, will be the core of this language, with Unicode being integrated at a conceptual level into the language syntax. The Grover era of Grȍővy will eclipse the Strachan and Tkachman eras, enabling Grȍővy to achieve its destiny of serving the entire world, whatever a programmer's native language.


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.


Post removed because it'll be superceded soon by a summary of wikiblog contents on main page


21 June 2013

Groovy's Laundry

Laforge didn't take long to spin his new trick for the Groovy Roadmap as predicted in my previous blog entry a week ago. He's just announced they're adding statically-typed traits to Groovy.

Laforge added Static traits or mixins to the roadmap for Groovy 2.2 (see screenshot in previous blog entry below) on 6 February 2013, the day after Andrew Binstock published The Groovy Conundrum, a scathing review of Groovy's documentation.

But these Traits have already been implemented 2 years ago in Groovy++ by its former developer Alex Tkachman. When Groovy added static compilation 1 year ago, they employed Champeau to copy it straight from Tkachman's Groovy++ codebase, then announced it to the world as "Groovy 2.0" without any credit. Now they're doing the same trick again, getting Champeau to launder the Groovy++ Traits and pass it all off as "Groovy 2.2".

So it seems within 24 hours of the scathing Dr Dobbs analysis, Laforge and Rocher had conspired to:
  • indefinitely delay the MOP rewrite, Antlr grammar upgrade, and JDK8 lambda retrofit, and Jochen Theodorou still doesn't know he's been screwed
  • set up their intention to launder the remainder of Alex Tkachman's Groovy++ codebase later in the year to give the appearance of active development while actually doing as little as possible as late as possible

There is no longer any active development on Codehaus Groovy. Its only purpose is to sell consulting and conference seats. All Laforge does as project manager is make Groovy look like it's still alive, while all software development work goes into merging together Grails and VertX so they can similarly screw over contributors and customers alike with that one too.


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

roadmap 90.jpg
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.


roadmap 91.jpg
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.


roadmap 92.jpg
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.


roadmap 96.jpg
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.


roadmap 98.jpg
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".


roadmap 99.jpg
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?


Post removed because it's been superceded.


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.


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.



Post removed because it's been superceded.

See earlier entries

Last edited Oct 22, 2016 at 6:03 AM by gavingrover, version 28

Comments

No comments yet.