It seems, these days, that knowledge of OO counts as much as knowledge of protocols, systems and computer science.
Which is mildly galling. The plain fact is, we'd all like to write cool code that everyone used, abstracted to the n^th degree,
which is as generic as a politician's answer but infinitely more applicable.
The art of the matter is recognising when that is productive to do. Mostly I like instantaneous results, which OO never is, either in creating or in running.
Occasionally it's useful for code reuse, but rarely in a quantifiable amount compared to function reuse

OO is a way of saving time and making robust systems, it's a methodology, take it off the pedestal, learn it, move on.
On to abstract oriented development, perhaps...

Err, good poll, sorry about the rant.

† Really like in the "evangelising" sense

--

Brother Frankus.

¤

I don't want to "evangelize" anything, but I'm not sure why you think OO programming isn't instantaneous. I think how instantaneous it is depends heavily on the language.

C++ looks laborious to me. I haven't learned to code to OO in C++ because I've never had time/need (to even learn C++). Ditto Java. Ditto Python.

Perl OO -- while not instantaneous-- is a great way to learn how OO actually works because all of the internals are exposed. It's almost annoying the way you have to shift $self off the argument list for $self to recognize it-$self, but you really do learn to see an object for just a (blessed) reference to a data structure. I mean, you're there building that structure and manually blessing it. You really get to learn the difference between the namespaces, and how to share data (exporter, etc), and how instance/local variables interact.

Then what about a language like Ruby. How much more instantaneous could a langugage get? It has a interactive mode (irb) where your program runs as you type it. You can define a class in very few keystrokes, redefine classes and methods after you've already started using them (existing objects can learn new behavior), pick up the objects, classes, and shake them and see what falls out. It couldn't get more interactive or instantaneous.

But is OO enough all by itself? Of course not. A good language will have a simple way to write a straight-forward imperative program. It will also have things from functional programming, like the ability to pass a block as an argument or creating closures.

And no, I haven't heard anyone going on about relational databases lately... but I have heard a lot of really enthusiastic discussion of star schema methodology for them. <grin />

Perl OO -- while not instantaneous-- is a great way to learn how OO actually works because all of the internals are exposed.

I couldn't agree more. I learned OO with Perl, and I find that it gave me a unique perspective on the meaning and purpose of inheritance, polymorphism, and encapsulation. Because it's so out in the open, it's less magical and more understandable.

I like Ruby and Perl too, both are cool languages, I run both on my iPAQ; I've also used C++, Java and Python in commercial environments, and I would not grumble if I had to use them again.I didn't feel the need to mention that in the previous post.

In effect, you've proved my point. In defending OO, you've missed the salient points and started with the premise that I'm a novice.

OO Development isn't instantaneous, invariably you'll need to "reign in" the analyst who's so busy producing a design that match the "problem set" rather than observing what goes into the system and what comes out. When running OO code, in Perl at least using OO has an overhead. I think you know these things already.

Perl OO isn't a good way to learn how OO works as it doesn't protect you from bad things, it'll take you longer as you stumble across means of implementing singletons and avoiding diamond inheritance structures. Of course when you do, you'll be a hardened veteran, whereas other langauages will not tell you of these horrors, simply avoid them silently, by means of the language design (mostly). This is where Damian Conway's book is indispensable. OO is fun in Perl, but Perl isn't meant to teach you OO.

If you're using Perl and nothing else, of course you'll learn OO using Perl makes sense, but it's only maginally less stressful than learning a new language and OO at the same time. Of course I'm speaking as one who learnt C++, Perl then Java then OO Perl.

--

Brother Frankus.

...
Ok, so I didn't really mean that about information hiding. Dramatic
license. But it is one of the things that bothers me the most about OO
code. A "real OO programmer", when given the task of implementing a
heart, would take a real heart and coat a meter thick layer of plaster
around it, then drill holes down to the aorta and stick tubes in them.
He would tell you how great it is that you can replace the buried hear
+t
with a vacuum cleaner or a rooster without changing anything else. Whe
+n
you complain about the tubes sticking out of your chest and the
wheelbarrow you need to push your new heart around in, he'd quickly
point out that the wheelbarrow is really an advantage because you can
haul around all kinds of other great things at almost no added burden.
...
[download]

