Dmitry Jemerov on IntelliJ 8, Flex, and Scala
Sorry if this has been posted before. While reading some stuff on the Javalobby, I was pointed to an interesting interview hosted on the Artima.com website.
Really quite an eye opener.
What we've done in the past four or five months is a very massive refactoring of the IntelliJ IDEA codebase, to separate support for Java from the core platform. We have extracted functionality needed to support an IDE for some language: parsing, refactoring, code manipulation, and so on.
With that in place, we can start building products for other languages based on that platform. Because not all those products will include all the functionality of IntelliJ IDEA, they can be much less expensive, and we can choose the price based on the target market. And developers don't get the stuff they don't care about. The new products can be much slimmer, lighter, and easier to get started with.
Sounds like a plan ... :)
We now have a framework we can use to build debuggers for any runtime system. The actual way we do that for each language is not something we came up with originally: For both Ruby and Python, there are standard solutions in this space, such as protocols for talking between an IDE and a debugee. For Ruby, there's a project called ruby-debug, and there's something similar for Python as well. We plan to implement all those standard protocols, call stacks, break-points, watches, and so on. We also abstracted away a common UI framework for building debuggers.
But then I came across this!
There some people who hold the opinion that you should not be using a debugger: Instead of debugging you should write unit tests that cover every method individually so if something breaks, you don't need to debug, but get a failing test instead.
Who are these masochists?
Please sign in to leave a comment.
Some interesting stuff at those links. Thanks for sharing Rayz. I think Dmitry makes some great points in his comments. It's also interesting to see where JetBrains is heading with things.
>But then I came across this!
>
>>There some people who hold the opinion that you should not be using a debugger: Instead of debugging you should write unit tests that >>cover every method individually so if something breaks, you don't need to debug, but get a failing test instead.+
>
>Who are these masochists?
Well at least they are not as bad as the ones who think instead of debuggers, use lots and lots and lots of logging, like every other statement... or worse... System.out... shudder... Trust me, I believe in good logging, but its not a replacement for a debugger. Ditto for unit testing. The "unit tests in place of a debugger" thing is a new one to me.
Mark Vedder wrote:
Right. The unit test tells you something's wrong. Then you fire up
the debugger to work out what exactly went wrong and why... how can
the former replace the latter? Unless you perpetrate some madness, like
making every operation in every line of code it's own method and write a
unit test for each it can't happen, surely?
N.
Nathan Brown wrote on 6.6.2008 2:33:
>> ...its not a replacement for a debugger. Ditto for unit testing. The
>> "unit tests in place of a debugger" thing is a new one to me.
With TDD there is not much need for a debugger, at least when working on
your own code. When each test focuses on a very small functionality and
there is near 100% code coverage, it's quick to see where the problem is
based on which tests fail. And because you run the tests between every
change, you know that the tests must fail because of those 5 lines of
code which you changed a minute ago. As a result, you very rarely need a
debugger and thus save time. Instead of debugging it may even be faster
to rollback your latest changes and use the 5 min old code from the
version control which passed all tests. I use a debugger mainly when
examining how the code written by other people works, not when I'm
writing my own code.
http://en.wikipedia.org/wiki/Test-driven_development
http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd
http://www.agiledata.org/essays/tdd.html
--
Esko Luontola
www.orfjackal.net
I think its a matter of wording: reduce versus replace. I whole heartedly agree that good unit testing reduces the need for a debugger, or more specifically debugging sessions. I'm a huge unit testing proponent. Just ask my co-workers about my unit testing soap box. But, IMHO, unit testing certainly does not replace a debugger; nor does unit testing mean a debugger should never be used. There are still times when you need to freeze the execution and take a look at what's going on under the hood to find the problem. There have been many times I have found obscure issues with 5 minutes effort in a debugger that would have been very difficult to find otherwise, including with unit testing.
finding bugs .. using debuggers .. that takes much, much time. So the
topic is how to minimize this time. One good approach is to write tests
in an inherent way. Tests should drive the development for sure ..
strict test-first is difficult to achieve though.
The trick is a comprehensive set of component and functional tests.
There are other approaches though to minimize late bugs. You may work
with continuous integration, permanent reviewing, pairing and some ahead
work on a good design. You should use those approaches complementary imo
.. totally working without any debugger is some kind of best case or
dream.
Actually good debuggers are assets provided by state-of-the-art IDEs.
Look at IntelliJ IDEA: when you use Groovy and Java in one project just
to mention one scenario .. you can work with the debugger seamlessly
bridging all language borders. Do you want to miss that?
Mark Vedder wrote:
>>
>>
>> With TDD there is not much need for a debugger
Mark Vedder wrote on 9.6.2008 19:23:
True, true.
I had today a situation (when writing an asynchronous RPC library using
TDD) that an integration test which I though should pass, was failing. I
used a debugger to debug the execution of the test to find out why it
was failing. (The problem was in my test: I had mocked the network
communication in a wrong way, so that in my test setup network messages
were sent and recieved synchronously instead of asynchronously. Adding
some threading to the test setup solved the problem.)
So in this case the tests alarmed that something was wrong, and a
debugger helped in finding out the problem, because the situation was
too complex to figure out right away.
--
Esko Luontola
www.orfjackal.net