Well, if you were wondering who my evangelist colleague was in my “Dynamic Languages: Rationalizations and Myths” blog, wonder no more. Please go read Steve Vinoski’s comments, they are a good read. One of my major points against dynamic languages was the inability for an IDE to provide reliable refactoring for them. Steve attacked this with a considerable amount of drivel. Here’s some good blurbs:
“The contrived Ruby example that Bill uses to “prove” [that dynamic languages can’t do reliable refactoring] is, well, contrived. Why would anyone write code like that or suddenly get the urge to rename init to init2? I’m no Ruby expert, but I’d probably rename the method and then stick a method_missing in there to catch any call instances I might have missed with my editor. “
Contrived my ass…Like I said in my previous blog. I write sucky code. I am constantly renaming methods, extracting methods, combining methods, renaming classes, deleting unneeded methods, fields, classes all the time. I never get things right the 1st time and rarely get them right the nth time. Steve, 99% of us are not the uber programmer you are. And, what Steve? Am I going to have to do a constant edit/test/edit/test continuously until I get my edits right? Sounds a lot less productive than having the IDE automatically and reliably do it for you with one click. Again Steve, I used to be in your world. Not as long as you, but still a considerable amount of time.
“I asked him if these magical modern IDEs that raise productivity and eliminate common errors also eliminate defects caused by missing or misunderstood requirements, missed use cases, or just plain ol’ bad programming. Again, no answer. The reason I asked this is that those are the bad bugs; syntactical errors are really the least of your worries. Even if the IDE spits out common idiom/pattern skeletons for you, it’s still quite possible to screw up the code logic, and neither the IDE nor the compiler is going to prevent that.”
Nice strawman Steve. When did I ever say or infer this? How is implementing in a dynamic language going to “eliminate defects caused by missing or misunderstood requirements”? It sure is going to be a hell of a lot easier to refactor your codebase to fix these problems, but eliminate? So Steve, are what you really saying is “IDE’s are not going to eliminate your bugs or poor design”? Thanks for stating the obvious. What I keep telling you is that I’m going to be 10 times more productive with a statically typed IDE when I try to fix these poor designs and logic.
“Considering how old Java is, it’s obvious that it’s taken quite a bit of time to get these IDEs to where they are today. I asked Bill if everyone should have to wait a long time, on the order of 10-15 years, before an IDE truly becomes valuable for a given language. No answer. Personally, I’d rather stick to my emacs and UNIX tools, with their infinite applicability and flexibility that can be used for development in pretty much any language, than wait around for someone else to give me a far less functional IDE that barely addresses only one language. But then again, if one language is all you got, then I guess you have no choice.”
Reality: One, I don’t remember him asking me this. Two, I think that IDEs (at least Intellij) are so well designed now that they can easily support a variety of languages fairly quickly. Add to this fact that their APIs are open (not OSS, but open) and have a great community. For instance, on a quick search I found plugins for Ruby, Python, AspectJ, XML, XML Schema, and Scala. The interesting thing about Intellij, is that it also has support for frameworks. For example, it has syntax checking and code completion for embedded Hibernate/JPA QL. Refactoring integration between Spring, JavaEE and Java. I haven’t looked at their RoR support, but I bet it is awesome. I continually find it AMAZING how these guys bang things out. They are either an army of people (doubtful) or just have an incredibly architected product (probable).
“I asked Bill if he’s ever considered that Java IDEs are the way they are due to issues with the Java language itself that must be compensated for. Consider its verbosity, for example, which is why IDEs spit out those skeletons.”
Reality: Let me go through the list of Code Gen and Refactoring items and see what is not useful in, let’s say, Ruby. There are 30 refactorings in IntelliJ + Java. Only 8 out of 30 are NOT useful to Ruby. For the “Generate..” code generation tab. 2 out of 5 are not useful for Ruby. I think the “Surround With..” tab is useful. The thing is, out of these 35 things, I *DO* use one of them *at least* every 10 minutes. This is of course assuming you believe that the unuseful things are because Ruby is a better language (I don’t beyond the closure stuff). I will admit that only 5 of the refactorings require a statically typed language to be *reliable*, but, at least for me, I do use these particular ones very very often, especially after the first prototype. (rename, move, safe delete, change method signature, inline). At least with Intellij, parameter types are also extremely useful with code completion. Good code is self documenting and with IDE code completion, I don’t have to look at a manual or source code comments to find out how to execute a method on an object. BTW Steve, what “skeletons” are you talking about? MDA bullshit? Or the crap I rarely use?
“Saying that “my buddy Jason was on a team that had to put type names in their Python function names” is certainly not even close to being solid evidence of your claim, Bill.”
Steve, I think Jason’s experience was a relevant experience. I wrote about it because I thought Jason’s experience was the funniest story I’ve heard. It sure isn’t the only horror story people have had with lack of static typing.
Bill the Plumber 
Feb 06, 2008 @ 05:56:35
Bill, you should try to stop contradicting yourself. In your previous posting you were complaining about the fact that the magic of modern IDEs could not be applied to dynamic languages because they lack static typing, but now in this posting you’re pointing out how all these IDEs do in fact support all these dynamic languages. What exactly is your actual point again?
I’m sure I’m not alone in thinking that your buddy’s story isn’t funny at all, but is instead quite sad. Clearly, their putting type names into Python function names was intended to help only the human programmer, not the Python runtime or libraries. So why not use the Python features intended specifically for assisting the programmer? If they were really having trouble tracking function expectations, it might have been because they were erroneously trying to use and enforce static language approaches rather than taking full advantage of the language’s dynamism. Obviously, I don’t know for sure because I don’t know any of that project’s details, but I’ve certainly seen this issue cause problems for other dynamic language development efforts. At the very least, a more useful approach for them, as I mentioned in my blog, would have been to fill out each function’s docstring and make it as descriptive as possible. The docstrings are readily available to the developer from the Python interactive prompt, and they would have been way more useful to your friend’s team than their Hungarian notation variant.
Feb 06, 2008 @ 12:57:09
Maybe you should stop being a programmer, then.
Feb 06, 2008 @ 14:32:06
Steve, I didn’t contradict myself. Go reread what I’ve been writing. If you read between the lines, I’ve added a lot of greyness to my arguments.
As far as the Python docstrings, I still stand by my statement that self-documenting code is far superior.
Feb 06, 2008 @ 15:59:47
Liam wrote “Maybe you should stop being a programmer, then.”
Nah, most developers write sucky code if they are man enough to admit it. In my case, I need an artificial productivity enhancer to bridge some of the gap between myself and developers like Steve. And I’m *not* being facetious here!
Feb 06, 2008 @ 16:25:11
It’s chicken-and-egg. If you use dynamic languages that do not (except for Smalltalk) have good IDE support for refactoring you learn to work in a way in which you do design outside the code (in your head, on paper, etc.) before committing the design to code.
If you use an IDE that has strong refactoring capabilities, you can use the code itself as your scratch-pad, so you learn to work in a way in which you experiment with live code rather than imagined or pencilled code that must later be typed in.
Feb 06, 2008 @ 16:56:45
There are better things for both of you to do with your limited time.
Feb 06, 2008 @ 16:58:46
Nat, awesome observation. I used to be the in your head, on paper guy, and now I’m moving towards the IDE approach. What I saw was that a lot of Smalltalk developers (particularly Gavin) behave, in respect to developing with an IDE, as you describe. It is taking me awhile to adapt to this method, but, I’m finding it better in most circumstances.
Feb 07, 2008 @ 02:21:12
I don’t really fit into this discussion in any sense, but I have to say I don’t agree with Steve when he says IDEs do not find more than syntactical errors. I don’t know about many IDEs since I have been hooked up with IntelliJ IDEA for so long that there is no other IDEs in the world for me, but IDEA actually captures very small and hard to find problems. Some of those really depend on its ability to understand types and their static binding + whatever dynamic binding they can have. So I argue these things are more or less impossible for a dynamic language. As an example, the following code is obviously wrong:
public class TestIde {
public static void main(String[] args) {
Object obj = getSomeObject();
if (!(obj instanceof Double))
return;
System.out.println(">>> size = " + ((String) obj).length());
}
public static Object getSomeObject() {
return (double) 10;
}
}
since when the code gets to the system out point the obj is definitely Double or something that extends Double, the cast is going to throw an exception because String is neither of them. IntelliJ IDEA here highlights the cast and tells you the cast is not going to work. You may argue this is a stupid code and one should not write a stupid code. However, this is just an example. In my own experience, I have always had to maintain someone else’s code and I have always had to change something in the middle of a method and it is easy to ignore Ifs like what is in the example above, specially if the two parts of the code don’t fit in screen so that you see them both at the same time.
Well, that’s my two cents 🙂
Mar 19, 2008 @ 12:29:37
“I asked Bill if everyone should have to wait a long time, on the order of 10-15 years, before an IDE truly becomes valuable for a given language.”
Intellij came much earlier than 15 years or even 10 years after Java was invented. Just do some research before stating facts. Tip: Google it (if you can’t do that as it seem to be the case, it’s 5 years)
Peace
-stephan
Mar 19, 2008 @ 12:30:55
(Fowler wrote the refactoring book in 1999, 4 years after Java)
Peace
-stephan