From: Nicholas Van Weerdenburg Date: 2005-01-29T05:17:32+09:00 Subject: Re: Ten Things Every Java Programmer Should Know About Ruby On Sat, 29 Jan 2005 00:40:14 +0900, James G. Britt wrote: > On Fri, 28 Jan 2005 23:38:14 +0900, Hugh Sasse Staff Elec Eng > wrote: > > On Fri, 28 Jan 2005, James Britt wrote: > > > But each can have significant influence. If you are trying to write > > > something out in longhand , and your pen weighs 700 pounds, it will take ... > > > > Ballpoints and pencils facilitate making notes anywhere. > > The typewriter sped up writing legibly considerably. > > > > > to go revise earlier work, and may be more willing to settle for a > > > less-than-ideal end result. > > > > This last point is interesting: being able to churn out fiction can, > > it is sometimes argued, allow people to produce lots of lower > > quality work than if they have to rework parts. I'm not sure how one > > applies that point to programming though, but maybe we are still at > > the typewriter stage. Is there any evidence that refactoring > > browsers allow people to "leave quality till later" and never get > > back to fix it? There are other factors at work though, not just > > the tools: time pressure for one. > > > > The 700-lb pen is a flawed analogy, though it offers something of a > good, quick visual. I tend to think that the ease with which people > can now write and self-publish has led to a flood of crap, though it > has also made possible numerous gems that might not otherwise have > been available. > > I wonder if there are reasonable analogies between programing tools > and writing tools; I'm inclined to see the Excel macro language as the > equal to the ballpoint pen. > > I also wonder about the efficacy of refactoring tools, especially if > one has to think of refactoring as a separate task. If something > isn't easy to do, so easy that it just because part of your unthinking > process, then it will often be pushed off forever. Or else you may > have to alter (stifle?) your normal creative process. > > There was a post on some blog someplace (how's that for precision? It > was either a java.net or artima blog, I think) positing that TDD might > stifle creative flow. And I can readily see that. > > Like at least a few people here, I tend to first bang out short > scripts to sketch out some possible approaches to a task, refactoring > as I go. Ruby make this very easy, both to try something out and to > move things around; a tool might be a good thing for large > applications, but for most things all I need is gvim. > > At some point I may go back and rewrite the application, once I've > discovered it's true purpose, and that's when I am more likely to > write the unit tests first. But since adding unit tests in Ruby is > snake simple I also find myself dropping them in during that first > stage, if code starts appearing less than obvious, so that I don't get > side-tracked looking for goofy bugs. > > I may be unfamiliar with available tools (aside from Eclipse, which > makes Java bearable), but I think this style of exploration, > refactoring, and testing is less fluid in Java, and it effects your > thinking. You are more inclined to want to do a bunch of up-front > design, much as when people had to write with quill pens they were > likely more inclined to think a whole bunch about what they wanted to > write. But, in both coding and writing, the physical process itself > changes how you think. You often don't really know what you're > thinking until you write it down. > > James > > I'd say that using a good IDE with refactoring in Java is pretty creative. It's amazing how many code changes you can make in IntelliJ IDEA in a short period of time. 1. create factory method 2. extract interface 3. change factory method to return interface What would take several days without a good refactoring tool can be done in an hour. It's like being on crack (or so I'm told). The static nature of Java code makes the refactoring browser really smart. It's quite incredibile. And, you develop a relationship of trust with it. I stopped reviewing the IntelliJ refactor change list after a while. Nick -- Nicholas Van Weerdenburg