Statically Typed Foreword
Robbie asked me to write a foreword for his upcoming Guice book. Having never written a foreword before, I Googled, "how to write a foreword," which brought me to two helpful posts from Muse Ink: Foreword Thinking and Foreword March.
Here's what I came up with:
I created Guice in the midst of one of the biggest projects of my career. When you have hundreds of engineers touching millions of lines of code, you come to appreciate the benefits of static type checking. Static types aren't just about compiler errors. In fact, I rarely see Java compiler errors nowadays. Thanks to all that great, formalized Java type information, my IDE helps me write correct code in the first place.
Writing your application in a nearly 100 percent type safe manner, like Guice enables and Robbie advocates in this book, opens the door to a new level of maintainability. You can effortlessly navigate unfamiliar code, jumping from interfaces to their implementation and from methods to their callers. As you master your Java tools, you realize that deceptively simple atomic refactorings combine to form molecular tools, which you can reliably apply to companywide swaths of code, accomplishing refactorings you'd never even consider trying by hand. In the long run, it's much cheaper to ward off bit rot through heavy reuse and constant refactoring than by nuking the world with a rewrite every couple years.
Having experienced Guice's benefits on a number of projects, we at Google knew we couldn't keep it to ourselves and decided to make it open source. Readying Guice for the outside world felt like it took an order of magnitude more work than writing that first internal version, but community contributors like Robbie who fuel the forums, help polish rough edges, and generate excellent documentation like this book pay back that effort tenfold. You'll find that Robbie's brevity and conversational tone suit Guice well. I like my books like I like my APIs: with high power-to-weight ratios.
I focused on static typing because I've gotten a lot of questions about it lately. There's a lot of misinformation out there. For example, some people incorrectly conflate static typing with compiler errors, and, based on that false foundation, they claim that unit testing is an adequate substitute for static typing.
Static typing and unit tests are orthogonal. Static typing doesn't replace unit tests. Unit tests don't replace static typing. In fact, static typing can make maintaining unit tests much easier, especially when paired with the right mocking framework. I certainly believe that scripting languages have their place; beware anyone who tells you that static typing doesn't.
19 Comments:
Two quacks here for duck typing. Most of my Java code makes heavy use of reflection. If you've got the method, let me call it. I don't care that I never even anticipated that classes of your type might exist. Hard to do statically unless you are creating separate interfaces for each method...hmmm, I could write code to generate that code.
I guess your main point here is refactoring is made more powerful by static typing. It does seem like the tool support for it in Java is better, so, empirically, there is evidence to support your claim. However, theoretically I don't see what that would be the case in perpetuity.
I find that a lot of that big time refactoring stuff didn't work well with Spring, Hibernate, etc., as there was always an XML file (or annotation) somewhere that wasn't getting changed. I guess it's cool if Guice makes this go away.
Maybe the counterpoint is that code that isn't statically typed doesn't have to be refactored as often since there are other ways of accomplishing the changes?
How do you think AOP affects static typing? It seems like it takes away some of the benefits, much like some of the configuration based reflective code does.
Good points on the static typing vs. unit testing silliness. I don't know anyone who was trying to say that static typing replaces unit testing, but, if they were...well, they deserve whatever you can dish out.
Congrats on the jolt, well deserved.
Looks good
Joshua Bloch opened my eyes about static typing when he talked about GWT in a conversation on a conference somewhere.
He said that static type checking enables you to catch a lot of error before your program actually runs. It cannot catch every error of course - some might pop up at runtime only - but with other languages that do not support static types you are forced to run your program to see if it does what you want.
The more complex your code is the worse this gets, because you are not able to check your "rocket" for basic errors before it actually takes off.
I am reminded of how true this statement is whenever I hear my Javascript colleague scream "Why is xy not defined??". ;)
just out of curiosity, why easymock over jmock?
@Matt: Thanks for the comment. I didn't go into much detail in this blog because I didn't want to get too far off on a tangent. Let me see if I can address some of your questions.
I used to make heavy use of reflection, too, and I still do, but now I try to do so in much more limited ways which doesn't sacrifice type safety. Guice is one example. EasyMock is another great example. This makes frameworks harder to implement, but it's better for users. I think this is where all Java frameworks should be headed.
Duck typing: I don't run into too many cases where I want to call the same exact method in two different classes which don't implement the same interface. In the majority of cases where I do, the two methods are slightly different, and I have to implement an adapter anyway. I don't want to write the same adapting code every time I call the method, so I abstract it behind an interface. The nice thing about explicit interfaces is that they not only help people use them, but they also help people implement them.
Java tools: I'm not saying that Java tools are there yet. They definitely have a long way to go. What's important to me is that they're already useful, they can go further and are going there, while languages like Ruby inherently limit how far tools can go by not capturing enough information.
@Daniel: Yeah, I think GWT is the future of Java web frameworks. It's simple, typesafe, and powerful.
@Gregory: EasyMock was the first mocking framework to take advantage of the Java 1.5 features to make dynamic mocking typesafe. It's still more typesafe than jMock. Also, jMocks API looks weird by comparison. It's as if they're just trying to be different from EasyMock.
I would add lightweight to the list of GWT characteristics. Especially when you compare its Composites to JSF custom components. And ridicously fast thanks the the RPC mechanism.
GWT is the way it should always have been.
I wholly concur on the static typing question. In fact, static typing is just one kind of many static guarantees made by a language (another is for eg., lexical scoping) that help you reason about a program's a priori semantics.
Unit testing is about verification of those semantics, i.e. a posteriori reasoning.
I highly recommend reading "What To Know Before Debating Type Systems":
http://cdsmith.twu.net/types.html
bob said: I don't want to write the same adapting code every time I call the method, so I abstract it behind an interface. The nice thing about explicit interfaces is that they not only help people use them, but they also help people implement them.
I agree that interfaces are nice, I just like to have one for each method... ;-) I tend to click on the "extract interface" too much, perhaps.
Visited a talk of Robbie yesterday. The idea of it was for him to talk about Guice and Alef Arendsen about Spring. I think Robbie did a fairly good job in a crowd where only one guy (me) ever touched Guice and the rest of 'em didn't.
I really hope you make the effort of submitting a JSR as I believe it is time to standardize IOC in the language. I'm biased of course, but I do think Guice has what it takes to becoming the definitive way to do IOC in Java. The features for Guice 2.0 you also talked about at JavaPolis/Javaposse sound great!
O and... I thought one thing was clear from both talks - people at Springsource are now trying to keep up with the way Guice deals with IOC - but still aren't there yet. They are slowly but surely leaving their initial fright of annotations.
Thanks for the update, POJO.
Hi,
I very like to use mock objects for testing purpose. It is really easy with Spring - just have several .xml files to define your beans.
One for "production" and one for testing with mock objects.
How wan i do something like that with Guice? Can one have 2 or more configurations? I did not manage to find how to do that - maybe i did not search well, that is possible.
I think i read that there is a "profile" in Guice. Is it what a way to do it?
Hope this question is not too rtfm-able...
Gabriel, you just swap in a different Module.
Thx Bob! It was so simple ...(ok ok.. sounds like i did not pay enough attention to the "Startup" chapter in the sample Guide!)
The book is out on the 14th?
It's already out!
My partner and I currently have a project called Notibreve.com. We have 10 programmers working on it full time in Venezuela. (EJB3 – postgress Jboss4.2, tomcat, eclipse)
It’s a combination of- youtube /cnn/yahoo. We allow journalist to write their stories, while helping them get a job. We just forward our developers Guice to see if it could help us with the speed of development. You see Chavez is taking down anyone that opposes his views and Notibreve is a site that is for journalist, which mostly oppose him. He only has one TV station left, Gobovision. After that, he will have total control of the Media in Venezuela. Anyways, we hope that we can develop this platform before he shuts us down. :( -- You know, freedom of expression is something we take advantage of here in the US and We hope your code can help us.
I have a man-crush on you right now. Static typing is grossly under-represented. This kind of clarity is so important. (Side note: Guice powers my site, our team loves it! thanks.)
Hi bob!
May I ask a question about Guice?
How to get Binding Annotation information in Provider?
say
@BindingAnnotation
@interface Property {
String value();
}
class DBService {
@Inject
@Property("db.url")
String url;
}
class PropertyProvider implements Provider<String> {
String get() {
//Can I acquire the value of Property corresponding here?
}
}
Post a Comment
<< Home