With the right examples, you can justify almost anything . . .

Unfair Comparisons Can Lead to Bad Choices

by Conrad Weisert, April 2, 2017
©2017 Information Disciplines, Inc., Chicago
This article may be circulated freely as long as the copyright notice is included.

Background

In 1968 our company was having spirited debates over the choice of a preferred programming language for business applications. With the choice of PL/I likely, one dissenting veteran programmer who strongly favored Cobol distributed a sample claiming to show the same logic coded in the two languages. The Cobol version took two pages of code while the PL/I version consumed three pages and was harder to understand.

What the programmer had done was to obtain a PL/I manual and find the closest equivalent to each statement in his Cobol program. It didn't occur to him, of course, that PL/I offered features that made many of those statements unnecessary, even harmful.

I took his example, and over several hours produced a 44-line PL/I equivalent, less than a printed page. It took appropriate advantage of PL/I features that had no Cobol equivalent. After I added appropriate commentary and white space it was just over one page. In a meeting the following week everyone agreed that the shorter PL/I version was far more clear and easy to understand than the original Cobol version. It might or might not have run a bit slower due to intefficiencies in the early PL/I (F-level) compiler, but those issues would surely be addressed in IBM's new (H-level) PL/I.

Today's controversies

Programmers are no longer arguing about PL/I (too big and complicated) versus Cobol (too resrictive and verbose), but we're still struggling with programming-language controversies, both valid and silly. A 2009 book1 comparing elegant Clojure with stodgy Java offers several examples. Here's one perfectly awful Java2 example from the third page:

 public class Person {
    private String firstName;
    private String lastName;
    public Person(String firstName, String lastName) {
        this.firstName = firstName;
        this.lastName = lastName;
    }
    public String getFirstName() {
        return firstName;
    }
    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }
    public String getLastName() {
        return lastName;
    }
    public void setLastName(String lastName) {
        this.lastName = lastName;
    }
 }

The author then shows his elegant one-line Clojure version, noting that

". . . the Clojure version is immutable. Immutable data structures are naturally thread-safe, and update capabilities can be layered in using Clojure's references, agents, and atoms."

Obvious question: Could we make the Java version immutable, too?

Obvious answer: Sure. Just remove those two ill-advised and ridiculous set functions. (We then can't change the object itself, but in Java we can still change a reference to the object.)

Further clean-up

We may also note these other flaws:

So the original twenty-line class definition reduces, so far, to these ten (not counting blanks and comments) lines:

 public class PersonName {
    private String first;
    private String last;

// Constructor
    public Person(String first, String last)  
       {this.first = first; this.last = last;}

// Accessors
    public String firstName() {return first;}
    public String lastName()  {return last; }

// Convert to external (directory) representation
    public String toString() 
       {return last + ", " + first;}

 }
And we still have to correct the seriously flawed internal data representation.

(more on this topic in May or June)


1—Stuart Halloway: Programming Clojure, 2009, The Pragmatic Bookshelf, ISBN 10-10934356-35-6, 264 pages
2—With minor changes the example applies also to C++ and C#.
3—Those flaws apply equally to Halloway's Clojure examples.

Last modified (link inserted) May 9, 2017

Return to articles on programming.
Return to IDI home page.