Interlude – Comments on Learning and Debugging


Hello. Hello people, and welcome to ‘It’s a Tree’. We have some really exiting guests for you this evening. A fabulous spruce, back from a tour of Holland, three gum trees making their first appearance in this country, scots pine and the conifers, and Elm Tree Bole – there you go, can’t be bad – an exiting new American plank, a rainforest and a bucket of sawdust giving their views on teenage violence, and an unusual guest for this programme, a piece of laminated plastic.

No tutes for while now – this part of the year gets very busy, so I’m sorry that we haven’t been having updates.  Part of the reason was that I was working on a short project (lunar lander) to use as an example here, but it seems to have run out of control with too much complexity – so I probably won’t be using it – or I will have to pare it back a fair bit.  Tutes will probably be sparse until after Christmas.

In an earlier tutorial I talked about how to make the code here your own.  I wanted to expand on those comments a little here.  First, the best way to learn is by doing.  When you simply listen or read something you don’t actually understand what is involved.  This is because when you listen only you will not understand the complexities or interactions that are going on.  Nor will you be making mistakes, because you’re not doing anything.  When I was working on the lunar lander I realised how many mistakes I was making when coding – and they were mistakes you will never see so ones you won’t learn from.

A corollary of the first principle is that you should be doing the homework I set.  When you do the homework you should keep in mind that I expect that you will be able to work it out based on the tutorial itself – or, in some cases, using earlier tutorials. So keep in mind that the homework is not super hard (those  parts marked “extra points” may well be too hard).  It is doable.  Revisit the tutorial itself and see what bits of it seem relevant.  Then try to think how you can apply those bits.  Never start from the position that you need to know some extra, mystical piece of knowledge other than what has been covered already – and in the vast majority of cases, other than what is covered in that specific tutorial.  If you really can’t work it out, post a comment.

Try and try again! No one gets everything right on the first try.  While Python syntax is not difficult, it can still take some time to master. You need to go through the pain of getting it wrong in order to learn how it works.  Sooner or later it will become second nature.  The pain of working it out the first time will pay off.

When working on your own project, think big, but start little.  Try to map out what will be involved, so far as you can.  If you can’t foresee each step, that’s not a problem, it will come to you.  Implement the part of the project that you feel confident doing, and then expand it from there.  It is often the case that the intial work on getting something going is much harder than improving it later. This might be because with new projects there is a period in which you can’t even run the code to show results. In this period you are working only on your faith in your own ability.  However, once you get the initial work done and can see something to show for your effort, expanding on that work is much easier, and more satisfying because a comparatively small amount of work can produce a substantially different result.  You will find that you will need to “refactor” the code (that is rewrite it, usually restructuring it) from time to time.  The amount by which you need to refactor will be dependent on what you knew and how much you planned before you started.  Refactoring is, by and large, unavoidable.

Use Python’s help() introspection to get help about a function.  When you are using a function or a method, make sure that the arguments you pass to the method are the same as the function is expecting and also that they are in the same order as the function is expecting.   Where I give a solution to a problem, try to understand why they solution works.

Adopt code that does some of what you want and expand from it, making changes here and there.  This, of course, depends on there being such code to adopt and your being able to find it.  If you are able to do this it is a good way to learn.  For example, if you look on the web, you’ll find a space invaders type tutorial.  Extending it means you can focus on just the extension, with the rest having been done for you.  You can, nevertheless, improve on it one piece at a time and get some gratification from achieving those things.

Look at my tute on debugging.  When you get something wrong, look at the message that Python gives you.  These messages can be cryptic, but they do have information in them that you can extract if you’re careful. Also, carefully compare what you have done to the code in the tute.

Finally, and most importantly: trust in yourself.  I am confident you are able to do this work. All you need is to commit to getting it done.

About these ads

2 Responses to Interlude – Comments on Learning and Debugging

  1. Noname says:

    tl;dr
    anything for kids should be less wordy

  2. Pingback: Python 4 Kids: Interlude – Comments on... | Python | Syngu

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 74 other followers

%d bloggers like this: