Groovy: Minimalism vs. Java-esque Verbosity

I’ve learned in my journey through life that it’s far easier to criticize than it is to critique. Criticism is adversarial while a critique is neutral. Misanthropic web sites like The Daily WTF use criticism as crass entertainment (I admit, I’ve had a chuckle or two there, but I’ve almost always felt guilty about it later) rather than as a tool to help improve the code base.

I am, however, still learning to make the distinction. When I posted Has JSR Derailed Groovy?, I intended it as critique. I had never heard of James Strachan until after I read his reply, but his defensive posture provoked a thought that maybe my tone was overly harsh.

I was relieved in a way, then, to read Mike Spille’s, Groovy Ambiguities, Optional Elements, and Syntax Shortcuts Considered Sucky. His cynical, spiteful tone makes my post look like love poetry. Mr. Strachan, I admire your thick skin.

Maybe it’s more “fun” to read as written but Mr. Spille’s venom overshadows his concerns, which were valid at the time (his post is dated 28-Mar-2004) and maybe are still. I agree ambiguities such as optional semi-colons, return statement, and vertical white space complicate the parser and increase defect probability. I disagree with Mr. Spille’s solutions but I won’t disparage him personally, as he does by labeling minimalists as “extremists,” among many other citable examples. Rather than imply Mr. Spille arguments are invalid because he consistently demonstrates his ignorance by misusing “alot,” which is not a word, I suggest he read Ken Arnold’s, Style is Substance, which elegantly proposes meaningful white space. (Did I just criticize in the guise of critique? 8-| )

Winnowing out his cynicism, Mr. Spille’s thesis is this: there are problems with the parser/compiler that should be solved by making Groovy syntax more Java-like. This is reasonable since a stated Groovy goal is to provide

an agile dynamic language for the Java 2 Platform that has many of the features that people like so much in languages like Python, Ruby and Smalltalk, making them available to Java developers using a Java-like syntax.

Therein lay one problem: a very likable feature of those languages is the conspicuous un-Java-like, concise syntax. Groovy’s goal contradicts itself. It is nearly impossible to suitably translate non-Java features (e.g. closures) into Java-like syntax since neither the feature nor the syntax currently exist in Java. Groovy is syntactically trailblazing.

Mr. Spille’s solution is to alter the syntax, partly to preserve Java-ness but mostly to simplify the compiler. He is apparently more concerned about the workings of the parser than the language it parses. Yes, ambiguity is a difficult problem but that doesn’t mean the language should shoulder the complexity vice the parser. The more problem-solving the parser does, the cleaner the syntax. I don’t want to have to tell the parser I’m starting a closure if it can determine that on its own. Call me a minimalist extremist if you will, but if I could write a functional web-based shopping cart with one keystroke, I’d do it.

Groovy Home

Has JSR Derailed Groovy?

The changes from Groovy beta-10 to the JSR release took me by surprise. I toyed with beta-10 Groovy earlier this year and found it promising. I had to put it down for awhile and when I picked it back up last week I downloaded the most recent version, JSR-03. I had no significant code base in beta-10 but I was curious about what had changed so I checked out the Migration from Classic to JSR page on the Groovy website. My initial reaction was, “Are you kidding me?” Since I tend to overreact at times, I made lists of changes that I liked, disliked, and didn’t understand. The latter may be due to the fact that I haven’t explored Groovy for very long. Here are my lists:

Like

Safe navigation. Looks clean and eliminates repetitive code and the ugly ‘->’. It shouldn’t be necessary (both println statements below should print ‘null,’ IMHO) but sometimes explicit declarations like this can avoid confusion (though I’m not convinced that should be a priority). As far as I know, there’s nothing like it in Ruby. Truly innovative?

s = null
println s.substring(0, 1)  // throws NullPointer
println s?.substring(0, 1) // prints null

Dislike (wow, that’s it for “Like?”)

Parameter separation in closure syntax. They co-opted that ‘->’ from safe navigation to separate parameters from the code in a closure. Yeah, really.

a {b | println b}  // classic
a {b -> println b} // JSR
a {|b| puts b}     // optional classic and Ruby style

I prefer the first classic syntax. In my mind, ‘->’ implies conversion or assignment.

Introduction of the ‘def’ keyword. Local variables now require ‘def.’ They are kidding right?

def foo() {
  int x = 123
  y = 456     // classic
  def y = 456 // JSR
}

Oh, and ‘def’ doesn’t apply to scripts “because those variables are automatically created in the script binding if they don’t already exist.” Nothing like a healthy dose of consistency.

Default level of class members. Previously the default was public, now it’s protected and requires ‘def’. It’s getting ugly.

class Foo {
  public a
  def b
}
z = new Foo(a:"Hello",b:"World")
println z.a
println z.b //errors in JSR

Let’s keep it simple, shall we?

class Foo {
  :a // public
  b  // private (default)
  #c // protected
}

