Re: Things I Don't Use in Perl

I don't get too excited about any new feature in Perl until it's survived a couple of major versions. A lot of things only sound like good ideas but disappear in the next version. Pseudo-hashes, for instance, died (thankfully), although I still have to deal with their insidiousness with the right versions of Perl.

Some other things I don't use and haven't seen mentioned:

our(): I can see the reason for our(), but most people don't use it to unmask a package variable. They use it so they don't have to use vars. That sacrifices backward compatibility for no good reason.
overloaded operators: I like overloaded operators and I think they are a lot of fun to play with, but I just don't think people think about Perl like that. I probably think about this because I learned about that sort of thing when I did C++ where I could overload based on object types. Since Perl think differently, I don't think people are expecting that. For instance, if I want to print a reference (on purpose, to debug or whatever), I don't want magic stringification. I can see the usefulness of that, but most Perl things don't do that so I don't expect it.
Exceptions: I think exceptions would be tolerable if everyone used them and they were built into the language, but not everyone does and they aren't. Perl is much more like C than C++. I'd rather have consistent expectations across modules than a list of modules where I have to remember to wrap everything in eval.
Source filters: Actually, I don't use much of anything Damian writes, but it doesn't have to do with the code quality, really. Some people get excited about his cool hacks, but can't seperate his production-useful stuff from the cool proof-of-concept hacks. They end up using anything from TheDamian, and some of them shouldn't be used for anything that anyone else has to maintain (and that's just about everything). I pretend none of that stuff exists so I don't spread the word. It's cool stuff: I just don't want to ever maintain it.

--
brian d foy <brian@stonehenge.com>
Subscribe to The Perl Review

Comment on Re: Things I Don't Use in Perl Select or Download Code

Replies are listed 'Best First'.
Categorized Damian Modules by TheDamian (Vicar) on Aug 25, 2005 at 23:10 UTC
Actually, I don't use much of anything Damian writes, but it doesn't have to do with the code quality, really. Some people get excited about his cool hacks, but can't seperate his production-useful stuff from the cool proof-of-concept hacks. They end up using anything from TheDamian, and some of them shouldn't be used for anything that anyone else has to maintain (and that's just about everything). I pretend none of that stuff exists so I don't spread the word. It's cool stuff: I just don't want to ever maintain it. The inability to accurately categorize and assess CPAN modules is a genuine problem that many people face. But refraining from all temptations just because a few of them are bad for you seems counterproductive. So, in the hope that `brian` (and everyone else) will be better able to take advantage of my genuinely useful contributions without falling victim to my occasionally insanities, here's a categorized list of my current modules, with recommended dosages... Damian modules you shouldn't use in production because they're intended to be jokes: Acme::Bleach Acme::Don::t Coy Lingua::Romana::Perligata IO::Busy Damian modules you shouldn't use in production because their purpose is to explore and prototype future core language features: Attribute::Types Class::Contract Perl6::Builtins Perl6::Currying Perl6::Export Perl6::Gather Perl6::Placeholders Perl6::Rules Perl6::Variables Quantum::Superpositions Switch Damian modules you shouldn't use in production because they've been superceded by better modules: Attribute::Handlers::Prospective (use Attribute::Handlers instead) Text::Reform (use Perl6::Form instead) Tie::SecureHash (use Class::Std instead) Special-purpose Damian modules that are useful for developing other modules or for solving difficult implementation problems, but which probably shouldn't be used directly in application code: Lingua::EN::Inflect Attribute::Handlers Class::Delegation Class::Multimethods Class::Std::Utils Filter::Simple Hook::LexWrap Inline::Files NEXT Parse::RecDescent Regexp::MatchContext Sub::Installer Text::Balanced Damian modules that are specifically debugging and coding aids and which Damian uses himself during code development: Debug::Phases Leading::Zeros Log::StdLog Module::Starter::PBP Smart::Comments Toolkit Damian modules that are generally safe, robust, and handy, and which Damian regularly uses in his own deployed code: Class::Std Config::Std Contextual::Return Getopt::Declare Getopt::Euclid IO::InSitu IO::Interactive IO::Prompt Perl6::Export::Attrs Perl6::Form Perl6::Say Perl6::Slurp Regexp::Common Text::Autoformat	[reply]
Re: Categorized Damian Modules by dragonchild (Archbishop) on Sep 06, 2005 at 15:24 UTC
I know this is asking a lot, but would it be possible for you to, as you have time, modify the REAMDEs and main POD for those to indicate their production-worthiness? I have seen Switch and Class::Contract used in production and I personally have used Quantum::Superpositions in production-affecting code (to good effect). My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]
Re: Categorized Damian Modules by tlm (Prior) on Aug 27, 2005 at 14:12 UTC
This hadn't occurred to me until I read your post, but now I think it would be very useful if submitters to CPAN gave a similar explicit rating to their submissions. For one thing, this would help distinguish those submissions that are made in the spirit of "release early, release often" from those that are, at least in the author's estimation, ready for production. I realize that the author's opinion of his/her module may be inflated (or in some cases deflated) but I think it would be a valuable piece of information nonetheless. the lowliest monk	[reply]
Re^2: Categorized Damian Modules by jdporter (Paladin) on Aug 28, 2005 at 15:43 UTC
They kinda do. See the DSLIP column in The Perl 5 Registered Module List.	[reply]
Re^3: Categorized Damian Modules by belg4mit (Prior) on Aug 21, 2008 at 19:23 UTC
Re: Categorized Damian Modules by leocharre (Priest) on Mar 03, 2009 at 14:42 UTC
Don't is kinda interesting.. I'm a big fan of syntax highlighting. If I have a chunka code that I want to ignore, I delete it (it's in some versioning system..), comment it out, pod it.. This could be cool to sort of... encase it. Ignore it. And still be able to look at code and know it does nothing. And still see the syntax highlighting. Hm- I guess I could also just.. not call the code.. Hm.	[reply]
Re: Categorized Damian Modules by chexmix (Hermit) on Nov 13, 2007 at 13:41 UTC
I just took a look at Coy. The fact that the documentation is in haiku makes me an even bigger fan of your work than I was already. Sorry to blather, but that's just great.	[reply]
Re: Categorized Damian Modules by belg4mit (Prior) on Aug 21, 2008 at 19:27 UTC
I think Don't belongs in the blue debugging/coding aids category. It's a nicer spelling of `if( 0 )` for multi-line commenting. `-- In Bob We Trust, All Others Bring Data.`	[reply] [d/l]


No such thing as a small change
	PerlMonks