Re: What I Most Recently Learned in Perl, But Should Have Already Known

I've discovered that an excellent way to dust off those less-than-oft remembered features of Perl is to try to interpret the obfuscated JAPH programs. You wind up looking up deprecated and seldom-used operators and functions in the course of trying to decipher what those things do.

The advantage to this is that it sometimes gets your creative juices flowing in a new way, and suddenly study might be your newest old toy.

Musing,
-v.

"Perl. There is no substitute."

Comment on Re: What I Most Recently Learned in Perl, But Should Have Already Known

Replies are listed 'Best First'.
Re^2: What I Most Recently Learned in Perl, But Should Have Already Known by TedYoung (Deacon) on Aug 17, 2006 at 13:04 UTC
I cannot agree with this more. I learned most of the Perl I know today through Perl Golfing (both participating and decoding other answers). Ted Young `($$<<$$=>$$<=>$$<=$$>>$$) always returns 1. :-)`	[reply] [d/l]
Re^2: What I Most Recently Learned in Perl, But Should Have Already Known by BerntB (Deacon) on Aug 19, 2006 at 12:43 UTC
I am afraid to look into the aby... at obfuscated/golf code, since I am afraid it might look ba... be contagious. (-: Are you saying that I should relax -- it helps keyboard speed if my fingers transform into tentacles and Cthulhu worshippers can scuba dive cheaper because of breathing under water? :-) I recently learned how neat parsing parameters is with Getopt::Long. What I've learnt the last year or so is to write tests for all code I write. The main advantages are development speed (for larger code), that you organize your code differently so it is testable and it really helps when you rewrite code. For my hobby project, I'm going to make an alternative implementation of a feature (big data volumes will be stored in a sql database). I can copy the tests and keep the interface! Neat. Since that was borderline elegant, I'll also show a monk's humility by mentioning a horrible kludge I'll add to that. Objects will rebless themselves to the other implementation type when the data size gets larger/smaller! (A nicer implementation would be to have an implementation of the storage which are contained in another object -- and let that create/delete objects with data. That gets complicated for other reasons.)	[reply]