I think it'd be hard to find a language that can't use OO at all. You could probably do it in BrainF*ck if you tried hard enough.

Though it might not be as deliberatly difficult as BF, Perl actually has a pretty high barrier to reach before you can start creating objects (this is different from using its object system, since it's not that hard to write my $obj = Foo->new(); $obj->bar(1);). To actually create objects in Perl, you have to understand (at a minimum) subroutines, references, packages, the bless builtin, and probably a few other things I can't think of ATM. In Java, you've already created your first class upon writing a "Hello, World!" (albeit with a lot of handwaving on the part of the tutorial author).

That's just Perl's most common object system. The concepts you need to grasp for using more esoteric Perl OO probably extend to the entire bredth of Perl knowledge.

So Perl gives us a high learning curve before we can start creating classes and objects. The trick is that once we've survived all that, we have an extremely powerful tool.

Raise your hand if you'd like to write a bunch of code like this:

int foo, bar, baz;

int get_foo() 
{
    return foo;
}

int set_foo(int foo) 
{
    this.foo = foo;
}

int get_bar() 
{
    return bar;
}

int set_bar(int bar) 
{
    this.bar = bar;
}

int get_baz()
{
    return baz;
}

int set_baz(int baz)
{
    this.baz = baz;
}
[download]

Or would you rather try this:

foreach my $field (qw( foo bar )) {
    no strict 'refs';
    *$field = sub { 
        my $self = shift;
        $self->{$field} = shift if @_;
        $self->{$field};
    };
}
[download]

Even if you split the get/set into two subroutines, the second provides a far easier way to add new attributes that need nothing more than a basic accessor/mutator. This is just one example of how Perl OO is far nicer to program for than Java.

There are a lot of things that bug me about Perl OO. Lacking a common way to do prototypes, Perl's subroutines can be trickier to use, and lack a nice self-documenting property. This, and most of my other greviances, is already covered in the Perl6 Apocolypses.

One other point:

This structure, let’s call it self structure is passed to each function (method) as the first parameter, so now all the function (method) knows about all properties;

This doesn't work very well with inheirtance. Arguably, inheirtance is over-stressed in OO, but I still think it's an important and very powerful concept.

Given the choice, I would choose

  attr :foo, :bar;
[download]

But I guess Ruby wasn't on your list...

Perhaps you meant the third group to mean languages like Smalltalk or Ruby or Eiffel, where everything truly is an object.

Or, maybe, all languages in the second category allow freedom of expression, but some freedoms are more expressive than others. (Or, is it some expressions are freer than others?)

------
We are the carpenters and bricklayers of the Information Age.

The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

... strings and arrays will suffice. As they are easily available as native data types in any sane language, ... - blokhead, speaking on evolutionary algorithms

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

I don't think we can put Ruby in group 3 either --- while everything is indeed an object, the way Ruby is designed supports programming in a non--OO manner (even if there are objects behind the scenes).

Well, that'd rule out Smalltalk and Eiffel then too, if that's your standard. Nothing at all would be in the third category. {grin}

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

This stands true, if you look at it from application programmer’s view. In Java, you are forced to put each line of your code inside some class.

Well, in Perl, every line of code has to be inside some package. I don't see why Java earns a special bump up for such a distinction.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

It seems to me that this is more of a "social engineering" decision: if i am working with a handful of Perl wizards, to hell with bondage and discipline. But if i am working with a lot of people with varying programming backgrounds then maybe we need something to keep us in line - something to keep us coding in a similar fashion, "seatbelts" to prevent us from crossing lines and breaking API's.

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

For instance, Java is forces you to use objects. But you can get away with just defining a class and do everything in that class. That's no longer OO in my book. ;-)

Abigail

Cannot agree with you more on this! Unfortunately, there is (almost) nothing anybody can do to change the situation.

It is always the person who uses the tool has more impact onto the product than the tool itself, especially in areas that does not allow your brain to rest.

An extreme example would be to put everything into one giant class, and then create bunch of lengthy methods.

e.g. in Java you can put all your code in public static methods - you won't be popular with your java enabled peers but the java compiler doesn't give a darn.

Which all depends upon the situation. However mostly when I use java for something (such as just now, for work), I find myself thinking, 'how can I test this line of code, or function quickly?', in perl it's a simple 'perl -e'<line of code here>', in java it's 'create source file, wrap class around it, compile, test', and thats what annoys me about it. (With any luck someone will answer this and tell me how to test on the fly ,)

Apart from that, I much prefer perls policy of allowing everything, and assuming the programmers'll be nice.. I just had to recompile a java app, cos someone wanted access to one of the protected functions publicly.. Silly..

But, thats about the language(s), and not the OO/not-OO things. There I prefer to be able to use whatever is appropriate at the time, no-OO if it doesnt warrant the effort, etc.

C.

I have just recently been subjected to Java training, so now I am officially dangerous (got the certificate and all that).

I actually behaved myself in class, being a Perl programmer at heart. It was interesting (for several values of "interesting") to compare and contrast Java and Perl (and C, on the side). On top of that, I have a body of C code written ten years ago that I have inherited. That code was written in a visibly object oriented manner, to an extent.

I can see benefits to the enforced "everything is an object" view of Java, but the designers stopped short by allowing the "primitive" data types to be non-objects by default. Sure, you can wrap them in an object, but you then have to cast this and access that to do real work with them. The benefits would be greater (IMO) if the so-called primitive data types were just as object oriented. Sometimes you get too wrapped around the axle figuring out just which flavor of object to use...

I do appreciate the freedom in Perl to use as much bondage and discipline as I want, but to stop when it is "enough" (and the definition of "enough" is right rubbery!). I have not yet sat down and written "Java::MethodMaker" to autogenerate stub class files with all those pesky getter and setter methods written...

Now, one thing I see in common between Perl and Java is an apparent reduction in the amount of gratuitous (but necessary) code I have to write. Java exceptions let me elide all that cluttery error checking code (at the cost of having to make sure I set up my exception classes appropriately). Perl's expressive power lets me say a lot of things with less code, and things like database programming involve so much less necessary but obstructive support code to set up queries and bind variables to columns and all that cruft.

On the Java side, I'm trying out NetBeans as an IDE. I'm not entirely thrilled with it, but it seems somewhat useful. My "IDE" for Perl is nedit or BBEdit, depending on the system I am running on. The Perl "IDE"s don't offer quite the level of language specific tools, but I'm not sure that is a real minus (and may even be a plus for versatility).

As I ramble, it just occurred to me...

In Java, one is faced with a gazillion standard classes to do all sorts of things. Which Collection type do you want to use for this set of stuff? Have fun picking through the list of choices! On the other hand, you have no real control over the object system. Perl, on the other hand, gives you lots-o-options for how you implement your objects, but you don't have the "thirty gazillion ways to do hashes and arrays". OK, I generalize heavily here, but this is more of a "how the lay of the land looks in my mind" than a precise technical assessment. Sort of how my mental map has me living in a "suburb of DC" and "far from Annapolis", when, in fact, those two locations are essentially equidistant from me, and accessible by an Interstate grade highway. It's not rational, but I can't deny the charge.