From: Lothar Scholz Date: 2006-07-06T22:10:57+09:00 Subject: Re: debugging proposal Hello Austin, >>> 1. refactor >>> 2. unit test >>> 3. write to stdout / stderr / log files >> I haven't done too much real work on ruby yet, but I still believe >> this is a very bad suggestion. Ruby (and any programming language) is >> about productivity and in my whole experience (I have to agree that >> most of it is spent on Java) never a sout have been more productive >> than a debugging session (for enough complex stuff). AZ> I think you misunderstood. This isn't a suggestion. It's just how one AZ> ends up debugging most of the time. Frankly, I think I have missed a AZ> graphical debugger exactly once in my Ruby programming. Everything AZ> else has been easier to deal with with judicious use of tracers and AZ> logging. Well, i and many of my customers will not agree with you. I have to do this print/logging debugging with eiffel many times (even with DbC) and i see minutes and minutes passing by. (There is no useable debugger for SmartEiffel). And also a debugger is the only wonderfull tool that helps you to see and oberve the control flow, together with the data. No tracer can do this. In complex and not very well documented frameworks like rails this can save you hours. It took me minutes to understand REXML and not hours of trail/error until you now what types/objects are expected and returned by each function. Unforunately productivity is something that is hard to measure and even harder if you are convinced that your own style is already good enough. There was only one try to deal with this. The so called "Personal Software Process" but too less people are using it because it requires additional time and a _LOT_ of diszipline (no wonder that this was developed from somebody who was a drill sergeant during his army time). -- Best regards, emailto: scholz at scriptolutions dot com Lothar Scholz http://www.ruby-ide.com CTO Scriptolutions Ruby, PHP, Python IDE 's