What are the biggest design errors in popular languages or libraries?

Question

For the popular languages and libraries we use every day: What are examples of some bad design, embarrassing APIs, or generally bad usability? Design errors that we have to pay for because they introduce subtle bugs, we have to use awkward workarounds or memorize unintuitive ways to get things done.

I'm especially thinking of issues like: There's a class in an OO language that really shouldn't inherit from that other class. There's special operator that makes a certain language hard to parse, and it turned out to be unused anyway. A function that's misnamed or is often in use for other things than it was designed for (I'm thinking of std::getline to tokenize strings).

I'm not looking for contributions that bash languages and claim that, say, Perl or some other language is just badly designed. I'm more looking for concrete examples or anecdotes about things that clearly should have been done differently. (Maybe the designers caught it too late and tried to fix it in subsequent versions, but had to retain backward compatibility.)

Answer 1

Java class called "NullPointerException"

Having migrated from C++ to Java I always found it amusing to find a NullPointerException in a language with "no pointers"

Answer 2

Java's URL class does (or did, a few years ago) a DNS lookup when determining the hashCode of a URL object. So, not only is a hash table with URLs as keys extremely slow, but it can change at runtime if two successive DNS requests return different values or you unplug the network cable!

Answer 3

http://www.infoq.com/presentations/effective-api-design

Skip to about 40 minutes and he talks about some of the XML APIs in Java.

In general, it's a pretty interesting presentation.

Answer 4

My favorite comes from the world of Smalltalk. Squeak to be specific. In Squeak the Semaphore class inherits from LinkedList. Semaphores may utilize linked lists, but they are not linked lists themselves. This makes for a very odd interface. This is terrible OO design.

Answer 5

API's where functions return null when they should return empty items...and then don't document when, how, or why they'll return null.

Answer 6

The majority of C++ is design flaws yet most people learn to live with it. [Ducks for mass of haters downvotes]

Answer 7

I found one in Ruby's Dir.glob().

I haven't been able to prove it's not related to my particular environment yet, since my environment is old and cobbled together by hand and I need to continue to support it unfortunately. There seem to be at least 5 cases:

• Directory has files and some match -> List of those files
• Directory has files and none match -> Empty list
• Directory is empty -> Nil
• Directory exists but the current user can't read it (don't know what happens here)
• Directory is missing (haven't tested this either)

It had me pulling my hair out because the documentation doesn't describe it that way.

Answer 8

Checked vs. unchecked exceptions in Java. Most Java developers either don't know when to use which, or, if they do, they disagree.

Then we have things like IOExeption which you can never handle them when they occur but have to throw them up (in all senses of the word). When you have finally reached a place where you can handle them, you have no idea how to figure out what might have caused them, so you can only present the user with the message and stack trace and hope she can figure it out (here "she" is normal user who knows that Java is a kind of coffee).

Answer 9

PHP has a good bunch of them, the ($needle,$haystack) ($haystack,$needle) inconsistencies. The string functions with mb_ prefixed to them to enable multibytesupport. My favourite mysql_escape_string and mysql_real_escape_string... Lets not get started on the OO part... :)

Answer 10

My personal favorite is atoi of the C standard lib.

int atoi ( const char * str );

• On success, the function returns the converted integral number as an int value.
• If no valid conversion could be performed, a zero value is returned.

Well, unfortunately it's painful to convert "0" with this function as you never sure if it was an error or "0".

Answer 11

Java "Calendar" API. It is error-prone and hard to use.

To enumerate just a few of the problems:

• misleading name: a Calendar object is supposed to model a "calendar system", but in practice encapsulates a time object, i.e it is a kind of Date (which is itself a problem, since Date should better be named DateTime or TimeStamp)
• there is only one concrete subclass of Calendar (GregorianCalendar), but the abstract Calendar class contains constants only useful in this specific case (JANUARY, MONDAY, AM_PM, ERA)
• you modify fields by using constants ("MONDAY", "WEEK_OF_MONTH" etc); these are integers and can be mixed up rather easily.
• in fact, just about every argument and return value is an integer; the usual problems with 0- and 1-based numbers apply (is January 0 or 1?=
• constants like "HOUR" and "HOUR_OF_DAY" that only make sense when the AM/PM system is used (which nobody outside the US understands anyway ;-)

Answer 12

In Java I would go with InterruptedException being a checked exception. If you need to know that your sleep method woke up early, that should have been a boolean returned from the method. Nothing gives checked exceptions a bad name like InterruptedException.