Reactions to OO-Perl

[pjf]

G'day everyone,

As some of you may know, I'm in the business of running perl training courses, and I'm spending much of my time working on course notes before they start. (The notes will be released under the OPL so everyone can enjoy them.) Many of the courses are based upon the old Netizen training manuals (for those who are familiar with them), although there's an equally large amount of material I'm developing from scratch.

The reaction to the courses has been great, a lot of people have expressed interest in them. However I've been really surprised by the reaction of people thinking of attending (or being told by their company that they will attend) the course on Object Oriented Perl.

Potential attendees who haven't had much programming experience, and haven't really used OO elsewhere, seem to have the attitude of "OO is a waste of time, I've never used it before, why should I learn it in Perl? Perl's a language for getting the job done, not screwing around with class diagrams." I've met people who've been falling over themselves to learn Perl, but recoil in horror the moment I mention OO.

I've had a few experienced perl programmers tell me they don't want to learn OO-perl, because OO-perl is difficult to understand, difficult to code, difficult to maintain, and just plain weird. I found that opinion a little odd, because they were all problems I found OO-perl did a good job in solving. Perhaps there's been a few people burning their fingers with OO-perl, or maybe those people who have are very vocal about it... On the other hand, perhaps OO-perl is difficult and yukky, and I can't see the wood for the trees because I spend so much time working with it.

The best reactions to the concept of learning OO-perl have come from people already experienced with other OO languages, such as java or python. The attitude there seems to be "we know that OO-perl is different, but we want to know how and why." There's real curiosity there, which is pleasing to see. Unfortunately, most potential attendees seem to fall into one of the categories mentioned in the paragraphs above.

Now, I'm working on "correcting" the people who have broken world-views, but I was wondering if these sort of attitudes are particularly widespread, because it feels to me that they are.

Just some food for thought while waiting for my espresso machine to warm up. :)

Cheers,
Paul

[perrin]

Perl attracts a lot of casual programmers. There are many who use Perl and have no real interest in programming per se. They've heard that OO is hard and that it requires lots of heavy books about design patterns and UML. They've probably had this view reinforced by expensive Java or C++ consultants.

Many casual programmers are also wary of anything new that they preceive as a barrier between them and coding. I think this is part of the source of attitudes like "I can't learn about CPAN right now; I've got to get this templating module written by tomorrow!"

I don't have any very useful advice about getting people past this, except maybe to provide some examples of when objects provide a cleaner, safer way to solve a programming problem.

[tstock]

1. Perl is at least in part so liked by starting programmers because of its short and easy syntax and shallow learning curve. OO Perl IMO should be taught after basic perl and the students have found the problems that OO Perl solves. My path to OO was slow and started by using CPAN modules.

2. There are better approaches to teaching OO programming than using Perl IMHO (XP's fall). Phyton or Java forced me to learn better OOP, which I can then apply to any language.

3. OO Perl forces you to learn more about the Perl internals IMO, and this can be ugly. It's a small step from learning about packages to learning about the dangers in pass by reference, trying to implement exceptions, AUTOLOAD traps, eval traps, magic "goto &func" etc. It was so much easier when your code was just a bunch of print statements :)

Tiago

[jackdied]

I was a long time C++ guy, and when I moved to Boston I took a job at an OO perl shop (openair.com). Most of the pople (maybe all) had previously been C++ people. I interviewed dozens of people for engineering jobs while I was there, and most of the had moved from some other OO language to perl. The reason I think this works better than the other way around is because you learn stricter OO habits in strict OO languages. Perl doesn't enforce them, so you aren't likely to 'discover' them by yourself. If you already have the hibts, however, it is very easy to figure out where to put your singletons, visitors, and other patterns in perl

While I was there the codebase grew from approx 25k of semi-OO perl to over 200k lines of heavily OO industrial perl. Being in perl allowed for very rapid development, much faster than would have been possible under C++. You sacrifice some security by using perl, namely that the compiler can't catch mistakes in argument passing - you have to wait to runtime. The advantage was that each developer would add 2-3k _per month_ (they have a monthly release cycle).

Perl6 seems to address some of these issues and looks like it will be even more attractive to possible C++/Java converts in the years to come.

-jackdied

[davorg]

I've been running some in-house Perl courses for Acxiom. The course I've run most often for them is called "Effective Perl Programming". It's intended to take people who think they know Perl and introduce them to things like use strict, references and complex data structures.

One of the most popular parts is the session where I do a quick overview of the standard Perl modules and CPAN. I point out a couple of dozen of the most useful CPAN modules. Some of them have functional interfaces and other have OO interfaces. I think that by doing that, I can introduce them gently to using OO modules. Once they've got the hang of that, the idea of writing their own objects is a little less scarey. We cover writing modules and (briefly) objects in a later session.

At the end of the course I ask if there are any other courses that they'd be interested in seeing. CGI programming is always first, but OO Perl is usually a pretty close second.

So I guess I should get on with writing that course than :)

