Value of "RE"-coding for the newbie

[Limbic~Region]

I am new to Perl and the monastery, but I want to extend a heartfelt thanks to all the monks that have helped and guided me. What I am about to write is meant for others like myself (newbies), but I believe it could benefit everyone at one point or another.

As you learn a language, what you are learning is the vocabulary (nouns, verbs, modifiers, etc) and the syntax. You are not learning how to "program". Sure, you may learn to emulate how someone else programs by looking at their code or by reading a book, but you are still just taking the vocabulary and matching another's template. For some, the story ends here, for others the story is just beginning....

When you decide to venture out on your own, you will be truly like a child experimenting with language for the first time. You will make minor mistakes at times, at other times you will seem to be babbling to the adults. Just as the naive child will touch the hot stove that the adult warned them not to, you will try and re-invent the wheel. If we are lucky, we do not stay children forever.

I have always been elated when I figured out code that solved my problem. Some time in the future, I discover a new technique that would have reduced the number of iterations in the loop by a thousand fold and I feel like a fool. IMHO, it is time to "RE"-code the original. In doing so, you will assimilate the new technique so that you don't make the mistake again. Most likely, you will reduce the size of the original and make it run faster. Almost definately, you will learn more new techniques in the process.

What is the single hardest about doing this? If you write code as one long run-on sentence and not in properly formed paragraphs and sentences. It is easy to correct English papers that have headings, sub-headings, paragraphs, sentences, etc. Each piece stands by itself and can usually be changed without having to change the entire document.

Learn the use of subs.

Learn proper indentation.

Listen to the adults, but don't be afraid to experiment.

Remember that every time someone gives you an answer, if you do not understand it, you are just learning how someone else programs that solution. Make sure you fully Grok it.

Limbic~Region

[vladb]

IMHO, it is time to "RE"-code the original. In doing so, you will assimilate the new technique so that you don't make the mistake again. Most likely, you will reduce the size of the original and make it run faster. Almost definately, you will learn more new techniques in the process.

This is so true. In my experience it almost always hurts to revisit my old code. Quite frankly, I've never learned to like my coding, especially that done in the past, and whenever I revisit I just have to change things around (as time allows). Hopefully this may be an indicator of my evolving into a better Perl hacker ;-). For if upon encountering an older code I didn't consider anything for a change, this would only indicate the three things: 1) My past code was near perfect (*laughs*); 2) I haven't gained any coding wisdom and know-how (so painful it couldn't be true! or could it?); 3) I have degraded in my knowledge of Perl to a point where my old code seems perfect... It's best if out of the three, none is true ;).

As far as learning new languages, I think you are also on target. Provided you have had earlier extensive (or near so) practical exposure to other languages, the matter of learning the guts of a new language pretty much concludes in learning the new syntax and 'culture'. My first encounter with Perl happened after nearly 3 years of non-stop C programming. The transfer wasn't too painful, in fact, I'd enjoyed it much especially realizing how much simpler it was compared to my older favourite.

_____________________

# Under Construction

[schumi]

Most people think that native speakers of a language speak it "perfectly", that they make no mistakes, and know everything there is to know about that language.

That is simply wrong. There is no way in which anyone could speak a language "perfectly". Most people use - when speaking! - some kind of dialect local to where they live. In our times, where people can travel easily, influences from other dialects and even languages are very frequent. Grammatical constructs which in standard language may be considered wrong, are perfectly acceptable or even normal in a dialect or variant of that same language.

Additionally, there are jargons of which only people who work in the field, have a clue. Other people may hear them talking, understand the words, but still don't get the meaning of what is said. The Oxford English Dictionary list some 616'500 word forms. It is estimated that the English language has more than three million words if regional variants, scientific terms and jargon words are included. No one could possibly know all of these.

There are many more reasons like the above which show that it is impossible to speak a language perfectly.

 

