Your update is not more important than my work

I love TextMate, but I just saw the most user-hostile, infuriating thing. I’m doing work when all of a sudden I get the pop-up:

 

TextMate forced update

It closed my document (thankfully giving me a chance to save), and now the program refuses to launch until updated.

sigh

CAPTCHAs must die

 

I just tried to leave a post on a site which uses a CAPTCHA to prevent bots from leaving spam comments.  I must be a bot, because I failed the test – not once, not twice… not even three times.  I tried over ten times in a row and it kept rejecting me after offering a new option each time.  I assume this is a software glitch, and I gave up.

 

For the purposes of validating comments, I find CAPTCHAs completely unnecessary.  There’s a better solution – it’s called machine learning.  I use Akismet in WordPress as my spam filter and it performs incredibly well.

 

 

Let the computers do the hard work of spam filtering.  Don’t frustrate and slow down legitimate users by making them fill out these things unnecessarily.  

Java annoyances

Having had Java as the programming language of the vast majority of my undergraduate courses, as well as the language I program in every day, I am most comfortable and fluent in it.  When I return to Java after using different languages such as AWK, Python, or Ruby, I’m always left with a bitter taste in my mouth.  There are some things Java just makes way too hard, verbose, and painful to accomplish.  It’s for that reason that I’m learning Scala, what could be (simplistically) described as a cleaned up, more succint version of Java.

Asymmetry in standard libraries

Symmetry is an important feature of a library; it basically means that methods come in pairs.  For instance, you’d expect that a class with a read method has a write method, or one with a set method has a get method.  (That’s not always the case, certainly, but API writers often strive for symmetry.  See Practical API Design: Confessions of a Java Framework Architect) As another example, there’s both a method to convert from an array to a list (Arrays.asList) and there is a method to go the other direction (List.toArray()).  Unfortunately, not all of the Java library APIs adhere to this convention.  The one that bothers me the most is in the String library.  There is a String split method that breaks a String up around a given regular expression, but no corresponding method to reconstitute a String from a collection of other String objects, with a specified separator between them.  This leads to code like the following to comma separate a collection of strings:

String[] strings = ...;
StringBuilder b = new StringBuilder();
for (int i = 0; i < strings.length; i++) {
 b.append(strings[i]);
 if (i != strings.length -1) {
 b.append(",");
 }
}
System.out.println(b.toString());

This whole mess could be replaced with one line of Python code

print(",".join(strings))

or in Scala:

println(strings.mkString(","))

It’s pretty sad that you have to either write that ugly mess, or turn to something like Apache StringUtils.

Different treatment of primitives and objects

It is a lot harder to deal with variable length collections of primitive types than it should be.  This is because you cannot create collections out of things that are not objects.  You can create them out of the boxed primitive type wrappers, but then you have to iterate through and convert back into the primitive types.

In other words, you can create a List<Double> but you cannot create a List<double>.  This leads to code like the following:

// Need a double[] but don't know how long it's going to be
List<Double> doubles = new LinkedList<Double>();
for (...) {
 doubles.append(theComputedValue);
}
// Option 1: Use for loop and iterate over Double list, converting to primitive values through
// auto unboxing
// Bad: leads to O(n^2) running time with LinkedList
double[] doubleArray = new double[doubles.size()];
for (int i = 0; i < doubleArray.length; i++) {
 doubleArray[i] = doubles.get(i);
}
// Option 2: Use enhanced for loop syntax (described below), along with
// additional index variable.
// Better performance but extraneous index value hanging around
int index = 0;
// Automatic unboxing
for (double d : doubles) {
 doubleArray[index++] = d;
}
...
b[index] // Oops

As I blogged about previously, there is a library called Apache Commons Primitives that can be used for variable sized lists for primitive types, but it is a shame one has to turn to third party libraries for such a common task.

Patchwork iteration support

Java 5 introduced the “Enhanced for loop” syntax which allows you to replace

Collection<String> strings = new ArrayList<String>();
Iterator<String> it = strings.iterator();
while (it.hasNext()) {
 String theString = it.next();
}

with the much simpler

for (String s : strings) {
 // deal with the String
}

