Couldn't agree more with this. My advice to all java programmers: Take a week to become an ace at your preferred IDE's debugger feature. Learn it inside and out. It's a gigantic timesaver, and gives you at least twice that vaunted "productivity boost" that REPL language advocates keep talking about.
For example, in eclipse, during a debug run, you can type any expression, select it (hint: Learn how to use the keyboard to quickly select entire lines, and set them up if you have to), and hit the "Display" or "Execute" key combo. Voila, REPL, *with* the exact context of your running app (i.e. you can access local variables and the like). You also get a nice-ish scaffolding for actually inspecting the data in your objects, in the variables view. So you don't have to go delving into the getters on the 'REPL', you can just mouse to the variables view and click around. On Oct 27, 6:59 pm, Cédric Beust ♔ <[email protected]> wrote: > This seems like slightly more effort than just creating a new class with a > main() method (in part because you need to configure your project to depend > on JUnit). > > You can even go faster by using Eclipse's very little known Scrapbook > page<http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.jdt.doc.u...> > . > > Overall, I think that users of languages other than Java that claim that the > presence of a REPL is a huge productivity boost are missing a few essential > facts: > > - Java has a REPL (as shown above). It has many, actually. > - Most of the time, you need to run code in context, so a break point + > display view is much more useful than a REPL that has just loaded but not > run your code. > > A REPL is great for quick demos at conferences or walking through an example > in a book, but for real world programming, nothing beats a good debugger. > > -- > Cédric > > On Wed, Oct 27, 2010 at 4:26 AM, Jan Goyvaerts™ <[email protected]>wrote: > > > > > > > > > > > Something I've learned from the TDD stuff are "learning tests" - it's not > > unit testing, but finding out how to make something work. When I need to > > find something out or just a one-shot coding I'm tempted to use JUnit 4 > > tests: > > > public class Demo { > > > @Test > > public void run() throws Exception { > > ... put your code here ... > > } > > > } > > > The IDE provides the means to create the class source code by entering the > > class name. And for test methods there are usually templates/shortcuts/... > > to generate the method declaration code. You're fairly quickly set to type > > in working code. Just fill in your code and press the Run button somewhere. > > > A nice added bonus is that each method is separate, so you can just add > > methods to experiment other things. The IDE usually shows a nice overview of > > the methods and does error handling. > > > -- > > You received this message because you are subscribed to the Google Groups > > "The Java Posse" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<javaposse%2bunsubscr...@googlegroups > > .com> > > . > > For more options, visit this group at > >http://groups.google.com/group/javaposse?hl=en. > > -- > Cédric -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
