I was scribbling notes during each lecture I attended, and going over them I can see one theme that permeated the entire conference more than any other: communication, starting with DesignFest, which was the first event I went to.

Software engineers face an infinite number of challenges involving communication. We’re not only talking about communication between software designers and customers, but also between software engineers and each other. How do you get people to communicate clearly and precisely? How can you distribute the intellectual work of software design and still maintain Conceptual Integrity? You need to be able to not only work together with someone face-to-face, but more and more you need to be able to work with people in other places, so called “telecollaboration” (more on this topic when I write about Fred Brooks’ keynote).

Think about the overhead and the time it takes in order to make another person understand the design you have going on in your head? UML models can only express so much, but they have their limits (as does any language). That’s why there were even tutorials, such as the one I attended – “The Art of Telling Your Design Story”, by Rebecca Wirfs-Brock – which are all about how to communicate your design to someone else.

As a whole, ooPSLA was a legendary experience that I never want to forget. This is one more aspect of my life that I have to thank Dominique for. She told me about the ooPSLA Student Volunteer program, and if it weren’t that I probably never would’ve even found out that the conference was in Montreal! Thanks, Dom! :D

It turns out that conference chair Dick Gabriel had once decided to take an MFA program. He was not terribly good at it (though he continues to write a poem every day). Peter Turchi was his teacher. What contribution could a Creative Writing professor possibly have at a conference on Software Engineering? I’ll tell you.

The purpose of Turchi’s talk wasn’t to present some radical new paradigm of programming, and it wasn’t to show off some fantastical form of research. The theme of Turchi’s talk, was that getting lost can be a good thing. When you get lost, you have to find your way back. In the process of finding your way back, you learn a new path. And sometimes, that is how you have to learn. In order to succeed and innovate, and create something new, you have to get lost in it.

If you have a map, you might be worse off than if you had no map at all. When using maps, you have to realize that all maps are distortions. No map tells the truth. Think about the typical world map that you’d see almost anywhere:

You’re pretty used to seeing it, so it won’t look particularly strange to you. But what about this “Upside-Down” world map?

It’s the same planet, and there’s no real “up” direction, so it’s just as accurate as any other map … but it’s still a distortion. The point is that no map is accurate, and if we rely too often on a single distortion (or abstraction), we will lose sight of our destination. We will get stuck in a certain paradigm, and be unable to “get lost” and discover a new path or a new perspective.

The parallels to software engineering are profound. A “map” can be some predefined solution to a problem; like a design pattern. There’s nothing wrong with using design patterns, sure they help, sure they show us useful and reliable information, so do maps. But we have to understand that design patterns themselves are an abstraction. Our purpose as software engineers and developers and programmers is to solve a problem, not to blindly trust and apply design patterns. We need to be able to get lost in a problem, and force ourselves to find a way out.

I was walking around the office today and I noticed a printed sheet sticking out of a printer that caught my eye. It was a printed version of this page. Look familiar?

Even more of a coincidence, the author of that page is Elliot Rusty Harold who, in addition to writing entire books on the subject of Java IO made himself known to the Ruby community when he more or less sparked the infamous Monkey Knife Fight a while back about Minimal vs. Humane Interfaces, which is the last time I think I had a serious code-related discussion on my blog.

I think this is because the design philosophy of Java is anal-retentive to the extreme. The library _is_ well-designed, but to the detriment of the programmer who has to deal with the textual overhead that all this flexibility demands. Take a simple example of a program that writes a text file to the screen. This is an extremely basic thing to do. Here is what it looks like in Java:

public class FileRead {
    static void printFile(String filename) {
        try {
            BufferedReader reader = new BufferedReader(new InputStreamReader(
                    new FileInputStream(new File(filename))));
            String line;
            while ((line = reader.readLine()) != null) {
                System.out.println(line);
            }
        } catch (FileNotFoundException e) {
            System.err.printf("No such file found: %s\n", filename);
        } catch (IOException e) {
            System.err.println("Error reading from file.");
        }
    }

    public static void main(String[] args) {
        if (args.length == 1)
            printFile(args[0]);
    }

}

