unhealthy fascination with OO (inspired by the desire to complete with Python) which I consider counterproductive

Python? Really? Do you mean Ruby? Quoting Matz from An Interview with the Creator of Ruby: "Then I came across Python. It was an interpretive, object-oriented language. But I didn't feel like it was a "scripting" language. In addition, it was a hybrid language of procedural programming and object-oriented programming. I wanted a scripting language that was more powerful than Perl, and more object-oriented than Python."

When I see bless statement in simple scripts I suspect fraud

That's an extreme position to take. Though an obsession with OO is unhealthy, your apparent anti-OO obsession is just as unhealthy IMHO. Don't want to use Moose? Fine. But don't blindly reject sound principles of design - which include using OO when appropriate. As for whether and when to use OO, there is no substitute for judgement and taste. A simple rule of thumb is to ask "do I need more than one?": if the answer is yes, an object is indicated; if the answer is no, then a module.

High-level Design Checklist (derived from On Coding Standards and Code Reviews)

• Coupling and Cohesion. Systems should be designed as a set of cohesive modules as loosely coupled as is reasonably feasible.
• Testability. Systems should be designed so that components can be easily tested in isolation.
• Data hiding. Minimize the exposure of implementation details. Minimize global data.
• Interfaces matter. Once an interface becomes widely used, changing it becomes practically impossible (just about anything else can be fixed in a later release).
• Design the module's interface first.
• Design interfaces that are: consistent; easy to use correctly; hard to use incorrectly; easy to read, maintain and extend; clearly documented; appropriate to your audience. Be sufficient, not complete; it is easier to add a new feature than to remove a mis-feature.
• Use descriptive, explanatory, consistent and regular names.
• Correctness, simplicity and clarity come first. Avoid unnecessary cleverness. If you must rely on cleverness, encapsulate and comment it.
• DRY (Don't repeat yourself).
• Establish a rational error handling policy and follow it strictly.

Some Related Perl Monks Nodes

• Strategies for maintenance of horrible code?
• Moving from scripting to programming
• Code Structure Changes
• What is the best way to add tests to existing code?
• Reading Someone's Program
• Object-oriented Reengineering Patterns book now available as a free download

• On Coding Standards and Code Reviews
• Nobody Expects the Agile Imposition (Part VI): Architecture
• The Boy Scout Rule

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.