Courage, the Cowardly Dog

Cool. That's the first time I've ever run across someone quoting me on the web (properly attributed, even!). A slightly updated version is at http://foxglove.dnsalias.org/~sfink/rants/information-hiding.txt, but the passage quoted above is unchanged (and probably the only part worth reading.) But as I say in the pointer to it from my home page:

If you disagree with it, then it's probably more right than wrong for you. If you agree with it (like I do!), then it's most likely more wrong than right. We humans are funny that way.

...this is very funny, but the analogy breaks down immediately when we realize that the heart is a component of a system that is not subject to extension, redesign, or feature creep. (So far at least, who knows what will happen in the age of nanotechnology?)

It's easy to laugh at the idea that encapsulation leads to the possibility that we could replace the heart with a vacuum cleaner or a rooster. But imagine a real-world situation that concerns something almost as dear to many of us, the filesystem.

Most Unix filesystem afficionados are aware that files are based upon a construct known as the inode. (An inode contains all of the relevant information that defines a file with the exception of the file's name.) In order to support the notion of remotely available files through the NFS filesystem, designers had to choose between either modifying the core code in the kernel to make special exceptions for files that are seen in a mounted NFS filesystem, or finding an abstract layer that encompassed all of the things that are common to both types of files.

It would not have been difficult to account for both types of files in the kernel, but then there was this other form of networking that was common in the early days of NFS. A lot of people called this the "sneaker net." People wanted to put floppy disks with PC filesystems into their systems and be able to read them.

So without an abstract representation of the inode concept, there would have had to be changes in the kernel to account for every new filesystem that came along. (So the S5 filesystem, the UFS filesystem, the PCFS filesystem and NFS filesystems were just the beginning of the problem.)

By throwing some plaster around the problem (not a meter thick perhaps, but maybe only a few centimeters), it became possible to support a virtually unlimited number of new filesystem types without much change to the kernel core.

In the end, OO programming is over-hyped, but then so are Tiger Woods, Michael Jordan, and Barry Bonds. This does not detract from their greatness. On the other hand, you probably wouldn't hire Tiger Woods to clean your carpets. A simple Perl one-liner would be a better choice.

...All the world looks like -well- all the world, when your hammer is Perl.
---v

...I fully expected someone to challenge me to demonstrate the Perl one-liner that will clean your carpets.

...All the world looks like -well- all the world, when your hammer is Perl.
---v

raise Zombie;

package Zombie;
sub raise { print "BRAINSSSS!\n" }
[download]

jeffa

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)

LOL! ++

Makeshifts last the longest.

If I may go into "grumpy old pfhardt" mode, I have worked with some fresh-from-college whippersnappers who can evangelize about OO and all that rot, but when you ask them something about real-world programming (like, say, dealing with user input errors), their jaws drop, the saliva begins to drip, and in my mind I hear "Duh, gee, Tennesse, let's ask Mr. Whooppee." Well, that or "Gosh, Mr. Obvious; I never made the connection." I think that, because the OO paradigm hides many things, they sometimes have trouble dealing with things that shouldn't be hidden to the programmer.

--
tbone1
As God is my witness, I thought turkeys could fly.

For example .. I'm writing a quick script to mirror a web site. Am I using OO? No, not really. I'm just getting the job done.

Another project I'm working on is quite large. Will I be using OO? Perhaps it's not pure OO, but I will certainly write modules to handle the two (so far) classes I have. And, yes, one class inherits the other. But I'm doing it that way because it's the right tool for the job. Not because everything looks like a nail.

It seems that if you mention a project you worked on was 'OO' you suddenly appear much more intelligent, technically competent and attractive to the other sex. Bollocks.

'OO' is one way to do the job. Period.

--t. alex
but my friends call me T.

When the only tool you have is a hammer, then every problem looks like a nail

-Abraham Maslow

Kristofer A. Hoch

    -- Chip Salzenberg, Free-Floating Agent of Chaos

10 print "Hello World"
20 print "Keep it BASIC, baby yeah!"
[download]

Then again, when I write OO, I write the the methods with a functional paradigm.

Some OO languages (ruby, maybe even python) are great, but being limited to one paradigm really stinks.

elusion : http://matt.diephouse.com

• Wrench set
• Socket Set
• Screwdriver set
• Pots and pans
• Vehicles
• Genetics...

My point:
OO exists in many place in many ways. It is great in situations where there are large unknowns in the future. You build code, test it and maintain it seperately. You assign rules (parameters) to its input and output. Others that use it follow these rules do not worry as much about the code in the object.

I have written programs that OO saved 100s to 1000s of man hours programming. I have seen programs written that added 100s of man hours by going OO. Like all great projects, map it out from a thousand feet, but land and see the ground around you before you decide on a coding method.

- cybear

Hopefully the answer is/was "Yes"?

cybear...

No matter what you see in the comments, either it's pro-OOP or anit-OOP, you should learn about OOP.
First its not that hard to learn (it's not nuclear science, it's not even math, relational database used to be math whatever that means!).

If there is one thing I learned about programming from PerlMonks website; it's there is several pardigms for programming(I dont remember the node name or author, sorry, but there is a specific node that I mean): functional, procedural, OOP, and ... well and more to come I hope! OOP will not corrupt your mind if you learn it.
Mostly people who attack it, are just turned off by other people who are so very ooh-no ooh-my pro-OOP. But OOP is really interesting, as many ppl say, and will continue to say.

OOP can be thought of in many ways, you can think of it as an upgrade to procedural programming, or the next logical step in the comp.lang evolution. In a procedural lang you manipulates data.

Just data you cannot manipulate anything that can not be seen as data!

Data are of course: Numbers(int, floats) and characters (strings!),data here is basically what ever you can insert from your keys in your keyboard...did i miss anything thing.

And functions are functions, anything you cannot describe as data, you had to code a functions to represent it, and still those function can only manipulates data!

OOP offers you a real way (by real I mean OOP is not just a theory, you have real implementation of its concepts) to manipulate more then just data, you can manipulate objects (and that is part why I think OOP implementations that don't support operator overload are missing a great deal!). Of course data can be objects, and objects can be anything. The gotcha here is, objects can only be anything that can be described in functions/methods and data; but hey, look around (at the different programs that exist today), that really almost anything!

So why not think of a button as a function that draw a button!
Don't you think it's better (a better and easier way to think when designing a program) to put a button object, on your window object (function..eek!), and add textArea objects and label objects to make a form!
Yes GUI programming is one area of design that benefits a lot from OOP.

So the bottom line is OOP is way of thinking when designing a program that is actually supported by langs that implement the concept and allow you to code what think the way you think it.

And yes if all you wanted to manipulate is just numbers and characters, OOP would not give you much of and edge.
But still its great to be here when you need it!

And believe it or not OOP offer you a lot more then what I said, take Inheritence, this feature proved to be a great way to organize and upgrade object. And offered a great maner of code reuse. Abstract object at the top more detailled ones as subs, and subs for subs...

A change in the the father Object with affect all its sons! WOW..thats impressive, not impressive to do, but to think about this way, and you know what you really code it that way, you can probably still do the same with regular modules. But isn't a lot more logical and fun to think about it in term of objects!

It really reduce the gap between modelling a program/system and the actual code.

I guess this is all.

Thanks for the input. I'll keep your comments in mind.

Got a good book to recommend?

- cybear

----
NaSe
:x

...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:
Vincent's Law of Elegant Programming: The most elegant programming solution is the one that is finished.

...All the world looks like -well- all the world, when your hammer is Perl.
---v

Um, some of us here actually like women and want to encourage them to program in Perl, including OO. Your comment is bizarre, and not very friendly to them.

i myself like women alot (and pee sitting) and it was just a joke in fact

in german there is a joke like this ("das ist was für sitzpinkler") and i tried to translate it into english but obviously it didnt work out. sorry.

----
NaSe
:x

I understand OOP just about as well as I understand sandscrit. Oh well, soon enough I will get around to it... one of these days; maybe... probably not... oh well.



---

work it harder make it better do it faster makes us stronger more than ever hour after our work is never over.

Ahem.....

FIRSTPOST!!!! ;-P

--

Brother Frankus.

so, brother frankus, how do you do it? do you wait for the poll to change?