Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer

Re: Trudging along the learning perl path.

by huck (Parson)
on Apr 16, 2017 at 01:04 UTC ( #1188033=note: print w/replies, xml ) Need Help??

in reply to Trudging along the learning perl path.

I'm at a point where I am not quite sure if it's even possible for me to continue with learning as my learning speed is considerably slow.

You can continue learning "as long as you keep putting one foot forward at a time". Just because it seems slower does not mean it has stopped.

Also the code I wrote today is not identical to what I wrote a week or two ago.

I think you will find this true for many of us. That is what makes programming an art. (even if that art is art evans). There is both a technical and expressive side to programming anything, perl is no exception. This is one reason to write it over and over a few times, then you recognize the core of that piece of art, and can produce a module or subroutine or tool out of it. What you will find is that by the 5th or 6th time you realize they are all beginning to look the same.

Just as there is both science and art in the task, the science side has many facets. I studied "compSci" and found it very useful. First was being taught "tricks", the slight of hand manipulations that tighten programs up. Second was learning methods of thinking. One of the best books for the first actually is The Art of Computer Programming. There are many others, some more perl or c related but they are about algorithms so the language doesnt really matter. Since my formal "learnen" i have found that looking at other peoples code can be just as good. There are perl cookbooks and tutorials that can guide you just as well. I have also found the discussions here to show many of the tricks of the trade, same for other places like stackoverflow

In regards to methods of thinking you will come to realize that the way you debug best is not the same thinking mode you are in when you are designing a process. And when doing the coding you need to think in a whole different way. Learning how to switch between them when you need to is important. Dont drift off to design issues when you are trying to get it working, dont dwell on the implementation as you layout the design. Learn to wear one hat at a time, but also how to change them when you need to.

Wanting to do this yourself is impressive. Realizing a working model is gratifying. Just dont forget that its probably been done before too, and better, Written about in books from the 60's even. Then go out and do it yourself for some other task, get it done again, and feel good that you did.

Were you too slow and made lots of mistakes as beginners?

No of course not, im still too slow and make lots of mistakes, and its hard to consider me still a beginner. What has changed tho is the timing of the cycle. No longer do i have to wait in line for a keypunch. getting in line for the card reader, bideing my time in the execution queue till i could get runtime, and waiting by the printer to then get out of its queue. Hey it could be worse, I knew guys that put their decks in a box, it was picked up at the end of the day, and if you got runtime that nite, you could get a printout by noon. Now i save and test after adding 3 lines, just to make sure i didnt drop a brace or semicolon. Expect things to go slow, expect mistakes, then when things go well you are extra happy! It doesnt change just because your not a beginner anymore.

  • Comment on Re: Trudging along the learning perl path.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1188033]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (8)
As of 2020-02-19 19:37 GMT
Find Nodes?
    Voting Booth?
    What numbers are you going to focus on primarily in 2020?

    Results (84 votes). Check out past polls.