Developer Forums | About Us | Site Map
Search  
HOME > TUTORIALS > SERVER SIDE CODING > PERL TUTORIALS > THE ROAD TO BETTER PROGRAMMING: CHAPTER 5 MODULES AND OBJECTS


Sponsors





Useful Lists

Web Host
site hosted by netplex

Online Manuals

The road to better programming: Chapter 5 Modules and objects
By Teodor Zlatanov - 2004-03-01 Page:  1 2 3 4 5 6 7 8

How does Perl mix OOP with procedural and functional programming?

Perl is a laid-back language. It goes to great lengths to let programmers do whatever they want, in whatever way is convenient to them. This contrasts sharply with languages like Java and C++. For instance, Perl is happy to allow the programmer to automatically create variables if they were not previously declared (though this is not encouraged, and can in fact be prevented with the use of the highly recommended "use strict" pragma). If you want to shoot yourself in the foot, Perl will give you ten bullets and a laser scope, then stand by and cheer you on.

Perl is, therefore, a great language for abusing methodologies. Don't cringe. It's OK. Accessing internal object data, changing classes on the fly, and redefining methods on the fly are all allowed, for example. The Perl way is that programmers should be allowed to break the rules in the interest of coding, debugging, and execution efficiency. If it helps get the job done, it's OK. Thus, Perl itself can be the programmer's best friend or worst enemy.

Why would anyone want to mix OOP, FP, and PP, if it means breaking the rules? Let's step back and consider the question. What are OOP, FP, and PP? They are just programming methodologies, bundles of concepts, stacks of rules that exist to serve the programming team. OOP, FP, and PP are tools, and every programmer's first job is to know his tools. If a programmer fails to utilize the FP Schwartzian transform in sorting a hash, but writes his own Sort::Hashtable, or fails to reuse the Sys::Hostname module and instead writes procedural code to obtain the system's hostname, that programmer has wasted time, effort, and money, and has reduced code quality and reliability.

A programming team can become complacent with the tools it knows best, and this is just about the worst thing that can happen to them. Using only a subset of the tools available in an industry as exciting and innovative as the computer programming industry guarantees that the team will become useless in a few years. A programmer should be able to mix any methodology whatsoever if it makes him more efficient, his code better, and the team more innovative. Perl recognizes and encourages this attitude.



View The road to better programming: Chapter 5 Modules and objects Discussion

Page:  1 2 3 4 5 6 7 8 Next Page: Benefits of OOP

First published by IBM developerWorks


Copyright 2004-2017 GrindingGears.com. All rights reserved.
Article copyright and all rights retained by the author.