125 KiB
| created_at | title | url | author | points | story_text | comment_text | num_comments | story_id | story_title | story_url | parent_id | created_at_i | _tags | objectID | year | |||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2014-12-11T14:32:45.000Z | Why I Hate Object Orientated Programming (2010) | http://blog.jot.fm/2010/08/26/ten-things-i-hate-about-object-oriented-programming/comment-page-2/ | Immortalin | 59 | 54 | 1418308365 |
|
8734877 | 2010 |
Ten Things I Hate About Object-Oriented Programming — The JOT Blog
The JOT Blog
2010/08/26
Ten Things I Hate About Object-Oriented Programming
Filed under: Editorial — Tags: ecoop — Oscar Nierstrasz @ 17:25
Boy, I some days I really hate object-oriented programming.
Apparently I'm not the only one. In the immortal words of Edsger Dijkstra: "Object-oriented programming is an exceptionally bad idea which could only have originated in California."
Well, I'm not normally one to complain, but I think it is time to step back and take a serious look at what is wrong with OOP. In this spirit, I have prepared a modest list of Ten Things I Hate About Object-Oriented Programming.
1. Paradigm
What is the object-oriented paradigm anyway? Can we get a straight story on this? I have heard so many different versions of this that I really don't know myself what it is.
If we go back to the origins of Smalltalk, we encounter the mantra, "Everything is an object". Except variables. And packages. And primitives. And numbers and classes are also not really objects, and so on. Clearly "Everything is an object" cannot be the essence of the paradigm.
What is fundamental to OOP? Peter Wegner once proposed that objects + classes + inheritance were essential to object-oriented languages [http://doi.acm.org/10.1145/38807.38823]. Every programming language, however, supports these features differently, and they may not even support them as built-in features at all, so that is also clearly not the paradigm of OOP.
Others argue convincingly that OOP is really about Encapsulation, Data Abstraction and Information Hiding. The problem is that some sources will tell you that these are just different words for the same concepts. Yet other sources tell us that the three are fundamentally different in subtle ways.
Since the mid-eighties, several myths have been propagated about OOP. One of these is the Myth of Reuse, which says that OOP makes you more productive because instead of developing your code from scratch, you can just inherit from existing code and extend it. The other is the Myth of Design, which implies that analysis, design and implementation follow seamlessly from one another because it's objects all the way down. Obviously neither of these candidates could really be the OO paradigm.
Let's look at other paradigms which offer a particular way to solve programming problems. Procedural programming is often described as programs = data + algorithms. Logic programming says programs = facts + rules. Functional programming might be programs = functions + functions. This suggest that OOP means programs = objects + messages. Nice try, but this misses the point, I think.
For me the point of OOP is that it isn't a paradigm like procedural, logic or functional programming. Instead, OOP says "for every problem you should design your own paradigm". In other words, the OO paradigm really is: Programming is Modeling
2. Object-Oriented Programming Languages
Another thing I hate is the way that everybody loves to hate the other guy's programming language. We like to divide the world into curly brackets vs square brackets vs round brackets.
Here are some of the nice things that people have said about some of our favorite OOPLs:
"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg."
It was Bjarne Stroustrup who said that, so that's ok, I guess.
"Actually I made up the term 'object-oriented', and I can tell you I did not have C++ in mind." — Alan Kay
"There are only two things wrong with C++: The initial concept and the implementation." — Bertrand Meyer
"Within C++, there is a much smaller and cleaner language struggling to get out." — Bjarne Stroustrup
"C++ is history repeated as tragedy. Java is history repeated as farce." — Scott McKay
"Java, the best argument for Smalltalk since C++." — Frank Winkler
"If Java had true garbage collection, most programs would delete themselves upon execution." — Robert Sewell
But perhaps the best blanket condemnation is the following:
"There are only two kinds of languages: the ones people complain about and the ones nobody uses." — Bjarne Stroustrup
3. Classes
Classes drive me crazy. That might seem strange, so let me explain why.
Clearly classes should be great. Our brain excels at classifying everything around us. So it seems natural to classify everything in OO programs too.
However, in the real world, there are only objects. Classes exist only in our minds. Can you give me a single real-world example of class that is a true, physical entity? No, I didn't think so.
Now, here's the problem. Have you ever considered why it is so much harder to understand OO programs than procedural ones?
Well, in procedural programs procedures call other procedures. Procedural source code shows us … procedures calling other procedures. That's nice and easy, isn't it?
In OO programs, objects send messages to other objects. OO source code shows us … classes inheriting from classes. Oops. There is a complete disconnect in OOP between the source code and the runtime entities. Our tools don't help us because our IDEs show us classes, not objects.
I think that's probably why Smalltalkers like to program in the debugger. The debugger lets us get our hands on the running objects and program them directly.
Here is my message for tool designers: please give us an IDE that shows us objects instead of classes!
4. Methods
To be fair, I hate methods too.
As we have all learned, methods in good OO programs should be short and sweet. Lots of little methods are good for development, understanding, reuse, and so on. Well, what's the problem with that?
Well, consider that we actually spend more time reading OO code than writing it. This is what is known as productivity. Instead of spending many hours writing a lot of code to add some new functionality, we only have to write a few lines of code to get the new functionality in there, but we spend many hours trying to figure out which few lines of code to write!
One of the reasons it takes us so long is that we spend much of our time bouncing back and forth between … lots of little methods.
This is sometimes known as the Lost in Space syndrome. It has been reported since the early days of OOP. To quote Adele Goldberg, "In Smalltalk, everything happens somewhere else."
I believe that the code-oriented view of today's IDEs is largely to blame — given that OO code does not accurately reflect the running application, the IDE gets in our way instead of helping us to bridge the gap. Another reason I believe that Smalltalkers like to develop in the debugger is that it lets them clearly see which objects are communicating with which other objects. I am guessing that one of the reasons that Test-Driven Development is popular is that it also exposes object interactions during development.
It is not OOP that is broken — we just haven't figured out (after over 40 years) how best to develop with it. We need to ask ourselves: Why should the source code be the dominant view in the IDE?
I want an IDE that lets me jump from the running application to the code and back again. (For a demonstration of this idea, have a look at the Seaside web development platform which allows you to navigate directly from a running web application to the editable source code. [http://seaside.st])
5. Types
OK, I admit it. I am an impatient guy, and I hate having to say everything twice. Types force me to do that.
I'm sure some of you are thinking — "Oh, how could you program in an untyped language. You could never be sure your code is correct."
Of course there is no such thing as an "untyped" programming language — there are just statically and dynamically typed ones. Static types just prevent you from writing certain kinds of code. There is nothing wrong with that, in principle.
There are several problems, however, with types as we know them. First of all they tend to lead to a false sense of security. Just because your Java program compiles does not mean it has no errors (even type errors).
Second of all, and much more evil, is that type systems assume the world is consistent, but it isn't! This makes it harder to write certain useful kinds of programs (especially reflective ones). Type systems cannot deal well with the fact that programs change, and that different bits of complex systems may not be consistent.
Finally, type systems don't cope well with the fact that there are different useful notions of types. There is no one type system to rule them all. Recall the pain we experienced to extend Java with generics. These days there are many interesting and useful type systems being developed, but we cannot extend Java to accommodate them all. Gilad Bracha has proposed that type systems should not only be optional, in the sense that we should be able to run programs even if the type system is unhappy, but that they should be pluggable, meaning that we can plug multiple type systems into different parts of our programs. [http://bracha.org/pluggableTypesPosition.pdf] We need to take this proposal seriously and explore how our languages and development tools can be more easily adapted to diverse type systems.
6. Change
"Change is inevitable — except from a vending machine." — Robert C. Gallagher
We all hate change, right? So, if everyone hates change, why do we all complain when things don't get better? We know that useful programs must change, or they degrade over time.
(Incidentally, you know the difference between hardware and software? Hardware degrades if you don't maintain it.)
Given that real programs must change, you would think that languages and their IDEs would support this. I challenge you, however, to name a single programming language mechanism that supports change. Those mechanisms that do deal with change restrict and control it rather than enable it.
The world is not consistent, but we can cope with that just fine. Context is a great tool for managing change and inconsistency. We are perfectly comfortable adapting our expectations and our behavior in our daily lives depending on the context in which we find ourselves, but the programs we write break immediately if their context changes.
I want to see context as a first-class concept in OO languages and IDEs. Both source code and running software should be able to adapt to changing context. I believe that many design patterns and idioms (such as visitors, and dependency injection) are simply artifacts of the lack of support for context, and would disappear if context were available as a first-class construct.
7. Design Patterns
Patterns. Can't live with 'em, can't live without 'em.
Every single design pattern makes your design more complicated.
Visitors. I rest my case.
8. Methodologies
"All methodologies are based on fear." — Kent Beck
Evidently some of my students follow the Chuck Norris school of Agile Development:
"Chuck Norris pairs alone."
"Chuck Norris doesn't do iterative development. It's right the first time, every time."
"Chuck Norris doesn't do documentation. He stares down the code until it tells him everything he wants to know."
9. UML
Bertrand Meyer tells this story about always wondering why diagrammatic modeling languages were always so popular, until one day it hit him: "Bubbles don't crash." I believe his point is that OO languages are modeling languages. (AKA "All you need is code")
There similarly appears to be something fundamentally wrong with model-driven development as it is usually understood — instead of generating code from models, the model should be the code.
By analogy, when FORTRAN was invented, it was sold as a high-level language from which source code would be generated. Nowadays we think of the high-level languages as being the source code.
I like to think that one day, when we grow up, perhaps we will think of the model as being the source code.
10. The Next New Thing
Finally, I hate the catchphrase: "Objects are not enough. We need …" Over the years we have needed frameworks, components, aspects, services (which, curiously, seems to bring us back to procedural programming!).
Given the fact that objects clearly never were enough, isn't it odd that they have served us so well over all these years?
Conclusion?
25 years ago we did not expect object-oriented programming to last as a "new" phenomenon for so long. We thought that OO conferences like ECOOP, OOPSLA and TOOLS would last for 4 or 5 years and then fade into the mainstream. It is too soon to dismiss OOP as just being part of the mainstream. Obviously we cannot feel passionately about something that does not interest us. The fact that academic and industrial research is still continuing suggests that there is something deep and important going on that we do not yet fully understand.
OOP is about taming complexity through modeling, but we have not mastered this yet, possibly because we have difficulty distinguishing real and accidental complexity.
I believe that to make further progress we must focus on change and how OOP can facilitate change. After all these years, we are still in the early days of OOP and understanding what it has to offer us.
Oscar Nierstrasz
[Banquet speech given at ECOOP 2010. Maribor, June 24, 2010]
95 Comments »
1, 2, 10 & Conclusion: Solid points (+1 for being informative)
Rest is all useless bashing (I’m sorry for using this term but I couldn’t find a decent word for being pessimist for the sake of it, complaining without considering the same points for the other side of things, …)
Comment by Monis Iqbal — 2010/08/26 @ 21:33
I see OO’s paradigm as “giving actions to data”. All the rest is variable in OO languages, but the common ground is that data has behaviour.
Whatever you do with that, the way you protect data or behaviour, it’s up to the language. But from Perl to SmallTalk, data has behaviour and the name of that union is “object”.
While Perl “bless” objects with “module descriptions” and C++ have “classes” to give types to “objects”, both do the same thing to “objects”: it gives them behaviour.
From that, comes the concept of empty objects with only behaviour (helper classes), empty objects with empty behaviour but with style (interfaces), objects without behaviour (PODs), grouping of objects (inheritance, traits, templates). Everything those languages do is with objects, but the way you describe the grouping is via classes or modules, or whatever you want it to be called.
In the end, there’s only one thing that survives: objects and its behaviours. That’s what’s all about OO.
What you complain (and I agree) is how languages implement Object-Oriented design. Stroustroup went wrong when he first designed “C with Classes”, it should have been “Objects in C” to give the right weight to the right things.
But well, that’s how things went because it’s more difficult to do what you say (run view in IDEs) than statically define everything, though it might not be the most logical view for the programmer.
Comment by Renato Golin — 2010/08/29 @ 16:08
You asked for “a single programming language mechanism that supports change”. I’ll give you two!
1. Polymorphism: depending on how it’s used polymorphism can be the most important mechanism in OOP for supporting change. Not arbitrary change, to be sure, but at least those abstractions conceived of by the original programmer.
2. IDE Refactorings: (not strictly a language mechanism, but the question was posed in the context of PL and IDE support for change). Modern IDEs increasingly support refactorings, both simple and more complex. The support is not always perfect, but it certainly aids the programmer in making changes to the design of software.
Comment by @smalltalkhacker — 2010/08/29 @ 22:04
I agree with you but I love OO too 
Comment by Jose — 2010/08/31 @ 17:32
Thank you for the thoughtful reflection on objects. I agree that more context is often valuable when programming with objects. I do it with Java/Eclipse as detailed here: http://www.threeriversinstitute.org/ProgrammingInTheConcrete.htm
Comment by Kent Beck — 2010/08/31 @ 18:57
Thanks for this wonderful post. I wished I had attended ecoop this year to hear it real
Comment by Alexandre Bergel — 2010/09/01 @ 01:28
If you hate classes in the object-oriented concept model, then you’ll REALLY hate a Category-Theoretic mathematical understanding of computer science and software development (whether O-O or not).
This prejudice usually indicates the triumph of training over education – you have learned to conceptualize in one, dominating paradigm to the exclusion of all others. Certainly, the same can be said of those who exclusively conceptualize in O-O, or AO or SO or …
Comment by Ken Lloyd — 2010/09/02 @ 14:02
However, in the real world, there are only objects. Classes exist only in our minds. Can you give me a single real-world example of class that is a true, physical entity?
public interface Car {
public void toggleEngine();
public void turnSteeringWheel();
public void applyThrottle();
public void applyBrake();
}
public class DefaultCar implements Car { /.. }
public class HondaCivic extends DefaultCar { /../ }
public class ToyotaCamry extends DefaultCar { /../ }
and so on …
It’s really a logical way to organize concepts.
In OO programs, objects send messages to other objects.
/** car **/
public void toggleEngine() {
getStarter().startEngine();
}
/** starter */
public void startEngine() {
List pistons = /…/
getFuelInjector().injectFuel(pistons);
/ and so on */
}
It’s really a logical way for concepts to interact.
Comment by rhume55 — 2010/09/11 @ 19:49
“If we go back to the origins of Smalltalk, we encounter the mantra, "Everything is an object". Except variables. And packages. And primitives. And numbers and classes are also not really objects, and so on. Clearly "Everything is an object" cannot be the essence of the paradigm.”
You are wrong. Variables are modeled as a either a Dictionary for global variables, eg: Smalltalk at: #VarName, or a positional mapping for local, instance, and other variables, eg: tempVarAt:/instVarAt:… as for packages, different systems model them in different ways, but always as objects, and numbers and classes are objects. Primitive methods are primitives, but still objects.
Comment by kevin — 2010/09/11 @ 20:11
Love the write up it shows that we are very often slaves to process and procedures.
Comment by Bo — 2010/09/13 @ 04:39
An object is a thing. Saying “everything is an object” is as meaningless as saying “everything is a thing.”
What object oriented languages provide are user-defined abstract datatypes with our type discipline made less rigid via type polymorphism. That still leaves much room for the programming language designer to determine the details of the type system, picking a compromise between simplicity vs. safety vs. expressiveness/flexibility.
The controversial part of OO is the mechanism for describing the implementation of one kind of object in terms of a related object’s implementation. The notion of inheritance combines implicit delegation (delegation from the object of the subclass to an unnamed implicit object of the superclass that it contains) with type polymorphism. I think language designers should have made this sort of implicit delegation more explicit (and flexible), and provided a separate, orthogonal construct for expressing the polymorphic subtyping.
It seems that the pioneers of object-orientation were more concerned with behavioral semantics (“look at what my programs can do”) than with denotational semantics (“look at what these programming language features mean”).
Related joke: “I learned reading via word recognition rather than by relying on phonetics. This leads to amusing errors sometimes, like when I confuse data-warehousing’ with data-whorehousing’. What is data-whorehousing, you ask? It’s a technique often used along with sex-object oriented programming.”
Comment by fsilber — 2010/09/13 @ 17:31
I really enjoyed reading this post, from the first to the very last word. Assessing “the model as being the source code” sounds a bit weird to me however – although I like what’s weird in general. It’s only a general feeling but I really don’t expect it to be the path OOP should go. Modelling is good for data, not for processing. The (only) design pattern I like to follow is the KISS one (Keep It Simple and Stupid). Optimization has long been forgotten for the sake of impressively useless complex designs and claim their beauty and pureness. After all we have so much resources now, why should we care about memory, disk space and CPU usage? What if “640KB ought to be enough for everyone”?
One thing is sure on the other hand: Smalltalk is one of the only languages I don’t know yet (along with Lisp) and I’m now really willing to dive into it.
By the way, you didn’t mention the OOP-like way of programming – the event-oriented one, may this be MS Visual Basic, MS MFC or Borland Delphi.
Comment by Fabien Bouleau — 2010/09/13 @ 23:32
Fabien Bouleau asked about the OOP-like event-oriented way of programming. This was another case in which hackers came up with a scheme that worked but couldn’t think of the right way to explain it. Thus, we get people overloading the word “event” to mean: (a) something that happened, (b) a notification that something happened, (c) a type of thing that can happen, for which your code can provide a handler to react when it does, or (d) a place to store your event handlers. The result is just meaningless jargon, as in one C# book which instructed readers to “add the delegate to the event” (you mean like “increment the explosion via the first-responder passed as the input argument”?). The only way a programmer could move from text-based systems to the presumably magical GUI-based system was by playing around with sample programs to see what happens when you do certain things.
Instead, we should have had a description of the way the operating system converts GUI actions (events) into messages in a message stream while the program reads the message stream and, in response to each message, calls a procedure which may do any combination of (1) computing, (2) issuing commands to the GUI, or (3) adding its own messages into the message stream to be processed later. To someone who has programmed in conventional languages, that’s an explanation which makes sense.
Comment by fsilber — 2010/09/14 @ 21:52
“I challenge you, however, to name a single programming language mechanism that supports change.”
update-instance-for-redefined-class
Comment by Faré — 2010/09/15 @ 07:15
… and YES, I have used it. See my ILC’2010 paper on ASDF 2.
http://common-lisp.net/project/asdf/ilc2010.pdf
Other example: Erlang’s syntactic distinction between static calls vs dynamic calls, which supports hot upgrade of code.
Comment by Faré — 2010/09/15 @ 07:20
@Faré: Actually I mispoke. I intended the challenge to apply to mainstream programming languages. Both Lisp and Smalltalk support class extensions, for example, which are very nice mechanisms to support change. Other examples abound, but there are not so many in bread-and-butter languages.
Comment by Oscar Nierstrasz — 2010/09/16 @ 18:14
Dijkstra was clever, but he complained pretty much about everything. Find something about computers that you’re passionate about, and you can be damn sure he complained about it 
Some of the things you mentioned are flaws of specific OOP languages. Fragmentation and “my-language-is-better-than-yours” seems to have more to do with human nature. It happens with procedural and functional languages as well. And flamewars between fans of static vs dynamic typing are the norm.
Finally, I don’t agree that OOP makes programs “harder to understand” than procedural programs. Simple programs are straightforward and easy to understand, of course — then again, so are simple OOP programs! Back in the real world, however…
Comment by Andrés — 2010/09/19 @ 16:32
Oscar: what about JavaScript, by the way? It’s a mainstream language for the web, with prototype-based OOP… which supports change!
(though not a lot of people are aware of the full power of JavaScript)
Comment by Andrés — 2010/09/19 @ 16:42
Great talk!
I especially like that it summarizes so well many of the ideas that new languages should try to avoid.
Are you familiar with scenario-based programming (SBP) and the language of Live Sequence Charts (LSCs)?
http://www.wisdom.weizmann.ac.il/~dharel/papers/LiberatingProgramming.pdf
It is interesting to test in light of your mentioned points, since it is very different on many respects, and it avoids many faults that way.
There is no paradigm yet, or you could consider the whole idea of SBP a new paradigm.
Since OOP is so mainstream, it is still not widely used and therefore not condemned yet. Then again, maybe being condemned is a good think…
It has the concept of classes, allowing to refer to groups of objects of the same class symbolically, which is closer to the idea of classes in our mind.
Methods and types, still remain part of the language, but they are hard to get rid of, but methods in LSCs are used as messages between objects.
The language is incremental and supports change easily.
Design patterns and methodologies are not part of the language yet, but if it will be widely used, they will probably appear, since they are something that grows with the language, again, maybe not too bad…
LSCs is taking a subset of UML, extending it, and making it executable. Making the model be the ‘source code’ or rather, the implementation.
Is it the next new thing? Who knows, but to be that it needs to be combined with OOP at least as a transition, since OOP is around for too long.
Thanks for this great summary.
Comment by M. Gordon — 2010/10/05 @ 05:24
Thanks for your thoughtful article.
As a database guy, I have another beef with OO: I abhor defining data structures around the accessibility limits of an OO model — i.e. “We’ll have to flatten this data so we can get to it.” Or “How do we cross over that link class?”
In my environment, this occurs because a multi-dimensional web of data is represented as a set of trees that only can be accessed in one direction. Directional access limits potential functionality. It also obstructs changes that use data in a different direction or along another path. Due to tree limits, our OO programmers spend significant time wrestling with potential access issues. What a load of complications!
Comment by R. Waymire — 2010/11/12 @ 00:22
I do not know how Dijkstra came about object-oriented programming was invented in California (I know these statements of him are tongue in cheek). I hope everybody here knows that object-oriented programming was invented in Sweden.
Comment by Jurgen Defurne — 2010/12/01 @ 13:50
The Norwegians will be surprised to learn this, I think.
Comment by Oscar Nierstrasz — 2010/12/01 @ 15:09
Although I can’t agree with even half of your arguments (a lot of which are already replied to in previous comments) I do share your pain that somehow OO still feels too limiting. Personally I think C# and C++ have major advantages over Java. (e.g. proper generics)
While thinking about how I would ideally like to code I found out about Language Oriented Programming. This really nice article explains its paradigm. It’s like DSLs on steroids.
http://www.onboard.jetbrains.com/is1/articles/04/10/lop/
I really like the ideology of LOP and am toying around with MPS by JetBrains lately. So far I only have one big complaint and that is that it still is java-oriented. LOP principles do allow for extension to any existing or new language but MPS hasn’t advanced far enough for that yet.
Comment by Steven Jeuris — 2010/12/10 @ 01:34
It seems to me that you might have let your education get in the way of your learning.
1. “Programming is Modeling” is absolutely right, but I don’t know if we mean the same thing. I design objects to represent resources and actors: this way, I am working with a symphony of nearly tangible objects to produce my desired result. I go see the actor responsible for making an action happen, or look at the resource that knows about a specific point of data. The focus is on mapping the problem domain so that I can speak in those terms when I’m developing.
2-5. I think you are way too hung up on very specific implementations and designs to solve problems and meet needs that admittedly aren’t amazing. Your observations are valuable but far too specific to be useful considering the more general notions you are on to. I support what you’re saying, but the bigger picture needs attention.
6. This is probably the most important thing you’ve pointed to! This made me very excited to read and happy to know that others are thinking about this problem, too. I don’t want to get ahead of myself, but I’m using a simple form of the decorator pattern to decorate specific resources in an API I’m iterating on in order to modularize changes for testing and reuse. I’m fairly pleased with the outcome, though having change be an integral part of the tools we use would be far better.
7. Here I think you’re hating on something because you’ve focused on the wrong thing. If we’re using the language to model our problems and find ourselves implementing theoretically equivalent code, we’ve got ourselves a design pattern! It just happens sometimes, and is a natural part of good design: we become consistent and use good designs to solve our problems, and sometimes those reflect these well known design patterns, and sometimes we’ve created new ones.
You say some great things, and you touch lightly on a lot of really important disparities and principles, but I feel like your letting your rant get in the way of the gold you have to share.
Thanks for sharing
Comment by Matt Todd — 2010/12/10 @ 11:45
My understanding of Alan Kay’s definition of OO is that of a computational semantics (not a paradigm for programming). Computation is message passing in OO languages, just as computation is function application in functional languages.
That’s why he dislikes Java and C++. They just bundle some data together and have some virtual method lookup. Most computation in Java happens within a method, which is just a series of procedural statements.
Comment by Eric Normand — 2010/12/10 @ 13:38
Er…regarding change, have you not heard of refactoring? There’s a whole camp of people for whom constantly reorganizing your code (using automated tools, of course) is very important.
I learned OOP as being “Encapsulation, Polymorphism, Inheritance,” which seems pretty reasonable, and I can’t think of an OO system that doesn’t have those things (although of course you could write one).
I’m not really sure what you’re ranting against. One minute it’s OO, the next it turns out it’s actually the failure of IDEs to show us code execution cleanly (I’m not sure you’re up to date on modern IDEs, but in this respect you’re right), and then you’re harping on things that are actually failures of language design–the frameworks needed to make modern C++ and Java usable. Except those are also libraries of common functionality! Like in C!
And then you’re complaining about type systems in an OO article. Are C and Pascal’s type systems so well-done and usable that this is an OO thing?
Maybe you’re cranky about people’s over-enthusiasm for OO, which, as such, ended about 15 years ago as everyone calmed down. There are rants like this from the 80s about OO, and from the introduction of structured programming before that. It’s just as misdirected now as it was then; I’m just shocked to see it in 2010, when almost all of us view OO as just another way to organize code (sometimes in a quite procedural manner). The world has moved on.
Comment by Chris D — 2010/12/10 @ 14:54
Jurgen,
Dijkstra said that object-oriented programming was invented in California because Smalltalk, the first OO language, was invented at Xerox PARC in Palo Alto, California.
Comment by JohnH — 2010/12/10 @ 18:23
Great insights!
Not just because this post emphasizes on how tough OOP is, but because you can get this sense of how complex and difficult programming in general actually is.
I’ve read most of the responses and I’m getting this certain vibe of people oversimplifying things – as if the current state of programming tools and technologies is adequate when confronting very complex problems. Well, it is not!
In my opinion instead of oversimplifying things all programmers and software engineers should acquire this healthy skepticism, because most of the stuff is just buzz – either it works only in scenarios with limited complexity or it requires 10 years of practice to just get some sense of the tool or paradigm at hand.
I really like the author’s suggestions and there are certain efforts in these directions.
For example, I really find fascinating the work of Gregor Kiczales in the field of adding some “real-world sloppiness” as part of the programmatic effectiveness. A year ago I wrote some sort of a thesis on this topic and it would be great if you find the time to get through these ideas (which probably aren’t new at all to you).
Comment by Vladimir Tsvetkov — 2010/12/10 @ 19:37
Hey Vladimir Tsvetkov,
I read you mentioned “Meta-Object Protocol for Lisp” in your post about formatility vs. informality.
While I haven’t checked this out yet, a quick look at it makes me believe it has some of the same principles as mentioned in the Language Oriented Programming article. Actually, it might follow the same paradigm. I’m sure you’ll find it a very rewarding read if you haven’t read about it yet! The main difference I see is that the CLOS still limits itself to “modelling” in text source. The revolutionary thing of MPS is that theoretically, it supports any best suiting representation of your model, as code isn’t stored as source files anymore. (“Programming is Modeling”, as the author of this article mentioned.)
“I challenge you, however, to name a single programming language mechanism that supports change.”
This is exactly the problem I was trying to find an answer to, which is how I ended up at LOP.
http://whathecode.wordpress.com/2010/11/19/language-oriented-programming/
Comment by Steven Jeuris — 2010/12/12 @ 17:31
There is a langage where the model is the code, Scade:
http://upload.wikimedia.org/wikipedia/commons/9/99/SCADE-cruise-control-design.png
Comment by nicolas — 2010/12/14 @ 12:25
1. There are class-oriented languages (java) and object-oriented languages (these are rare, javascript is an example). People mistakenly call them all object oriented, but that’s not really accurate. I would say OOP is about controlling objects and objects contain state and behaviour.
2. Yes, language beauty is in the eye of the beholder.
3. Think of class as short for classification. Objects are examples of their classification, not equal to their classification. Just like a rabbit is an example of an animal, not the definition of one. That is not a hard concept to get.
4. Based on your complaints, I think you really mean functions as well. So ok, everything is a top to bottom script in your world. Best of luck with no code-reuse.
7. OOP has documented idioms called Design Patterns. You can argue that they are over-hyped and prone to zealotry. But remember that all programming styles have idioms.
5,6,8,9,10 All of these are orthogonal to OOP
Comment by Tim — 2010/12/15 @ 04:12
Dijkstra was wrong, object-oriented programming was invented in Norway by Kristen Nygaard in the early 1960′s with the SIMULA programming language.
Nygaard drew his inspiration from Marxist ideology and regarded OOP as a means of advancing socialism through the medium of computer programming. The theoretical underpinning of OOP is the philosophical foundation of Marxism, so if you want to understand what OOP is, study dialectical materialism.
And if you want to understand what is wrong with OOP, study what is wrong with Marxism. If you travel far enough down that road you will find that Marxism is ultimately rooted in Kantian subjectivism. This explains why OOP is essentially anti-conceptual in nature.
The Marxist means of forming abstractions is characteristically model building rather than concept formation. Models are related to reality by means of an approximate similarity relation. Reality is conceived as having no definite nature and always being in a state of flux.
Concepts on the other hand, are related to reality by means of an identity relation, with the assumption that reality has a definite nature that determines and delimits cause and effect.
The architectural efficiency of models vs. concepts is different. Models break down when scaled up in complexity due to the cumulative effects of not being exactly mapped to the things that they are supposed to model, sort of like the logical equivalent of what happens with round-off error in floating point calculations when carried beyond certain limits.
This means that as the world’s software infrastructure increases in complexity there is increasing pressure to move from model building to concept formation, and from information hiding toward information visibility and organization. There is thus a fundamental shift emerging in the principles of integration used in building complex systems. The future belongs to concepts because nothing else can do the job.
Comment by Tim Lee — 2011/01/06 @ 22:35
The object-oriented paradigm is frustrating to understand due to its essential nature as an arbitrary system of anti-concepts.
It is helpful to consider another such arbitrary system, this one from the field of economics. It too is a system of thought constructed according to the subjectivist model building approach of Kantian philosophy.
Here’s what an economist said about this type of thinking: “In the final analysis, however, Keynesian theory is a set of mutually reinforcing but jointly unsupportable propositions about how certain macroeconomic aggregates are related to one another. Keynesian policy is a set of self-justifying policy prescriptions.” — from “The Trouble With Keynes” by Roger W. Garrison.
The object-oriented paradigm is also a set of mutually reinforcing but jointly unsupportable propositions about how software should be designed. It is an elaborate castle in the air.
The object-oriented theory does not start from the objective nature of computers and the human mind, and then build accordingly from there, rather, it is fantastic wish-fulfillment projection originating in the mind of a subjectivist.
That is why, for example, it is so important to the object-oriented theorist to hide information, raising information hiding to the status of a “principle”. Information must be hidden and protected against because natural reality is the enemy of those who crave the arbitrary. The object-oriented paradigm is inherently nihilistic due to its origin in subjectivist philosophy.
See “Introduction to Objectivist Epistemology” by Ayn Rand for an analysis of what is wrong with Kant’s philosophy.
Comment by Tim Lee — 2011/01/22 @ 21:36
Is there a language, where the model is the code?
What is Scade?
What about UML?
What is the difference between model and code?
Is model something graphical and code something textual? Or is any formal representation of the real world a model, somehow?
You hate OOP? – I love this discussion!
Comment by Siegfried — 2011/01/25 @ 14:43
I agree with you but I love OOP too, I enjoyed reading this post, incredible, over March of 2011 and yet we have a lot of doubts about the effectiveness of OOP.
Close to the natural language? did you make the base class library?, How it is possible to understand it? OOP is like a trick or an artifact to programing computers, but tomorrow everything will be decorated with [_ ] =>;
beautiful.
First, human understanding, readability, please.
Comment by Fernn — 2011/03/11 @ 03:12
When we programmed in assembler, we used OOP. We didn’t call it that and we didn’t have any support from the assembler, but we thought of the data records as being “things” with their own existence as units and we knew that various subroutines had no sensible function when called with the “wrong” data on the stack (or being pointed at). One common type of subroutine was one that made a copy of an existing object in memory.
Object oriented programming is actually quite a natural way of working and eventually someone started writing languages that helped with the process, in particular memory handling. Essentially, we ask the language to enforce the rules that we once enforced on ourselves to try to keep the complexity down.
Thing is, of course, no one really agrees on where the line is between “helping” and “suffocating”.
These days, when I programme for fun, I use Forth and build the OOP features I need for the task at hand (or just for the sake of trying different ideas) using the language’s language-defining features. Generally I end up with something much more like Smalltalk rather than C++, so perhaps I should make a serious effort to learn Smalltalk at last.
Much as I admire Dijkstra, he suffered badly from Ivory-Tower syndrome hating anything that made computing practical if it cost anything in rigour. But my clients at work want functionality and they don’t have a government grant to pay for years of conferences and hotels and meetings and formal proofs. They want to take an on-line booking for their training courses and they want to do it this month.
Dijkstra’s bad-tempered complaints about saving Computer Science from itself was the product of never having to actually do it in the real world. Sometimes being correct is not the same as being right.
Comment by Thomas Worthington — 2011/04/30 @ 00:09
Do you have what it takes to survive a software zombie apocalypse?
Worst-case Scenario: The news reports an object-oriented programming infection.
What do you do?
A) Run.
B) Fire all the engineers with Scandinavian last names, just to be sure.
C) Stock up on quinine tablets, memory maps, beef jerky, and a copy of “CMOS Cookbook”.
D) All of the above.
Wait a minute, wait…
Here comes an OOP zombie right NOW!
The hands are outstretched, the eyes… empty sockets…
…it shambles right into your cubicle, opens up its maw and moans:
“MuSt… dEsTRoy gLoBalS… Encapsulate::Everything… BRAINS! GIVE ME BRAINNNSSSS!”
[FADE TO OPAQUE]
SNAKE PLISKEN (V.O.) “We saw this coming back in ’87. No one took it seriously.”
– George Butler
Comment by George Butler — 2011/05/08 @ 19:27
Great article.
And you are just touching the surface. You need to dig for the creators of OOP. You will be very surprised to see what people love now. Was nothing to do with OOP today. In fact their goal was to make complex systems. And they needed a better way to deal with variable scope. The whole idea of hiding information is actually pretty silly. Why hide information if it really just needs to be in the right place. Who are we protecting and what is the price we pay for it?
We really need some fresh ideas in this profession.
Comment by Arturo Hernandez — 2011/06/30 @ 07:33
- [...] reflect the truth behind OOP. This reflects a slight change from his previous blog on that topic (Ten Things I Hate About Object-Oriented Programming): Oscar now agrees Object-Orientation is indeed a paradigm. I buy Oscar’s claim that the [...]
Pingback by TOOLS Europe 2011 – Day 1 — The JOT Blog — 2011/08/04 @ 17:55
Let’s simplify this … low-level languages > high-level.
OOP is dead.
Let’s move on.
Comment by Andy Harglesis — 2011/11/10 @ 05:27
I think the O-O idea is actually pretty good.
What went wrong was giving the development to ins… consulting companies that sell tools.
That directed the whole development towards selling features instead of working base.
The worst thing is trials of mathematization of O-O:
One of the basic rules that makes math work is “two sets are identical if their elements are the same!”. That means: The female presidents of United States are flying cows (both sets are empy). Design a class (object) structure of that.
Obviously O-O is based concepts – that is: on language.
Comment by Turboscrew — 2011/12/13 @ 13:50
- [...] But let’s dissect OOP from a pure abstract view (courtesy of The JOT Blog): [...]
Pingback by What’s Wrong with OOP? « Linux Philippines — 2012/01/03 @ 10:04
I think only frustration not understanding the “true” oop let you write this rant. Without OOP is chaos. Procedural programming is chaos. OOP is abstraction, not everyone use/understand abstraction. Look at the software engineers and how they “love” mathematics. Soo… things in life are not that easy to understand…
Comment by adi — 2012/01/06 @ 23:56
The article from Kent Beck is the modern version of coding in the debugger from Minsky see http://c2.com/cgi/wiki?ProgrammingInTheDebugger (middle of the page)
being in context. ain’t nothing like it!
Comment by agumonkey — 2012/01/07 @ 00:11
Nice article. But I think that Smalltalk is the best OO language in the world.
I especially agree with your 4., 5. and 6. point. But they are especially true for C++ and Java but not so much for Ruby and C# and even less for Smalltalk.
I think what Alan Kay tried to do with Smalltalk (see http://himmele.blogspot.com/2010/11/alan-kay-on-object-oriented-programming.html) does not solely depend on the programming language.
…maybe we should all switch to Erlang :-).
Comment by Himmele — 2012/01/07 @ 00:51
Oscar, I just saw this via Hacker News. Thank you for explaining why I loathe doing OOP, in particular via section 3 on classes vs. objects; I no longer wonder whether I’m an idiot who just doesn’t have the mental capacity to “get it”. Oh, and I hope to return to functional programming (which is where I started thanks to APL — it’s not purely functional, but the purely functional part is what everyone likes).
Comment by Rohan Jayasekera — 2012/01/07 @ 02:23
Wrong: programs = functions + functions
Correct: programs = functions(functions(programs), functions(programs))
Comment by Dave — 2012/01/07 @ 04:32
I’ve seen some instances of OOP done really bad/wrong. I’ve also seen some projects where it’s been done so well, that the architecture is clear and understandable, and the code reads like a good book (for instance, see ns-3, written in C++).
Comment by Lalith Suresh — 2012/01/07 @ 23:37
OOP is a powerful strategy to go even further into the wrong direction. It is an attempt to represent complexity as a LEGO toy, quite the opposite of abstraction.
Even worse, the mixing of data and logic is orthogonal to functional programming. Due to the limited OOP possibilities in old-fashioned procedural languages, the programmer was forced to thing more thoroughly how to avoid complexity. But in OOP he can make objects instead and increase the amount of states and mutable data. Many people claim, OOP helps to handle the complexity, but I say it helps to increase it.
Comment by Nico Voss — 2012/03/24 @ 13:43
- [...] was going through this blog (rant about the things the author did not like in OOPS). It was an interesting post and i liked it [...]
Pingback by Can a programming paradigm be influenced by political philosophy? « ctrl+k+c — 2012/04/23 @ 19:00
Procedural:
Examine problem -> code solution
OOP:
Examine problem -> Create objects -> code solution
I’ve used c++, java, javascript, C#, ruby, scala, ada, modula-2, lisp, and F#. I can sort of see the hype of functional and modular languages, but for the life of me I can’t see what’s so exciting about object-oriented ones. Maybe it’s just the way my brain is wired but I personally love the procedural way of doing it. The best programs I have ever written were in C. And another thing I enjoy is using gotos.
Comment by Bob — 2012/05/24 @ 17:32
The myth of OO is that it’s better than procedural.
It simply isn’t. In fact OO is harder to learn and less productive than procedural, it’s LESS reusable, not more, it’s LESS easy to design, not more.
The only reason most programmers these days like OO is that they were raised with it and are used to it.
Good modularized procedural programming if faster, more agile, easier to code, easier to maintain, and easier to extend. And much, much, much lower learning curve.
The only reason OO become popular is that it was a fad that caught on, and it allowed programmers to make their work more convoluted and more complex, so they could derive higher billing rates and more job security.
I say all these things as somebody who spent 10 years writing huge procedural-based programs, which were very well organized, highly proceduralized and modularized, etc. Then I took 10 years off to be a marketing drone. ThenI went back and started programming again…in Java and Objective-C. I am a hot OO programmer now, fine. It works fine. But it’s absolutely not one iota better.
I do have to laugh when younger programmers who have never written large procedural applications tell me:
“oh, but procedural programming is so hard, so messy, so difficult to maintain.”
and I say: “no, not if you design your sub-procedures and custom functions properly. They serve exactly the same function as objects.”
then the poor little OO guys say :”oh, but that’s a lot of up-front design.”
and I say “Yes, just like OO is a lot of up-front design. NO DIFFERENCE WHATSOEVER”
Except as noted before: OO has a much larger layer of bull**** terminology slathered on top, and a lot of new “features” like inheritance, which really are absurdly useless in the real-world programming. As a programmer one must spend more time wallowing through all this *** before doing the work.
Comment by Tom B — 2012/06/17 @ 16:50
OOP is for sociopaths, procedural is for empaths.
OOP is like a literary novel, procedural is math/science
if you ever had to fix someone’s OOP code…ugh.
I find the vast majority of ‘experienced’ programmers are copy/pasters and are not that good…and all of them seem to be OOPers.
I am pretty sure windows is OOP, which explains why it gets more fluffy and less ‘fixed’ with each version.
Comment by bob — 2012/06/21 @ 15:33
You don’t really understand OOP. Most of your points are irrelevant.
Comment by Nissim levy — 2012/07/02 @ 00:39
OOP is just a complex way of doing code that today’s Basics like PureBasic and various others can do with a few lines of code. Programmers love to jump on a new band wagon, gives them an excuse for not finishing projects in Basic or some other equally easy language , they started and lost track or direction in.
I hate OOP, its over bearing, the reuse code ability it claims to have exclusive rights too is total BullS**t, and the coding rules it uses just slows down coding and it hurts creativity. You still have to add lines of encapsulating code,just to reuse anything.
A simple call to a Print statement in Basic to produce a Print “Hello world” takes on a whole new world of hurt in OOP.
To me, and this is just my opinion, Its Freakin stupid .
It is the programmers fault that languages like Purebasic are not getting the press they deserves.
Basic is not dead, its just out of the main stream headlines. And because most are procedural , some dumb programmers think they are toy languages. yea right, better get skooled.
And today’s Basics are fast as hell, almost all compile to native code and produce an EXE, or whatever it is Mac’s run (prg’s?) .
Hell Purebasic supports Mac, Linux and Windows and you can write any type of program with it!. It supports all APIs and if its not in there, you can make a Procedure and create it yourself. Remember Procedures?, god I love em!. Or create your own library, in any language you want, Pure doesnt mind. It loves all Libraries.
With built in 3D graphics, Sprites, both 2D and 3D, OpenGL and DirectX, Sound,Midi, Music,Menus, Gadgets, Internet support, Types, Structures, Libraries, inline assembly, and over 1000 commands, whats not to like?
Look at Blitz Basic for example, more shareware games have been written in it than any other language and its not OOP.
Only problem I have recommending it (Blitz), is the lack of updates lately. Now Blitzmax is kinda OOP, but not so much that a programmer gets lost in the code.
So yes, I’m tired of lazy programmers tryin to force OOP on the world. get some balls and learn how to program like a real boy. You bunch of wooden headed dolls!, jk
GO BASIC!!!
Comment by Ken — 2012/07/07 @ 17:27
Object oriented programming, to me, is a joke!!.
Ok, lets pile on more complicated commands, brackets, terminators, constructors, Methods((Functions), Procedures), inside of other Procedures (classes),and inside of more procedure calls(constructors). Yea, that looks like really readable code now!!.
I dare anyone to take anything beyond a simple Class, and try to deconstruct it, as in, tell someone step by step whats going on. Good luck!. Bet you don’t get past why it has to have a main section or it will not run.
I program in Purebasic, one of the few languages that didn’t fall victim to the mighty OOP buzz word stampede.
It uses Procedures!.,Yes, it has Structures, Types, can make API calls, and other fancy bits, but its highly readable, and it compiles out to an EXE for Windows Systems. a PRG for Macs, ( I think its PRG, dont own a mac, anymore so not used to their tags).
The point being, it is a modern language, powerful, can make any type of program you can think of, is fast as hell, and no OOP insight, Thank God!.
And yes, I can do, Java, Actionscript 3, Html5, C#, C++. But too me, its like painting a picture with a lions tail, while its still attached to the lion!.
Me,I’d rather use a real paint brush, one with plain ol’ procedural calls.
Nothing wrong with Basic these days, just something really wrong with today’s programmers.
Some of you believe your own hype!. Most cant even get past the “hello world”tutorial starter program that comes with most languages.
Yet you all run around quoting OOP buzz words, I assume , in a failed attempt at looking intelligent. It doesn’t work!., Us real programmers, those of us that have sold products written in Basic, regular C, Modula, Forth Assembler or some other OOP lacking language know the truth!. So stop it!!, please?,
All you are doing is ruining the future of programming and piling more crap on the fire.
Reminds me of some guys I knew that bought the Game Genie for the old Nintendo back in the day. They used to brag about beating a game when in fact it was the Game Genie that did it for them.
Same with OOP,. Most don’t even understand it, they just use it because they have been told its the latest!, greatest!, … its not!!
And before you think I’m just some crazy nut from the 80′s, well I am, I have programmed Atari 8 bits (when I was a teen), Atari STs, Amigas, Intel based computers and others, in almost every language invented, Ever done a game in forth? I have. Ever programmed in a language called Action on an Atari 800 on a hot summer night while drinking a beer, then release a game that thousands played? , I have!
Ever worked on a bit of assembly code so long that you later dreamed in binary? I ha…… well you get it!
So stop hiding behind classes, methods, constuctors and all that other OOP mess and man the hell up!!
Real programmers dont need OOP!!!,
All we need is a good IDE, some killer graphics code, a woman that understands late hours in the glow of a monitor, and a beer, later all!
Comment by Ken — 2012/07/08 @ 16:12
You should go for javascript, Its the language of the Web.
Comment by Eick Brandr — 2012/07/20 @ 02:19
It seems to me
Procedural programmers do not like OOP because they do not understand it.
OOP programmers do not write good OOP because they do not properly understand the ‘golden rules’ of it.
Many OOP programmers do not plan their code – at all.
Both styles can create perfectly good code. Personally (horses for courses) OOP suits the line of work I am in.
Comment by Anthony — 2012/07/24 @ 18:03
100/100
When I started OO programming, I have faced problems. After 12 years, I will say, I am still facing the same problems.
And the problem is nothing but OOP itself!
Comment by Srinivas Nayak — 2012/08/21 @ 13:53
Hey dude, I like your article…
But dont you think you should give examples for every point you write here. So that every ponit will look relevant and easy to understand.
Comment by nanda — 2012/08/30 @ 17:26
I wonder if anyone has considered that our tools for what we are building (languages are TOOLS people. yes. that’s right. they are tools to build something. a means to an end. not THE end) are so extremely primitive, that there’s no point in arguing which “paradigm” is better? We are basically neolithic humanoids twirling a stick in the mud and calling it writing. Except our stick and mud are java and c++ and ides and frameworks etc. We don’t even know what the metaphorical “lever” is in the world of IT (much less what a “wheel” is.. there is no wheel to reinvent because we aren’t at a point where we can standardize something “round” and “useful” and standard)
Comment by ha — 2012/09/13 @ 01:32
- [...] Ten Things I Hate About OOP [...]
Pingback by The Object Cube | The soft nature of software — 2012/09/19 @ 18:34
I tend to agree with Ken about OOP. Summing the above, the problems seem to concern extant implementations, and development tools that impede more than they help.
Java and its various IDEs are a particular obstacle to stable and reliable applications. The desire by vendors to support multiple jars with classes that do much the same thing -but with small variations- is a general cause of stress alopecia.
Languages such as Python, wherein mere source indentation replaces explicit punctuation, are not advances. As the DB guy said, languages which attempt to “be all things to all men” in re DB interfaces cause problems. When a DB vendor publishes an interface, a language designer should just use it and move on.
Lastly, there’s too much academic Computer Science thinking. In the real world, people deal every day in filthy lucre that’s only used with a set precision. Every language should have a ‘money class’ and ‘money object’ that can be declared and used with a standard and predictable rounding method that doesn’t depend on the hardware being used.
Comment by Yeah Sure — 2012/11/19 @ 00:23
Well well well …. use python …
Comment by Scaringella — 2013/03/18 @ 17:21
There will never be a single, great programming language or construct, for one reason. People.
It’s not the fault of the language that people use it differently, its because people think differently.
I myself am highly logical and it is reflected in my code – very small amounts of code in the right places doing lots of work.
When I look at most other peoples code, I simply cannot see how they thought what they were doing made any sense. But to them, it obviously made all the sense in the world. Conversely, other people sometimes have difficulty grasping my code.
That isn’t the fault of the language – actually, its not a fault at all, its just the way things are.
Comment by Rodney Barbati — 2013/04/05 @ 18:44
You sound like you love OOP, but hate most of the popular implementations. Join the club. Types aren’t fundamental to OOP, nor is bashing another guy’s language (I don’t even understand why that’s on this list). Nor are classes. Nor inheritance. In your 6th argument, you’re not even complaining about OOP, but about every programming language I’ve ever seen. Context sounds great, but it’s certainly not mutually exclusive with OOP.
Don’t hate OOP for the languages that do it wrong.
Comment by weberc2 — 2013/05/31 @ 17:44
I’d like to point to my PhD research on the (mathematical) meaning of (nominally-typed) OOP (eg, Java, C#, C++, Scala, etc). The official copy of my PhD thesis is available at scholarship.rice.edu/handle/1911/70199, a more polished version of which was recently published as a book (http://www.amazon.com/dp/3639512812/).
Chapter 2 of the book (and the thesis, but in less-polished form) discusses and presents OOP concepts and what “the essence” of OOP is. The discussion in that chapter is more oriented towards developers than researchers.
Comment by Moez AbdelGawad — 2013/06/20 @ 21:43
Nice post but doesn’t agree all you are saying. It is a good thing to create some structure in the code and avoid duplicated code. Creating code is not similar to ‘hacking’, it might be easy to insert some code, copy some and change it a bit, you will get soup at the end of years. After these years you cannot easily change it when it is huge (mostly it huge).
The stupidity of OOP is that everything must be a class these days. To make it more complex, each class has it’s own file even when it is just a couple of lines. And, some prefer name spaces, 10 levels deep because it is a cool thing. Some people also use classes for unique things like constants, it is class abuse. constants needs to be defines or consts not classes because when it is a class (or an array) it can be changed!
The cool thing of OOP is that you can inherit it and it is meant to inherit. You don’t need it for simple things. I have seen a script from Microsoft that extends the Javascript API (they wanted to add some new rules can’t remember what it actually was) but it was very complex to arhieve the same effect, I need just 4 lines of code (they needed with their example 20 lines or such).
That’s the stupidity of these days, not everything has to be class because somebody or company tells you so. It makes simple things more complex, it is stupid! It is like the abuse of exceptions, same story, the abuse of namespaces, interfaces, packages etc.
It seems to be cool to understand the difficult thing, it has nothing to do with being a good programmer. Like you said, not a programmer but a modeller.
Over the years I use classes also but when it can be a general thing I will use/create a function that can be used inside a class. Working like this, you will have a library with functions that extends the language’s core functions (for example to read a file) and some classes that extends the functionality you need. At the end you will get: Standarized code, great extension to the core functions and less bloated/compact classes and easy to fix when there is a problem. At the long run it will be rock solid.
Use classes only when you need it, not always.
Comment by Erwinus — 2013/08/20 @ 05:08
There are two types of programmers – those that understand and use OOP and then there are those that don’t. The latter are quick to criticise but not so quick to shut up and learn something useful. You rarely find OOP guys criticising the procedural programmers (whats the point really). I am sure that most good OOP programmers have thought to themselves at some point in time “What is all this stuff about? Why am I bothering?”. Then that hallelujah moment happens and it all slots into place in your mind and you never want to go back. Its a bit like learning to ride a bike – you can’t really tell someone how to do it – they have to figure it out for themselves. I can’t even think about code unless its objects nowadays. It doesn’t help that a lot of the OOP texts and articles out there do a truelly awful job of explaining it and I’m not surprised when people just give up and go back to “safe” procedures.
I very important thing is that bad code is bad code regardless of the style or techniques used and for the most part the bad coders use procedural coding because if they were any good they would have moved to OOP already. Thats not to say that there has been some awful code written in C++ Java and Delphi.
There is one GREAT language – C#.
Comment by Tim Black — 2013/12/02 @ 16:00
Seriously Tim?
“bad coders use procedural coding because because if they were any good they would move on to OOP?”
That made me laugh so hard,
look dude,
I know how to code in Classes, Methods, Attributes, types,lists, maps, ect.
Accessing things that with one function or Procedure and an Array, I could do way easier and without referencing every damn thing the class has so I can find out what I have to input just to get a result back.
Look at the Procedure PrintFunny(funny$)
Not hard to understand is it?
You input string$ funny$ as in
Print(“funny this guy thinks we are all stupid!”)
and something funny gets printed.
You can find out what string to input by looking up the procedure in a procedure list , usually on the right side that comes with most Procedural IDEs,
like Purebasic, Blitzbasic , Fastbasic, Powerbasic, Euphoria, AGK ect, Darkbasic , Javascript to a degree with RJ textED.
All very powerful languages and most capable of producing anything a class based language can.
So dont treat us procedural guys as dumb asses, we are not!
We prefer knowing what our code it up too,
Instead of blindly hoping the class we are referencing in some giant set of classes elsewhere will do what we want.
And that we have input all the attributes so the class does not go batshit crazy on us.
I can program in Java, Javascript(which I do), C# , C++, assembly languages dating back to the 6502, 68000 (Amiga and ST) ,and 386.
So do not ever treat me or any other programmer as some fool you can point and laugh at because we don’t use the same club to kill our prey as you do.
We like looking up procedures and finding out what is inside, we like simple calls to functions that don’t require a PHD in computer science to decode.
We like procedures!
Now run along and program in that OOP language I’m sure you use , that you have never even gotten past the “hello world” class in!
We’ll stick to procedures and Functions, (samething)!
And before you act as if we could never write any programs without your precious classes?
Tell me then, how did all those guys, (me included) sell software back in the late 80′s early 90s with just our bare hands and a procedural language?
Guess we are better than you, cause we used what in your opinion is a caveman’s language to make some of the best software and video games ever made.
Sure your heard of Pacman?, Donkey Kong?, Mr.Do?, Mario? all done without the use of Classes.
thank you for your time!.
Comment by the Ken — 2014/02/13 @ 19:24
“I can't even think about code unless its objects nowadays.”
I’m sorry for you Tim!
I don’t have a problem with OOP per se, I have a problem with programmers who can think about code in one way only.
Sometimes OOP is the right abstraction, but more often it is not.
You think C# is great? Compared to F# it looks like a toy language!
You can use patterns, I can abstract them away. You can’t do that because your language and your mindset is too limited.
Comment by Jürgen Heiling — 2014/05/03 @ 16:06
It’s not just object-oriented code, it’s everything beyond straight C. If you think about it you have very few things in programming. You have memory, and you have the executable code that works on that memory. C is a worthy invention b/c it abstracts away the various assembly languages out there. But beyond this everything else is unnecessarily complicated, yet we are told it will make our life easier. There was a time when people viewed programming as a way to make a machine do something useful in the world. Now it seems people have lost touch with that simple idea. The only reason other languages have become the norm is b/c they have large standard libraries meant to enhance productivity. Has nothing to do with paradigms.
Comment by Bob — 2014/06/17 @ 18:55
Obviously there are some extreme views on the list, but I have to say I have struggled with the OO concepts for years now.
I stated in Basic then went to Cobol and used a 4GL called PowerHouse (from Cognos). I like to think I was a pretty good programmer and could do most things. PowerHouse had a CRUD generator which meant providing the DB was right you could have a fully working system within literally 10 minutes, doing CRUD functionality with automatic validation of field types. Of course the limitation was that there were boundaries on what you could do, but that wasn’t such bad thing, this encouraged easy to read code and simple debugging.
I started using Java and then C# and I couldn’t believe what a huge step backwards this was in development. I had to write stacks of code to do the most simple things. There were no direct access to a DB, you had to write SQL Select statements in the code!
I still tinker with C#, mainly Aspx, but I have never really got my head around OO. It is just too abstract from real coding. In general, you input something, process and output it. You don’t create a copy of a class and extend it.
Someone in this chain put the Car class and inheritance as a real world example. To me that’s exactly the problem, that is a physical example of something that you never program. I would prefer a real world programming example. So input something, write it to a DB and send something to a printer. I have never used inheritance as I never see the value in it. If I have a printer class and I want to add a new print function, in reality I need to edit the printer class and add it. Otherwise I am making a dependant piece of code that someone else might end up duplicating as its not in the original class.
Anyway that’s my 2 pence worth
Comment by Richard Barker — 2014/06/26 @ 15:38
1. Isn’t Programming is Modeling a valid paradigm? Do you have any exposure to domain-driven design? Modeling is one of at least three basic survival skill for software developers.
2. The theme here seems to be that the language is responsible for its own misuse by developers. No language, however well designed for change, is ever going to be a substitute for discipline and maturity of the programmer who wields it. It will always be possible to create abominations in any programming language, including all those you didn’t mention (i.e., non-OO languages).
3. The answer to your question is: architectural blueprints. They are of course a physical entity, they exist, but the only really purpose they serve is to help one construct, or understand the construction of, buildings and other structures. I recommend looking at Scala, it supports working with both objects and classes.
4. As long as methods are designed according to well understood principles (OCP, LSP, ISP, SRP, etc.) then there is no reason you should have to understand the whole in order to enhance or extend a part. A tool (IDE) is not going to protect untrained developers from creating abominations. Again, point the finger in the direction it belongs: the developer. If they don’t understand and follow patterns and principles, then they deserve the big ball of mud they’re going to end up with.
5. If you are having to use RTTI to get the job done then you haven’t thought through your domain well enough. The LSP says (essentially) that an instance of a derived class must be usable anywhere an instance of the base class may be used, without any side-effects or type-sensitive processing (RTTI), Types are not inherently evil. Developers who don’t understand their domain are.
6. “the programs we write break immediately if their context changes” Exactly! The programs we right. Don’t try to transform responsibility for building into the design the required flexibility into some omnipotent tool that is going to save your from your own lack of foresight. Tools are NEVER going to save you. Grow up and take responsibility for your own failure to follow well-understood patterns and principles. If it’s tough to refactor, it’s because you wrote it that way. Don’t blame the tool or the language.
7. BS. Written as one who has probably gone overboard applying patterns where they do not make sense. If you’ve actually read the GoF or any other decent design patterns book, you’ll note that patterns are defined in the context of a specific problem they are meant to solve. If you have a hammer, not everything is nail. As a case in point, how many Singletons were in your last project? If you answered more than say two or three, then you do not understand that pattern nor likely any others. If by “make your code more complicated” you mean make it more articulate, make it match the domain better, make it easier to understand and extend, then yes I agree. If you do not understand the principles behind them you cannot apply patterns correctly.
8. Suck it up. Unless you’re a cowboy coding in your Mom’s basement, you are going to get involved in methodologies. There is going to be traceability, responsibility, reporting, schedules, (oh my!). Methodologies have NOTHING to do with whether or not quality software (OO or not) gets written. Stop externalizing your angst.
9. UML is useful because it is an abstraction that doesn’t crash. I do not think that the way we write complex software today is a sustainable model. They are already getting too big, too complicated. What is need much more than a new language or new tool, is a useful abstraction above writing the code that we write today. How many times have you written a loop that iterates over a collection (for, while, foreach, whatever)? Doesn’t it make you angry? It should. We are so mired in arguments about semi-colons and braces, that we are completely failing the see the train wreck that awaits us at the end of this tunnel.
10. I fail to understand the argument here, I do think that Objects are not the end-all, be-all solution to software development. But I do think that there are cases where their application makes perfect sense…in the hands of a mature, trained developer.
Conclusion
Tools and languages are no substitute for a well trained, mature developer who understands the underlying principles on which ALL software is written. Don’t depend on tools and languages as crutch, to take over responsibility for doing things right. Either that, or invent the next layer of abstractions that obsoletes all discussion of execution models, language paradigms, etc. But stop whining about OO. It doesn’t deserve it.
Comment by Loren Erickson — 2014/07/25 @ 00:26
In early-days, only simple programs like add-amount-to-account or remove-an-account or calculate-interest or backup-tape was written in LOTUS/COBOL/BASIC. So Procedural programming was enough for those days.
In today’s world it gets more complex. General public (billions of users) are using a website (Facebook?). For instance, a credit card has complex-calculations/limits/offers/conversion-rates/etc. For this we need multiple classes/interfaces defining the behavior and business-logic. That demands OOP.
People have lots of criteria to choose/buy products. That make them ask for
product-x, (product.name)
price-y, (product.price)
quantity-q, (product.quantity)
brand-z, (product.brandid) (brand.name)
delivered-in-n-days, (shoppingcart.deliveryType)
billed-to-a, (shoppingcart.billingdetails)
delivered-to-b, (shoppingcart.shippingdetails)
+ apply my offer-coupon-code-xyz. (shoppingcart.coupon)
That needs OOP. isn’t it?
Comment by Arun — 2014/08/23 @ 20:36
In a procedural environment, how would you represents concepts such as an invoice, a file on the filesystem, UI buttons or even a string?
Oh right! A data structure with functions to manipulate it! That sounds awfully object-oriented to me…
If the above statement doesn’t make sense to you, chance are you don’t understand OO.
Object-orientation is a paradigm–not a language feature.
Comment by J-F Bilodeau — 2014/09/06 @ 01:42
Some of the biggest messes I have seen have been people taking OO too far. Too many objects, too many “nifty” techniques. As a logical concept it is great. Especially encapsulation and organization/categorization of the logic into black boxes and such. But, you do not need objects to effectively do that all the time. OO implementations often gets bogged down in too many objects, properties, methods and other things. For example, I have seen many crap developers put way too much functionality and logic into constructors so that all sorts of things magically happen when you simply declare objects and leave a freaking mess to try to understand them and what is going on in the areas using them. Same with too many events or too much inheritance. Done wrong it can make a system too rigid to where people do not want to modify things because they got too difficult to work with. The concepts of the benefits of it and the use of reasonable objects where they make sense are the good points. It is a technique… but sometimes some focus on the technique more than the functionality, readability, and final solution and just make a freaking mess. Sometimes developers go way too far into objects and tiers that they just make an overly complicated mess for the actual need at hand. The better systems I have worked on have featured a mix of traditional and object oriented techniques. Use the right tool and technique for the job via a weighing of pros and cons. But using OO over not does not automatically make an OO solution better, not by a long shot. Build with objects or object-like principles when they help you and are needed… but it certainly can be something where people take it too far.
Comment by JW — 2014/09/11 @ 19:18
Before I get mad and rant for thousands of characters, I’d like to know: How much do you actually program in the workspace???? Because there are quite a few things that I do daily that require objects…
Comment by Garzella — 2014/09/30 @ 02:53
A motivating discussion is worth comment. There’s no doubt that that you should write more about this issue, it may not be a
taboo subject but typically people don’t discuss such topics.
To the next! Cheers!!
Comment by diverse.unm.edu — 2014/10/09 @ 11:48
OOP is not scary but some concepts are harder to understand and very broad. Specially in UML there are many diagrams to represents 11 types almost, very confusing.
Regards,
Comment by Creately — 2014/10/17 @ 11:12
Procedural is a descendant of OO rather than the two being separate entities. Consider that functions or methods called in OO are ultimately granted a slice of processor pie and run procedurally until they terminate. It’s not too difficult to write a heavily recursive function that will crash the runtime and sometimes the host machine. That code can be ported almost as-is to a procedural language and achieve the same effect.
OO is a bootstrap for looped procedural programming. It comes at the cost of some control — we often don’t have access to the looping mechanism, memory management, etc. — but comes with convenience.
It’s true that OO’s structure can be messy but I would argue it’s no worse than tens of thousands of lines of crammed procedural code in one flat file (if you split it up into external includes you’re tacitly agreeing that OO structure makes sense). Either way, readable code is more a reflection of the developer rather than the programming paradigm they’re using.
As someone who cut their teeth on procedural I am reluctant to return unless there’s a compelling reason. I want to write useful code without spending my time re-inventing the wheel. It’s not bad to have a gander at the wheel once in a while to see if maybe it can be improved but if we did only that we’d never have created the countless wheel-bearing devices we have today. I believe the same can be said for OO.
Comment by Patrick — 2014/12/11 @ 18:35
I meant: “OO is a descendant of procedural…”
Comment by Patrick — 2014/12/11 @ 18:37
@Garzella: nothing you code requires “objects” unless you’re forced to work within an already-existing OO paradigm. Any program may be written without objects.
Comment by Dave Newton — 2014/12/12 @ 17:24
I think the obvious is missed here. OOL’s weren’t created for developers to code easily, but for machines to read, compile and organize the code and executables – and for IDE’s to help us reliably cobble together thousands of tiny pieces into a gazillion different puzzles. Why else would anyone write an “EventHandler” for a snippet which could easily be typed in a few characters of inline code? If we wrote “procedural” code we’d still have to deal with a library of a few thousand functions unless we wanted to re-code them each time. Over time the functions become words, the language grows and you need a reference to handle it. If you want to build an IDE, you need to structure the reference for quick access and before you know it you end up with something very like OOP – without necessarily exposing the object paradigm to the developer.
That said, I absolutely hate OOP for inherently procedural processing, which is most of what I find myself doing on a daily basis. That’s what scripts and procedural languages are for. Cranking up a full-fledged version of VS xxxx .NET to produce three webpages dealing with a few dozen data elements is like swatting a fly with a gold-plated toaster-oven; it works, but that oven gets a little heavy after a while and there are more appropriate tools to use. Sometimes the customer just wants that oven anyway, though. It’s just so-o-o-o shiny!!!
I am a structured-programming guy from the COBOL days – a discipline which could straighten out a lot of the object gobbledegook being produced lately. There is no incompatibility here. We work in hierarchical organizations, live in a hierarchical society, deal largely with hierarchical data, build hierarchical systems (hardware and software) and we should approach our code design with a similar methodology if we want it to be readable and maintainable – starting with the requirements phase. Structured programming is simply a hierarchical movement from General to Specific. However, it relies upon a similarly-structured methodology which starts with a general statement of the requirement and moves to the specifics of a user interface or back-end processing.
This rational methodology is what allows organizations to break problems into their component parts and to assign work to development teams which subsequently assign tasks to individual developers and analysts – with the goal of producing the best possible product in the shortest possible time.
Instead of widespread adoption of this, we increasingly see high-level managers and consultants choosing hardware and software products according to the latest street buzz and then trying to find some poor coding schmuck and his buddies to spend the next 12 months or more tied to a chair with his brain wired to a spaghetti network of 18 different language flavors-of-the month trying to make the whole disorganized contraption function with some semblance of order.
The results are usually somewhat less than stellar.
While I’m on the subject, the minute someone utters the words “The Cloud” he is forever marked a fool or charlatan to anyone with a smidgen of technical understanding.
A network of server farms, themselves a network of thousands of individual servers tied to mega-terabytes of very real electro-mechanical storage devices and housed in very real terrestrial installations collectively consuming enough electricity to power a mid-sized city can hardly be described as a fluffy cloud. It’s like calling a power plant “The Mist” or a brick a melody – or terror a country you can declare war upon.
“The Cloud” is a marketing masterpiece – and a societal diaster; an almost complete collective failure to come to terms with the realities of of our technical existence. It gives me nightmares even briefly contemplating a future with such people in positions of authority.
Ironically, this is the epitome of the object paradigm – give it a name, hide the details and expose the methods. The imaginary “Cloud” is a huge abstraction which people are content to treat not only as an actual object, but THE actual object – which bears little or no resemblance to the reality.
It’s analogous to the name “God” – he is who and what we say he is and he works in mysterious ways and he is good unless you are bad, in which case you will be punished.
(God, I hope The Cloud doesn’t decide to punish me for blasphemy or I am financially fxxxxd!)
The fault lies not with the paradigm, but with the widespread eagerness to choose the abstraction over the reality; to accept as truth that which they know to be untrue; to choose ignorance over knowledge and sophistry over their own sophistication.
Safety in numbers I guess.
Which brings one more name to mind: “Titanic.”
Comment by Just Another Steve — 2014/12/25 @ 03:55
The hardware we are dealing with is inherently procedural. It loads a program at a memory offset, executes from the beginning, and runs to the end.
The entire object paradigm is an abstract illusion of spinning wheels between start and end.
The stack and heap of various VMs are likewise abstract inventions which few machines actually implement in hardware.
ALL object-language programs can be therefore be written procedurally because that’s how the generic hardware operates.
All objects are translated into procedural code at some point, because that’s how the hardware works.
The question is: is the object paradigm the best way to implement our ideas – or would we be better off working with the reality, or a different paradigm?
Comment by Steve — 2015/01/07 @ 09:35
I use Gambas3 in GNU-Linux. Gambas3 is apparently OOP.
Interestingly I am not required to understand this in order to use it.
I write code for fun, hours a day and I love it.
If your programing language requires you to understand and explain OOP in order to use the language and to read their code manual then there is something seriously wrong.
OOP should be invisible to the programmer, like a function which they may use or may choose not to use.
Comment by Evan — 2015/03/30 @ 00:10
Steve’s says that once a program has loaded it “executes from the beginning and runs to the end”. That’s a bunch of baloney! Once a program is loaded it does only one thing: it enters the message loop. That's all there is to it. A program starts up and enters the message loop. And it stays in the message loop receiving an indeterminate amount of messages until the "terminate" message appears.
The OOP paradigm is perfectly natural. It is based on the way things work in the real world. Consider this: what is a person? Could you say that a person is an animal with two legs and two arms and a head? You could say that but you would be wrong. A "person" is an abstract idea.
That's the object-oriented paradigm. Nothing is real. You need to refactor whatever it is you may think about the world around you. You will find that the object-oriented methodology of inheritance is the keystone. Twenty years ago programmers understood that. Today there are people claiming that interfaces and method overloading provide polymorphism. That's nonsense. Two methods sharing a name while receiving different parameters; what's polymorphic about that? Absolutely nothing! And interfaces are just collections of abstract methods; all they offer is a shared nomenclature! They don't do anything! It's hardly object-oriented and it's certainly not polymorphic! Inheritance is the foundation of the way it works. Polymorphism is the result. It is a cause and effect relationship.
Object oriented programming is founded in the way the natural world works.
Comment by Skats McDoogle — 2015/04/03 @ 20:17
I haven’t programmed anything for a long time, but when I did, it was procedural. OOP seemed to me just like a lot of faffing and dancing around whatever needed doing, instead of getting on and doing it.
At base, computing is just about something being added to something else. There is no getting away from that, and it is a procedure, and there is no point enveloping it in layers of unnecessary nonsense that seem to me just using a “sledgehammer to crack a nut”. Actually, a lot of sledgehammers, each inheriting a bit of the original sledgehammer… What is the point of that? Just use nutcrackers instead.
No wonder I gave up programming.
Comment by Keithy — 2015/04/04 @ 01:18
You seem to be displaying your own lack of understanding as weaknesses of OOP, I don’t blame as OOP is not clearly defined and there are so many different things called OOP that its easy to get confused, it took me a long time to finally put a definition to the magic word OOP.
1. I would say OOP is the paradigm where you program using objects as opposed to bytes (and other primitives) and pointers to memory. What is an object? An object is an abstraction over a block of bytes, instead of working with the bytes directly i.e. first byte = first field, second byte = second field, etc, (to access the second field you add 1 to the pointer to where the first byte is stored in memory) you can view this block of bytes as an object. An object is a high level abstraction allowing you to easily give meaning to a block of bytes which is specific to your problem domain. A simple example would be a rectangle object, the first byte in this object represents the length, the second byte represents the width. Methods are functions/procedures which are specialized to take rectangle objects as at least one of their input arguments (not “this/self” is actually implicitly the first argument, i.e. the method does not belong to the object) an example of a method would be an area method which calculates .. the area of the rectangle. The area method encapsulates the details of how the area is calculated (you don’t need to explicitly pass the rectangle dimensions to area) you call area with rect as the argument and it will calculate the area for you. Why is this encapsulation useful, lets say you decide to add triangle objects to your program, the formula for calculating triangle objects is different than that for rectangles what are you to do now? OOP makes this easy, you just add a area method for triangle objects (note this does not necessarily mean inheritance) and you can carry on using area same as you did for rectangles. I just defined polymorphism here, what I just said here are the fundamental principles of OOP and what do you know those principles are heavily used in Functional Programming and the likes, nowhere did I mention state or inheritance or mutability.
“The Myth of Reuse” You are right there is myth that using OOP means you automatically get reuse with no extra effort that is wrong, you do indeed get reuse if done properly but if not it becomes even worse than procedural code. “instead of developing your code from scratch, you can just inherit from existing code and extend it” Umm no, just no, I think you said that on purpose because you need to bash OOP and pretend you don’t know what is meant by reuse. Reuse means that once you develop a class you can use it in other projects, you don’t have to recode it, of course this is not automatic, the class has to be designed carefully such that it can be reused.
2. No comment, other than to say that different languages do OOP differently and you shouldn’t judge the paradigm based on how C++ or Java implement it, Objective C, SmallTalk and even Common Lisp do a much better job than Java or C++.
3. What are classes you ask? Classes are simply a description of a type of object, I already used classes to explain objects refer to my rectangle object. A rectangle object is an object which posses 2 properties (dimensions) the length property and width property. You are right classes exist only in our minds, in reality we only have bytes, bytes and pointers to bytes, so unless you really love programming in terms of bytes classes are your best friend (not even procedures exist they are merely addresses to the machine code in memory), A class simply tells the compiler/interpreter how a particular object is mapped from to memory and vice versa.
4. The sole confusion which arises from methods is that most OO languages group methods with a class and somehow give the illusion that methods belong to a class, with “this” being some magic entity which comes out of nowhere, when really a method is just a function/procedure with “this” as its first parameter identify which object, IMO Common Lisp does a good job of separating methods from classes. On another note if you want a runtime version of your program, get yourself an assembly debugger showing you each assembly instruction and the contents of each register,
5. I agree with you fully here, I prefer dynamic typing and would love for types to be optional. Most modern typing systems are incredibly lacking but I struggle to see what this has to do with OOP but rather languages in general.
7. I completely agree here as well, the first stage in any design should be prototyping to actually become aware of your problem and aware of what you actually need to do. Rushing into complex design patterns such as UML leads to unnecessary complexity.
Comment by Jay — 2015/05/17 @ 17:13
Tim Lee… you may be insane or absolutely brilliant. Either way, your description of marxism as it relates to materialism and OOP is positively fascinating.
Comment by Peter — 2015/06/04 @ 22:37
On 2015/01/07 at 09:35 Steve said…
The question is: is the object paradigm the best way to implement our ideas – or would we be better off working with the reality, or a different paradigm?
Well said, Steve.
Comment by Phil — 2015/06/05 @ 00:05
The funny thing is that; all the OOP languages were made using Procedural programming, not only but also all OS are made using Procedural programming too, but when it comes to users; they want you to use OOP, because this secures them.
OOP is just that they don’t want you to access there application, they just give you some parameters and you are allowed to use them only not more not less.
after all of these applications and programs nowadays, OOP now become useless, because you have to know and keep memorizing each parameter for each application, in other words “it is not real programming any more” it is like learning history.
Comment by Shahim Khlaifat — 2015/08/22 @ 13:09
Let me make my argument by dubunking this OOP abomination: http://www.csis.pace.edu/~bergin/patterns/ppoop.html
How is 83 lines of code across 7 different files more maintainable than 19 lines all in one place? Those software “engineers” can trace the logic of instantiations and registrations and invokations between files, but not those “unwieldy if statements!” that read EXACTLY like the problem they are describing? FOOEY BUCKETS!!
I love OOP where it’s appropriate, which is for modeling DATA and atomic operations on it; but it’s not even an appropriate model for behaviors on a SYSTEM of objects/data.
SO WHAT, that you’d have to change the code to add more ifs. With the OOP version, you’d still have to create or modify SOME code, and what does it matter if there is some “central” part that does not change, when you have to trace the execution to the part that you DO change anyway?
On the point of efficiency, there is no reason that a hash-table / map / dictionary could not be created inline at the top of the “hacker” code, and work just as efficiently (actually MORE so, since it would just be one instance instead of multiple class “singletons” being initialized at startup).
On the point of scalability & maintainability, these arguments hold up just as well for larger applications: ok, so there’d be more inline-procedural logic to understand, but which is easier to understand & maintain: the one that just SAYS WHAT IT DOES, or the one where the logic is scattered everywhere across multiple classes & files?
Maintainability & extensibility does NOT come from mechanisms, it comes from your code being understandable in terms of the HUMAN mental model of what it does. If one cannot look at the code and be able to see what the over-all INTENDED behavior is, then you end up with a ball of mud that’s hard to change because you cannot REASON about it, because it does NOT correlate nicely with the human (user) mental models that it’s supposedly supposed to fulfill.
If you want to maintain changes, then source-control does that nicely for you; especially if you can look at a change from direct-behavior A to direct-behavior B, rather than having to reverse engineer the whole thing to understand the ramifications of a small change on the whole system interactions woven between many classes.
This is a difficult topic, because the software industry has become a pop-culture obsessed with fads and patterns and languages, etc., rather than the HUMAN models that software is supposed to be. There is this is assumption that newer is better (newer languages, newer mechanisms, etc.), and that the “old guys” don’t understand OOP because it’s too advanced from their more primitive languages.
The real shame is that software people do not understand their own history, and think it’s unapplicable. Few software engineers are familiar with key figures such as Alan Kay, Doug Engelbart, John McCarthy, Christopher Alexander; but a physicist who is not familiar with the works of Newton, Tesla, Einstein, etc. would be dismissed from the field. In software, we don’t know and don’t care, because the modern trends surely are better than that foundational stuff that we abandoned (and we see the same ideas being reinvented every 20 years).
Furthermore, focusing on LANGUAGE is not going to get us anywhere, because if software was a true craft, then “language” would be as moldable as the software we use it on, and you could just “use” whatever paradigm you wanted. Instead, we have these pre-made un-changable languages & IDEs that have already decided on a base set of paradigms/tools for us to use to make programs, and you can built on TOP of them, but you cannot change the base. This is like how a carpenter cannot make his own tools out of wood because he needs METAL to shape the wood; but a metal-worker/smith could. We use software to shape software, so why are we still restricted by any specific language or tool?
Neither OOP nor functional nor any other language paradigm, nor testing nor TDD nor IDEs nor any other tools result in my software being “good” any more than a glossy cover, typesetting, and spell-checking will make for a good STORY. The software industry needs to start thinking about what makes a good STORY, not just a good “book” in the physical sense. Once that’s accomplished, then the languages, tools, etc. will follow suit to the extent that they can help with the BIG PICTURE.
My beef with OOP (or rather, how OOP is used) is that it’s much the opposite of what I just said above: people are so focused on the mechanisms and “architecture” within their code, that the actual resulting behavior is no longer the main concern. For example, the focus on which patterns are being used where, rather than on what is the best way to express the HUMAN model of behavior that is expected (it has to be expressed IN THOSE TERMS, or it’s not really understandable). Software “Patterns” came from Christopher Alexander’s “Pattern Language”, which failed in physical architecture for similar reasons.
Any who, if you look at where all the REALLY major advances in software came from, the focus was always on HUMAN concerns, not mechanism (Doug Engelbart’s NLS, Alan Kay’s Dynabook, etc). OOP and Patterns came out of this thought, but quickly diverged from it, and now we are dealing with the mess left behind. Jim Coplien sums that up here: http://www.infoq.com/interviews/coplien-dci-architecture
Comment by Dan — 2015/08/29 @ 22:40
As someone who learned structured programming in the 80s, and who is struggling to grasp the concepts of OOP in the 21st Century, I read this with great interest.
I learned to write structured programs. That is, we have a small, compact main loop that conditionally calls various subroutines.
Compared to this, OOP seems thus far to me–and I will admit I am still struggling to comprehend it–an unworkable, overdesigned hairball. “Objects,” “methods,” “constructors,” “events,” isn’t it all just blocks of code? Only they’re blocks of code that have been created as virtual widgets that interact in a standardized manner that makes the most trivial tasks almost impossible. It is inelegant. It adds layer upon layer upon layer of unneeded abstraction, layer upon layer upon layer of gingerbread and unneeded complexity to what should be a straightforward matter.
Perhaps I misunderstand, of course. I’m still struggling with the concepts.
Comment by Noah Baudie — 2015/09/22 @ 16:17
Learn LISP to get out from the swamp. Usually, it is not the paradigm that is bad, but the languages. Some languages are bloated and some language requires you to write boiler plate. For procedural language, I love C. For OO language, I love Python. For functional language, I love Scheme.
Comment by Alex Vong — 2015/12/20 @ 11:14
RSS feed for comments on this post. TrackBack URL
Leave a comment
Name (required)
Mail (will not be published) (required)
Website
Powered by WordPress
-
Subscribe:
-
Pages:
-
Categories:
-
Search:
-
Archives:
- June 2016
- April 2016
- August 2015
- April 2015
- March 2015
- September 2014
- July 2014
- June 2014
- August 2013
- June 2013
- January 2013
- October 2012
- August 2012
- April 2012
- January 2012
- December 2011
- August 2011
- July 2011
- April 2011
- March 2011
- January 2011
- November 2010
- October 2010
- September 2010
- August 2010
- July 2010
- June 2010
-
Meta:
[URL]: Universal Resource Locator [[RSS]: Really Simple Syndication [*XHTML]: eXtensible HyperText Markup Language [*RSS]: Really Simple Syndication