I just learned at least the basics of perl OO, and my God. What elegance.

Apocalypse 12 will be out in about a week

<squeak of excitement>

:-)

Don't get too carried away. Perl OO is by no means the top of the OO implementations. Try learning Python or Ruby and then come back.

I've been writing OO code for about 6 years now (first C++, then Java, then some Python and Perl), and Python and Ruby turn me off. True, Perl's OO implementation is scarred and awkward (awk-ward? sorry for the pun), but the underlying tenets of Python (tabbed identation, "there is only one way to do it" (TIOOWTDI)) and Ruby (well, it's like Perl, but it doesn't have as many cool toys) hardly make them languages where you can truly feel at home. Java is well liked by those that like it, but you will find it is also disliked by the greatest of OO purists, and while it tried to 'fix' OO in C++, it made a few issues of it's own.

Perl, while it requires more discipline to make OO work well, really is a breath of fresh air, since it is unencumbered. However, you really do have to watch yourself carefully. Perl6 will fix much, and I am looking forward to it. But I have been long polluted by the evils of Lisp, a language where it is hard to get many things done, but once tasting the waters, you start to code Lispy things in other languages.

Yes, if you are new to OO, I don't recommend learning Perl OO first...but once you know it, Perl is definitely workable there (and the mixture of OO and functional concepts, to me at least, is the holy grail). Maybe you could learn it first, but be careful, and be sure to pick up a few others along the way to balance yourself as you dive into the depths of Perl modules.

One of the more seductive things about OO, especially in other languages, is the tendancy to overdue objects and limit the usage of constructs found in the core language. Java is the extreme for this, and in some cases it works, but in Perl, you have the feeling you can use as little or as much OO as you want. Also, being Perl can be a little heretical to the buzzword-compliance trends in OO these days, you feel less restrained and you have more fun. Perl culture, for instance, doesn't require overabundance of getter and setter methods as Java seems to -- which is good, because that is a misleading practice to begin with.

Anyhow, OO is loosely defined and is largely what you make of it. It's always subject to debate. To use pure objects? To mix paradigms? Where to go? Learn from others -- both from what they get right, and what they get wrong. There really isn't a true path to OO design, find what works, and don't stop evolving as a developer. I once was a huge hardcore "OO only" guy coming out of college. Industry has taught me a lot about balance and when to say no to excessive object proliferation -- but everybody looks on OO design differently.

I've had a small sample of both of those, ruby is COMPLETELY OO, and python is a good part OO. I haven't begun to understand those two as well as perl though, but when I do, I'll come back.
All posts are spawns of an archaeic and instinctual remnant of pre-neanderthalian neural synapse that, while irrevocably human, remains an anomoly to the common laws of nature.

Or, for that matter, Common Lisp and Smalltalk.

Thanks perrin, the kind words are appreciated :-)


All posts are spawns of an archaeic and instinctual remnant of pre-neanderthalian neural synapse that, while irrevocably human, remains an anomoly to the common laws of nature.

Declarative programming is just the tip of the iceberg!

How about multidimensional declarative programming based on intensional logic with Lucid. Or Concurrent Distributed Progamming of Soft Real-Time Systems in Erlang.

And who could forget our wonderfully esoteric friends, the functional programmers. I think John Backus said it all in his 1977 Turning Award Lecture, when he uttered:

(/+) ° (α×) ° Trans.

Which is much better than the good ole von Neumann style:

c := 0
for i := 1 step 1 until n do
    c:= c + a[i] * b[i]
[download]

But seriously FP is the bomb! Not a variable in sight.

And nothing, but nothing matches the power, poise and sophisitcation of APL.

PRIMES : (~RεR°.×R)/R←1↓⌊R

(see this mess explained here)
-stvn

no unicode was harmed in the composition of this post, some character entites were improvised and others were changed to protect the innocent

Yes, exactly. Lots of people miss that, despite the inclusion of encapsulation and inheritance, a lot of OO code is essentially just changing the semantics. This of course is bad OO, and 'good' OO will make some use of the new syntax, rather than just using it as sugar. The basic conversion is (pseudocode, not Perl, not C):

foo($alpha,$beta,$gamma);
// into
$alpha->foo($beta,$gamma);
[download]

These concepts can be used to do pseudo OO in C (a non OO language by all means), whereas many think you need C++. However, you lose the encapsulation so you have to have extreme discipline in that regard (just calling functions and refusing to twiddle structure bits) and you can't leverage inheritance without using function pointers to simulate method lookup tables. It's when you start using function pointers for virtual-ness when it starts to get ugly, very ugly, so you might not have gone there in the first place. Bad!

So, anyway, what I mean to say is that while encapsulation, inheritance, and polymorphism are viewed as basic tenets, the simple idea of "keeping data together" (i.e. C structs or Perl nested datastructures such as an HoH) are perhaps some of the most widely used -- a "non OO" OO. It quickly devolves into basic proceduralism., especially if you have already broken encapsulation with too many trivial getter/setters. Inheritance, too, is widely overused.

What was I saying? Ah yes, as you say, it's just proceduralism by any other name -- but a HECK of a lot cleaner than base proceduralism if you want the same power and safety in your data structures.

By the way, the (highly useful) idiom for calling a method on an object in the Linux kernel is: foo->function(foo, arguments, go, here);. (Where foo is a pointer to a structure having a function pointer named function.) Note that this is almost exactly like perl.

---

Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

Where did you learn these enlightening basics?

Did you notice our monastery has a page dedicated to all sorts of Perl tutorials? Any time you wish to learn some new Perly stuff, click Tutorials :)

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

Seriously, though, it's a wonderful feeling. Cherish it. They are few and far between. And, they come for many things. OO is wonderful, but it not the panacea. Functional programming (map, grep, closures, continuations, Lisp, Scheme, etc) was a similar flowering for me, about a year ago. And, I know I have only scratched the surface. The next step (at least for me) is to learn a functional language, like Scheme, Lisp, etc. But, there's that time factor. :-)

I just learned at least the basics of perl OO, and my God. What elegance.

Oh, well, everyone his/her opinion. I guess there are people that call BASIC and COBOL elegant as well.

Abigail

OOP, can be a pain for parsers, compilers (to write) and what not. It's biggest strength, is to represent real life things and basic concepts.

'careful daniel san. Now that you have a new hammer, everything is NOT a nail.


-- "So far my experience has been that most people who go for certification have broad but not deep knowledge in the field and the flavor of the knowledge is academic. But every once in a while one finds a gem of a person who learns all the time and uses certification to prove it." -- on Orkut

Good GOD, that quote is GOLDEN!!!!
*drools at quality of quote*
All posts are spawns of an archaeic and instinctual remnant of pre-neanderthalian neural synapse that, while irrevocably human, remains an anomoly to the common laws of nature.

Certifications prove something? This is like saying my drivers license proves that I am a good driver because I am certified to operate an automobile in the US -- we know that is not true. US licenses are given out to people who can barely read English (correction -- they don't have to be able to read English, which all of our signs are written in) and don't understand how to negociate a 4-way stop, of all things. Similarly, Microsoft certifications are so widely distributed in the industry, even the simplest of software testers now have them, thanks to the 'test training schools' all around the area (which are kind of like puppy farms). Actions and past experience speak much more loudly than documents and titles. True, a good person can get a certification, but what does it prove? It proves he got a certification.

I just learned at least the basics of perl OO, and my God. What elegance.

I said that once. I was sarcastic.

Perl 5 has the most inelegant, unintuitive (hi mjd), messy OO I have ever been victim too. Please learn more than one language.