Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Re: kind of effort required for learning OO perl ?!

by BrowserUk (Patriarch)
on Jul 30, 2010 at 00:56 UTC ( [id://852026]=note: print w/replies, xml ) Need Help??


in reply to kind of effort required for learning OO perl ?!

If you want to learn the use of OO in Perl and have time (say 2 to 4 weeks of evenings) to play:

  • start with the perldocs perlobj, perlboot & perltoot to get an understanding of how the mechanics of OO works.
  • Once you get bored with reconstructing those mechanics manually each time, do the Moose tutorial thing. (Another 2 to 4 weeks say.)
  • Once you get fed up with the performance; you might decide that you don't need all the bells and whistles; and that actually, reconstructing the mechanics manually isn't so arduous after all.

If you want to understand the right way to think about problems, in a manner that will allow you to use OO effectively and maintainably, download an Eiffel compiler and splash out on Object-Oriented Software Construction, 2nd Edition by Bertrand Meyer.

Neither a cheap, nor easy, nor quick option, it will make you think about software and software development in a completely different way than if you acquire your OO knowledge in a piecemeal fashion. And you will never regret it.


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^2: kind of effort required for learning OO perl ?!
by punkish (Priest) on Jul 30, 2010 at 02:28 UTC
    I have to admit up-front that I am biased favorably toward listening to BrowserUk's advice. So, I want to take the advice seriously, but I am trying to understand where it would lead me? Should I go the traditional Perl OO route? Should I go the Moose route? Should I go back to the traditional Perl OO route? Or, should I chuck it all and work with a grounds-up OO language (not something I am going to do without very good reason) such as Eiffel, which, eventually gets compiled into C anyway (via SmartEiffel compiler).

    BrowserUk, please educate me and others.

    Thanks in advance.

    --

    when small people start casting long shadows, it is time to go to bed
      Or, should I chuck it all

      Learning a new language, especially in order to become familiar with a new paradigm, does not imply that you forget or stop using what you already know. Not even vaguely.

      Over the last 8 years I've experimented with a variety of FP languages--Haskell, Caml, Mozart/Oz, Erlang, Q/Pure amongst others--specifically to get a handle on FP. And I believe that those efforts have greatly benefitted my approach to solving some types of problems. But I still use Perl as my first choice when I need to get something done. And revert to C when I need to do (parts of) it more quickly.

      I encountered Eiffel--actually an OU teaching variant call Small Eiffel--and OOSC when mentoring a mature OU undergrad, 15 or so years ago. I'd done various forms of OO programming before that, including some fairly in-depth (v.large project; huge overall system complexity) in C++. My C++ skills were rated (by others) as "above average"; but I hated it!

      I hated it because nothing was simple; nothing was intuitive; nothing was elegant. Nothing ever seemed to be really "right". There were always compromises. Too many compromises. Even as we were gathering the plaudits for a job well done, having met all the requirements & performance criteria; and passed all the tests. The customer had signed off and agreed to completion bonuses. I still had nagging doubts. And I was not the only one on the team with them, though we mostly kept them to ourselves.

      It wasn't until I read OOSC, and worked with Eiffel that I understood why.

      The 'add-on' nature of C++, especially back then, means that it is not just far too easy, but you are actively encouraged, to think of OO as a way to create a convenient set of name-spaces in which to stick your data and subroutines. And for large numbers of OO programmers in many languages, that is pretty much all they get from OO; and they are happy that way.

      What Meyer taught me was that OO is far less about the mechanics of hiding your data & methods behind name-spaces; and far more about modeling your application in its own terms. Sorry for the emphasis, but its an important point that I will strive to explain.

      Far too often, classes and class hierarchies are modelled around concepts like numbers(subdivided into integers and reals(further subdivided into 8/16/32/64-bits etc.), strings(subdivided into various fixed and variable lengths), Persons(subdivided into employees, customers; and then managers etc.), polygons(subdivided into squares, circles etc.). And each of these low-level classes are written (or supplied or bought in as libraries) to be complete. So numeric classes not only know how to add, subtract, multiply, divide and compare themselves; but also how to integrate and differentiate and calculate Bessel functions et al. that a complete math library should.

      The problem is, at the top levels of any particular application (suite), the entities required are hybrid. The data comes into the program in a file that contains strings. Within those strings are names, ages, addresses, zipcodes, versions, dates, times, places, quantities in a variety of units, sounds, colors, distances, routes, feelings, truths and speculations.

      And those high-level entities are constructed--through composition or multi-inheritance--from a rag bag of the low-level entities. And so you end up with things like:

      Addresses split into:

      1. StreetNo (int)--which screws up when it is '221a'--despite that you never perform math with street numbers.
      2. First line (char80) -- In the UK this is streetname; in the Netherlands it is the Town.
      3. Second line (char80)
      4. TownOrCity (char40) -- what if I live in a village or hamlet or on an island?
      5. County/State/Region (char40)-- Um. Monaco (or Andorra).
      6. Country (char20) -- Monaco (Andorra).
      7. ZIPCODE/POSTCODE/ (char8) -- Just too damn bad if you live in Iran with their 10 digit post codes.

      Personnel applications where job description is an attribute of the Employee, when the jobs are the constant and the people come go and move.

      Version number stored as floats.

      And each of those objects brings in huge chunks of the underlying class library code that the application will never use. Eg. You'll never need to run a Bessel function on a version number. And with it, you get a whole bunch of parameter validation at each of those lower levels that is (should be) redundant, because the higher level composing classes perform their parameter validation where it should be done--on input.

      To answer your 3 questions.

      • I believe that understanding how the mechanics of OO works is very important when it comes to debugging.

        Working out why your code is producing weird results, because you've derived from two classes that have a common method name, if you don't understand the mechanisms of inheritance, is almost impossible. And Perl's 'native OO' gives you a better insight to that than just about any other language I'm aware of.

        But it is far too easy to get wrapped up in the details of those mechanisms, and loose sight of the overall problem you are trying to solve. And that can lead to OO myopia. To the concentration upon writing good OO at the expense of solving the overall problem cleanly, efficiently, and maintainably.

        I think that OO-spaghetti is far harder to debug than procedural spaghetti. And that these days, OO-spaghetti is far more prevalent simply because the problems with gotos and globals etc. are very well known and talked about. But everything OO feels like you're doing the right thing.

      • I think if you need to get something going quickly, you'll probably get there quicker with Moose than without it. And most of the time it will probably work.

        But without the grounding of understanding what Moose is doing for you under the covers, when it goes wrong, whether through your fault or theirs, you'll be up shit creek without a paddle.

        I also think that Moose comes with an agenda and an underlying philosophy that means if that is your first experience of OO, you're likely to find yourself bewildered and confused if you have to move away from that to (say) Java, C++ or JS.

        It may also lead to the same kind of OO myopia I mentioned above.

      • Whether you will find the performance of Moose limiting will very much depend upon the type of programming you do.

        If everything you do is IO-limited, perhaps not. If you write anything that is CPU-bound for more than a few minutes, you'll definitely notice it.

        The problem is that it isn't really possible to just re-write the slow bits of your Moose application in Inline::C or XS, because the overhead is not in your code, but in the (now hidden) mechanics of the OO itself.

        OO encourages the use of myriad small methods calling other methods calling other methods. Put those in loops--and all CPU-bound code involves loops--and you multiply the cost of Perl's sluggish function calls over and over. Be overzealous with your parameter validation, add in a little runtime introspection, and you are going to notice.

        And once you notice, you might be tempted to measure. And once you measure, you might find yourself wondering what all that overhead is buying you.

      • If you have the time, or the inclination to make the time, then I seriously doubt that you would ever regret learning enough Eiffel to get you through--the first few chapters at least--of OOSC.

        I also seriously doubt many people will move over to Eiffel as their main or only language; or even use it for paying commercial work. But like those that got to grips with Lisp early in their careers say, it will influence everything you write from then on, whatever language you write it in.

      The (my) bottom line. If you have the time, try all three: Perl basic OO; Moose; and Eiffel+OOSC. If you don't have the time, make the time. If not now, then over the next few weeks or months. Each will benefit you.

      If I didn't know PBOO, and had to get something together now. I'd go the Moose route. But I'd stick to the Moose basics, and not get caught up in trying to use every bell and whistle. I'd use only what I needed. To avoid lock-in and overhead.

      And then make the time to go back and try the other two.


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      If you want to learn OO well and don't mind exploring a language besides Perl, Eiffel is a good candidate. Smalltalk is another.

        Though be aware that Eiffel not only is OO, it's also "design by contract". There's a strong focus on checking pre- and postconditions and invariants.

        There's nothing wrong with "design by contract", but it might bog you down if you're looking at Eiffel just to get more knowledgeable about OO.

        To explain in a few lines and with lots of handwaving: each class has a set of invariants defined. Each time you call a method in an object of said class, the invariants are checked upon method exit. Exception on failure. Loop invariants and postconditions are checked in a similar way.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://852026]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having a coffee break in the Monastery: (6)
As of 2024-03-28 08:55 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found