in reply to Coding styles: OOP vs. Subs

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?

Replies are listed 'Best First'.
Re: Coding styles: OOP vs. Subs
by jonadab (Parson) on Nov 16, 2005 at 13:39 UTC
    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
[reply]
      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.

[reply]

        Hey. No fair. I thought I'd done a thorough job of purging the musical "works" of Olivia Newton-John from my brain...

[reply]

In Section Meditations