Here’s the rub: this syntax is supported for arrays and Iterable objects.  But guess what?  Iterators are not Iterable.  Why is this a problem?  Well, you might want to return read-only iterators to your data.  If you do this, the client code cannot use the enhanced for loop syntax, and is stuck with the earlier hasNext() code.  If you want to use the enhanced for loop syntax to work for Iterators, you need to introduce a wrapper around the Iterator which implements the Iterable interface.  From the previously linked blog post:

class IterableIterator<T> implements  Iterable<T> {
    private Iterator<T> iter;
    public IterableIterator(Iterator<T> iter) {
        this.iter = iter;
    }
    // Fulfill the Iterable interface
    public Iterator<T> iterator() {
        return iter;
    }
}

I hope this strikes you as inelegant as well.

Furthermore, arrays are not iterable either, despite the fact that you can use the enhanced for loop syntax with them.

What this all boils down to is that there’s no great way to accept an Iterable collection of objects.  If you accept an Iterable<E>, you close yourself off to arrays and iterators.  You’d have to convert the arrays to a suitable collection type by using the Arrays.asList method.  It would be great if we could treat arrays, collections, etc., agnostically when all we want to do is iterate over their elements.

Lack of type inference for constructors with generics

Yes, we all know we should program to an interface rather than to a specific implementation; doing so will allow our code to be much more flexible and easily changed later.  Furthermore, we also know we should use generics for our collections rather than raw collections of objects; this allows us to catch typing errors before they occur.  So in other words

// BAD: Raw hashmap and programming to the implementation!
HashMap b = new HashMap();
// Good
Map<String, Integer> wordCounts = new HashMap<String, Integer>();

In fact, this lack of type inference is one reason why Joshua Bloch suggests that static factory methods can be better that constructors – it is possible to have a static factory method that can infer the correct types and instantiate the object, without making you explicitly repeat the type parameters.  For instance, Google Guava provides many static methods to instantiate maps:

Map<String, Integer> wordCounts = Maps.newHashMap();

Fortunately, the problem of having to repeat type parameters twice for constructors is being fixed in JDK 7 with something called the Diamond Operator.  It will allow you to replace

Map<String, Integer> wordCounts = new HashMap<String, Integer>();

with

Map<String, Integer> wordCounts = new HashMap<>();

This improvement to the language can’t come fast enough.

Conclusion

I use Java on a daily basis for about 90% of the work I need to do.  I’m comfortable with it, I understand its syntax, it’s fast, it’s powerful.  After being exposed to languages like python and scala, certain issues in Java stand out in stark contrast, and thus I’ve enumerated a few of the reasons that Java annoys me on a daily basis.  Fortunately excellent libraries exist to correct many of the annoyances, but it’s painful to have to use them to do such basic things as joining a list of Strings with a given separator character, or creating a variable sized list of primitive types. Fortunately Java continues to evolve, and at least some of my irritations will be fixed in JDK 7.

Post in the comments if you have better workarounds than those that I’ve suggested, you have other languages that make these tasks easy and would like to highlight them, or any other reason you can think of.

Give an indication of why a button is disabled

In general, it’s a good idea to disable buttons whose functions cannot be accomplished at the given time.  For instance, if you have a table of data and a delete button that deletes the selected row or rows of data, it would make sense to disable the Delete button when no row is selected, and enable it when a row becomes selected.  This is superior to the alternative choice, which is to leave the button enabled and then indicate some sort of error message letting the user know that they can’t delete an empty selection, when they try to press it.

An example of an enabled and disabled button

If you do go down the route of programmatically disabling buttons, it is absolutely crucial that you give some indication as to why the button is disabled.  In the previous example, a savvy user could probably figure out that the delete action doesn’t make sense when there are no rows selected.  This isn’t always the case.

I dealt with an application recently where validation logic was spread across four different tabs, where each tab had a checkmark indicating that it was filled out correctly.  When I finally managed to get all of the tabs to show that they were in a valid state, the final button to complete the action stubbornly remained disabled.  I have no idea what the problem is, and there’s no indication whatsoever in the application.

The easiest thing the programmer could have done to give some feedback to the user is to provide a tooltip on the button that indicates why the button is disabled.  Perhaps a better solution would be to provide a small text pane in which the error messages would be displayed; this has the benefit of working with devices which do not have a mouseover tooltip capability (e.g. iPhone, iPad).

While it would have taken a little more effort on the part of the designer and programmer to make that screen more usable, it would have saved me the past two weeks of trying to solve the problem and waiting for their technical support.  Let that be a lesson for you.