oh yeah . . . .been down the prn road for many many hours, myself. seems like a lot of nice people here ready to help .... so i'll get back into it soon and post specific problems. . . . there are a lot lot lot of them, so i am sure it will take some time.
Thanks for the ideas. On Mon, Jun 29, 2009 at 8:39 PM, Howard Lewis Ship <hls...@gmail.com> wrote: > My negative experience with debugging touches on a number of things, but > the biggest is the way that lazy evaluation makes it hard to determine cause > and effect while debugging. This has been a problem, and I've had to do a > lot of (prn) calls to try and identify what's going on. > > I eventually have figured out everything, but it's been a challenge I > wouldn't recommend to a new coder without a lot of experience to draw upon! > > I'm not sure how to address it; but this is an issue that may ultimately > have Clojure relegated as a "language for experts". I want it to be a > language for everyone. > > > On Mon, Jun 29, 2009 at 5:35 PM, Richard Newman <holyg...@gmail.com>wrote: > >> >> > at the risk of sounding negative and (-; thus getting >> > "moderated" ;-) ... I'm very interested in taking another stab at >> > clojure after putting it down for a while, but I had real trouble >> > debugging my programs. I'm looking for advice and/or an approach. >> >> Aside from two areas — JVM problems, such as with gen-class'ed >> classes, and exceptions occurring in Java code — I've found that the >> best general approach is to build small, functional programs. >> >> If every function is only a few lines long, and stands mostly alone, >> you can build from the bottom up and rely on your foundations. Test as >> you go, by hand or automatically — I find that automation is much less >> important with functional programming, because there are fewer knock- >> on effects of changes, but that's another kettle of fish — but if you >> keep most of your program free of side effects, composed of small >> functions, you should find that debugging in the large is greatly >> reduced. >> >> No side effects mean that the only time you can have a bug is if you >> get the wrong output from your function for the inputs you provided; >> debugging in that case means inspecting your function, and maybe >> navigating outwards the tree of calls it makes to other pure >> functions. Add tracing until you find the function that's returning >> the wrong thing, and fix it. >> >> If you're finding that you're managing a lot of state, and thus have >> trouble debugging, then you're probably not taking a sufficiently >> functional approach. (A big hint is if you find yourself wanting a >> stepping debugger to watch values change. It's the "change" part >> that's worrying!) >> >> If that's not your problem, could you elaborate so that we might all >> opine? :) >> >> -R >> >> > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > Director of Open Source Technology at Formos > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
