Hello AppleFritter,

Thank you for your time and effort, I will definitely take a look. I am also reading the perlootut (the official tutorial) which also includes some rules apart from guidance.

Again thank you for your time and effort.

Seeking for Perl wisdom...on the process...not there...yet!

The only one of those I am not sure about is the natural hierarchy/inheritance one. The big problem is the LSP and often data that seems to follow a natural hierarchy (a square is a rectangle) in fact violates the LSP.

Inheritance is powerful but it is also very difficult to get right. On the other hand, one thing I really like about Moose is the fact that the roles and delegation systems provides a useful alternative to inheritance where what you really want to offer is a consistent interface.

The only one of those I am not sure about is the natural hierarchy/inheritance one. The big problem is the LSP and often data that seems to follow a natural hierarchy (a square is a rectangle) in fact violates the LSP.

Hmm, could you elaborate on this? As I understand it, the LSP stipulates that a property that holds for objects of a given type must not fail for objects of a subtype thereof.

So suppose that you've got a class Rectangle, and a subclass Square. What property would be provable about instances of Rectangle that isn't provable about instances of Square? You can prove additional facts about the latter, of course, but I'm not seeing any property that's lost by transitioning from (general) rectangles to squares.

The proficient programmer is not unlike the experienced mechanic.

She or he will have learned various paradigms, an assortment of different ways of looking at problems, and how to use a wide variety of tools. Then when presented with a task, will use experience and judgement to grab the tool that seems to best fit the task. And this practitioner will choose an overall approach that might not seem obvious to a beginner, but that in the end simplifies the project.

Object oriented programming is one way of approaching a problem. It's not the only way, and it's not necessarily the best way. The best way will be the way that fits best within the greater project, that is most maintainable, that meets efficiency requirements, that follows accepted coding norms for an organization... but most importantly, the one that solves the problem most effortlessly. Sometimes the primary task is only part of the problem. Other components of the problem might be things such as the ability to extend the solution later on. Some of these sorts of concerns are not obvious to a beginner.

I sometimes find taking an object oriented approach leads to over-engineering what ought to be a simple problem. Other times, I find that it helps keep a non-trivial problem manageable. But the same can be said of functional techniques sometimes. Once in awhile the shortest path to success is just a few lines of plain old code.

One should probably strive to become well versed enough that they don't fall into the trap of "If the only tool you have is a hammer, every problem will begin looking like a nail."

Hello Dave,

I totally agree with you, there no right and wrong solution. A solution is a solution, maybe at early stages like me the solution might not be perfect or well written but I guess until you master something it will always be like this. Even at this stage I found my self taken the decision what approach to follow. Any solution has positive and negative effects, the programmer needs to decide upon what to choose and what is closer to his needs.

Thank you for your time and effort to comment on my questions.

Seeking for Perl wisdom...on the process...not there...yet!

Object-oriented programs run slightly slower [....] If you can get away without using object orientation, you probably should.

What a horrible conclusion. An equivalent conclusion is "If it is possible to do something in C or C++, then you probably should just not do it in Perl."

What are usually rather trivial run-time performance differences should have nearly zero bearing on your choice of approach. Even if your OO experiment found that the OO code was consistently 20% slower than the non-OO code, that is unlikely to be a significant factor in evaluating whether or not to use OO for that case (are you even going to notice most of the time if your script takes 3 seconds to run instead of 3.6 seconds to run?).

Clearly it shouldn't be the single most important factor. That particular comment should be simply and easily dismissed.

Hello tye,

You are right, a user would not been able to observe a difference even of a second. Some times I found my self spending too much time and effort trying to improve and compare my code with small percentages.

The reason that I am using Perl is that simplifies life so much and also there are so many modules available to choose upon that it makes all other programming languages look so poor.

So in conclusion is C and C++ faster? Yes, since Perl is written in C. But, taken in consideration the variety of modules available in Perl, I do not think so there is something to compare here.

Apart from timing and simple tasks is also the ability to solve something really fast and really simple. This is the beauty of Perl.

Thank you for your time and effort reading and replying to my question.

Seeking for Perl wisdom...on the process...not there...yet!

One nit to pick: C isn't faster than Perl because Perl is written in C. It's faster because it isn't doing much behind the scenes compared to what Perl is doing. Once you layer in a significant portion of what Perl would be doing, a C program would begin to perform similar to Perl, or worse since its code hasn't undergone the years of scrutiny Perl has.

One reason that XS is useful is that it allows the programmer to decide what things that Perl would normally do are unnecessary in a particular xsub, thus only paying for what is needed and used.




Dave

Method calls are very slightly slower than function calls...

use v5.10;
use strict;
use warnings;
use Benchmark qw( cmpthese );

sub Foo::bar { $_[0][0] or die }
our $object = bless [1], "Foo";

cmpthese -1 => {
    "method call"   => q[ $::object->bar ],
    "fun call"      => q[ Foo::bar( $::object ) ],
};

__END__
                 Rate method call    fun call
method call 4365983/s          --        -15%
fun call    5128108/s         17%          --
[download]

This is because with a normal function call, Perl can figure out which function is being called at compile time. At run time, it just has to call the function. With a method call, Perl needs to figure out which method to call at run time, taking into account things like inheritance.

However, the problem is with these toy examples that they're not taking into account the fact that in a typical program factors like method dispatch are not a major bottleneck. In a script that does heavy number crunching, or lots of IO, or string processing, switching from method calls to function calls may help you shave 0.04 seconds off its three minute execution time, so in terms of "how do I optimize this script", it's barely worth thinking about.

In my previous example, try changing the sub definition to this:

sub Foo::bar {
    my $filename = sprintf('/tmp/%s.txt', ref $_[0]);
    open my $fh, '>', $filename or die($!);
    print $fh $_[0][0] or die($!);
    close $fh or die($!);
    1 while unlink $filename;
}
[download]

And watch that 17% difference disappear. Speed is really not an important factor in choosing an OO approach.

While there are some tasks for which a procedural, or functional approach is more warranted¹, for most medium-to-large-scale tasks OO should be your default approach. A well-structured OO project should result in very readable, understandable, maintainable, and extensible code.

¹ Imagine Scalar::Util or List::Util written in an OO style. No thanks.

Method calls are very slightly slower than function calls...

How much? 0.000,000,030 s slower according to your benchmark. That's a mere 30 nanoseconds!

I know, it seems wrong to use the word "slow" to describe anything that's being done over 4 million times per second. How about saying that method calls are not quite as insanely fast as function calls?

toby döt ink

Hello tobyink,

Update: (forgot to add the "not" should not be so picky)

Nice example, thanks for sharing. Well I guess if someone wants to benefit from the advantages of OO programming he should not be so picky about the speed performance since the difference is so so small.

Thank you for your time and effort reading and replying to my question.

Seeking for Perl wisdom...on the process...not there...yet!

How much is your time worth? Should you spend 15% more time programming something to get a 5% speed increase at run time? How many times will this code run? Will an extra one second saved per run over 3652 runs (roughly once a day for ten years) be worth it to spend two hours of programmer time (7200 seconds)? Will your code run that often? Will it only take two extra hours to write and maintain? Is your time cheaper than that of the computer, or even of the users running the code and waiting that extra one second per run?

In Donald Knuth's paper "Structured Programming With GoTo Statements", he wrote: "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."

Is this one of those 3% times? Likewise, Stephen C. Johnson and Brian W. Kernighan said "the strategy is definitely: first make it work, then make it right, and, finally, make it fast."

Is your code handling the common case? Is it now handling edge cases and debugged? Are you at a point that you have a well-designed, well-implemented, easily maintained program with a runtime that is just too slow? That's the time to start looking at small optimizations, and not before.

Hello mr_mischief,

That is absolutely true, even I that I am beginner I find my self spending maybe way too much time to make the code faster and more efficient. Maybe I should focus more in other criteria and less on the speed.

Thank you for your time and effort reading and replying to my question.

Seeking for Perl wisdom...on the process...not there...yet!

First I think this is a great question. I also think it demands a sort of discussion that I haven't seen on this thead yet, namely why object oriented programming exists at all.

The single biggest problem in computer programming is state management. All bugs fit into three classes: doing the wrong thing with the wrong data, doing the wrong thing with the right data, and doing the right thing with the wrong data. Almost always by the time you see a bug the proximal issue is doing the right thing with the wrong data, so debugging involves backward tracing the program to see hos the data was set up incorrectly in the first place.