(I actually googled for a while hoping to find a shorter version of this thing, and I actually couldn’t. I spent a good ten minutes thinking “It can’t seriously be this long…”).

There are good reasons why this sort of program needs to be written this way. We want to read from a File, so we create a File, and a FileInputStream to read from it. The FileInputStream basically gives us a sequence of characters from the file, and implements an InputStream interface which all InputStream-type things share. This means that a FileInputStream can easily be interchanged with an InputStream from some other source – this is (in the “big picture”) a good thing, because it’s generic.

But I want to read from the file. So I need to convert that InputStream into something that can actually do reading, which is a Reader. An InputStreamReader converts an Input Stream to a Reader. But I want to read from my file one line at a time. That means I need to use a specific kind of Reader that lets me read by the line. That’s BufferedReader. And that’s why we have that really long line of code that’s creating a file, an input stream, and input stream reader and a buffered reader.

Also notice that we actually are forced to deal with the FileNotFoundException and the IOException errors. So in case something goes wrong with the file and reading process, we are forced to handle the error. In a lot of cases, this is a good thing – it means that the compiler won’t let you get away with some potential bugs. But what if we explicitly checked that the file existed before trying to read from it? What if we did:

File file = new File(filename);
if ( !file.exists() ) // ...

Well, we’d still have to handle the FileNotFoundException even if it would never, ever, ever occur because we’re checking for the file’s existence. That’s making things kind of messy. Plus – what if it’s a perfectly normal thing to have a file not exist? By definition, it wouldn’t be an Exception, but we have to handle the error anyway because Java has decided that we have to deal with FileNotFoundException no matter where it may be.

All this just means I have to write a lot more code than I should.

To contrast, here’s a Ruby program that does the exact same thing:

filename = ARGV[0]
open(filename).each_line { |line| print line }

Wow. It’s basically one line. And it even reads like English “Open filename, each line print line”. You don’t even have to be a programmer to figure out what that does. Mind you, what if “filename” doesn’t exist? You’re right, I’m not checking for any of the errors here. If the file doesn’t exist, the program will just exit with an error. But I guess just to push things closer to the Java version, I’ll add some error-handling.

filename = ARGV[0] or raise ArgumentError.new("No filename provided")

begin
  open(filename).each_line { |line|
    print line
  }
rescue Errno::ENOENT
  $stderr.puts("No such file: #{filename}")
end

I think that’s still pretty clean, even though the ENOENT might throw you off if you didn’t know it meant “No Entry”.

What about Python?

from sys import argv

if len( argv ) == 2:
    try:
        file = open( argv[1] )
        for line in file.readlines():
            print line,
    except IOError:
        print "Error reading from the file."
else:
    print "No file specified."

Hey! That’s also really short. It just calls “open” and then loops over all the lines in the file. It doesn’t take a Computer Scientist to figure out what “file.readlines()” ought to do.

My point is that while Java is great at maintaining a generic, flexible design, it’s not very good at revealing the intentions of the programmer. I don’t think that code in Java is very readable, because you need to understand all the inner workings of the Java Library in order to understand what a simple piece of code that prints a file to the screen does. And I don’t think that should be necessary. I think you should be able to look at a piece of code and see “Oh, ‘print each line of the file’”. Any programming language that is as close as possible to “print each line from file” is certainly revealing the intentions of the programmer, and therefore is much easier to read and follow.

Java is great at revealing the internal workings of the library – waitaminute, isn’t that in contradiction to good Object Oriented Design? Aren’t you supposed to encapsulate and hide away your implementation details so that nobody needs to know how they work? Why then do I need to know that a File needs to be read through an InputStream and converted to a Reader and finally read? Why do I need to know that BufferedReader and LineNumberReader are the only Readers that let me read one line at a time?

WHY CAN’T I JUST SAY “FROM FILE PRINT EACH LINE”?

Alan Kay has a very famous quote:

Simple things should be simple and complex things should be possible.

Java makes complicated things possible, and simple things complicated. There is a huge variance between the code you write and the thing you want to be doing. I think the closer those are, the better.

Even if you haven’t heard of any of these programmers, if you have even the slightest interest in programming I highly suggest reading the article. The insights are pretty interesting.