I found an article on OnJava.com from last year about Generics. In the article the author Budi Kurniawan states that...
Let's start with the first point. I think that the most important feature of Java 5 are annotations. Annotations by themselves are not too exciting, but the tools and frameworks that will use annotations I think will be very exciting.
The author's second conclusion I think misses the mark as well. Yes, I agree, it is very useful to have type checking for collections at compile time, but it is fairly rare to see this type of bug make it into production code. His second point about eliminating the need for type casting is only useful because programmers are lazy creatures. I contend that both of these are useful, but I think that there is a more important contribution. The contribution I am speaking of is that generics now makes it possible to increase the usefulness of the IDE.
<flashback>
I have worked with many languages over the years, and dealt with a lot of editors and IDE's. One of the biggest improvements in IDE's that I ever witnessed was when the Visual Basic IDE added code completion. Code completion (for those living under a rock) is when the IDE can list the methods and properties available to an instance of an object. This allows you to code more quickly because code completion means less keystrokes and it makes it easier to use a library that you aren't too familiar with. In dynamic languages like Perl, Python, JavaScript, and Ruby you don't see good support for this, if any support at all. That is to say that dynamic languages are very useful, but it does make it a little harder to use because you need to either know the library calls by heart, or have a good reference available.
</flashback>
Generics not only aids code completion, but also code documentation. The tools available can now document what type of objects a list can hold without the programmer documenting this by hand. All of this is tied to ease of use, greater productivity, and greater accuracy.
I strongly believe that the future of programming will be about the tools. It won't be rapid development tools (like Ruby on Rails) that will dominate the future, it will be IDE's that can bear the brunt of the coding and design task. The more advanced the tools get, the easier it is to build an maintain larger and complex applications. I am a fan of static languages like Java and C# for large applications because of the tool support. I am also a fan of dynamic languages like Perl and Ruby, but only for smaller applications, because the tool support is lacking.
One note about Ruby on Rails. RoR has one advantage that helps propel the tool, and that is that it hides a lot of complexities of coding a web application. This means that instead of having to write database code, RoR does it for you. I don't think that this is enough for some applications though. As the application lets larger and more complex it may be impossible to avoid writing the things that RoR tries to hide, and at that point RoR loses it's advantage.
<disclaimer>
The web is evolving, as are the languages and tools. There is also so much currently available it is impossible to know everything. Thus, I proclaim that this article is based on my opinion at this particular point in time. As I learn more I will almost undoubtedly change my mind.
</disclaimer>
- "Generics are the most important feature in J2SE 5.0"
- "generics make two contributions..."
- "they add type checking to collection types at compile time"
- "generics eliminate the need for type casting when retrieving an element from a collection"
Let's start with the first point. I think that the most important feature of Java 5 are annotations. Annotations by themselves are not too exciting, but the tools and frameworks that will use annotations I think will be very exciting.
The author's second conclusion I think misses the mark as well. Yes, I agree, it is very useful to have type checking for collections at compile time, but it is fairly rare to see this type of bug make it into production code. His second point about eliminating the need for type casting is only useful because programmers are lazy creatures. I contend that both of these are useful, but I think that there is a more important contribution. The contribution I am speaking of is that generics now makes it possible to increase the usefulness of the IDE.
<flashback>
I have worked with many languages over the years, and dealt with a lot of editors and IDE's. One of the biggest improvements in IDE's that I ever witnessed was when the Visual Basic IDE added code completion. Code completion (for those living under a rock) is when the IDE can list the methods and properties available to an instance of an object. This allows you to code more quickly because code completion means less keystrokes and it makes it easier to use a library that you aren't too familiar with. In dynamic languages like Perl, Python, JavaScript, and Ruby you don't see good support for this, if any support at all. That is to say that dynamic languages are very useful, but it does make it a little harder to use because you need to either know the library calls by heart, or have a good reference available.
</flashback>
Generics not only aids code completion, but also code documentation. The tools available can now document what type of objects a list can hold without the programmer documenting this by hand. All of this is tied to ease of use, greater productivity, and greater accuracy.
I strongly believe that the future of programming will be about the tools. It won't be rapid development tools (like Ruby on Rails) that will dominate the future, it will be IDE's that can bear the brunt of the coding and design task. The more advanced the tools get, the easier it is to build an maintain larger and complex applications. I am a fan of static languages like Java and C# for large applications because of the tool support. I am also a fan of dynamic languages like Perl and Ruby, but only for smaller applications, because the tool support is lacking.
One note about Ruby on Rails. RoR has one advantage that helps propel the tool, and that is that it hides a lot of complexities of coding a web application. This means that instead of having to write database code, RoR does it for you. I don't think that this is enough for some applications though. As the application lets larger and more complex it may be impossible to avoid writing the things that RoR tries to hide, and at that point RoR loses it's advantage.
<disclaimer>
The web is evolving, as are the languages and tools. There is also so much currently available it is impossible to know everything. Thus, I proclaim that this article is based on my opinion at this particular point in time. As I learn more I will almost undoubtedly change my mind.
</disclaimer>
No comments:
Post a Comment