Over the years, many strategies have developed to manage this problem, including procedural, structural, and object oriented programming. Functional programming is another set of strategies broadly compatible with procedural, structural, and object oriented programming, but it exists on a different axis. While functional programming tells you what your program can or cannot do with the data (do not mutate it in place, for example), the other strategies have to do with organizing your data so you can more easily maintain things.

A progression may be worth looking at. With simple scripting, your variables are scoped to your script, it runs linearly or perhaps to specific points with goto statements. This works fine for trivial things but breaks down when even a little complexity is added.

Procedural programming encapsulates your script's logic behind procedures and as much state as possible is local to the procedure. This helps with the complexity but as your data becomes complex it becomes very easy for mistakes to occur.

So the next is to make variables into more complex data structures. This allows far more complexity. Perl provides a number of basic data types from which complex structures can be built. Most importantly this allows a programmer to determine what variables belong together. But everything has to know the insides of every data structure so interfaces become very brittle

Object oriented programming is basically where you take data structures and associate them with behavior. This allows you to hide the internals and thus exercise greater control over program state. This gets to when to use object oriented programming (either imperative or functional) in Perl: when your application is complex enough that this helps manage state. There's both programming and performance overhead but that helps avoid perpetual problems in software development.

Object oriented programming allows you to write programs that are far more robust and easy to maintain than you can reasonably do without it. You should use it whenever and wherever it is helpful in this regard, namely any time a program goes well beyond the trivial stage.

On a related note, sometimes I find using OO only to have separate name space and not have to import k number of subs. That surely beats having to write the module name every time when calling a function. I do cringe having to provide a constructor (when all I need is a short syntax to call a sub) due to, however minor, work involved.

Is there any other reasonable alternative to the above?

If these are utilityish methods that don't actually need a real blessed object, then:

package Foo::Utils {
   sub frobnicate {
      shift; # ignore invocant
      print "frobnicating!\n";
   }
}

...; # some time later

my $utils = "Foo::Utils";  # no need for a constructor

...; # some time later

$utils->frobincate;        # call as a class method
[download]

That said, writing a constructor isn't hard:

package Foo::Utils {
   sub new { bless [], shift }
   sub frobnicate {
      shift; # ignore invocant
      print "frobnicating!\n";
   }
}
[download]

Or even easier:

package Foo::Utils {
   use Moo;
   sub frobnicate {
      shift; # ignore invocant
      print "frobnicating!\n";
   }
}
[download]

toby döt ink

Bottom line for me is ... I happen to find “the object-oriented approach” to be damned useful!!   :-D

And here is why:   “because you always know precisely where your data is!”

Q:   “Exactly what piece of data is this piece of code supposed to manipulate?”
A:   this

Instead of treating “executable statements” and “the data which the statements are to affect” as two separate things, the object-oriented paradigm makes things very, very easy:   whenever your executable subroutines are invoked, “the piece of data that they are intended to manipulate” is implicitly known.   You don’t have to monkey-around with “passing ‘the right thing,’ everytime and everywhere” to them, as procedure/function parameters that you must take care to provide “correctly.”   Instead, the language itself does this for you.

“The language, itself” also shoulders more of the burden of determining whether-or-not these subroutines are “the right subroutines to call” in any particular situation.   Instead of throwing that burden entirely upon you, as the application-programmer, the language bears much of it, through a clearly-defined mechanism of classes and inheritance rules which are easy to understand ... and to exploit.

“Damned useful,” as I said earlier, because it makes my chore easier.

Now, is there an equally-pragmatic down side?   You bet there is!   This crops up whenever you look at a particular bit of source-code ... and you simply can’t tell exactly what it’s gonna do ... and it actually makes a difference.   (Example:   you’re chasing-down a nasty bug, and you run into a fork in the road, and you cannot tell which direction the rabbit might have gone.)

Hello sundialsvc4,

You are absolutely right, I was reading all the time about OO programming and I was not able to understand the abilities of such a coding process. The moment that I created a sample of code, I was so impressed with the result that I am wondering was I was doing so long? How could I have mist something so important. From my point of view OO programming could practically assist a programmer in so many ways that it does not even worth spending the time not measure the performance.

Thank you for your time and effort reading and replying to my question.

Seeking for Perl wisdom...on the process...not there...yet!