Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid

Learning OOP

by BarneyFife (Acolyte)
on Jun 23, 2003 at 03:03 UTC ( [id://268029]=perlmeditation: print w/replies, xml ) Need Help??

In your opinion, is Perl a good place to start (not necessarily the end all) learning the principles of OOP in general?

I've gone through the learning perl book some time ago and I'd rather brush up on my basic Perl and then move on to Randal Schwartz new book, "Learning Perl Objects, References, and Modules" instead of learning Java just to acquire a knowledge of OOP.


Replies are listed 'Best First'.
Re: Learning OOP
by thraxil (Prior) on Jun 23, 2003 at 03:21 UTC
    • Perl's object model is a little different than you're likely to encounter in other languages. you'll face a bit of a learning curve when trying to apply what you've learned from perl to another language like java.
    • since it wasn't designed as an OOP language from the ground up, some things are a little odd. eg, objects are kind of (but not entirely) like modules and methods are kind of (but not entirely) like regular functions.
    • perl's object model is extremely transparent, flexable, and easy to play with. if you want to really poke at things and see how OOP is done, perl will let you right into the guts.
    • Damian Conway's Object Oriented Perl is one of the best books on OOP out there in any language.

    and, fwiw, i wouldn't bother with Java even if you decide you want to learn OOP in another more OOP-focused language. instead, i'd look at smalltalk, ruby, or python instead.

    anders pearson

•Re: Learning OOP
by merlyn (Sage) on Jun 23, 2003 at 03:17 UTC

      Your book is also available on safari as of a couple days ago. Although everyone should also buy the treeware for reference ;-)

      I'd recommend either Python (for those who love scripting languages) or basic C++ (ignore the STL, exceptions, etc, at first...I don't like them anyway).

      Java reminds me of Ent-speak, and Perl's very different... things can be said better w/o making Perl objects 95% of the time.

      Edit by tye, title, P

