Putting the Soft back in Software
Sunday, May 29th, 2005Or why Java is still around: Bill de hÓra: No more nails: making good technology choices
Or why Java is still around: Bill de hÓra: No more nails: making good technology choices
Yesterday I stumbled upon Guido van Rossems weblog and I was struck once again by how beautiful and simple expressions in Python can be.
In a post about some complicated functions that aren’t really needed (filter(), map() and reduce()) he showed elegant other ways of creating lists on the fly. I had always known they were there, but by showing them here I hope to remember them a bit better… Anyway, on to the examples:
[x for x in S if P(x)]
and
[F(x) for x in S]
In this last example, most of the time you don’t need to even create the list, you can just use a generator expression. For example:
max(len(line) for line in file if line.strip())
Now I am not even beginning to think about how to write this in Java.
Programming in Java is like having a really short attention span.
Let me explain why I am saying this: If you program according to the OO principle, you keep your methods/functions short. This means that most of your function calls are internal, to methods you wrote yourself, to do some work on objects you created yourself. However, if you program in Java you need to check the data type everytime you do a function call or even in function calls where you need to create temporary variables (e.g. when you want to do something with every element in an array).
In other words, I give you an apple, you take it, check if it’s really an apple and take a bite. So far so good. But then you want to put it down: you have to determine it really is an apple and put it down. Say you change your mind right after you put it down. Then you’ll have to determine if that object you left at that exact spot over there is really an apple, pick it up, check if it’s still an apple, take a bite, etc.
Now even with using Eclipse this means you have to do a whole lot of finger typing and brain cycles to make the compiler happy with things you know already and can cope with in your program easily. Especially using test-first coding and proper tests, this compulsive checking of types is really unnecessary.
I wrote earlier about effort versus ease of reading. Now that I know a bit more about this, I got into several discussions with some friends about Java and Python, more specifically about strong versus weak typing. Now I had read some things about that a while ago, but I could not recall the specific arguments for or against the typing scheme. This entry summarizes some of these differences and will contribute to (future) discussions.
In an interview Guido van Rossum mentioned that while it is important to detect programming errors as quickly as possible, strict typing will not detect all the bugs in your program. The strict typing idea will focus the programmers attention on getting the types right, but not necessarily getting the rest of the program right.
In versions of Java previous to 5.0 it was even worse if you were using arrays or arraylists, because everything you got out of there was of type Object and the programmer must track himself to which type it has to be cast back. This not only makes for more work, but also for more room for error, because the programmer ‘just’ casts it back, not thinking about what might happen if that cast fails. Python makes it very easy for you, because containers are generic there, but everything you put in there, comes out the same way.
As I said, with Java 5.0 this is easier, because you it allows for more generic programming now, but still, a lot of typing is focused on getting types right, which I feel is not necessary for about 90% of the variables you use.
In this blog entry of Bruce Eckel he mentions the fact that strong or weak typing is a matter of preference and that it is good for programmers to learn about the possibilities of both. It allows you to think better conceptually and use the ideas of both.
It might be true that strong typing would work for some people, but I still feel that it gives you a false sense of security. Especially if interaction with other programs or the user is required, because then you should always be on your toes about the value or types of things that are returned. Strict typing will not help you there.
Another blog entry at artima.com from Robert C. Martin reflects much of how I feel about strong versus weak typing. The idea is that test-first coding keeps your code straight and to the point and if done right, you don’t need the strict typing to get correct results.
In a pretty good article titled: Scripting: Higher Level Programming for the 21st Century is a picture that says more than a thousand words.

As seen on the TextMate mailinglist:
I have no idea who that is, but he’s terribly right.