I'm over OO.

Seriously, I'm sick of it.

I don't understand modern programming's obsession with object-orientation. For goodness' sake, not everything is an object, so why treat everything like one? It's so unnecessarily constraining. Programming is about algorithms and using them to manipulate data. Sure, you may throw objects in the mix as well if you want, but I wish people would stop trying to twist every concept to fit the OOD model. Language designers should focus on implementing real life principles instead of trying to reinvent them.

Even worse is when people start trying to force everything not only into objects but into design patterns. (Java is a torturous example of this.) I feel that programming languages are becoming less intuitive for their users and more and more simply for computer science students to write lengthy, vacuous, and yet seemingly profound essays about.

Object-oriented languages are an annoying fad and are not the future.

(*Dons flame-retardant suit*)

timeshifter, that's more of a rant than your effort. :)

It's all about the flame-retardant suit. If I'd rememberd to don that, mine would have been superior.

Quote:

---

Originally Posted by penagate

Seriously, I'm sick of it.

I don't understand modern programming's obsession with object-orientation. For goodness' sake, not everything is an object, so why treat everything like one?

---

Everything is an object. I do agree that some people have taken it way too far and defeated the purpose of oop design. Especially college professors who couldn't hack it in the real world. For some reason writing unusually confusing code to spit hello world out to a console makes them feel better about the fact that they aren't getting paid sheit.:lol:

A nice logical OOP design makes it eaiser to split tasks off to different developers with different skillsets. For example, It's a lot eaiser for a noob to do type something like Account.Balance than write a routine that calculates an account balance.

Array.Sort is one of my favorites... granted, a good binary sort is only 13 lines of code in VB6, regardless of how many entries the array has... but Array.Sort is easier and a hell of a lot faster.

Quote:

---

Originally Posted by MasterBlaster

A nice logical OOP design makes it eaiser to split tasks off to different developers with different skillsets. For example, It's a lot eaiser for a noob to do type something like Account.Balance than write a routine that calculates an account balance.

---

I agree, but that's modularisation (and namespacing); attributes that come with OO, but are not restricted to it. You can make efficient non-object-oriented designs.

Quote:

---

Originally Posted by timeshifter

Array.Sort is one of my favorites... granted, a good binary sort is only 13 lines of code in VB6, regardless of how many entries the array has... but Array.Sort is easier and a hell of a lot faster.

---

Again, a virtue of the library, not the paradigm.

I think it's the intellisense that drives them.

dim objPenagate as vbForumUser

objPenagate.isOverOOP=true

Wow.. you are not OOP.

Dim Penagate As New vbForumsMember

Penagate.isOverOOP = True

Penagate.Banned = True

Quote:

---

Originally Posted by penagate

I agree, but that's modularisation (and namespacing); attributes that come with OO, but are not restricted to it. You can make efficient non-object-oriented designs.

---

I was just listing an attribute that I liked about oop. I can add to that list if you'd like.

From what I've gleaned of VB2005 in my limited time working with it, it behaves like VB6 but looks like a more traditional OOP IDE. I like it.. the code is more precise and efficient, but I can program it similarly to how I code VB6.

Quote:

---

Originally Posted by MasterBlaster

I was just listing an attribute that I liked about oop. I can add to that list if you'd like.

---

Well there are a lot of things I like about it [OO] too. It's people's insistence on using it everywhere, including where inappropriate, that annoys me.

Learn ASP.

Penagate, I do have a great deal of respect for your technical skills but I cannot help feel a little disappointed by your outburst.

However, I realise that you are under a lot of stress what with uni work and everything so I think we can all put this down to exhaustion or a weather balloon or something.

In light of this I think we should each light a candle and pray for Penagate's soul at this time of emotional upheaval.

Can I light a firecracker instead?

Although I agree that there is a time and a place for OO and non-OO. Don't let those who would impart their doctrines upon you deter you from the holy path of OOP with their poison gospel. Follow thine own path, Grasshopper.

Quote:

---

Originally Posted by timeshifter

Can I light a firecracker instead?

---

Yeah fine whatever keeps you quiet.

[quiet]

Why am I being quiet?

[/quiet]

I kinda agree with penegate. I know my post number and my.. programming skills.. may be a bit.. low. But still, when I am looking on codeproject and other sites like that and I see like 10 overloaded classes each with one line, each saying get and set something, and then you realize you can do all of this with ONE method and around 5 lines of code. I don't really know if this pertains to what we're talking about, but still. It's supposed to make your code more organized, in my mind, it just makes it more confusing! You can rather use one method, and examine each line and see what it does, rather than reading all these overloads and seeing, well this goes to that, that goes back, that goes there and then that can be either this or that.. well.. it's just something confusing

The overloads are to force parameters to behave how you want them. An overloadable function will tell you its' default values. You are in no way required to use overloads.

Quote:

---

Originally Posted by timeshifter

The overloads are to force parameters to behave how you want them. An overloadable function will tell you its' default values. You are in no way required to use overloads.

---

As well as throw a build error every where that function or constructor is called if you change the parameters. This comes in very handy if you are working on a huge system. Especially in constructors.

I'm sorry, did I leave that part out? My bad.

Quote:

---

Originally Posted by timeshifter

I'm sorry, did I leave that part out? My bad.

---

What the hell. You're off your game today man. :lol:

What he actually meant in that rant was, "Java sucks".




But please, keep the discussion going.

Quote:

---

Originally Posted by penagate

Seriously, I'm sick of it.

I don't understand modern programming's obsession with object-orientation. For goodness' sake, not everything is an object, so why treat everything like one? It's so unnecessarily constraining. Programming is about algorithms and using them to manipulate data. Sure, you may throw objects in the mix as well if you want, but I wish people would stop trying to twist every concept to fit the OOD model. Language designers should focus on implementing real life principles instead of trying to reinvent them.

Even worse is when people start trying to force everything not only into objects but into design patterns. (Java is a torturous example of this.) I feel that programming languages are becoming less intuitive for their users and more and more simply for computer science students to write lengthy, vacuous, and yet seemingly profound essays about.

Object-oriented languages are an annoying fad and are not the future.

(*Dons flame-retardant suit*)

---

You know you can make a boat using hand tools or you can join the 21st century (well in this case the 20th century) and use a few power tools where warranted to make the process go smoother and quicker. Not to mention easier for later upgrades and maintenance.
And please GAWD tell me that by Java you are not meaning JavaScript?!?
I know it's difficult changing you're thinking to use OO when you're used to procedural programming but studies show that it is much more efficient.
Granted not everything deserves OO treatment, there is always going to be a place for C code.

Quote:

---

Originally Posted by timeshifter

What he actually meant in that rant was, "Java sucks".




But please, keep the discussion going.

---

Java still sucks? No way, didn't JR date her once upon a time? :eek2:

Quote:

---

Originally Posted by penagate

You can make efficient non-object-oriented designs.

---

I'm sorry I'm new here, but is this meant to be tongue-in-cheek?

well said penagate

try debugging someone's code who got carried away with OOP. You have to navigate through a huge tree of methods that each contain only one or two lines of code because objects are created to do every task.

I create new public functions and subs for the most common reason of it's used in more than one place. For instance, in one of my current projects, I've got a function that builds a title for the current page based on its' location in the web.sitemap file. It needs to be in every master page... which right now means four different places. I hate redundant code, so I put it in the common.vb file and reference it with one line from each master page. Works like a charm, too. I might just put it up in the code bank, it's so brilliant...

Quote:

---

Originally Posted by drunkenmonkey

You know you can make a boat using hand tools or you can join the 21st century (well in this case the 20th century) and use a few power tools where warranted to make the process go smoother and quicker. Not to mention easier for later upgrades and maintenance.
And please GAWD tell me that by Java you are not meaning JavaScript?!?
I know it's difficult changing you're thinking to use OO when you're used to procedural programming but studies show that it is much more efficient.
Granted not everything deserves OO treatment, there is always going to be a place for C code.

---

I am not advocating the use of primitive tools. Merely, I am pointing out that OOP is not the be-all end-all solution to every programming problem under the sun, as its proponents would have you believe. I have nothing against the concept of objects, but designing a whole system to be objects is pointless and unnecessary. It's bureaucratic design. You can easily end up spending more time architecting class relationships than you do actually focusing on code flow and algorithms. And it's also rigid design. Heaven forbid you make a mistake in your initial class relationship chart, or you have to go back and move a whole bunch of code around because class A now needs to inherit from class C instead of B and so method X needs to be replaced with method Y or B::Z is now C::Z and so on. Dropping reusable objects into code is a beautiful thing. Designing a fully object-oriented application is not.

One of the key principles of OOP is encapsulation. Objects are supposed to be able to deal with things by themselves. But what happens when they can't? You've hidden everything away so the object's useless beyond its stated capabilities. Instead of letting programmers deal with problems, OOP shoves them under the rug of encapsulation.

Objects also couple data and functions. This is usually undesirable. We spend a lot of time trying to separate data, algorithms, and presentation. Yet OOP objects couple these together like a ball of Play-Dough.

I am also disgusted by over-abstraction and the propensity of bad OOP programmers to abstract beyond necessity. Abstraction is evil! The more implementation details you hide, the less certainty you have when using code. Sure, it works. But what's the cost? What are the possible side effects? And the more abstraction layers you pile on, the more danger you have of the abstraction collapsing and rendering itself useless [see Joel Sporsky's Law of Leaky Abstractions]. There is a sweet spot between no abstraction and over abstraction.

The same applies to inheritance. Inheritance can be a powerful tool in the right hands. When used with abandon, it wrecks the cohesiveness and maintainability of a system. You will run around for hours up and down inheritance chains looking for that bit of code that's causing a bug that once fixed will cause you to run up and down another inheritance chain looking for another bug.

OOP does nothing but encourage, and in many cases force, programmers to employ facilities such as these which only the best programmers are capable of using wisely; madness ensues. Two years ago I didn't know what it was. Now, after both having used it and having it continually shoved down my throat as the best thing since the proverbial sliced bread, I'm thoroughly sick of it.

(P.S.: I am appreciative of the subtle differences between Java and JavaScript. One is a rigid object-oriented language while the other is a more free-form procedural/object-oriented language. I actually like JavaScript (although I don't enjoy client-side web programming much), but Java is horribly stifling.)


Edit: Moved from Chit Chat.

So what you're really saying is you hate krappy OOP designs. I don't think anyone will disagree with that.

Yes, but I'm also saying that I hate the restrictiveness of OOP that forces people to make, or feel as though they should make, said krappy designs. ;)

I strongly believe that in a decade OOP will no longer be employed in mainstream new development.

Quote:

---

Originally Posted by drunkenmonkey

You know you can make a boat using hand tools or you can join the 21st century (well in this case the 20th century) ...

---

Although OOP was not commonly used it was originated more than 40 (!) years ago. 21st century, eh ? :rolleyes:

Quote:

---

Originally Posted by drunkenmonkey

...I know it's difficult changing you're thinking to use OO when you're used to procedural programming but studies show that it is much more efficient...

---

Procedural language is synonymous for faster (much more faster) processing.

Quote:

---

Originally Posted by penagate

...I strongly believe that in a decade OOP will no longer be employed in mainstream new development.

---

I sincerely hope so but somehow don't believe it's going to happen - with .Net MS does nothing but promoting what was once almost forgotten. :)
(if that makes sense to anyone...)

Penagate leaves O-O?? Oh dear lord no! :eek:

Quote:

---

Originally Posted by RhinoBull

Although OOP was not commonly used it was originated more than 40 (!) years ago. 21st century, eh ? :rolleyes:

---

thus the use of (well in this case the 20th century):rolleyes:


and Pen, the seemingly pointlessness of architecting first vs just jumping in and coding is a trap that quite a few programmers fall into.
You are correct you can go to far with OO architecture, however if the project is planned out and you use incremental steps i.e. use case, design, meet with domain experts, code a mode, in two weeks then meet and reflect and make necessary changes; I've found it to be far more productive.

Some things do not need this though you are right, sometimes all you need is a script to get the job done.
We're really comparing apples to oranges here.

Quote:

---

Originally Posted by penagate

Yes, but I'm also saying that I hate the restrictiveness of OOP that forces people to make, or feel as though they should make, said krappy designs. ;)

I strongly believe that in a decade OOP will no longer be employed in mainstream new development.

---

That's on architect and dev team then, not a design architecture. If you see someone washing their car with a sandblaster, who's the Idiot? The sandblaster or the guy sandblasting. Use the right tool for the right job.

OOP will be around for a long time. It's an efficient compliment to RAD tools and makes development of large applications with large dev teams managable and affordable. This is coming from a former COBOL developer. There are benifits to both, never limit yourself.

Quote:

---

Originally Posted by RhinoBull

Procedural language is synonymous for faster (much more faster) processing.

---

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.

..what is this procedural programming you speak of?..

chem

Quote:

---

Originally Posted by drunkenmonkey

how about in the long run when there is maintenance to be done?..

---

So what? What is your concern?

Quote:

---

Originally Posted by RhinoBull

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.

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.

Nice to see someone else who hates OOP and thinks it smells :D
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.

Quote:

---

Originally Posted by drunkenmonkey

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

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

I Like OO programming :)
It save me time by producing a lot of reusable code to me. :bigyello:
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.:wave:

Quote:

---

Originally Posted by RhinoBull

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

---

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?:rolleyes:

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.

Quote:

---

Originally Posted by Dnereb

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.

Quote:

---

Originally Posted by Dnereb

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

---

I like that quote... :)

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.