Much the same applies to a programming language. You may be able to blindly put together a regex, but when it comes to use, say, DBI, you might be at a complete loss. And even if you know much more of a programming language than most other people, chances are that you have developed your very own way of using that language - much like you often adopt the dialect of wherever you grow up.

Learning the basics of a language - programming or other - usually involves reading, maybe going to classes, reading, exercising, and reading. Gaining proficiency in that language involves using it, exercising, exercising, and again reading. Only when you regularly use a language, can you acquire a certain routine in it. (And believe me, if you stop using it, that routine is gone much quicker than it is acquired...) And when you read your first efforts in the other language again, you will find that you could easily re-do those on a much higher level.

When you talk to someone in a foreign language, however proficient you are in that language, you will still pick up words, sayings and grammatical constructs the other person uses. Much more of what you hear and read in that foreign language will enter your passive vocabulary - stuff you don't use yourself, but which you understand when someone else uses it. Again, the same goes for programming languages.

 

So, in a way learning a programming language is very similar to learning a foreign language. The best thing is always, once you've acquired basic skills, go where that language is spoken, and learn from there!

Oh, yes, in my other life I'm a linguist...

--cs

There are nights when the wolves are silent and only the moon howls. - George Carlin

[gmax]

I have recoded sometimes, for very small projects, or for small portions of a larger project. It is a refreshing experience, which can lead to improvements. However, for large applications, I would rather follow Joel Spolsky's advice about reading code and rewriting software.
Summarizing: rewriting code is hard, because programmers have trouble reading code. Once you know how to read, you can face a rewriting task with more confidence.


 _  _ _  _  
(_|| | |(_|><
 _|   

[hsmyers]

One of your points, Learn proper indentation, raises a problem. What's proper? I'd suggest that you re-word that to just Lean indentation! Why the change? Well as you progress as a programmer, you'll notice that there are certain things that seem to provoke much outcry. Formatting code (the hows and such...) is almost as sensative as what editor to use or even what language to use. When asked, I usually recommend what I call the Zen solution. To shorten the overly long lecture, I point out that a possibly trite but still useful summary of Zen and the Art of Archery by Eugen Herrigel, is "To hit the target, let go of the arrow!" I often further condense that to just "Let go!" Point being that holding on to some things, gets in the way of other often more important things. In Yoda-ease, Proper, important is not, indentation is.

--hsm

"Never try to teach a pig to sing...it wastes your time and it annoys the pig."

[John M. Dlugosz]

I think "proper" here means a set of requirements, not a specific set of rules.

[diakonos]

Oh the wisdom from the meditation. How many times have I sat and thought about re-coding the original. But very few of those times have I actually put thoughts into action.

I remember a mentor of mine once saying "A lazy System's Administrator makes the best System's Administrator". I don't know if I agree with all of the reasoning behind it but there is some truth to it. You see the lazy Sys Admin is the guy (or gal) who makes the system work entirely for them. They do as much programming up front to accomplish those things that normally they would have to do on a day to day basis. The result is the time that they saved they can spend doing their "lazy" task.

This is going somewhere, trust me..

We all grow as we "learn" and "USE" the language on a day to day basis. Those that grow are those that use what they have learned and are pushing for more. Here is the part that I am going to get flamed over: But those who stay children are those who don't understand the language and are looking for the "quick" way out by pirating code examples with no intention of understand its method. The result is a short life'd programmer (I give too much credit here) who creates a mess for someone else to clean up. These are the ones who are only satisfied with the result, though most of the time blinded by the result itself.

I think your comments here are well said and I think it should promote a sense of striving for the next level. Wanting to "RE-code the original" is a true sign of a programmer (even a newbie in the language). It is a mark that seems to be somewhat fading in a SUPER-FAST Paced society.

I think I am going to pull some of my old code out. It is time for a change. It is time to apply what I have learned over the years to yesterday's code. I wonder if they will let me do that and not work on my projects today?

As always in humble regards.

Doug