in reply to Re^5: Student in trouble
in thread Student in trouble

OK Tilly maybe I can see your perspective a little (based on your past experiences) but I would also like for you to see it from mine, This is a new language for me and I don,t know any seasoned perl programmers (aside from my lecturer) that I could ask for advice (and I see him only on saturday afternoons) or explain something I don't understand. How would you define legitimate assistance Tilly?

Replies are listed 'Best First'.
Re^7: Student in trouble
by tilly (Archbishop) on Nov 12, 2004 at 01:49 UTC
    My definition of legitimate assistance would be assistance that helps you understand, which doesn't in any way contribute to the work that you'll later submit as your own.

    Some trivial examples of clearly legitimate assistance: Advice on study strategies (which I already gave you), pointing you at http://www.perldoc.com/online documentation (personally I prefer using the perldoc command to get the version that matches my version of Perl), answering conceptual questions that you have, and assisting you after the fact in understanding why you got the grade that you got.

    Of course giving you that kind of assistance generally requires that you have done enough work up front to identify how you need to be helped. Which serves many good purposes. First of all if you take that energy you'll often manage to work out the answer and won't need assistance. Secondly if you do need assistance, you're now primed to internalize good advice and so get more value from effort spent. Thirdly your up front work gives you more focussed questions, allowing others to give answers that are more likely to address where you actually are.

    A trivial example of assistance that I'd consider illegitimate would be someone else debugging the code that you'll submit. (Note that this is pretty much what you actually were asking for.) Figuring out what to do when things go wrong is a large part of the effort that programming takes. In fact debugging is so much of a time sink that good programmers direct most of their energy towards doing things that will simplify later debugging. That includes design activities, incremental development, writing test suites up front, inserting appropriate error checks, and so on. In fact good programmers spend a smaller fraction of their time actually programming than bad programmers do yet finish faster!

    I wouldn't expect you (or anyone) to do all of that on a first programming exercise. But learning to be careful is part of the skill. Being able to track down your own syntax errors is like knowing how to dribble in basketball - theoretically you can play the game without that skill, but so poorly that you might as well not bother. And once you have an experiential foundation for knowing why care matters, you're primed to learn more advanced lessons in how to avoid those problems in the first place.

      Ok tilly I will follow your advice. I will go through my text (learning perl, which is such a great book) to get the up front understanding of the language and I will practice the exersises after each chapter. Can you recommend any online perl tutorials for novices?