Google Squared is an impressive (but still beta) offering from The Google that seems to have some real potential for students and others who want to do quick-and-maybe-not-do-dirty research.

This post is also a bit of an experiment. I want to find out whether I can capture screen shots that are large enough to be (at least partly) readable without completely blowing up the page layout I’m currently using for this blog.

Given the subject matter of this blog, it’s no surprise that I thought of this query:

which gave me the following result:

I admit to being surprised and impressed with the collection of values presented with no additional guidance. However, I want to refine the content a little. First, I’ll click on the [X] column to the left to remove Pascal, Fortran, Cobol, and Forth, (none of which I’m currently using ; then I’ll use the “Add items” input field to include Java, Scala, Erlang, and Haskell. Some fairly interesting look-ahead kicked in as I began typing:

With all my new rows in place, I have this:

It’s interesting that “Appeared In” was not found for Java, but Google Squared is a beta. I’m impressed that it chose to put that column in, and did find values for the other languages!

The next hint of the underlying sophistication in G² came when I decided to modify the columns. After removing “Influenced” and “Appeared In”, I started to add replacement columns, and was offered an interesting set of options.

Curiosity took over, and I picked “Typing Discipline” from the list. The resulting column confirmed that the term was being used correctly (e.g. with values of “duck,dynamic,strong” for Python and “static,strong,inferred” for Haskell).

Replacing that column with new ones for “tutorial” and “blogs” gave me some additional leads to follow:

When I clicked on the tutorial column in the Scala row, G² provided a pop-up with a link to Bill Venners’ presentation on Scala at last year’s QCon.

I won’t burden this page (or you, kind reader) with any more screen shots from G²; perhaps by now you’ve seen enough that you’ve already left to try it out yourself or have decided it’s not (yet) for you.

There’s an obvious comparison begging to be done here; Wolfram Alpha wasn’t immediately successful for this particular search:

…but let’s remember that both of these new tools are work in progress.

My overall impression is that it’s a very impressive start, but has room for improvement. Several of my attempts to add other columns relevant to this blog (such as “DSL” or “parsing”) yielded “No value found” in most or all rows. Even the proposal from G² of “Major Implementations” was only partially successful. There were multiple values for all languages except Java, Scala, and Erlang, all three of which got “No value found”.

It would be really interesting to be able to derive new columns from the contents of others. For example, counting the number of values in a list or doing arithmetic with numeric values would both be handy.

You may have noticed in the full-page screenshots the link at the top-right-hand corner that invited me to “Sign in to save your Square”. I did so, and plan to come back later to see if the results change over time.

I’m very interested in seeing how G² grows from this not-so-humble beginning.

This month’s Memphis Java Users’ Group meeting featured Jesse Tilly of IBM Rational Software, who spoke to us on static analysis. He will be doing a more product-intensive session, “What is IBM® Rational® Software Analyzer® Telling Me?”, at the upcoming IBM Rational Software Conference. (Don’t be misled by all those “circle-R”s; I just linked to the title from the conference web site.)

For our meeting, Jesse left the branding iron at home. He began with an overview of the history and benefits of static analysis. The major portion of the presentation offered a practical approach to analysis as part of a development project, including a detailed how-to on interpreting and using analysis results. Jesse finished with return to history, drawing unexpected parallels with the analysis of Enigma traffic at Bletchley Park during WWII—the background for Allen Turing’s later theoretical work that led to the computers we program today.

Because Jesse had an early flight, our regular door-prize drawing followed his presentation. In our lightning talk segment, Matt Stine introduced Morph AppSpace, I presented on “Structured Functional Programming” (pdf here), and Walter Heger gave a quick look at jGears.

Recommended reading:

Encryption and cryptanalysis are deeply entwined with computing, whether in history(Codebreakers: The Inside Story of Bletchley Park) or in imagination (Cryptonomicon).

Two highly-respected tools for static analysis in Java are FindBugs and PMD; both web sites offer excellent documentation and other reference material.

This post describes the first model in Haskell for the BuilderBuilder task. We will develop the model incrementally until we have rough parity with the Java version.

I’m experimenting with ways to distinguish user input from system output in transcripts of interactive sessions. This time I’m trying color, using a medium blue for output. I will appreciate feedback on whether that works for you.

Step one: defining and using a type

The simplest possible Haskell version of our model for a Java field is:

data JField = JField String String

However, the PMNOPML (“Pay Me Now Or Pay Me Later”) principle says that we’ll regret it if we stop there. In fact, later comes quickly.

We can create an instance of JField in a source file:

field1 = JField "name1" "Type1"

To do the same in a ghci session, prefix each definition with let, as in:

*Main> let field1 = JField "name1" "Type1"

Step two: showing the data

Trying to look at the instance yields a fairly opaque error message.

*Main> field1

<interactive>:1:0:
    No instance for (Show JField)
      arising from a use of `print' at <interactive>:1:0-5
    Possible fix: add an instance declaration for (Show JField)
    In a stmt of a 'do' expression: print it

Remember that in Java the default definition of toString() returns something like com.localhost.builderbuilder.JFieldDTO@53f67e; that’s also obscure at first glance. Haskell just goes a bit further, complaining that we haven’t defined how to show a JField instance. We can ask for a default implementation by adding deriving Show to a data type definition:

data JField = JField String String deriving Show

After loading that change, we get back a string that resembles the field’s defining expression:

*Main> field1
JField "name1" "Type1"

Step three: referential transparency

Our first model represented a Java class by its package, class name, and enclosed fields. The Haskell equivalent is:

data JClass = JClass String String [JField] deriving Show

The square brackets mean “list of …”, so a JClass takes two strings and a list of JField values. I’ll say more about lists in a moment, but first let’s deal with referential transparency.

We can build a class incrementally:

field1 = JField "name1" "Type1"
field2 = JField "name2" "Type2"
class1 = JClass "com.sample.foo" "TestClass" [field1, field2]

or all at once:

class1 = JClass "com.sample.foo"
                "TestClass"
                [   JField "name1" "Type1" ,
                    JField "name2" "Type2"
                ]

and get the same result:

*Main> class1
JClass "com.sample.foo" "TestClass" [JField "name1" "Type1",JField "name2" "Type2"]

As mentioned previously, only one of those definitions of class1 can go in our program. To Haskell, name = expression is a permanent commitment. From that point forward, we can use name and expression interchangeably, because they are expected to mean the same thing. That expectation would break if we were allowed to give name another meaning later (in the same scope).

Consequently, we can define a class using previously defined fields, or we can just write everything in one definition, nesting the literal fields inside the class definition. As we’ll see later, this also has implications for how we write functions; a “pure” function and its definition are also interchangeable.

Step four: lists

The array is the most fundamental multiple-valued data structure in Java; the list plays a corresponding role in Haskell. In fact, lists are so important that there are a few syntactical short-cuts for dealing with lists.

• Type notation: If t is any Haskell type, then [t] represents a list of values of that type.
• Empty lists: Square brackets with no content, written as [], indicate a list of length zero.
• Literal lists: Square brackets, enclosing a comma-separated sequence of values of the same type, represent a literal list.
• Constructing lists: The : operator constructs a new list from its left argument (a single value) and right argument (a list of the same type).

For example, ["my","dog","has","fleas"] is a literal value that has type [String] and contains four strings. "my":["dog","has","fleas"] and "my":"dog":"has":"fleas":[] are equivalent expressions that compute the list instead of stating it as a literal value.

By representing the fields in a class with a list, we achieve two benefits:

• The number of fields can vary from class to class.
• The order of the fields is significant.

Step five: types and records

Given a JField, how do we get its name? Or its type? We can define functions:

fieldName (JField n _) = n
fieldType (JField _ t) = t

and do the same for the JClass data:

package   (JClass p _ _ ) = p
className (JClass _ n _ ) = n
fields    (JClass _ _ fs) = fs

but all that typing seems tiresome.

Before solving that problem, let’s note two other limitations of our current implementation:

• Definitions using multiple String values leave us with the burden of remembering the meaning of each strings.
• The derived show method leaves us with a similar problem; it doesn’t help distinguish values of the same type.

If you suspect that I’m going to pull another rabbit out of Haskell’s hat, you’re right. In fact, two rabbits.

Type declarations

We can make our code more readable by defining synonyms that help us remember why we’re using a particular type. By adding these definitions:

type Name     = String
type JavaType = String
type Package  = String

we can rewrite our data definitions to be more informative:

data JField = JField Name JavaType deriving Show
data JClass = JClass Package Name [JField] deriving Show

Record syntax

The second rabbit is a technique to get Haskell to do even more work for us. We represent each component of a data type as a name with an explicit type—all in curly braces, separated by commas:

data JField = JField {
     fieldName :: Name ,
     fieldType :: JavaType
} deriving Show

data JClass = JClass {
     package   :: Package ,
     className :: Name ,
     fields    :: [JField]
} deriving Show

When we use this syntax, Haskell creates the accessor functions automagically, and enables a more explicit and flexible notation to create values. All of these definitions:

field1  = JField "name1" "Type1"
field1a = JField {fieldName = "name1", fieldType = "Type1"}
field1b = JField {fieldType = "Type1", fieldName = "name1"}

produce equivalent results:

*Main> field1
JField {fieldName = "name1", fieldType = "Type1"}
*Main> field1a
JField {fieldName = "name1", fieldType = "Type1"}
*Main> field1b
JField {fieldName = "name1", fieldType = "Type1"}

Step last: that’s it!

We have covered quite a bit of ground! The complete source code for the model appears at the end of this post. With both Java and Haskell behind us, we have most of the basic ideas we’ll need for the Erlang and Scala versions.

Recommended reading:

Real World Haskell, which is also available
for the Amazon Kindle
or on-line at the book’s web site. I really can’t say enough good things about this book.

The current BuilderBuilder mode in Haskell, along with sample data, is this:

-- BuilderBuilder.hs

-- data declarations

type Name     = String
type JavaType = String
type Package  = String

data JField = JField {
     fieldName :: Name ,
     fieldType :: JavaType
} deriving Show

data JClass = JClass {
     package   :: Package ,
     className :: Name ,
     fields    :: [JField]
} deriving Show

-- sample data for demonstration and testing

field1  = JField "name1" "Type1"
field1a = JField {fieldName = "name1", fieldType = "Type1"}
field1b = JField {fieldType = "Type1", fieldName = "name1"}

field2 = JField "name2" "Type2"

class1 = JClass "com.sample.foo" "TestClass" [field1, field2]

studentDto = JClass {
    package   = "edu.bogusu.registration" ,
    className = "StudentDTO" ,
    fields    = [
        JField {
            fieldName = "id" ,
            fieldType = "String"
        },
        JField {
            fieldName = "firstName" ,
            fieldType = "String"
        },
        JField {
            fieldName = "lastName" ,
            fieldType = "String"
        },
        JField {
            fieldName = "hoursEarned" ,
            fieldType = "int"
        },
        JField {
            fieldName = "gpa" ,
            fieldType = "float"
        }
    ]
}

Updated 2009-05-09 to correct formatting and add category.

The next step in the BuilderBuilder project is to develop a model in Haskell that is analogous to the Java model in the previous post. This post will introduce just enough Haskell to get started; the next post will get into the BuilderBuilder model.

Environment:

I’m using GHC 6.10.1, obtained from the Haskell web site. There are a variety of platform-specific binaries; I used the classic configure/make/install process on OSX. (For Java programmers, make is what we used instead of ant back in the Jurassic era.) Consult the Haskell Implementations page for details on obtaining Haskell for your preferred platform.

The complete development environment consists of two windows: one running a text editor, and the other running ghci, the interactive Haskell shell that comes with GHC.

Haskell introduction:

Use your text editor to create a file named bb1.hs with this content:

-- bb1.hs

-- simplest possible data declarations

data JField = JField String String

-- sample data for demonstration and testing

field1 = JField "id" "String"

-- sample function

helloField :: JField -> String
helloField (JField n t) = "Hello, " ++ n ++ ", of type " ++ t

Then run ghci as follows, where user input is underlined:

your-prompt-here$ ghci
GHCi, version 6.10.1: http://www.haskell.org/ghc/    for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Prelude> :l bb1.hs
[1 of 1] Compiling Main             ( bb1.hs, interpreted )
Ok, modules loaded: Main.
*Main> helloField field1
"Hello, id, of type String"
*Main>

We started ghci, told it to load our source file (the :l … line), and then invoked the helloField function on the sample field. Now let’s examine the Haskell features used in that code. The lines beginning with double-hyphens are comments, and will be ignored in the description.

Defining data types

Because Haskell emphasizes functions, it’s no surprise that the syntax for defining data types is very lightweight. The Java BuilderBuilder model represents a field with two strings, one for the name and one for the type. The simplest possible Haskell equivalent is:

data JField = JField String String

This defines a data type named JField. It has a constructor (also named JField) that takes two strings, distinguished only by the order in which they are written.

Defining values

The next line of code defines an instance of this type:

field1 = JField "id" "String"

The equal sign means “is defined as“. That statement defines field1 as the instance of JField constructed on the right-hand side. It is not declaring and initializing a mutable variable. Within the current scope, attempting to redefine field1 will produce an error. (More about scope later.)

Defining functions

Finally, we have a simple function that converts a JField to a String.

helloField :: JField -> String
helloField (JField n t) = "Hello, " ++ n ++ ", of type " ++ t

Everything in Haskell has a type, including functions. The double colon means “is of type“, so the type of helloField is function from JField to String.

The value of applying helloField to a JField containing strings n and t is defined by the expression on the right-hand side. Haskell regards strings as lists of characters; the ++ operator concatenates lists of any type. The names n and t are only meaningful within that definition, similar to the local variables in this Java fragment:

public static String helloField(IJField f) {
    String n = f.getName();
    String t = f.getType();
    return "Hello, " + n + ", of type" + t;
}

Type inference

Java requires that we explicitly declare the local variables as type String. But in Haskell, because JField is specified to have two String values, the compiler can infer the types of n and t In fact, the entire first line of helloField is not necessary. The defining equation in the second line explicitly uses a JField on the left and constructs a String on the right. Therefore, the compiler can infer JField -> String as the type of the function. Haskell’s type inference allows us to write very compact code without giving up strong, static typing.

To see that in action, add the following line to the end of your bb1.hs file:

hiField (JField n _) = "Hi, " ++ n

(The underscore is a wild card, showing the presence of a second value but indicating that we don’t need it in this function.)

Reloading bb1.hs in ghci allows us to see type inference at work.

*Main> :l bb1.hs
[1 of 1] Compiling Main             ( bb1.hs, interpreted )
Ok, modules loaded: Main.
*Main> hiField field1
"Hi, id"
*Main> :type hiField
hiField :: JField -> [Char]

As we’ll see later in this series, Scala brings type inference to the JVM environment. Coming from the dynamic language side, the Diamondback Ruby research project is adding type inference to Ruby. So perhaps type inference is (finally) an idea whose time has come.

We’ll pick up more Haskell details along the way, but we have enough to start defining our first BuilderBuilder model. That will be the subject of the next post.

Updated 2009-05-09 to fix formatting.

This post will describe a tiny Java model for implementing the BuilderBuilder task. It is simple almost to the point of crudity, because the goal of the series is to compare languages and styles, not to produce production-ready sample code.

This post will focus on the parts of the overall data flow highlighted below:

The interfaces:

I’m using interfaces to hide implementation from the remainder of the code. The first version will use simple DTOs, but I want to leave other options (e.g. by reflection against existing DTO classes) open for later exploration.

This first model has two interfaces; one for a Java class:

package com.localhost.builderbuilder;

public interface IJClass {
    public String getPkg();
    public String getName();
    public IJField[] getFields();
}

and the other for a Java field:

package com.localhost.builderbuilder;

public interface IJField {
    public String getName();
    public String getType();
}

We all know that “the simplest thing that could possibly work” doesn’t mean “the stupidest thing that could possibly work”. The use of an array may cross that line, but it was a deliberate choice. Developers who moved to OOP from imperative programming are very familiar with arrays. We’ll be able to compare array processing against the FP style of list processing, and perhaps consider other OOP alternatives later on.

First implementations:

In the spirit of eating our own dog food, the simple DTO implementation of those interfaces will contain their own Builder inner classes. Given that, there’s no surprise in the JFieldDTO code, which appears at the end of this post.

The JClassDTO class throws in one new wrinkle—instead of having a fields(IJField[] fields) method that accepts an entire field array, JClassDTO.Builder provides a field(IJField field) method that accepts one field at a time, accumulating them to be placed in an array by the instance() method. The complete code for JClassDTO is given at the end.

It remains to be seen whether this DTO-style implementation is throw-away code, but getting a first implementation in hand will allow us to start comparing data types and structures with the other language, and then move directly to the generation phase of the project. We can always come back and add features (and complexity ) at a later time.

Recommended reading:

• Anything by “Uncle” Bob Martin.
• The origin of the Model-View-Controller (MVC) paradigm.

The JFieldDTO implementation:

package com.localhost.builderbuilder;

public class JFieldDTO implements IJField {

    private final String name;
    private final String type;

    public static class Builder {

        private String name;
        private String type;

        private Builder() {
            // do nothing
        }

        public Builder name(String name) {
            this.name = name;
            return this;
        }

        public Builder type(String type) {
            this.type = type;
            return this;
        }

        public JFieldDTO instance() {
            return new JFieldDTO(name, type);
        }
    }

    public static Builder builder() {
        return new Builder();
    }

    private JFieldDTO(String name, String type) {
        this.name = name;
        this.type = type;
    }

    public String getName() {
        return name;
    }

    public String getType() {
        return type;
    }

}

The JClassDTO implementation:

package com.localhost.builderbuilder;

import java.util.ArrayList;
import java.util.List;

public class JClassDTO implements IJClass {

    private final String pkg;
    private final String name;
    private final IJField[] fields;

    public static class Builder {

        private String pkg;
        private String name;
        private List<JFieldDTO> fields;

        private Builder() {
            fields = new ArrayList<JFieldDTO>();
        }

        public Builder pkg(String pkg) {
            this.pkg = pkg;
            return this;
        }

        public Builder name(String name) {
            this.name = name;
            return this;
        }

        public Builder field(JFieldDTO field) {
            this.fields.add(field);
            return this;
        }

        public IJClass instance() {
            return new JClassDTO(
                pkg,
                name,
                fields.toArray(new JFieldDTO[fields.size()])
            );
        }

    }

    public static Builder builder() {
        return new  Builder();
    }

    private JClassDTO(String pkg, String name, IJField[] fields) {
        this.pkg = pkg;
        this.name = name;
        this.fields = fields;
    }

    public String getPkg() {
        return pkg;
    }

    public String getName() {
        return name;
    }

    public IJField[] getFields() {
        return fields;
    }

}

Updated 2009-05-09 to fix some formatting and to add a category.

Short version:

Given minimal information (package, class name, and collection of fields described by name and type), produce Java source for a data transfer class, including a static inner class that functions as a builder.

The data flow of this task looks like this:

Given data in a specified input format, a loader will consume the input to produce a model of the class and fields. A code generator will consume the model and produce Java source. The “direct construction” case allows model instances to be produced by code without the need for source data.

Long version:

Data transfer objects (described here) may be used to pass data across boundaries (between systems via network, between Java and non-Java systems, etc.) Developers supporting the Registrar’s office at Bogus University might create a data transfer class representing a student, beginning as follows:

package edu.bogusu.registration;

public class StudentDTO {
    private String id;
    private String firstName;
    private String lastName;
    private int hoursEarned;
    private float gpa;
    // ... other fields
    // ... construction method(s)
    // ... get methods
}

Constructing an instance of StudentDTO is commonly done in one of two ways:

1. calling a constructor that has a parameter for every field, or
2. calling a no-argument constructor, then calling a set… method for every field.

The first approach can minimize clutter in the client code that creates a StudentDTO and, more importantly, makes it easy for StudentDTO to be immutable. But as the number of fields grows, so does the parameter list to the constructor call; it becomes ugly and potentially error-prone. The second approach makes the initialization more explicit, at the cost of losing immutability. For this series, we’re going to go through door number three.

Enter The Builder

We’ll create another class whose job is to construct StudentDTO instances. Making it a static inner class to StudentDTO allows us to keep the construction machinery private, giving us more control over the way clients obtain an instance. It also allows us to re-use the idea without name bloat; any FooDTO can have an associated FooDTO.Builder.

Usage

The code is a bit tedious, so we’ll begin with a sample of the intended usage.

StudentDTO student = StudentDTO.builder()
    .id(ID)
    .firstName(FIRST_NAME)
    .lastName(LAST_NAME)
    .hoursEarned(HOURS_EARNED)
    .gpa(GPA)
    .instance();

The static method StudentDTO.builder() provides an instance of the inner Builder class. There is a method on Builder for each field of StudentDTO. Each of those methods returns the Builder instance, allowing the chaining shown in the sample. Finally, the instance() method returns an instance of StudentDTO

The net effect is that of a constructor method with named parameters; we can provide them in whatever order we wish, and can even do the initialization in stages:

StudentDTOBuilder studentBuilder = StudentDTO.builder()
    .id(ID)
    .firstName(FIRST_NAME)
    .lastName(LAST_NAME);
// some tedious computation of HOURS_EARNED
studentBuilder.hoursEarned(HOURS_EARNED);
// some tedious computation of GPA
studentBuilder.gpa(GPA);
// and finally
StudentDTO student = studentBuilder.instance();

(I’m not suggesting that we should use it that way; just demonstrating the flexibility of the technique.)

The Code

There’s a high level of redundancy, so I’ll post just enough to show how the code is organized; the remainder should be obvious.

package edu.bogusu.registration;

public class StudentDTO {

    private String id;
    private String firstName;
    private String lastName;
    private int hoursEarned;
    private float gpa;

    public static class Builder {

        private String id;
        // etc. for all StudentDTO fields
        private float gpa;

        private Builder() {
            // nothing here
        }

        public Builder id(String id) {
            this.id = id;
            return this;
        }

        // similar methods for the other fields

        public Builder gpa(float gpa) {
            this.gpa = gpa;
            return this;
        }

        public StudentDTO instance() {
            return new StudentDTO(
                    id,
                    firstName,
                    lastName,
                    hoursEarned,
                    gpa
            );
        }
    }

    public static Builder builder() {
        return new Builder();
    }

    private StudentDTO(
            String id,
            String firstName,
            String lastName,
            int hoursEarned,
            float gpa
    ) {
        this.id = id;
        this.firstName = firstName;
        this.lastName = lastName;
        this.hoursEarned = hoursEarned;
        this.gpa = gpa;
    }

    public String getId() {
        return id;
    }

    // all StudentDTO fields have get methods

    public float getGpa() {
        return gpa;
    }

}

Just a few key points before closing:

• The constructors are private to control instance creation. Client code never uses new... () for either class. In addition, we can later address the question of making sure that all required data are present, so that a “half-baked” instance is never created.
• Each StudentDTO field is shadowed in StudentDTO.Builder. This represents the “work-in-progress inventory” without creating an inconsistent or incomplete object.
• The ugliness (and risk) of a zillion-parameter constructor for StudentDTO is hidden from the client. Only the generator needs to see that monster.
• Much of the redundancy is driven by Java’s approach to explicit, static typing. Code generation will keep the many repetitions of the same information in synch.

That’s enough to get a simple version of the problem on the table. Next time, we’ll begin looking at internal representations: first in Java, then in Haskell, Erlang, and Scala.

• The classic “favor immutability” essay is Item 13 in Effective Java (2nd Edition) (Java Series), by Joshua Bloch.
• The OOPSLA 2006 paper by Steve Freeman and Nat Pryce, “Evolving an Embedded Domain-Specific Language in Java”, takes this technique all the way to 11. It describes how they evolved the idea over several generations of the jMock test framework.
• Martin Fowler’s “FluentInterface”article discusses pros and cons of the approach in detail.
• “Java theory and practice: To mutate or not to mutate?”, by Brian Goetz, gives thorough coverage to the subject of immutability in Java.

The “BuilderBuilder” posts will be my exploration of one question: “What does Functional Programming mean to me as a practicing OO software developer?” Despite contemporary buzz about how FP will save the world from bugs and single-threaded code, I don’t want to read (or write) another clever Fibonacci number generator, or another theoretical explanation of category theory and monads. I want to see what FP is like when it sits down the aisle from me in work clothes.

To pursue that goal, I’m going to explore a programming problem that meets these criteria:

1. Its purpose would be recognizable to a working programmer.
2. It is large enough that a clever one-liner won’t suffice.
3. It isn’t (consciously) chosen to cater to either OO or FP.
4. It will require me to try things outside my daily comfort zone.

That last point means that I’ll make mistakes and do stupid things. I hope the record, warts and all, helps someone else (including me, later on) avoid them.

The problem I’ve chosen is a specific code generation task, which I’ll describe in the next post. There is a wide range of opinions on source code generation, but source code is one thing that any programmer understands, regardless of other application domain specialization.

Because my goal is exploration, and I’m starting with unequal familiarity with the languages I’ll use, the code almost certainly won’t be idiomatic or make best use of all available libraries. In fact, I’ll probably do more than necessary “by hand” to avoid bias toward more familiar tools. I may be able to address some of that along the way, based on accumulated experience (or helpful feedback, hint, hint… .

OK, enough meta-talk. Next up, the task.

I’ve been very happy with the progress of the Memphis Java Users’ Group under Matt Stine’s leadership, and last night kicked it up a notch, with a visit by Jared Richardson, author of Career 2.0 and Ship It!, and NFJS speaker!

Jared’s talk on refactoring your career was full of practical advice, engagingly presented …

Just stop right there! This is your Second-Guessing-Self speaking. Do you realize that you’re starting to gush? Even worse, you’re breaking my adjective-per-paragraph rule. Don’t tell your readers what to think! Just give them the facts and let them draw their own conclusions.

But S-G-S, I really enjoyed his talk, and—judging from their reactions—so did everyone else there. He even had Diane talking back to him, and you know how shy and retiring she is.

I’m more concerned about looking professional than about your enjoyment. Be objective!

Whatever…

Jared covered a rich list of specific suggestions for developing one’s writing and speaking skills; he also discussed a variety of contributions to open-source projects as a way to build visibility, reputation, and connections. These topics were all illustrated with examples from his own career, such as how he wrote the JUnit totorial that’s a front-page Google result.

The evening was rounded out with a discussion of goals and how to set and achieve them.

I have to say that hearing Jared was one the most enjoyable—but effective—kick in the seat of the pants I’ve had in quite a while! (Take that, S-G-S!)

Those who heard him speak (especially his advice on writing ) will understand when I say, “Thanc yew, Jerrid Rytszchurdsen!”

Programmers often need to talk about ranges of values (whether or not the language at hand supports the concept explicitly). For example, given the Java array

String[] streetLines = new String[3];

an index i must satisfy

0 ≤ i < 3 (in normal Mathematical notation)

or

0 <= i && i < 3 (in Java notation)

to be a valid index on streetLines. But how does one read those expressions aloud?

I learned to read <= and ≤ as “at most” and >= and ≥ as “at least” from Dijkstra. Those readings have at least two benefits:

1. They are quite natural. For example, the assertion
   

   there are at least six eggs left in the carton

   is at least as obvious in normal speech as the equivalent phrase

   there are six or more eggs in the carton

   and is probably much more obvous than other equivalent phrases, such as

   the number of eggs left in the carton is greater than or equal to six

   or

   there are more than five eggs left in the carton

   even though we’ve seen the equivalent of those in code many times.
    

2. They avoid introducing extraneous logical operators. The phrasing
   

   less than or equal to

   seems more complex than

   at most

   because it implies the use of disjunction (logical “or“) in its evaluation. The other equivalent phrase

   not greater than

   introduces negation into a simple comparison.

As a tiny “easter egg”, look for uses of “at least” en passant in the preceding few sentences! If they went by without being obvious, perhaps that serves as evidence of point 1 above.

I happened across an interesting post on Chris Okasaki’s blog, titled Less than vs Greater than. Let me suggest that you read it before continuing here.

I would paraphrase his point about errors he observed in students’ programs as follows:

A student who writes an expression such as

expL < expR

often appears to lock on the concept of “something being smaller” and then become mentally stuck on “dealing with smaller stuff”, even if that is not appropriate for the meaning of expL and expR at that point in the program.

He illustrates his point very nicely with a flawed binary search.

For quite some time I’ve tended to write expressions of the form

lowerBound <= someVar && someVar < upperBound

to express that someVar is within the half-open range

[lowerBound..upperBound)

e.g. array subscripts that must be at least zero, but less than the length of the array. The visual hint of placing the variable textually between the limiting values seemed nicely mnemonic to me. (From there, it has also seemed natural to experiment with preferring left-to-right, lesser-to-greater ordering consistently in comparison expressions, although I’m not suggesting that as a universal coding convention).

However, I was quite surprised by the first comment, which described as “linguistically wrong” the common C-language-based idiom

if (5 == i) …

(intended to catch typos involving only a single equal sign). The commenter said

Linguistically that’s wrong. You’re not testing 5 to see if it’s equal to i, you’re testing i.

which implies an asymmetrical interpretation of equality as being a “test” on its left-hand value!

By ignoring the fact that == is simply an assertion that its operands are equal, that interpretation fails on many completely valid cases, such as

(a + 1 == b - 1)

and the first clause

lowerBound <= someVar

of the “within bounds” cliché above.

That misinterpretation of == seems consistent with a variety of incorrect or awkward uses of boolean expressions widely seen. Many of us have probably seen code (or read blog posts about code) resembling:

boolean fooIsEmpty;
...
if (foo == null) {
    fooIsEmpty = true;
} else {
    if (foo.length() == 0) {
        fooIsEmpty = true;
    } else {
        fooIsEmpty = false;
    }
}

I suspect two culprits behind this kind of abuse:

1. Failure to include the right kind and amount of Mathematics in the education of a programmer, and
2. The C/FORTRAN use of = for assignment.

With respect to point 1, I believe that Boolean Algebra is simply a fundamental skill for programming. The ability to manipulate and understand boolean expressions equally important as the ability to deal with numeric expressions for most programming of the kind I see daily. It is understandable that a programmer whose training never addressed boolean expressions except in the context of if(…) or while(…) would be uncomfortable with other uses, but that’s a problem to be solved, not a permanent condition to be endured.

Regarding point 2, much of what I’ve read or experienced supports the idea that FORTRAN—and later, C—were more commonly used in the US than Algol or other alternatives due to political, cultural, and commercial issues rather than technical ones. (I recommend Dijkstra’s “A new science, from birth to maturity” and Gabriel’s “Worse is Better” as good starting points.)

Whether that conclusion is valid or flawed, the decision to use = for the (asymmetrical!) “assignment” operation immediately creates two new problems:

1. The need to express the “equality test” in a way that won’t be confused with assignment; and
2. The risk that users of the language become confused about the symmetry of equality, due to guilt by association with the “assignment” operator.

Algol—and its descendants, including Pascal—avoided those problems by using the asymmetrical := for assignment. The ! character is used as an operator or suffix in other languages to express destructive value-setting. But Java, C#, and others, have followed the FORTRAN/C convention, with the predictable effects.

Given such far-reaching consequences from a single character in the source code, I’m reminded again how important it is to make good choices in coding style, API design, and other naming contexts.

Postscript:

The left-to-right ordering of the number line has some interesting cultural and even individual baggage. I recall reading about a mathematician whose personal mental model was of negative values being behind him and positive values receding into the distance in front of him.

I believe it was in connection with the Dutch National Flag Problem that Esdger Dijkstra wrote about a student whose native language was written right-to-left. While other students had designed programs with indices increasing from zero, that student had produced an equally-valid program with an index that decreased from the maximal value.