Friday, March 12, 2004

Type Safety and IDEs

The speaker at a local Java User Group meeting, mentioned his dislike for strong type safety, giving the usual reasons: high overhead in type safe languages, quick turn around with loosely typed languages, and the relatively small amount of errors caught by compile time checking. In a seemingly unrelated discussion, he mentioned his preference of code editors: Emacs. It occurred to me that I�ve never met someone who likes strongly typed languages AND uses a modern IDE. I believe the two preferences are closely related.

Those who use a text editor to write their code, have to compile their code AFTER they write it; only getting the benefit of compile time checking in small iterative batches. Even those who use inferior IDEs have to save their work and wait for the source to be parsed to see any compile time errors. Those using modern IDEs (such as IntelliJ IDEA) get to see their compile time errors as they type (it even offers to fix them for you with a keystroke).

Even with that aside, I believe compile time checking is only a minor benefit of strong typing. The greatest benefit is the added level of self-documentation provided by type checking. An object has only so many methods, and depending on its reference only a portion of those may be visible. With a good IDE, you have complete access to all the possible method calls for an object. You can quickly scan the list for method names that make sense, and even consult the method�s documentation without leaving your code. With only basic knowledge of an API, a programmer can immediately become productive.

I don�t believe anyone who uses Emacs could fully appreciate how much more productive these hints can make the average programmer. If you use VI to edit Java code, then you have to use an html browser to read the documentation, and type everything on your own. Since type safe languages have more ritual, the VI user gets all the downside of the type safe language and none of the advantage. Of course, from that point of view, switching to a loosely typed language is going to feel MUCH more productive.

I don�t have anything against loosely typed languages, or using VI as an editor. I happen to be learning Ruby and am enjoying it a lot (although I miss my IDE). I just don�t like hearing otherwise respectable people preaching about the huge productivity gap between strongly and loosely typed languages. I think it�s all in the tool.

UPDATE:

This last post was a bit sloppy, and a few people called me on it. I�d like to clarify some of it and take a couple things back.

First of all, I used the phrases �strongly typed� and �staticly typed� interchangeably. This isn�t correct. You can read more about this here.

I would also like to clarify my point a bit. I don�t believe that any type of inline code generation (live templates in Idea) are a good substitute for simply ridding the language of the need for such code. Less is more. When I talk about programmers being more proficient with a strongly typed language, I was referring to �average� programmers. The learning curve with such languages is not as steep because the languages are somewhat self-documenting. Sure, once a programmer is proficient in all the APIs they use on a daily basis, productivity can be measured in keystrokes. But beginner and intermediate programmers spend much more time looking up API information than typing. And in my experience, intermediate programmers outnumber expert programmers by a very large margine.

Either way, after reading this entry in Martin Fowler�s blog, I�ve come to realize this is just a difference in point of view. I�ve spent the last few years of my life working with complete newbies to Java/OOP. Those experiences have pushed me whole-heartedly into what Martin Folwer refers to as the Directing Attitude of software design. I can understand where these features would be very helpful to someone who can handle them, but I�m just not optimistic that enough of these programmers exist. I just know too many people who rely on a strict interface to push them in the right direction.

Labels:

0 Comments:

Post a Comment



<< Home