http://www.perlmonks.org?node_id=508868

Hi Monks,

I'm asking for your wisdom. I have a co-worker I have to work with and my job is to assign tasks to him. The problem is I want him to code OOP style and use Template-Toolkit for websites. He refuses to use objects as he is used to programming using numerous 'subs' in the script's code. He says he has no problem adding new functionality or changing something. I showed him some code of mine. Please note everything was in its place, seperate classes for different tasks. Ie one class is to fetch data from our servers. The 2nd class is to parse replies from one of our servers. The 3rd class processes replies. All these classes create a new instance of the 1st one to fetch data. It's all nice and very easy to understand and to add new methods, implement new features. It has nice logging facility (a separate class is used for logging purposes). So, he said he would spend more time programming OOP style than using subs. My answer was and still is to use OOP. I'm sure somebody will have to implement new features in these scripts one day. In my humble opinion, it's much easier to work with a nicely organized code than with a file XXXXX lines long that does all kinds of junk.

And the question is... how can I convince him to start programming OOP style and be organized? I'm just stuck with this guy due to company's reasons. And I want to teach him and make things better in life. I hope you, monks, understand me. I even suggested we write a simple script in OOP and subs styles and then implement extra functionality and see what it feels like to do it in both scripts: his and mine. He disagreed as 'he was not interested in spending his valuable time for such stupid competitions, and classes are damn slow even in C++.' I just can't handle it. I confess. Please help me to find a way to deal with it properly and show him the way to go and make him believe in the power of OOP.
Thank you so much and take care!

Replies are listed 'Best First'.
Re: Coding styles: OOP vs. Subs
by Tanktalus (Canon) on Nov 16, 2005 at 04:29 UTC

    Do you have coding standards documents in place? If not, it might be a bit like closing the barn door after the horses have escaped. If you do, they would hopefully clearly define acceptable coding standards - which would ideally include heuristics on when to use OOP and when to use procedural.

    On my work team, I was the original perl programmer. Since then, I've brought on board two contractors (in serial - both their contracts have ended) and currently have one full-timer working for me. The contractors were brought on board with varying degrees of experience, but were largely the "hack-it-and-forget-it" style of programming. By the time they left, they both had a fair dose of OO-style in them, but not likely nearly enough for them to design anything with OO. The full-timer had nearly no experience either way - he could get perl to do things, but there was nearly no depth.

    In each case, I could show them the benefits of OO for our particular project and they were suitably convinced. They just needed to get used to thinking in terms of objects (which actually quite amazes me - because, in my mind, we deal with objects every day outside the context of programming, so why is it such a tough sell inside programming?). In the case of the contractors, they both knew they were merely hired guns, and knew to take orders, so there was little clash. Sometimes I'd tell them how to design something, and they'd go off and not do it right, but largely there was little struggle.

    The full-timer, however, was another beast. As someone the company would keep for a while (most likely - he has almost as much time at the company as I do, and at least a decade of experience before that where I was hired right from university so this is my only full-time job since I graduated), he had a bit of an ego. (As do I - an ego is not necessarily a problem to me.) He thought that he was actually quite proficient in perl. Then again, I think the same about me. We had some serious clashes near the beginning of working together there. Very heated arguments. Eventually, through code reviews and the like where I could show him many WTDI, and rattle off the pros and cons of each, he gradually came around to see my way of doing things and why the design we had was actually taking into account more things than his new design was. It's not that we have a perfect design - just better than the known alternatives. Nor do we do everything in 100% pure OO. In fact, one of the new modules he wrote just in the last 8 months or so was OO where I didn't think it was warranted. We had a bit of a discussion on that, and he eventually saw a demarcation point. What I don't want is "cargo cult" programming where he does everything OO just because "that's the way it's done here." Some critical thinking is required, and disagreements are expected. At the same time, teamwork is a requirement, and an ability to live with and work within team decisions is a must.

    If he doesn't want to waste time in "stupid competitions", perhaps he can explain why he wants to waste time in forking the project into multiple styles. It will raise the bar for maintenance, guaranteed. Trying to read a mix of multiple styles is far more difficult, and thus error-prone, than reading a single style.

    It also sounds like your colleague is suffering from a case of premature optimisation. Trying to solve speed problems that probably don't even exist. Finally, if speed is his concern, why is he wasting time in perl rather than assembler? The benefits of OO vs procedural in large projects is the same as the benefits of perl over C or C over assembly: abstraction. Allows you to do more with less, which invariably speeds up development as well as reducing errors and speeding up bug-fixing.

    Heck, if you really want speed, don't use apache - write your own webserver. All that overhead of apache calling system() has to just make him completely nervous. Or maybe you use mod_perl - but switching contexts and languages must have a speed penalty in there somewhere.

    If he's not concerned about all these other speed penalties, why the heck is he worried about the relatively minor overhead of OO?

      They just needed to get used to thinking in terms of objects (which actually quite amazes me - because, in my mind, we deal with objects every day outside the context of programming, so why is it such a tough sell inside programming?)

      Because the concept of an object in programming is not closely related to the concept of an object in the real world. The concept of an object in programming is related to the concept of an object in math. People who have not had math beyond the secondary level tend not to have been exposed to the concept of an object in this sense at all.

      The exception is the way objects are typically used in the Inform programming language. Now, Inform objects *are* programming-concept objects, and can be used as such, but in a typical Inform program, an Inform object represents a real-world object, such as a chair or a box or a door. This is a consequence of the problem domain, but it makes an *excellent* introduction to OOP, because it builds on something people are already familiar with and then introduces programming concepts to it (properties and so forth).

      I don't think this could be handled in the same way with the Perl object model, however, because the Perl object model (even, as near as I can tell, in Perl6) does not provide the object forest, which really is essential for elegantly dealing with Inform's particular problem domain (i.e., the chair is in a certain room, and the player can set the box on the chair (because the chair has the supporter attribute) and place the amulet in the box, and so forth, and that containment tree is built into the object model at the vm level as well as at the language level; it is, incidentally, generally useful for other kinds of problems as well.)

      When you program in a language like Inform, where the objects represent real-world objects, you see how *different* traditional programming objects are from objects in the real world.


      "In adjectives, with the addition of inflectional endings, a changeable long vowel (Qamets or Tsere) in an open, propretonic syllable will reduce to Vocal Shewa. This type of change occurs when the open, pretonic syllable of the masculine singular adjective becomes propretonic with the addition of inflectional endings."  — Pratico & Van Pelt, BBHG, p68
        Well, I do have a soft spot in my heart for that style of language, having once upon a time hacked in (and on) a language called Dungeon Definition Language. I've also once wrote a "dungeon" in Prolog, though it was actually a space ship...

        It would be relatively easy to define objects in Perl 6 with a role or set of roles that define spatial relationships, and those roles can mix in various one-to-many relationships, so it'd be pretty easy to do physical containment and delegation to contained or nearby items. Perl 6 is not intended to match up exactly with every problem domain. It's merely intended to be easily mutable into a different language (also called Perl 6) that matches up with your current problem domain. At worst you'd have to say "use Physical;" at the top of your program, or some such.

