|
|
|
| laziness, impatience, and hubris | |
| PerlMonks |
comment on |
| ( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
|
A couple of things this morning set me thinking about Perl and its nature, and the methods it provides to complete tasks in more than one way.
I'm sure I'm not alone here in that I code Perl for a living, 8 hours a day (theoretically *g*), 5 days a week. This morning, though, I was looking through a module I wrote about 4 or 5 months ago, that works perfectly well doing what it's doing (interfacing with one of the corporate databases and processing information that comes from it). Completely on the spur of the moment, I decided that I could improve one of the methods in the module, and started to rewrite it (I had time on my hands). About half-way through, I realised I wasn't improving anything much at all: I was largely just changing code so that it looked different - I wasn't adding anything or taking any functionality away. Now, I started thinking about this, and I finally came to the conclusion that because I can do something differently, as my tastes for code and style change, I logically do do things differently. The method that caused offence this morning was quite nicely written, given my tastes that month, but it just happened to be incompatible with what I'd decided I liked this month. Sounds quite shallow, and I guess it is, but there's no other explaination (at least, that I could think of) for me picking up on a couple of things and subconciously thinking they're "bad". I'm slowly coming to the conclusion now that what happened this morning is quite natural, and not as shallow as I originally thought. 4 months ago I was relatively new to Perl, relatively new to the concepts I was trying to implement. I guess it's only natural that I'd have gotten something working (regardless of how) and left it at that. Coming back to the code now, with a much better knowledge of both Perl and the DB that I was slowly learning then, a couple of ways of writing code that were perfectly acceptable to me then just aren't now, because of what I've learnt and the methods I now know how to use. The whole concept of there being MTOWTDI has a flaw: if you're out to seek personal improvement, as either a byproduct of learning Perl, or as part of it, it's inevitable that you (and your perspectives) change, in some ways. I think me looking back at old code critically, simply because I wouldn't do it that way now, is a part of this, at least for me. Don't get me wrong here, I think that the whole concept of having more than one way to do stuff is great. My point, I think, is that the knowledge you need to confidently be able to do things differently, and to evaluate the different ways of doing things for clarity, efficiency and readability, takes a very long time to gain. This, though, is the same for anything - until you have the necessary basic knowledge to be able to evaluate your options effectively, decisions you take are by definition flawed, simply because you can't fully explore all of the possibilities. This, in my mind, is one of Perl's best points: you never stop learning, and coding with the language can always be challenging and interesting, but also one of it's worst points. Where do you draw the line? With (most) languages, it's possible to step back at some point and say that you know it inside out. I'm not sure that's possible with Perl. I'm interested to know what other people think about this - is there an attainable point that would cause you to think that you know "all there is to know" about Perl? (Is this even possible?) What's your take on this? A few random thoughts (that became a crazily long post) .. excuse the rambling :)
In reply to Self-improvement and TMTOWTDI by Tanalis
|
|