This post originated from an RSS feed registered with Ruby Buzz
by Obie Fernandez.
Original Post: Ben Loritsch, Future Rubyist?
Feed Title: Obie On Rails (Has It Been 9 Years Already?)
Feed URL: http://jroller.com/obie/feed/entries/rss
Feed Description: Obie Fernandez talks about life as a technologist, mostly as ramblings about software development and consulting. Nowadays it's pretty much all about Ruby and Ruby on Rails.
Actually, I have no idea how Ben feels about Ruby, but he offers an insightful, must-read assessment of balancing between harsh typing and latent typing. I love that term harsh typing. It really conveys the pain of working with Java once you're aware of the alternatives.
Java's generic facility is prone to erasure so you have to bastardize generics to the point where something has to implement an interaface or base class to be used properly. In theory that would be good enough--except that in reality it isn't. Being one of the principles on the Avalon project, I can't tell you how many times I heard that other projects didn't want to use the Avalon framework because it "poluted" their application with all these interfaces outside the package space that they were using. After all, what if they wanted to use com.bigot.Framework.initialize() instead of org.apache.avalon.framework.Initializable.initialize()? They both perform the same function and they both have the same intent--but you can't use them interchangeably in Java (you could in C++, Python, Ruby, JavaScript, Boo, Groovy, etc.). This is a real problem, and part of the reason we have a rash of Not Invented Here (NIH) syndrome. You could argue about using attributes/annotations for the same function (i.e. mark whatever initialize method you want with the @Initializer annotation) and use reflection. But guess what? Now we are back to wanting to use duck typing for this solution. We are subject to all the same issues with duck typing in Java due to using annotations for what an interface should be able to do.
Previous Topic