•Re: Learning OOP
by merlyn (Sage) on Jun 23, 2003 at 03:32 UTC
    If you truly want to learn objects, you should probably learn objects in a system that is truly object oriented. Smalltalk is a good language for that, and the Squeak system is cross-platform, full of goodies, fun to play with, and has a strong community support (including a couple of Squeak specific books).

    Don't bother listening to claims that Java or C++ are "object-oriented". They're hybrid languages like Perl (some objects, some primitives).

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

      Speaking of Squeak, who can answer a question for me: Alan Kay is on the Squeak team. I know there was an Alan Kay involved with the development of Smalltalk at Xerox PARC. But there was also a Kay involved with developing an early PC named the Kaypro, which happens to be the first computer I owned. I've seen people attribute both to Alan Kay; others say there were two different Alan Kay's; and still others say that Kaypro was founded by Andrew -- not Alan -- Kay. I know I'm now OT but I've always wondered about that. I still have that CP/M based Kaypro. 1 experience point promised to anyone who knows the real story!


        1. Andy Kay - kaypro
        2. Alan Kay - smalltalk

        I'll collect the experience point later ;-)

      If you truly want to learn objects, you should probably learn objects in a system that is truly object oriented.

      Totally agree with merlyn.

      Along with Smalltalk I would take a look at Ruby (whose more traditional syntax you might find more friendly) and Eiffel (if you're of a static-typing bent.)

      Much as I love Perl I wouldn't recommend it as a learning environment for OO concepts. Because of the TMTOWTDI perl approach (and the cruftyness of some of the Perl5 OO implementation) its harder to see the advantages (and disadvantages) of OO code and the OO mindset.

      My advice would be to learn OO in a strictly OO language. Get into the OOA/OOD/OOP mindset. Take the best bits of what you learn and apply it back to Perl.

Re: Learning OOP
by Zaxo (Archbishop) on Jun 23, 2003 at 03:22 UTC

    Perl has the great advantage that its OO features are flexible and not mandatory.

    A language, like Java, that is built around OO must be built around some particular theory of OO. The result is that, in use, your classes must be built to meet the constraints imposed by the language. OO language bigots have immense flamewars over whose OO flavor is purest. The languages they all love to hate are Perl and C++, for leaving the rules up to the developer.

    I've been told (by merlyn ;-)) that the book you mention is ideal for your purposes, and that TheDamian's Object Oriented Perl makes the perfect follow-on study.

    After Compline,

      Of the OO languages I've used, Perl is most like C++, in that it gives you more freedom than most. Both also give you more rope to hang yourself with, but that can (IMO) help you learn a lot too.

      Two of my favorite Perl features are ties and closures. If you learn these, you'll be too spoiled to learn Java.

      Even though you need certain features to do OO "right", it's my opinion that OO is mostly a way of thinking. I've seen C code that's more OO in its design than some poor Java code I've also seen. The thing that forces most people into OO ways of thinking is tackling large problems with identifiable patterns. Most developers innately want to fit the patterns they see emerging from any problem space into neat packages of some sort. If you start thinking that way, OO will follow.

      If you do choose to learn Perl OO be prepared for a lot of people wanting to constantly argue that Perl is not an OO language. Usually, by quietly solving the same problems in less time they go away.

Re: Learning OOP
by Anonymous Monk on Jun 23, 2003 at 03:19 UTC
    is Perl a good place to start (not necessarily the end all) learning the principles of OOP in general?

    Not Perl 5*. The Perl 5 OO model is, to put it nicely, messy. It also isn't representative of the many other OO models out there. I would strongly recommend Ruby for your purpose. Stay away from the bloat that is Java unless you want to put it on your resume.

    You should also consider that there really isn't much fundamentally different about object-oriented programming. It's not as if all the algorithms you've ever learned will stop working. It also isn't the best solution to all (or most for that matter) problems. Ensure you have a good foundation before moving on to buzzword-hyped methods.

    *Perl 6 appears to fix a great deal of the problems.

Re: Learning OOP
by nite_man (Deacon) on Jun 23, 2003 at 08:59 UTC

    I like Perl. I use Perl every day. I think that Perl is one of the best programming languages! For me, Perl is not programming language, Perl is life philosophy! But ...

    Using my expirience I can not say 'Perl is good place for start lerning the princeples of OOP'! You can use Perl for development an OO applications, Perl leaves to you many features - it's beyond controversy. But Perl doesn't have an clear implementation of OO.

    I think that it will be better for you to start study OOP on SmalTalk, C++ or Java. Try to look at The Introduction to Object-Oriented Programming. This book shows principles of OOP in different programming language: SmalTalk, C++, C#, Java, Delphi. Unfortunatelly, author wrote nothing about Perl.

    Also, visite on Timothy A. Budd personal page (author of "The Introduction to Object-Oriented Programming").

    SV* sv_bless(SV* sv, HV* stash);
Re: Learning OOP
by Tomte (Priest) on Jun 23, 2003 at 06:52 UTC

    If you're really after learning good OO knowledge and style I can't help but recommend study the things that Bertrand Meyer has to say about it in "Eiffel, The Language" , and play around with SmartEiffel a bit. The Concepts of OO-Programming, not the least Programming by Contract, as explained and to a great deal coined by Meyer, are leading IMHO to best practices in every oo-enabled language.

    I don't know smalltalk very well, but from what I know, some of the others here are right, that it will make a good starting point too.


    Hlade's Law:

    If you have a difficult task, give it to a lazy person --
    they will find an easier way to do it.

Re: Learning OOP
by tilly (Archbishop) on Jun 23, 2003 at 12:14 UTC
    Well I started learning the principles of OOP in Perl.

    I don't seem to have any scars left from that. Well I did, but TheDamian left bigger ones in approximately the same places...

    Seriously, learn a technique to use it, not to be able to claim to know it. If OO is possibly useful to you, and Perl does OO, then learn OO in Perl If you are left feeling like you don't understand it very well, then you can go back and learn it for real in a language that does it better than Perl does. If you want, then tell yourself that you are learning oop right now, not OOP.

      Seriously, learn a technique to use it, not to be able to claim to know it.

      So how do you propose learning something you know nothing about? If I didn't know what Object-oriented programming is, how would I learn that it's useful to me? You need to constantly evaluate new ideas whether or not they end up being useful. Any other approach results in a self-fulfilling prophecy of ignorance.

        I never meant to suggest that one should not constantly evaluate new ideas. Indeed I do try to constantly evaluate new ideas.

        However I am constantly trying to integrate those ideas into my knowledge and life rather than learning them as stand-alone things. Sometimes that doesn't work - some ideas really can't be fit into any framework that I have. But usually it does, and usually the fact that it is not sitting in a vacuum allows me to ask better questions, learn faster, and make use of what I have learned more quickly. And since it does that for me, I sometimes tell other people that it is a good way to try to work as well...

Re: Learning OOP
by BarneyFife (Acolyte) on Jun 23, 2003 at 13:26 UTC
    I want to thank you for your input. It has been very enlightening.
    I enjoyed the comments of those who learned oo-programming while using Perl.
    My reason for gaining an understanding of oop is one of many steps in becoming a better ‘programmer’, my goal is to write code I can be proud of when it works and when viewed by programmers with more experience than myself. (to quote a former manager, "chicks dig sexy code") I’m an old dude (42) who was a musician for 20 years who had no desire for a college degree, and now doesn’t have the time.

    (Married > 3 Kids > Self-taught web designer hanging with Perl and Java Programmers > Learns Perl (entry)> Takes a detour for a 2 year PHP contract > Now wants to be able to get farther away from the “Just another designer who does a little scripting, but really doesn’t know what he’s doing” group – I hate that ;-).

    I’d love to take a few years and do anything it takes to get a CS degree, but that just not going to happen. My goal is to make money doing what I like, building stuff with my computer. I’m fascinated with programming; at Merlin’s reference to SmallTalk I went and checked it out. My heart says, “cool”, but my brain says, “Yea, but you don’t have the time to get to the “super-geek” level.” (perhaps as a hobby)

    So after reading your posts and much meditation, I think Perl is perfect for me, I can use it for learning more advanced programming, it’s time well spent, since I can use the knowledge right away in my work.
    Thanks, now I can quit thinking and get to work!

    - DJS

      Commenting on his own post:

      Reading this in the context fo the thread...
      Sorry if this is too "up close and personal".
      Age old question, "Too much coffee, or not enough?"


      That's a pretty good distillation of all those replies. But I still want to pipe up.

      I agree about the Smalltalk reference; it is an *excellent* way to learn OO, but perhaps not 'practical' for some value of practical.

      If you are looking for marketability, I concur with one reply that mentioned Java. Java will teach you a basic OO-way of thinking, and much of the syntax will be familiar to a Perler. Most non-web jobs don't use the word 'Perl' in their descriptions. There's always C#... (I can't believe I said that).

      Also, we know that learning another language teaches your brain to think about programming in new ways; it's not an addendum, it's a synergy.

      Finally, I agree with nearly all the replies that say that Perl is not a wonderful way to learn OO. However, it will probably teach you more about the guts of an OO system than Java would, and in fact might not straitjacket the learning process -- that is, Perl gives you more rope. But again, that thread might circle back to the Smalltalk issue... how much does the average Perler need to know in order to make a living?
Re: Learning OOP
by TomDLux (Vicar) on Jun 23, 2003 at 04:41 UTC

    I saw merlyn's workshop on objects in Buffalo (good beer in Buffalo) and heartily recommend his approach to explaining OO.


Re: Learning OOP
by tos (Deacon) on Jun 23, 2003 at 09:04 UTC

    in my opionion it's a good place to start gathering experience with oop. I myself took several attempts with other languages as c++ or java. With c++ my problem was the insufficient knowledge of the basics of c. The java-attempt was to much academic.

    With perl things became easier for me. This was above all the quite simple realisation (so it affects me) of oop in perl. Classes aren't anything different as packages, objects are blessed data-structures, mostly hashes of a particular class, methodes are simple subroutines in packages(classes). This took away any esoteric imaginations i've had before and i was really astonished how easy object-orientated behavior could be realized in a script-language as perl is.

    Meanwhile i use my still growing oop-experience in real life applications with good success. Further development is due to perls flexibility relative simple. For studying more professional implementations i've a look in the CPAN.

    So from my point of view i can absolutly recommend perl for learning oop. Try man perltoot as a first step.

    greetings, tos

      I think you're over-simplifying it. Methods aren't just package subs, Classes are not just packages and object are not just blessed references.

      Sure, that's how it all works (in Perl). But the way of thinking is different.

      Objects are "more of the same" class, and their specific data can be handled with methods.

      But of course you already know that.... ;-)

Becoming a better programmer (Re: Learning OOP)
by dragonchild (Archbishop) on Jun 26, 2003 at 12:14 UTC
    The Principles of OO:
    1. When you abstract out an operation, try and keep similar operations together. Likewise for data.
    2. Similarity depends solely on how easy it is for the developer to grok it. Everyone thinks differently.
    3. Once you have a bunch of specialized objects, you ask them to do stuff for you. (If you're really nice, they'll actually do it.)
    That's it. It has nothing to do with a language and everything to do with a philosophy. OO theory is over 40 years old. OOP can be done in C, Fortran, and x86 assembler.

    Confused? Think about it this way - why were the first OO languages designed? It was because someone wanted to express an idea more easily than he could in the languages he had at hand. The idea predates the language.

    A better plan, imho, would be to understand the paradigms of programming - imperative, object, functional, and logical. Once you understand those (and how Perl allows you to do any/all of them as you choose, with appropriate modules), then you will be fine.

    Now, if you want to make yourself a better programmer, try this:

    1. Purchase and read Code Complete, by Steve McConnell. And, I mean read every single word. It'll take the average intelligent reader about 3 months. This is the seminal work on generalized programming how-to knowledge.
    2. Borrow and read The Mythical Man-month. This will give you a true understanding of project management. (Why should you care? Anything that isn't a one-off is a project, whether you know it or not.)
    3. Find, purchase, and read a good book on problem analysis. (This will, most likely, be in the mathematics section, not the programming section.) I apologize for not having any titles at my fingertips. (Why should you care? Every single thing you write is a solution to a problem. If you don't know how to solve problems, you can't design good code.)
    4. Find, purchase, and read a good book on designing tests. This is a lot harder than it looks.
    5. Ask a million questions on Perlmonks. Even better is to answer a million questions, especially when you answer them wrong. PM is one of the few places where you will be corrected gently, if it seems that you're actually trying.
    6. Learn LISP. (I'm at this step, myself.) The lambda calculus is arguably the most important foundation of program development. Not knowing it is like being a architect without an understanding of the tensile strength of various materials.
    7. Finally is to avoid buzzwords. Who cares if your program is(n't) OO? The primary and most important feature of a program is correct execution.

    We are the carpenters and bricklayers of the Information Age.

    Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

    Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.


      I wish someone had given me those 7 Easy:) Steps when I was starting out. It sure would have saved a lot of blind alleys.

      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller

Re: Learning OOP
by mooseboy (Pilgrim) on Jun 23, 2003 at 14:04 UTC

    I can certainly add my voice to those recommending TheDamian's insightful OOP book. I'm about three-quarters of the way through and am learning a great deal about Perl, OOP and programming in general. At least I think I am, I guess I'll find out when my head stops going round %-)

    Another source you might like to look at is Bruce Eckel's website, where he has copies of his books Thinking in Java and Thinking in C++ available for free download. They will give you some insight for OOP in other languages.

Re: Learning OOP
by chunlou (Curate) on Jun 23, 2003 at 15:39 UTC
    I feel OO Design is more applicable to a wide variety of problems than OOP itself.

    Actually, you could also learn a bit about UML, sort of OO way of thinking, without being language specifc (though Java is the most often used examples).

    Unless you work on video game or missile guiding system, your analysis and design skills (i.e. knowing how to turn unorganized requests into actionable req spec into codeable design spec) are probably more important than your programming skill (as long as it's descent enough).

    And the same old advice: practise. One hour of practice is better than 12 hours of reading. Solve some problems that interest you, be it making webpage or sorting through DNA.
Re: Learning OOP
by scrottie (Scribe) on Jun 24, 2003 at 11:50 UTC
    Many books and tutorials have been written on using objects in Perl, but as you said, you want to learn OO design, not just OO syntax.

    Most OO code is horrid. It completely misses the point of writing OO code. It was tought incorrectly for decades, resulting in vast quantities of truely wretched OO code. Students see shining examples of OO principles, but when they're put into the wildness of writing code, they can't produce the same results. How to get from here to there is lacking. Merely inheriting rather than cutting and pasting was insufficient - the structure of code is still rigid, and different implementations can't be easily swapped out in favor of another during development or runtime. The names of classes are still hardcoded into each other. Things are abstracted, but the abstracted interfaces are difficult to use, and the implementations are horrid and gain little from being hidden. OO design is just as, if not more, laiden with traps as any other aspect of software engineering.

    Starting with Java or Python would help. If you already know Perl, then using the optional stricture might be enough. Class::Contract on CPAN allows you specify compile-time interface/implements relationships - a key concept. Rough edges around the Perl object system can be overcome with other modules as Object::Lexical (blantent self plug number 1). Still, Perl has no type safety unless you steal from, which might be useful for design and development, but should probably be disabled for production. It is still only run time. Normally, type safety (another corner stone concept to OO design) is checked at compile time. This is important, and makes sense if you realize that objects are themselves types, and expecting the right species of object and then getting it is critically important. In fact, you can think of types and subtypes and interfaces and so forth as sets. Set theory absolutely applies to OO design.

    To finally answer your question, I highly recommend Object Oriented Design Heuristics. Perl Design Patterns itself (free online book, blantent self plug #2) is heavily based on this text. Dispite its cliche free name, I found it far superior to other, more trendy OO texts, such as the namesake of Perl Design Patterns, Design Patterns: Elements of Reusable bleah bleah bleah.

    Taking this full circle, In My Humble Opinion, Refactoring, Design Patterns, etc are finally OO design done right. Applying known idioms, watching for tell tale signs to know which idioms to implement, and stepwise moving away from weak structures to stronger ones is the only way to apply OO to a program that grows, gains features, or isn't designed in minute detail before implementation begins.

Re: Learning OOP
by Anonymous Monk on Jun 23, 2003 at 15:26 UTC

    Perl6 will be, but if you have little or no prior exposure to OOP I cannot recommend Perl5 for this purpose. (For purposes other than learning OOP, Perl5 is of course wonderful.) Python perhaps, though I personally found Python not to be to my taste.

    My favourite book for learning the principles of OOP is the Inform Designer's Manual. The problem domain that Inform is designed to solve (besides being very interesting and providing an excellent didactic framework in general) lends itself spectacularly well to an OO approach, unlike the highly contrived examples in many books, and Graham Nelson is a superbly talented writer.

    The only thing is, the book is compiled in the wrong order for this purpose, so you'll want to skip the early parts (about the procedural portions of the Inform language, arithmetic expressions, loops, and so on) and instead go straight to reading the chapters that cover the OO stuff. (The book can be understood just fine in this order, and in fact used to be ordered more this way in the third edition. But you want the fourth edition, because it has many improvements.)

    The fourth edition is available both online and in dead tree format.

      Err, neglected to login, but that was me. So if you reply and want me to _see_ your reply, either /msg me or reply to this message.

      {my$c;$ x=sub{++$c}}map{$ \.=$_->()}map{my$a=$_->[1]; sub{$a++ }}sort{_($a->[0 ])<=>_( $b->[0])}map{my@x=(& $x( ),$ _) ;\ @x} split //, "rPcr t lhuJnhea o";print;sub _{ord(shift)*($=-++$^H)%(42-ord("\r"))};

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://268029]
Approved by Zaxo
Front-paged by broquaint
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others meditating upon the Monastery: (3)
As of 2024-05-27 19:18 GMT
Find Nodes?
    Voting Booth?

    No recent polls found