It’s the little things…

Yesterday I was writing some java code, and I needed to count the number of occurrences of a character in a String. I wanted to stay in pure java and not introduce a library dependency, so I ended up writing this code:

  int count = 0;
  for( int i = 0; i < str.length(); i++ ) {
    if( str.charAt( i ) == '.' ) {
      count++;
    }
  }

This is a preposterous amount of code to write for such a simple and common problem. There is a hilarious thread on Stack Overflow on how to do the same thing:

  http://stackoverflow.com/questions/275944/how-do-i-count-the-number-of-occurrences-of-a-char-in-a-string

In Gosu, via CoreStringEnhancement, the code is simply this:

  var count = str.countMatches( "." )

There are big features in Gosu that make development more productive that we bang on a lot publicly (type inference, closures, and the The Open Type System to name a few) and rightly so. But these small things make a huge difference in day to day coding as well. It’s not like the code for these convenience methods are hard, it’s just that the methods are there and in a place you can find them.

The culture of Java has never emphasized making the easy stuff easy. A favorite example of mine is the code to read a file. Contrast that with how you do so in Gosu:

  var content = new File( "foo.txt" ).read() 

One of my pet theories is that the reason that dynamic languages get better, easier-to-deal-with libraries is that, since they don’t have good tool support, library developers simply can’t adopt the baroque APIs that Java developers have become used to. This creates a culture and a set of expectations that a library will be simple to get going with and will scale up in complexity only as necessary: otherwise the library just never gets off the ground.

We are aiming to capture that same culture of simplicity in Gosu, while retaining the advantages of a statically typed language.

---