On Scheme

Thoughts on Scheme and teaching Scheme

What Java Did Right

Posted by Peter on May 14, 2006

If you read my blog you probably know that I am no fan of Java. However, Java is a popular language, and because I believe that people are rational that means that it must have some advantages. Obviously Java is not a hacker’s language, nor is it wonderful for quick solutions, or elegant solutions for that matter. What Java does do right is team programming, i.e. any project with three or more people working on it.

First let’s consider Java’s use of types, specifically the fact that they are everywhere. Not a single argument or variable declaration or exception may have its type omitted, even when the compiler could have inferred that information from other sources. This practice is highly cumbersome when you are programming on your own, after all you know what type of arguments your functions expect, because you wrote them, but when looking at someone else’s code it can be salvation itself. Sure your teammates may name their variables inscrutably, but at least knowing the type immediately gives you some hint of what they do. The same argument can be made about Java’s exception handling. Yes it seems silly for the single programmer to declare exactly which exceptions can be thrown, but once again this kind of information is necessary when using someone else’s code. You don’t want to examine the body of the function for throw statements, you want that information in the function declaration where you can see it, and Java gives you this.

Java’s excessive object orientation can also be seen as feature that aids the programming team work together. For example public and private are meaningless in a single programmer’s project, but when working with a team they let you notify your coworkers which functions should be called, and more importantly they provide an implicit promise that you won’t be changing the signature of the public functions. Object oriented programming as a whole also makes it easier to break up who is responsible for what functionality, since the notion of an object that can do certain things is fairly intuitive. Finally, objects, used properly (not singletons), allow programmers working on different parts of the project to both use your code without interfering with each other’s state. For example if you simply wrote a package that exported some methods then it is possible that when the code that programmer A wrote properly using your package and the code that programmer B wrote properly using your package happen to step on each other’s toes when put together (for example the package methods store data in some global variables). On the other hand if your code was an object then A and B would each create their own instances of the object, and there would be no need to worry about shared state.

Now here is the problem: while these features might be nice for teams we want a language that is friendly to the lone coder, so can a language be easy to use in a team project without saddling us with excessive typing and object orientation? Unfortunately I think that no language can, which leaves us with only two options: be able to document everything in the project plan (impossible), or create better IDEs. Ideally the IDE should be able to display visually all the information that Java makes you declare explicitly. For example if the compiler figures out types by inference the IDE should figure them out as well, and display that information where it is useful. Yes I know this doesn’t fix the need for published/public/private functions or objects, I am still thinking about those.

Feel free to chime in with your own ideas.

2 Responses to “What Java Did Right”

  1. inglorion said

    Now here is the problem: while these features [mandatory type declarations and throws clauses] might be nice for teams we want a language that is friendly to the lone coder, so can a language be easy to use in a team project without saddling us with excessive typing and object orientation?

    I think so, yes. Types can be inferenced, and the list of exceptions a method can throw can be determined without explicitly declaring it, too. If this is done, you don’t have to spend time explicitly declaring things, the information is always up-to-date (no need to go and update a lot of throws clauses when you change a low-level method), and you can still get everything neatly listed when you need to.

  2. Magdalena said

    I believe that Java has a common denominator that most other programming languages do not have. It’s far more intuitive to learn for people with a less ‘functional’ mindset (this does not mean that their minds aren’t functioning…). Speaking from personal experience it took me far less time to get to grips with Java than it did with languages such as Prolog, ML or Haskell. Now, I’m aware that the aforementioned languages are better, in the sense that they’re more mathematically pure, and in theory once grasped should be easier to program with. The problem is that not everyone has the same mindset and I think Java bridges that gap very well. That’s just my 2 cents worth…
    P.S I liked

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
Follow

Get every new post delivered to your Inbox.

%d bloggers like this: