Why perl is more OO than C++ or Java...

[dragonchild]

Object-oriented programming has been described, by many people in many places, as a style of programming where you create a thing and ask that thing to do stuff. You, as the user of that thing, don't care how it gets that stuff done, so long as it's done correctly.

I was thinking this morning about how I'd go about explaining to my coworkers why this series of modules that have been created for a project I'm on is really OO, despite the fact that there's a new() function and methods and attributes and everything.

My first thought was to describe OOP as being a hands-off manager vs. a micro-manager. Then, it hit me. A scalar is an object!

Think about it. You use this thing and you have no idea how it does its stuff. You ask for it to be there and it is. You ask it to add something to itself and it does it. You ask it to compare itself to a string and it does it. You ask it to go away by itself when it's done being used and it does. And the same goes for lists and hashes.

While the programmer may have a tougher time writing strictly OO code in Perl, every Perl programmer is using an OO environment whenever they write Perl.

[ariels]

That's not an object. All programming languages have "objects" in the sense of something which does stuff in ways you don't care about. Do you really need to know the precise details of CORDIC implementations used to compute a cosine of a C double? That's not OOP.

OOP is about being able to add objects not in the language spec. Plus all those little things like inheritance, per-object instance variables, class variables, etc. Perl has some of these, to varying degrees.

Sure, you can use the term "OOP" to refer to something completely different. But you'll be proving that Perl is something completely different than what people mean by OOP...

[jepri]

Well, we can tell where you went to school. :P

That certainly is an object. Well, it is to everyone who didn't attend 'Comp Sci: OOP and Pissing on people 101'. It may not meet your definition of an object, but Perl doesn't meet many peoples definition of an object orientated programming language either.

Why not pat someone on the back and say 'Yes. It is an example of code that encapsulates code and data into a uniform interface. And wait till perl 6, when it will have even more object properties to play with.'

Update: I really need to get more sleep before posting things like that. In fact, if I got more sleep I wouldn't post things like that. I'm sorry, ariel, for the rudeness.

However I do not think that 'patting someone on the back is rude' - it may just have different overtones depending on where somebody comes from. dragonchild clearly had a revelation on how to structure code well, so ++ for seeing it. Perl isn't more OO than C++ or Java but it does use some of the ideas of OO when dealing with data.

I guess I'm a little sensitive because I keep being cornered by people who prefer to talk it rather than do it (I'm not accusing you of this) and one of the favourite seems to be whether certain things are OO, functional or whatever.

I can recall having exactly the same thought as dragonchild and then thinking "oh, wait, can't inherit, can't add properties, damn". I was still quite proud of it though.

I think my next project may be a little proggie that monitors what I type and pops up and says "Do you really want to flame him? y/N?" whenever I lack the judgement.

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

[dragonchild]

I disagree. For normal Perl programming, you will never care about how a scalar is implemented. For normal C programming, the size of an int is critical! (I know this because I got hit by the fact that Win32 has a 16-bit int and Unix a 32-bit int.)

OOP is about using objects, as well as adding objects. It's a paradigm shift, not just a few new keywords and syntax goodies. People were writing OO code before OO existed and people are writing procedural code with OO syntax.

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

[Masem]

I disagree that it's *just* about using objects. The distinction between typical programming that is common in C and FORTRAN, and true OOP, is that you don't think of the program as working step after step, but of objects invoking methods of other objects in a non-deterministic way.

It's very easy to convert a C program that doesn't use objects to one that uses them, but if there is still a strong dependence on how the events of the program should fire, it's not OOP.

-----------------------------------------------------
Dr. Michael K. Neylon - [e-mail] || "You've left the lens cap of your mind on again, Pinky" - The Brain
It's not what you know, but knowing how to find it if you don't know that's important

[John M. Dlugosz]

First, in Win32, ints are 32 bits, not 16.

Second, if you were to use integers in Perl 5, you would indeed care how many bits it had. When using the normal floating point values in Perl, you care about its range and precision. If you demand too much precision in a real number, your arithmetic fails. If you demand too many bits in an integer, you also get the wrong answer. That's no different than when programming in C.

If Perl 6 provides seemless bignums, then you won't have that problem. But you still "care". You rely on the fact that ints grow to any number of bits.

In Perl you have IV's and lots of stuff behind the scenes. But in C, you don't care how an int is implemented, either! You know that adding two ints obeys the rules of arithmetic, but what registers are used, how the CPU's ALU is constructed, what the pipelines do, and all that is something you don't care about. It just magically works that 5+4 produces 9.

—John

[tilly]

Perl is not OO.

Perl's data types are somewhat like objects in that they are encapsulated. Perl offers and interface to that called tie. But since the behaviour of Perl's data types is tied to Perl's syntax, Perl is unable to allow those tie implementations to be extended in any reasonable way.

To get a feeling for how much this matters, I suggest learning a truly OO language. For me it was Ruby. The difference is incredible. Should you decide that you want something like a hash in Perl, you can tie. Suppose that is backed by data on disk and you want to add locking functions, you simply can't make it look like a hash the rest of the time. In Ruby you can make it look like a hash, and just add whatever methods you desire, without conflicting with the syntax.

[stefp]

It seems that today the most popular operating concept that displaces classical OO is interfaces. For example, well defined interfaces are crucial to automatical glue generation for remote-procedure calls (be they inter processes, or inter hosts).

Classical OO insisted too much on class inheritance. Classic inheritance is an implementation concept that is not relevant to the user of a class. Abstract class inheritance is just a way to specify part of an interface.

To complete interface, reflection allows to dynamically inquire the interface. Interfaces are based on function and method signatures, this is mostly missing from perl5. In that sense, perl5 is hardly an object-oriented language. We have indeed low level interfaces that are defined from the semantic of existing entities (scalar, arrays, hashes..) and formalized in ties. Ties allow to implement complex object and access them thru the syntactical convention designed for the said entities.

What strikes me in Perl5 is this intricacy between low-level entities and specialized distinctive syntax and operators. We say $dict{$a} while in another languguage dict.get(a). It makes the language more difficult to learn and gives it the reputation of being cryptic to the layman. In another language access to these entities would be part of standard classes that would have to be learn anyway and must be accessed thru cumbersome functional interface. This leads to a great expressity that is the main perl specificity. I already wrote about it in patterns, language and syntax

So, no, Perl is not more OO than other languages. And yes, in a sense, it is OO in a very orignal way when it includes in its very syntax the interface of low level entities and permits thru tie to build objects that conform to that interface.

-- stefp please message me to correct my English

[archen]

Object orientation is way more than implementation. OO programing is sort of a philosophy of doing things. Probably the two languages which best embody OO programming are Java (of course) and Small Talk. I've also found that to be the weakness of these languages. Despite what many people say, not everything has a wonderful OO solution. Many problems are very strait foreward, but a language such as Java will force you to take the object oriented approach. The strength of C++ (and Perl I guess) is that it lets you choose what you want to do, whenever you feel it is appropriate. When the next big craze in programming overtakes Object Orentation, I wonder where Java will sit? C++ will obviously be able to adapt to just about anything, and more than likely Perl will too.

[Nitsuj]

True enough on the C++, however, this is actually viewed as a design flaw by many, as it creates ambiguity in the language and other problems.

A lot of people never really think about this, as it's easy enough to pick implementations that makes sense... but have you ever seen code that one minute tries to use cout, or cerr, and the next min fprintfs to stout n stderr? That's solvable enough, but what about creating an object from a c header with a function that exit(1)'s, which is obviously inappropriate, and now should be handled differently... or when people mix using C code and methodology with C++. Everbody's been stuck debugging code at some point in their life that somehow has a linked list of objects in it (the linked list being started with *my_list, the objects being improperly instantiated somewhere, and you with a debugger and a big pot of coffee.

This of course is not to detract from the merits of C++

Just Another Perl Backpacker

[charnos]

You seem to be using C++ synonymously with C, when I think it is quite case sensitive here. C++ was the C community's answer to Object Orientation. Your node suggests that some other paradigm will eventually overtake Object Orientation, which is true enough, but the result will be a different C variant, it would seem silly (at least to me) to tack on another backwardly compatible paradigm to C (C+=2?).

[Nitsuj]

While I could go into what makes an object oriented language object oriented, the most important distinction is that is the creation of data "objects." In this case, Perl is certainly not more object oriented than C++

Any HIGH LEVEL language hides the particular implementation of anything it does. Only writing in bytecodes or assembly hides nothing. I know that you don't consciously think of what register you are writing to when you make a variable in C.

What you are thinking of is how "high level" the language is. Which is to say, how abstracted from the hardware is it. Perhaps Perl is more high level, but again, I could argue that foundation classes and such make C/C++ just as high level as any visit to CPAN. Data hiding is only one aspect of an object oriented language. The reason PERL treats variables as it does is because of the nature of the interpretters that it is meant to replace.

Just Another Perl Backpacker

[spm]

I think what a lot of people are forgetting is that in essence, Perl is exactly as OO as for example Java, and possibly even more so. The reason I like Perl more than any other language is that Java for example, has a lot of stupidities that annoy the hell out of anyone who is trying to use it, for example having "string" as a primitive text string variable, and "String" as a Object designed to manipulate the "string" type, but is completely uncompatible with string unless you use the built in functions. With Perl, we manage to get over that sort of stupidity, whereas Objects are exactly the same as scalars - they look like scalars, but you can call subfunctions to them with things like $foo->bar(); This is pretty much the same because in Java Objects are just like other variables. Now, this does not prove my point. Lets see if this will: In Perl, we allways have a current package, as in Java, we allways have a current class - Perl is better and easyer to code however, because we don't have to write 4 lines of Perl just to be able to start writing Perl code, while Java people do - class foo { public void main() { } } being the bare minimum IIRC, while with Perl there is no minimum - just the #!/usr/bin/perl line, which is also optional to some extent. We allways have the main:: module, and that gives us a "class main" in a way. I'm not going to go on and on about this and that feature and/or bug in the implementation of Perl OO support, but I do think that Perl is in fact more OO than a lot of languages, without people even having to know that it is OO. And so what if people have to learn the language a bit better to be able to use those features? They're hackers, they're smart, they'll figure it out!

[seesik]

ugh, am i feeding trolls here?

Java for example, has a lot of stupidities that annoy the hell out of anyone who is trying to use it..

look, you're obviously entitled to your opinion, but try not to generalize too much. java and perl are two different beasts, with varying syntax and corresponding idiosyncracies. just because YOU don't dig it, don't presume that "anyone who is trying to use it" finds the syntax to be annoying. sure, there are lots of things about java (and perl) that bug me; i doubt that my pissy "i want to gc NOW" reasoning would hold up to the sun engineers' countless hours of research, experience, and development.

..having "string" as a primitive text string
uh, java doesn't have a primitive string type. there are benefits and costs associated with using String/StringBuffer objects; it's not "stupidity", it's a different programming paradigm.

just because you can "start writing" code in a specific language with fewer keystrokes hardly makes it either "better" or "easyer"(sic). i hardly see how your brevity example has anything to do with OO either way. if you just want to bash java, start a new thread.

[feloniousMonk]

Sorry, but had to respond to this:
> Perl is better and easyer to code however, because we
> don't have to write 4 lines of Perl just to be able to
> start writing Perl code

So this makes shell scripting a better language than Java,
C, C++, Ada, assembly, etc.?


--
feloniousMonk

[John M. Dlugosz]

I've also noticed that there's a fine line between ATD's (Abstract Data Types) and Classes. A class is a way to create your own ATD's, though all languages have built-in ATD's.

I also note that the Perl scalar, unlike a C primitive type, is polymorphic. A function can do different things depending on its actual content at run-time, which could be a string, float, int, hash, or undef.

Scalars can also be tied. So you are indeed calling FETCH as an abstract interface, which could have any of a number of implementations behind it, including the built-in normal one.

As for your 4th paragraph, you make a case that any "higher level" language indeed treats variables and values as objects. However, simple languages like old BASIC don't provide for OO programming because you don't create your own object types as a means to solve a problem. That's a crutial difference—a few built-in objects as part of the language definition doesn't allow you to take an OO approach in programming.

—John

[jeffa]

Regardless of just how OO Perl really is or is not, i found that learning Perl OO increased my overall understanding of OO in general. Of course, that's to be expected any time you study something from more than one observation point.

When i read your post, the first thing that popped in my mind was the Seven Stages of a Perl Progammer:

A Perl Adapt (level 4):
  * Curses the flexibility of the Perl object system
 
A Perl Hacker (level 5):
  * Delights in the flexibility of the Perl object system

jeffa, Just Another OO Hacker . . . . /duck

[Starky]

Just to bring the discussion right round, I thought I'd mention the textbook definition of an object: It is something that has identity, state, and behavior. That's all.

If you think of a behavior of the scalar as, for example, to place itself in the proper context depending on the operator operating on it (as it does in Perl), state as the value and other meta-attributes associated in the Perl guts with the scalar, and identity as, well, I'm kinda digging here, but the name of the scalar, then dragonchild is exactly right (and with a keen observation): A scalar is an object.

(I am but a lowly mathematician, so any CS folks out there who know better please pipe in if I am wrong. For reference, this definition of an object comes from "Object-Oriented Analysis and Design" by Grady Booch, 2nd Ed., p. 83.)

This observation is somewhat amusing to me in light of all of the discussion insofar as everyone seems to be debating whether Perl is OO or how OO Perl is. Perhaps one could argue that Perl is so very successfully OO that Perl programmers don't even know they're using objects?

Ah, the irony ;-)