At first, the planning phase of a software is very important. And if you are able to split up the huge problem into small pieces you can solve easily in a very good and flexible way, very often you can solve problems with just very basic code.
If you want to improve your knowledge in a certain language, you need a lot of training, which may become difficult without doing a lot of coding. And without a lot of coding, you might never find out about many of perl's idiomatics.
When I write some code for customers, I often try to write it as easy as possible and only as complicated as absolutely necessary, because very often, these programs are enhanced or maintained by people who only have a basic perl knowledge or the like. Or if I write a code (e.g. at perlmonks or www.perl.de) which is addressed to a beginner, I'll try to use "easy" perl code that may easily be enhanced.
If I'm playing around in my sparetime and writing some codes propably nobody else is interested, I play around with perl, write programs that perhaps (sometimes hopefully :-) ) will never be finished, just to find out how I could do it. As soon as I've found a way, it very often isn't interesting any more.
With such perl-"games" I improved my perl-skills a lot, found a lot of perl "bugs" which very often turned out to be nice features, or found out about some nice techniques.
Best regards,
perl -le "s==*F=e=>y~\*martinF~stronat~=>s~[^\w]~~g=>chop,print"
In reply to Re: Code re-use: productivity gains vs. skill deprecation
by strat
in thread Code re-use: productivity gains vs. skill deprecation
by Phemur
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |