PureBasic Forums - English

What I sometimes see when I interview people and review code is symptoms of a disease I call Object Happiness. Object Happy people feel the need to apply principles of OO design to small, trivial, throwaway projects. They invest lots of unnecessary time making pure virtual abstract base classes -- writing programs where IFoos talk to IBars but there is only one implementation of each interface! I suspect that early exposure to OO design principles divorced from any practical context that motivates those principles leads to object happiness. People come away as OO True Believers rather than OO pragmatists. Hopefully the co-op program shocks them out of it, but better to not get Happy in the first place.

When we drop down to the algorithm level, I think OO can seriously thwart reuse. In particular, the use of objects to represent simple informational data is almost criminal in its generation of per-piece-of-information micro-languages, i.e. the class methods, versus far more powerful, declarative, and generic methods like relational algebra. Inventing a class with its own interface to hold a piece of information is like inventing a new language to write every short story. This is anti-reuse, and, I think, results in an explosion of code in typical OO applications.

That said, I certainly was a fan of C++ in the day, and five more years of it cured me of that. The complexity is stunning. It failed as the library language it purported to be, due to lack of GC, in my opinion, and static typing failed to keep large OO systems from becoming wretched balls of mud.

I think the lack of reusability comes in object-oriented languages, not in functional languages. Because the problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

If you have referentially transparent code, if you have pure functions - all the data comes in its input arguments and everything goes out and leaves no state behind - it's incredibly reusable.

Programmers have been conned into using all these different programming languages and they've been conned into not using easy ways to connect programs together.

There must be big commercial interests for whom it is very desirable that stuff won't work together. It creates thousands of jobs for consultants. And thousands of tools to solve problems that shouldn't exist. Problems that were solved years ago.

TI-994A wrote:Being an oft-requested feature for PureBasic, here are some thoughts on the object-oriented programming model by three respected authorities on the subject, vindicating the Fantaisie Team's decision not to implement it as a sound and practical one.

Bravo to the team!

An excerpt from an interview with Rich Hickey, Developer of Clojure

That said, I certainly was a fan of C++ in the day, and five more years of it cured me of that. The complexity is stunning. It failed as the library language it purported to be, due to lack of GC, in my opinion, and static typing failed to keep large OO systems from becoming wretched balls of mud.

Don't believe the hype!

HanPBF wrote:But, there's no reason not to have polymorphy:
add(*ContainerGadget, *TextboxGadget)
add(*ContainerGadget, *ButtonGadget)
add(*DBXYZ, *TableABC)
etc.

What I must do today is
add_ContainerGadget_TextboxGadget(*ContainerGadget, *TextboxGadget)
etc.
if I want to have my own implementation for different types.

heartbone wrote:I truly feel sorry for the multitude of victims who've had their minds warped by the object oriented paradigms used in university academic programs.

heartbone wrote:This is an excellent thread and presentation TI. Thanks.

TI-994A wrote:Being an oft-requested feature for PureBasic, here are some thoughts on the object-oriented programming model by three respected authorities on the subject, vindicating the Fantaisie Team's decision not to implement it as a sound and practical one.

Many people tend to look at programming styles and languages like religions: if you belong to one, you cannot belong to others. But this analogy is another fallacy. It is maintained for commercial reasons only. Object-oriented programming (OOP) solidly rests on the principles and concepts of traditional procedural programming (PP). OOP has not added a single novel concept, but it emphasizes two concepts much more strongly that was done with procedural programming.

Many people tend to look at programming styles and languages like religions: if you belong to one, you cannot belong to others. But this analogy is another fallacy.

TI-994A wrote:vindicating the Fantaisie Team's decision not to implement it as a sound and practical one.
An excerpt from a blog post by Eric Lippert, Principal Developer of Microsoft C#

What I sometimes see when I interview people and review code is symptoms of a disease I call Object Happiness. Object Happy people feel the need to apply principles of OO design to small, trivial, throwaway projects. They invest lots of unnecessary time making pure virtual abstract base classes -- writing programs where IFoos talk to IBars but there is only one implementation of each interface! I suspect that early exposure to OO design principles divorced from any practical context that motivates those principles leads to object happiness. People come away as OO True Believers rather than OO pragmatists. Hopefully the co-op program shocks them out of it, but better to not get Happy in the first place.

Which brings me to my second point -- why do we have OO principles in the first place? Not because they are cool, I hope. Rather, because OOP is a style of programming which emphasizes encapsulation, abstraction, contracts, information hiding, extension through inheritance, etc, etc, etc. These are things which help in the design and implementation of large scale software.

Super. That's goodness for me -- I work on systems like that. But in an introductory course in computer science, typically the students are working on small, simple programs by themselves. OO languages are not necessarily good pedagogically at the introductory level.

What I sometimes see when I interview people and review code is symptoms of a disease I call Object Happiness. Object Happy people feel the need to apply principles of OO design to small, trivial, throwaway projects. They invest lots of unnecessary time making pure virtual abstract base classes -- writing programs where IFoos talk to IBars but there is only one implementation of each interface! I suspect that early exposure to OO design principles divorced from any practical context that motivates those principles leads to object happiness. People come away as OO True Believers rather than OO pragmatists. Hopefully the co-op program shocks them out of it, but better to not get Happy in the first place.