This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
How do you guys actually debug your methods written in eclipse using pattern matching and recursions. I do not understand the flow of my debug statements. They simply jump from one case block to another. I think getting recursion correctly without the help of a debugger is to think about the solution and re think if the test case fails. This to me looks inefficient. What is your opinion?
SCJP 1.4, SCWCD 1.4 - Hints for you, Certified Scrum Master
Did a rm -R / to find out that I lost my entire Linux installation!
No. I've just been using unit tests. Starting really simple and building up. I haven't needed the debugger. Also for simple ones, I've been using a scala command line to explore intermediate expressions like whether foldLeft does what I think it does.
That holds good for the assignments that we currently do. But thinking about real time applications that we write? I have many times used the debugger to understand the source code written by other developers. I have also noticed that with some of my implementations of the assignment problems, the code is not any more readable and understandable although it works. This coupled with no debugging possibility is definitely a nightmare.
I haven't been using the debugger, partly because I'm not all that familiar with Eclipse and partly because I suspected it would work the way you say with all those recursive calls anyway. I've been using Scala worksheets a fair bit for building up the elements of my solutions, and of course using the unit tests to see if things are working. I've noticed we need to implement extra tests to check the various edge cases these days.
I wonder how far people are really using this kind of recursion in real-world projects, especially where people are still in the process of learning FP e.g. moving from a standard Java platform. So you might start out with a fairly imperative solution to get the inputs/outputs working right, then re-factor that into a more elegant recursive approach where appropriate. And some of the recursive solutions we've been working on here are not especially efficient, so recursion isn't always the best approach anyway. Even if it feels really cool to get something like this working recursively!
No more Blub for me, thank you, Vicar.
author & internet detective
chris webster wrote:I And some of the recursive solutions we've been working on here are not especially efficient, so recursion isn't always the best approach anyway. Even if it feels really cool to get something like this working recursively!
Agreed/ Suppressing that urge and doing it recursively since it is a functional programming class.