Comments on: Productivity

By: steve

steve — Mon, 10 Dec 2007 15:34:36 +0000

Bill: negated? I hardly think so. Refactoring is only one of several areas related to productivity.

By: Bill Burke

Bill Burke — Mon, 10 Dec 2007 15:28:46 +0000

Steve, I think you should reread my comment. I didn’t say that a Ruby IDE couldn’t do refactoring, just that such refactorings wouldn’t be reliable and that the IDE would be guessing when it tried to refactor.

With an IDE with reliable refactoring, I’m more than an order of magnitude more productive anyways, so any increase in initial productivity I might get with Ruby et al. is negated.

By: steve

steve — Mon, 03 Dec 2007 04:16:55 +0000

Bill: funny, I don’t seem to have any problem whatsoever with productivity or meeting schedules. In fact, I’m usually ahead of schedule, and typically deliver a few extra niceties in every iteration. What do I need with a crutch/IDE? The main differences between an IDE and the tools I use (which BTW are not grep and sed) is that the IDE takes up way more memory, is slower, and is far less extensible.

Don’t underestimate the power of brevity. When you can choose the right language, you can often write a more functional application in an order of magnitude fewer lines, and the need for an IDE is significantly reduced.

If you think the languages you mention have “zero type safety,” then you have some studying and learning to do. And if you think IDEs can’t handle such languages, think again. I would expect a self-proclaimed IDE expert like you to know better.

And finally, the last time I checked, Bill, your single hammer for all nails, Java, is from the 20th century…

By: Bill Burke

Bill Burke — Mon, 03 Dec 2007 03:31:21 +0000

Isaac, I agree with you 100%. The problem with Steve is that he’s still stuck in the 20th century coding with vi, emacs, and refactoring with grep and sed. Now that he’s coding in Erlang and Ruby, he’ll never know the productivity we have in IDE land. Seriously, I don’t understand how somebody could make any of these dynamic language arguments without the experience of using one of these IDEs in a medium to large project.

The thing is, these languages with zero type safety make it nearly impossible for an IDE to reliably refactor simple things like moving a method to a different class, renaming a method, class, or property, changing a method signature. Sure, they could make incomplete guesses, but then in that case, I’m better off using grep/sed and living in the 20th century.

By: Isaac Gouy

Isaac Gouy — Mon, 26 Nov 2007 21:31:59 +0000

steve vinoski wrote November 25th, 2007 at 11:40 pm
> why don’t you do the work to prove that it’s wrong?

I didn’t write a blog article that assumes it’s true.

I can suggest why we shouldn’t just assume it’s still true after 30 years of technology change.

Just 10 years ago, for programmers using a statically checked language, simply changing the name of a type could be a major effort that could introduce bugs – that is no longer true.

Just 10 years ago, it was understood that encapsulating fields avoided the rework and bugs that would follow renaming – the cost and risk from field renaming has disappeared.

How much boiler-plate code does your IDE generate? Wouldn’t that change any bugs per line relationship?

The whole point about the bugs per line of code constant is that it’s a dated empirical observation and not an immutable law of nature.