Re: Coding styles: OOP vs. Subs
by Trimbach (Curate) on Nov 16, 2005 at 03:03 UTC
    I think there's really two things (maybe three) things going on here. First. there's preferring methods and classes over subs. Second, there's a willingness to use CPAN and not reinvent the wheel. And third, there's setting coding standards at work.

    For #1, not sure I can really help you. OOP is not suitable for every task, and lots of people think it tends to be overused (or at least used when not really appropriate). There is a performance hit, and extra coding overhead for going OOP, though on the other hand this is often made up by simplifying maintenance. You say to-MAY-to, I say to-MAH-to. Different strokes for different folks and all that.

    For #2, that's a bit more serious. Most of the CPAN modules are OO because it provides encapsulation and a defined interface, and that's all a good thing. I can't imagine someone avoiding the "OO style" so strenuously that they would avoid the CPAN. That's just not smart.

    Lastly, it's common practice to enforce coding practices at work, and establish policies and such. If your OO code is the standard code that's supposed to be used at your business, then that's what's supposed to be done. Creating multiple competing solutions that perform the same function is not good business, and if you can't enforce uniformity at this you should find someone higher up your food chain that can.

    Bottom line is we're not really talking about OO versus non-OO. He's totally within his rights to prefer one style over another, but work is a whole different matter.

    Gary Blackburn
    Trained Killer

Re: Coding styles: OOP vs. Subs
by perrin (Chancellor) on Nov 16, 2005 at 04:18 UTC
    If I knew how to make co-workers do things my way, I'd probably be the CEO of some large company. This is a people problem.

    Since you asked, there are some simple reasons why OO is usually better. You get more code reuse, more encapsulation of components, and thus code that withstands changes more easilly. A really good programmer can do this without traditional OO through careful design and some use of callbacks and such, but this guy does not sound that good.

    What he's doing with the huge long files of code should not be tolerated. Splitting code into modules is not an OO thing; it's just a basic good practice.

    Unfortunately, the fact that he sees no problem with writing these huge files probably means he isn't very interested in writing good code. Even if you do convince him to use OO, he will probably not know how to do it effectively, and will just write enormous class files.

    Finally, claiming performance as a reason not to use OO is absurd. Are you writing some kind of 3D shooter in perl? Has he profiled the code and discovered that method calls are slowing you down? I didn't think so. Your bottleneck is probably I/O (database, disk) like it is for almost every other program written in perl.

Re: Coding styles: OOP vs. Subs
by tilly (Archbishop) on Nov 16, 2005 at 08:14 UTC
    Read What you refuse to see, is your worst trap.

    The more clearly you explain to him that he sucks, the more important it will be for him to defend himself. The stupider the justifications that he winds up using in that defence, the more upset he will become, and the harder it will be for him to listen. If you are explicitly holding yourself up as the good example and him up as the bad one, expect his resistance to increase ten-fold.

    This is a no-win situation.

    You either have to find a way to divorce his ego from his code (likely impossible), or find ways to encourage him to improve while avoiding triggering a defensive reaction (somewhat tricky). It is helpful to be able to recognize when you have triggered defensive reactions that make communication impossible. Then you can try to narrow in on ways to avoid that situation, and ways to defuse it. This will take practice, and I cannot guarantee success. But I can guarantee that success will become more likely.

Re: Coding styles: OOP vs. Subs
by dragonchild (Archbishop) on Nov 16, 2005 at 04:30 UTC
    Modules are not OO. If he's uncomfortable with OO (for whatever reason), then have him put stuff in libraries with Exporter. That, at least, is code reuse.

    As for performance ... if it's performance you want, why are you writing in Perl? Perl's OO isn't the performance hit - it's those damn scalars, arrays, and hashes you love using. If those weren't around (particularly the scalars), Perl would be at least 2-3x faster and use like 1/10th of the memory. But, what would be the point?

    As for work - there's a manager, and it doesn't sound like it's you. You need to talk to this person and have him/her make a decision as to coding styles and if there will be one for the group. If there isn't, DROP IT. No-one is so valuable that they can't be fired. I was once let go the very next day after I implemented a 99% speedup (~5 minutes to ~2 seconds) in the core subroutine for the application that controlled all of $VERY_LARGE_COMPANY's factory forecasting and purchasing. If you are perceived as being hard to work with, you will be the one in the sights, not your coworker.

    And, maybe you coworker has a point. Maybe this stuff doesn't need to be written very well, so long as it works. Maybe getting it out the door is more in line with the company's vision than having stuff that takes longer to write, but is easier to maintain. Maybe the extra time spent polishing the code costs more than a bug. I don't know, but maybe your coworker might.


    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
      I really liked your example. I thought about it for a while and decided to let him write it his way as long as it works. I will make him work on this entire project. We should have started this project a long time ago and it's time to show something. hehe so, we have no choice.
Re: Coding styles: OOP vs. Subs
by demerphq (Chancellor) on Nov 16, 2005 at 08:01 UTC

    Is his code buggy or a maintenance disaster waiting to happen? If so then you have a point and an argument. Analyse his code, identify a feature that will require him to rewrite the whole thing but that could be implemented easily in an OO framework. Then ask him to make the change. Point out afterwards how much easier it would have been.

    If his code isn't ugly and works, and the thing that is really bothering you is that he wont admire your cool shiny OO framework, then I advise that you get over it. Only if you can really put your finger on things that have gone wrong due to his programming style will you be able to win an argument, and even then it will be a hard battle.

    ---
    $world=~s/war/peace/g

Re: Coding styles: OOP vs. Subs
by BrowserUk (Patriarch) on Nov 16, 2005 at 09:53 UTC

    Are you up for a challenge? Here it is.

    Suggest to your cow orker that you select an example of his code (suitably anonymised) and post it here for review.

    For counterpoint, he gets to choose a sample of your code that will also be posted for review.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      Definately a good idea.

      ---
      $world=~s/war/peace/g

      2 questions about that B:
      A) Can we form a betting pool somehow?
      2) Can I yell, "MORTAL KOMBAT," before hand, if they do? :)

      ----
      Give me strength for today.. I will not talk it away..
      Just for a moment.. It will burn through the clouds.. and shine down on me.

Re: Coding styles: OOP vs. Subs
by Perl Mouse (Chaplain) on Nov 16, 2005 at 10:10 UTC
    I'd say that pushing OO for the sake of using OO is not a single bit better than to never use OO. You're both focussed on a single methodology, pushing for it without looking at the problem.

    Some problems are better solved using OO. Some problems are better solved by avoiding OO. Most problems can be solved either way, and whether you use OO or something else is a matter of preference.

    As for the "numerous subs", solving the same problem using OO typically requires at least the same amount of methods, and often more, because you'll have methods with the same name in different classes.

    Perl --((8:>*
Re: Coding styles: OOP vs. Subs
by sanPerl (Friar) on Nov 16, 2005 at 05:47 UTC
    I wonder about your working style. From your problem, I would like to suggest following approach.
    1) It seems that you don't have any coding standards in place, please prepare them and approve them from Top management.
    2) Always ask programmers to create a 'Design report', before he/she touches the code, carry out the practice of 'Design review' by some unbiased 'Senior' programmer (Not you, since you already have conflict with the said guy)
    3) Always remember that OOP is Not always right approach and hence in case of any conflict, call up a meeting with Senior Programmers and both of you, and come to some conclusion at the end of the meeting.
    4) DO NOT Force programmer to write code if he is Not okay with your design, simply because he would Not give you good output. In that case change the programmer.
Re: Coding styles: OOP vs. Subs
by spiritway (Vicar) on Nov 16, 2005 at 04:06 UTC

    Fifty bucks and a six-pack ought to do it. Either give it to him, or else give it to some guy with a baseball bat and no neck...

Re: Coding styles: OOP vs. Subs
by tphyahoo (Vicar) on Nov 16, 2005 at 14:40 UTC
    In my humble opinion, it's much easier to work with a nicely organized code than with a file XXXXX lines long that does all kinds of junk.

    I agree, lots of lines per file is usually bad for maintainability. It gives me a headache just looking at a long code file sometimes.

    So, maybe you should first try to sell him on using *modules* with the result of less line of code per file.I was first motivated to use modules mainly because I was getting sick looking through how much code I had in a file. The jump to objects is a much easier sell once you're using modules.

    Baby steps...

      I rather work with a few files containing a lot of lines of code, than with a lot of files, each containing a few lines of code. My window will give me a local view anyway - typically 36x80 or 48x80. And finding something in the current file is much easier than finding something in a whole bunch of files.

      With documentation, it's even worse. A module containing 100 subs will have a large manual - but it's only one manual, and you'll have the right manual right away (because there's only one). Not so with OO. If you want to know the details of a method supplied by a certain class, it could be in the manual of said class, or in any of the fifteen classes it inherits from.

      I believe in a middle ground. Too large files become unwieldy. Too large class hierarchies as well. And if I have to choose between the two evils, I pick the large files.

      Perl --((8:>*

        Doesn't your editor support multiple files and global find?

        (I'm not knocking your preferences, just wondering why you hold them if that makes sense).

        The biggest problem with lots of stuff in big files is that I nearly always want to edit one place whilst flicking back forth to a couple of others. Even with an editor that supports multiple views within the same file, it is usually limited number of views (often only two) which doesn't cut it.

        By putting stuff in small(er) files I can switch from one file to another for reference or editing and switch back to where I was in the first, cursor in place and just carry on.

        The ability to save and restore whole sessions of files as a single command line option is invaluable. If only TP would remember where I was in each file it'd make me a happy bunny.

        I use a global search to generate an index to the function, method or variable I am interested in and that allows me to flick between the relevant files easily.

        In the end I guess it's down to how your habits have evolved, but I find huge monolithic files tedious and awkward to deal with.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
      Am I the only one who sticks mutiple things in one file?
      ##################################################### package Foo; ##################################################### package Bar; ##################################################### package Baz;

        Am I the only one who sticks mutiple things in one file?

        Yes.

Re: Coding styles: OOP vs. Subs
by SolidState (Scribe) on Nov 17, 2005 at 06:42 UTC
    Hi nikos,
    You think you have it bad? One guy at my workplace refuses to "use warnings;" because, get this, they generate warnings, and he doesn't want to deal with them!
    In other words, he's convinced that as long as he doesn't see the warnings everything is fine...
      Or, everything is fine, and the warnings are wrong. Note that warnings are generated when Perl thinks the programmer made a mistake - if Perl would be sure, it would have thrown an error.

      I've removed 'use warnings' from programs as well, after getting tired of adding 'no warnings' all over.

      Perl --((8:>*
        I'm surprised; "use warnings" saved my a** a couple of times, and the overhead is really small :
        $ wc -l *.p* | tail -n 1 6949 total $ grep "no warnings" *.pl | wc -l 8
        I'd be interested in seeing what kinds of programs those are. Other than throwaways, I have very rarely run into problems with warnings. The most common warning I see is "undefined value used in ...", which is alerting me to a real bug. Sometimes, I think I should turn the undefined warning into a fatal error, but I'm too lazy to do it. :-)

        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
Re: Coding styles: OOP vs. Subs
by nikos (Scribe) on Nov 30, 2005 at 23:05 UTC
    First of all, thank you so much for pointing me the way out of this mess. We decided to make it work first and do not bother whether it's writtin using objects or modules as long as it works. I hope there won't be a lot of maintance madness going on and I will put him on this project. As for other large projects, I agree there must be a written manifest on how-to write your code, how-to comment it and so on and so forth. As for small projects and little scripts, it's much faster to write them just in one file with no objects or modules involved.