--
<http://www.dave.org.uk>

"The first rule of Perl club is you don't talk about Perl club."

[ajt]

I think I count as a casual, self-taught programmer. I'm formally trained in genetics, I knew of Lincon Stein before Perl, and I informally picked up programming (BASIC and Pascal), a long time before Perl.

I came into Perl from HTML, like many, Perl was the "thing" to use when writing CGI, and so with the help of the Rat book and CGI I was away.

I'm currently reading through Object Oriented Perl for the second time to see if I can get the hang of it this time. I have no problem using an OO module, I even grasp the concepts, I just have no hope of writing OO at the moment.

Perl has a reputation for being both easy and obscure (!!), and I think the problem is that OO seems even harder. I think OO just puts people-in-a-rush off - "I don't know enough OO-Perl to know if it's hard, but it looks hard, so I'll carry on doing what I'm doing now, 'cos it works..."

My humble thoughts, I suppose I one of the many with broken world views, please help me.... ;)

[jepri]

I am one of those people who initially thought that OO perl wasn't worth it. Actually I thought that OO in general wasn't worth it, was a bit of a wank, etc. I am mostly self taught.

I am now quite happily blasting out OO perl code and very glad I took the time to learn. I was badly scarred by C++, and mildy traumatised by Delphi . I could just about turn out code that compiled in Delphi, but that was it. I tended to treat objects like function libraries. It sounds silly, but everyone starts somewhere.

My attitudes changed while I was programming my gnutella client (a little hobby of mine). At one point it became clear that I would have to hand the packets from module to module, allowing them to be modified by many different routines. It was clear even to my poor awareness of OO that this was a situation where OO would be very beneficial. And it has worked tremendously well.

The code is still an intriguing mess of procedural, OO and at one point, functional styles. I hope this is a trick that perl never loses - it would have sucked having to do the whole thing OO style, ditto procedural.

If you want to convince people that OO is worth it you could find an example where it would be a horrible mess to try and do it procedural, but very very simple with OO techniques. We already feel smug because perl saves so much time, I'm sure all you have to do is demonstrate how OO perl can save even more time, and people will be hooked.

____________________
Jeremy
I didn't believe in evil until I dated it.

[tommyw]

I did much of myl earning (computing degree) just as OO was becoming fashionable, but before it got into my course content. So I've known of it's existance for a long time, but never used it. The texts I've started reading about OO cover encapsulation, and I think "but I can do that anyway" and then inheritance (usually with very artificial examples: is a circle a parent or child of an ellipse?).

So I've got turned off the idea of OO because the official approach to it takes far to long working through the basics before presenting me with anything genuinely new.

On the other hand I've found the perldoc explanations (perltoot) amazingly useful: they take the attitude "you already know how to program. Why would you want to use OO techniques as well" Which is exactly the approach I want. I don't have any difficulty writing simple OO code. Now I just need to find something that's actually better written using OO than by normal methods.

(For comparison, on that last point: I've had to write some C libraries at work to make our Oracle database provide the same API as our really, really old Unify system. Then the existing code doesn't need to be rewritten. I've implemented an equivalent of DBI and DBD::Oracle in C. It works great, 'cos I really like the DBI interface, but it's not OO, where the original is. I don't notice any difference in use.)

[netjackal]

Although I am crazy about Perl and use it for almost anything. I have (almost) always suggested another language to learn if the person has no programming background at all. Java comes to mind. I personally do not like to code in Java because ... well I am plain lazy. And perl is just perfect for me. But Java enforces the discipline to do "The Right Thing". And it is not as easy to develop bad programming habits that Perl allows. I like OO Perl since it has made my job much easier and maintainable but it will be difficult for someone without Perl experience to appreciate what good OO Perl can do for you.

[perrin]

I wouldn't suggest Java for someone with no programming experience. Check out this article about the pain of writing "Hello World" in Java. I think Perl is fine for a newbie. My first language was AppleSoft Basic, and it was a good one because it was so easy to get some positive results out of it. That kind of quick success is important for new programmers.

[dragonchild]

This kind of quick success is the reason why I'm teaching my fiancee Perl as a first language. And, as I will be teaching her strict and warnings and good technique from the get-go, she shouldn't have any problem with OO-Perl. *grins*

------
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.

[netjackal]

I agree that Java is a pain to program in ... and it is one of the reasons I have stayed away from it so far.

