|Just another Perl shrine|
...some days you wish that you could -- more than once.
I know several "true men" at Sun who work on the kernel internal design, many of them pee sitting down (and bunked in the womens' dorm at school), and they have developed several object-oriented artifacts that make the system what it is.
Thanks to the magic of encapsulation (forget about code reuse and modularity, that junk is for the trade shows) we have the virtual filesystem (thanks guys (and gals) for the swapfs, the specfs, the tmpfs, and the procfs), the virtual memory system (the vnode layer made the virtual filesystem possible), and the creation of scheduling classes (now we have timeshare, realtime, system, fairshare, and fixed priority scheduling classes).
All this is done without a line of Java, C++, Ruby, Python or Smalltalk. Using only C and assembler, the designers of the OS kernel have given us the best of OO design without too much in the way of overhead. And it makes possible the solutions to problems that would never have been solved without a tremendous amount of overhead in the kernel code itself.
No, OO programming is not for every problem, but it should be mastered by every serious programmer at this point. There's not much to it actually, and it doesn't actually demand a heroic ability for abstract thought. I actually cover most of the core principles in my Advanced Perl class in about an hour.
On the other hand, I don't think that Perl is the ideal language to use for initially exploring OO concepts. But if you start out that way, you'll be able to do anything in other OO languages as soon as you become accustomed to how they work.
I would guess that programmers who learn OO with Smalltalk or Java will only struggle a bit with Perl for OO, but those who learn first in Perl may chafe at the strictures imposed by more typesafe languages like Java. (I also found high levels of resistance in C++ programmers trying to move to Java.)
Bottom line for me is this: If you think loops, switch constructs and the conditional operator are really slick, then don't worry about OO. You'll find plenty to amuse you in procedural programming. If you had enough of writing simple logic structures in school, then maybe you want to move up to the world in which you program the behavior of such program constructs that are already encapsulated in an object that regulates behavior so that it remains rational most of the time.
That's an important part of what we talk about when we teach new Java programmers. Trying to ensure rational access to things so that bank accounts don't magically have their balances set to $-1,000,000 or that life support systems don't magically shut down due to a minor error condition. Encapsulation is a big win, and it helps us to build more robust structures in our programs.
But there are many ways to tackle any problem and all of them are good as long as they succeed. Once more with feeling folks:
...All the world looks like -well- all the world,
when your hammer is Perl.