Archive for November, 2005

h1

Selling Groovy to Luddite Tech Leads

November 20, 2005

On my current project, I refactored hard-coded data to a simple XML file similar to the following: 

<test>
<parent code="A">
<child>a</child>
<child>b</child>
</parent>
<parent code="B">
<child>b</child>
<child>c</child>
</parent>
</test>

Currently, we use Jakarta Commons Digester to parse XML. For this example, the code looks something like this: 

Digester d = new Digester();
d.push(new ArrayList());
d.addObjectCreate("test/parent", "test.Code");
d.addSetProperties("test/parent");
d.addSetNext("test/parent", "add", "java.lang.Object");
d.addObjectCreate("test/parent/child", "test.Code");
d.addSetNestedProperties("test/parent", "child", "code");
d.addSetNext("test/parent/child", "addChild", "test.Code");
List parent = (List) d.parse(new File("test.xml"));

If you’re already familiar with Digester, it may be apparent what’s going on. If not, you’ll have to do a little reading to determine what the Digester methods do.

So, I thought I’d simplify things with (gasp) Groovy: 

import org.codehaus.groovy.sandbox.util.XmlSlurper
import test.Code

class XmlLoader {
def List getCodes() {
 def list = new ArrayList()
 def xml = new XmlSlurper().parse(new File("test.xml"))
 xml.parent.each {
   def parent = new Code("code":it["@code"])
   it.child.each { parent.addChild(new Code("code":it)) }
   list.add(parent)
 }
 return list
}
}

Now, even if you don’t know Groovy, I daresay it’s easier to read the Groovy code than the Digester code.

I foresee these issues when trying to convince the former tech lead (who thinks he still is the tech lead) the Groovy solution might be better:

  • He already groks Digester, so he won’t understand the “easier to read” argument.
  • He won’t like the import from a “sandbox” package.
  • Groovy is in its infancy; Digester is time-tested.

So, I’ll write a Digester solution just to be prepared, but (woe is me) it’s tough wanting to be on the cutting edge.

Posted in Uncategorized | 4 Comments »

h1

Beyond Ruby

November 6, 2005

Are personal programming languages the “Next Big Thing?” Not “personalized,” but “personal”—each programmer with his own language. It’s possible if Dr. Gregory V. Wilson’s vision is realized. In Extensible Programming Systems for the 21st Century, Dr. Wilson expresses the belief

that next-generation programming systems will store source code as XML, rather than as flat text. Programmers will not see or edit XML tags; instead, their editors will render these models to create human-friendly views, just as web browsers render HTML. For example, a program might be stored on disk like this: 

<doc>Only replace below threshold</doc>
<cond>
<test>
 <compare-expr operator="less">
   <field-expr field="age"><evaluate>record</evaluate></field-expr>
   <evaluate>threshold</evaluate>
 </compare-expr>
</test>
<body>
 <invoke-expr method="release"><evaluate>record</evaluate></invoke-expr>
</body>
</cond>

but it will be viewed and edited like this: 

// Only replace below threshold
if (record.age < threshold) {
 record.release();
}

If this doesn’t nearly blow your mind, read no further. Now, think of a shop where each programmer has his own language. John, an old curmudgeon who only knows Java, writes this bit code: 

// notify user that process has completed
System.out.println(“Done.”);

What he commits to the source repository might look something like this: 

<doc>notify user that process has completed</doc>
<field-expr field=”out”>
  <evaluate>System</evaluate>
     <invoke-expr method=”println” param=”Done.”>
        <evaluate>out</evaluate>
     </invoke-expr>
</field-expr>

Rita, fresh out of a tech school that taught Ruby, loads John’s code into her editor expecting to see: 

# notify user that process has completed
puts “Done.”

The problem is that her editor chokes on the Java-specific code in the XML, so the XML output must be revised to indicate what the code should do, not how: 

<doc>notify user that process has completed</doc>
<write output-stream=”stdout” param=”Done.” />

Now Rita’s editor can properly translate. Let’s assume she adds another comment to the code: 

# notify user that process has completed
# John has a long moustache
puts “Done.”

This XML is changed to: 

<doc>notify user that process has completed</doc>
<doc>John has a long moustache</doc>
<write output-stream=”stdout” param=”Done.” />

When John loads the code into his editor, the comments most probably appear like this: 

// notify user that process has completed
// John has a long moustache

John prefers multi-line comments enclosed in /* */, so he changes the code: 

/*
notify user that process has completed
John has a long moustache
*/

The XML <doc> tag must contain meta data that the Ruby editor can ignore but has meaning to the Java editor: 

<doc meta=”line-1”>notify user that process has completed</doc>
<doc meta=”line-2”>John has a long moustache</doc>

The “Next Big Thing” may very well not be a new language or methodology but new storage mechanism in concert with code editors that allow easy adaptation and customization of existing and new languages. With a standardized XML model, each programmer could have his own language, or view. The problem is going to be nailing down the model standard, but that’s what the guys in the ivory towers are for.

Posted in Uncategorized | 1 Comment »