I have not actually been on a formal Perl course so I cannot really comment on how good Perl will be for a beginner on a good course. But I made the comment that I did not recommend Perl to beginners on the basis that they are going to be self-taught and more importantly 'self-policing'. That is the only guru to tell them to use strict and not to use map in void context etc is themselves.

I think Perl is a good language to suck people in to programming because it is tons more fun coding in Perl than any other language I have done

A simple language like BASIC is good for beginners and I agree with that but I think Perl is not just simple .. I think the way it is makes it easy for beginners with no proper guidance to abuse certain features without knowing it.

Having said that ... sites like perlmonks.org and mailing list like [e-mail] do a lot to help these people.

[chromatic]

My theory is that it's easy to learn enough Perl to do interesting things. It's easy to learn enough Perl beyond that to do useful things. You don't have to learn about references. You can just get things done.

Perl's Object Orientation is built around references and packages. If you're not familiar with them, OOP will seem alien and scary.

There's also the conceptual leap to consider. Procedural programming is pretty easy. It's like following a recipe or a list of instructions. It takes a little more work to understand things like encapsulation (hiding things that vary) and polymorphism (interpreting a message appropriately). There's less instant gratification.

[drinkd]

I almost never use OO-Perl, and here's why, if it helps.

I am a casual programer, meaning the program gets thrown out after its run, so nobody ever sees it, just its output. I write pseudo-code thats a mix of basic, fortran, c, with some lisp/apl stuff in there if theres recursion/multi-d-arrays. I like perl because it can usually run the pseudo-code with less changing the syntax than the other languages I have around.

I learned programing 15 years ago before OO became the fad with professors, and always suspected its main advantage was to make grading easier. People that learned programming under OO like it, analogous to people who learned to drive an automatic.

Manual cars are hard to come by nowdays, and so will be modules that work right without OO, so I guess we'll all get assimilated eventually. There is no escape.

drinkd

[jlongino]

My experience is similar to drinkds. I progressed through Basic, PL/I, Assembler, Pascal, Fortran, SAS, SPSS and Perl. I went directly from University student to Staff and only a few years later did they actually start teaching C++.

Making the leap from linear to OO programming is not intuitive nor easy for everyone and the longer you've done the former, the more difficult it is to come up to snuff (as in attaining the same degree of speed/expertise/comfort) with the latter. Learning to write an OO "Hello World" script or similar useless programs doesn't prepare one to convert existing programs or start new ones that make extensive use structures like $employee{ssn}{$PO}{email}.

When I begin the switch (and there is no doubt that I eventually will) it will be done on my own time. I don't have the luxury of doing it on company time since I've got at least a dozen projects already going or on my TODO list and only one or two are with Perl.

My employers don't care if it is OO or not as long as it works. My boss is a bit older than I and although he doesn't do much with Perl, he is an excellent programmer, problem solver and can follow and modify any of the Perl code that I write. He has a similar background to mine and there would be a learning curve for him as well if I switched.

Real world constraints often take precedence over idealized ones. -- jlongino

[ichimunki]

OO-Perl is easy and fun. It is too bad for those who don't want to get into it. It certainly makes some of the "pure" OO scripting languages out there look like they're doing it the hard way. The problem is, we all start with Hello World, but nobody goes and does that for OO Perl (except maybe merlyn in perlboot-- his menagerie of animals make a few interesting noises). So here's a start on why OO Perl shouldn't be intimidating...

#!/usr/bin/perl -w
use strict;
use World;

# object oriented hello world

my $USA = World->new('English');
my $foo = new World;

$USA->greet;
$foo->greet;

and then in World.pm

#filename World.pm (easiest to put in same directory with calling scri
+pt)
package World;

my %greetings = ( 'english' => 'Hello, World!',
          'german' => 'Guten Tag, Welt!',
          'latin' => 'Salve, Munde!',
          );

sub new
{
    my $class = shift;
    #default language is Latin
    my $language = lc( shift ) || 'latin';
    my $self = {};
    #check to make sure the language is valid
    $self->{'language'} = (grep( /$language/, (keys %greetings)))[0] |
+| 'latin';
    
    bless $self, $class;
    return $self;
}

sub greet
{
    my $self = shift;
    my $language = $self->{'language'};
    print $greetings{$language}."\n";
}

1;

Trivial example, but imagine writing this (same functionality) in procedural code. You might be able to fake it with some closures or a handrolled lookup table, but when you have data that lends itself to the object model it pays to use OO. In the few lines above we have class data (%greetings), class methods (new), instance data ($self->{'language'}), and instance methods (greet). And once we've built our class, we have very few instructions to get a wide variety of greetings going. Imagine localizing more IO routines this way...

Anyhoo. Just having fun. The world can always use another hello world program right? *grin*