I'm over OO.

[drunkenmonkey]

So what? What is your concern?

Did you not read the entire post?

faster how? processing; how about in the long run when there is maintenance to be done? Not so fast then, and if it's procedural there is ALWAYS maintenance that needs to be done.
Procedural does not always equate to faster.

[penagate]

The amount of maintenance that needs to be done depends on the requirements of the client. The time and effort involved to effect such maintenance depends on the flexibility of the architecture of the system. Both OO and procedural systems can vary hugely in this regard but OO designs lend themselves to rigid architectures. This can be bad for maintenance (or good - depending on the type of work required).

In other words, your procedural systems must have been badly designed.

[kedaman]

Nice to see someone else who hates OOP and thinks it smells
OOP bundles together data and functions - this is highly undesirable and annoying. The concept used in for instance Haskell classes are much more flexible and useful, because the data is abstracted from a class.

However I don't agree, that abstractions are evil - it is OOP that corrupts the pure concept of abstraction, because of all the unnecessary overhead that polymorphism causes, which is why you have generic programming in the first place. What you would rather have is a mechanism that applies formal methods to prove that a function or a class (any type with specified operations/functions) really do what they are suppose to do. This would ensure that abtractions are not just abstractions by name.

[RhinoBull]

Did you not read the entire post?

faster how? processing; how about in the long run when there is maintenance to be done? Not so fast then, and if it's procedural there is ALWAYS maintenance that needs to be done.
Procedural does not always equate to faster.

Try not to confront - otherwise you might be talking to yourself...

[Spacehamster]

I remember (with some sheepish embarassment) my first meeting at my current workplace (3 years ago). It was to discuss a strict programming architecture that we were to apply to every single application we'd ever write - regardless of how big or small it was. As I dimly recall, this involved at least 6 levels of abstraction and over 36 subclasses. It took 2 hours to explain how it all worked.

At the time, I wasn't very enthusiastic about the idea, but back then I couldn't put my finger on why. After reading Penagate's original posting, I realise why - it was OO Design and abstraction gone mad. A perfect example of Architecture Astronauts at work. And another lesson that there's no such thing as a Silver Bullet.

[Dnereb]

I Like OO programming
It save me time by producing a lot of reusable code to me.
and I can easily find the propperty's or Methods I need without reading complete manuals.
Maybe I still remember writing assembly, and programs hanging together with goto's.
And OO is a means to a purpose not a purpose on it self... just like normalising databases is.

[drunkenmonkey]

Try not to confront - otherwise you might be talking to yourself...

Well I don't know it sounded like you were doing the same. I thought that's how you all talked to each other here?

[Slaine]

OOP is just one tool in the architects toolbox. Granted it can be over used, and quite often by those who have no sense about when and where it is good, and when it is not.

However, the accomplished analyst will pick it from a far wider palette of design architectures based on the job at hand.

The overriding problem is that there are far too many incompetent developers out there who don't deserve the name.

That being said, I think the shift towards multi core/processor systems will soon bring about a paradigm shift towards a newer design pattern that overcomes some of the problems OOP has in this kind of environment. But again, this will just add another tool to the box.

[RhinoBull]

I Like OO programming
It save me time by producing a lot of reusable code to me...

But reusable code could be produced without any OOP at all. Not that I am aginst OOP - it's just a matter of fact that OOP isn't necessary in this case.

And OO is a means to a purpose not a purpose on it self... just like normalising databases is.

I like that quote...

[Shaggy Hiker]

This may be a bit old for some of the folks here, but to summarize PG, he is opposed to Small Talk.


Even .NET has a core capacity for pseudo non-OO code in the module. Since a module is a shared class, it actually is OO, but you can simply ignore that unimportant fact if you want to. Considering that the head of VB7 (.NET2002) would agree with all PG has said, perhaps that is why this feature is in there. That project manager told me that OO can be horribly abused, and has led to some terrible spaghetti in the past (and I love spaghetti....just not in my code), and he was reluctant to give it any support. Personally, I use objects when they make sense, and don't use them when they don't. I've only used inheritance one time, so far.