JDK5 ‘for’ loop not supported. Well, it used to be and I wish they hadn’t removed it, although with closures, they could probably eliminate the ‘for’ altogether.

for (element : list) {…}  // classic
for (element in list) {…} // classic and JSR

Head scratchers

Property keyword. The property keyword was replaced with an annotation. I think I missed something. I couldn’t find an explanation for the property keyword or annotation anywhere on the Groovy site (that’s not to say it’s not there, just that I couldn’t find it). I assume @Property generates implicit accessors for public attributes but the same occurs for public and protected attributes.

I’m confused. Okay, maybe avoiding confusion should be a priority.

class Foo {
  property bar  // classic
  @Property bar // JSR
}

Exclusive range. I think someone over-engineered here.

range = 1…10      // classic
range = 1..<10    // JSR
range = 1..9      // hello?

I like Groovy. It runs in the JVM, offers closures, and includes some nice features like Markup, Regex, Sql, etc. But, doggone it, they’re mucking it up.

def botched = true

Groovy – Migrating From Classic to JSR syntax

How Do You Want Your Eggs?

Efficiency is king in the restaurant industry. A simple but effective technique to improve efficiency is to provide customers with numbered menu combinations. It works for a couple of reasons:

• It’s quicker to order #1 than to order two eggs, bacon, hash browns, and toast.
• Customers decide faster when a large, varied a la carte menu is condensed to fewer, simpler choices.

The sooner customers decide and order, the more customers the restaurant can serve in a given time.

Paradoxically, the two reasons are inversely related. For example, here’s the breakfast menu at the local Greasy Spoon:

A la carte
• Eggs
• Bacon
• Sausage
• Hash browns
• Toast

Not too complicated, but it’s better with the addition of combos:

Combos
1. Eggs, meat, hash browns, toast
2. Eggs, meat

A la carte
• Eggs
• Bacon
• Sausage
• Hash browns
• Toast

Efficient, isn’t it? Truckers will gobble up #1 and if you’re on a low carb diet, #2 is for you. Most customers won’t even look at the a la carte options. That’s the beauty of packaging options—it gives meaning to information.

But with combos, you can carry it too far.

Combos
1. Eggs (scrambled), meat, hash browns, toast
2. Eggs (sunny-side up), meat, hash browns, toast
3. Eggs (over easy), meat, hash browns, toast
4. Eggs (scrambled), meat
5. Eggs (sunny-side up), meat
6. Eggs (over easy), meat

There are now more combos than a la carte items without yet accounting for all the possible combinations of meat and toast.

Restaurants must find a suitable balance between the speed of combos and the advantages gained by keeping the number of combos to a minimum. A common solution is to let customers use the menu to choose a subset from a set and use the server to further refine the choice: “How do you want your eggs? Bacon or Sausage? White or Wheat?”

Why all this fuss about menus? IT customers know their options—they want high-quality, inexpensive software delivered in a timely manner. But they don’t understand these options are mutually exclusive. You can’t have your eggs scrambled and sunny-side up. So, I’ve posted this menu at the Java Bar & Grill:

Java Menu
1. Good, fast, !cheap
2. Cheap, good, !fast
3. Fast, cheap, !good

Customers can now order their software thus: “I’ll have an A/R package #1, please,” or “I’ll take a web-enabled warehousing system, #3.” If a yokel comes in and says, “Give me an online shopping cart, good, fast, and cheap,” I can say, “It ain’t on the menu, pal.”

The Universe is My Computer

Early in our pre-history, technology compensated for our pitiful vulnerabilities. As our survival as a species became less doubtful, we used technology to enrich our lives. All the while, technological development transformed the things around us to suit our needs. Soon, according to Ray Kurzweil, technology will transform us.

Kurzweil, in his new book, “The Singularity is Near,” contends that the imminent Singularity will be a “period during which the pace of technological change will be so rapid, its impact so deep, that human life will be irreversibly transformed.” This transformation is predicated by rearranging our environment.

…we’ll ultimately be able to convert most of the matter and energy in our area of the universe into very efficiently organized processes for running intelligence.
And then, this intelligence will expand outward, almost like information, but it will actually be able to essentially convert and absorb into itself all the matter and energy that it encounters as it continues to spread outward into the universe.
–The Technology of Universal Intelligence, Ray Kurzweil

Further, we will imprint the essence of who and what we are into this circuitry, thereby eradicating the distinction between Man and Machine.

This should give any thoughtful human being reason to pause. We have such a profound lack of knowledge about ourselves and our purpose that we cannot possibly understand the implications of such a metamorphosis. What makes us human is intangible to us. We can’t pinpoint that some thing about us that differentiates us from any other known form of life. We intuitively sense its presence and we label it “soul” or “sentience” or “spirit” but it remains amorphous.

We cannot, therefore, state with any certainty what it is we stand to lose in Kurzweil’s Singularity, but I for one would like to hold onto it.

KurzweilAI.net

The Technology of Universal Intelligence