- I was tempted not to publish, for fear of the cry of the Boeotians, but decided that I should go ahead.
- I hope that advocates and critics alike will appreciate the content of this list.
- The eye-catching title may be misleading, I intend neither to praise nor criticise OOP, but to ask a question. How do you solve the problems associated with OOP?
- If advocates claim that OOP is perfect, and fail to even admit that there are problems, many problems, then the only people offering solutions are the critics, and so by default, they will win the day.
==================================================
OOP is somewhat overrated: collected quotes
==================================================
What's Wrong With Object-Oriented Programming?
https://www.yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html
Jeff Atwood (2007)
Your Code: OOP or POO?
"OO seems to bring at least as many problems to the table as it solves."
=====
Oscar Nierstrasz (2010)
Ten Things I Hate About Object-Oriented Programming
"OOP is about taming complexity through modeling, but we have not mastered this yet, possibly because we have difficulty distinguishing real and accidental complexity."
=====
Eric Allman (2011)
Programming Isn't Fun Any More
"I used to be enamored of object-oriented programming. I'm now finding myself leaning toward believing that it is a plot designed to destroy joy. The methodology looks clean and elegant at first, but when you actually get into real programs they rapidly turn into horrid messes."
=====
Asaf Shelly (2015)
Flaws of Object Oriented Modeling
"Reading an object oriented code you can't see the big picture and it is often impossible to review all the small functions that call the one function that you modified."
==================================================
[Richard Mansfield]
WhitePaperHasOOPFailed.pdf
http://4js.com/files/documents/products/genero/WhitePaperHasOOPFailed.pdf
OOP has taken over computer "science" departments to the exclusion of any alternative programming system. A generation of programmers has graduated from schools that teach only the OOP way, so that’s what they tend to prefer. It's really all they know. They memorize a set of “best practices” (abstract design rules) to help them grind out OOP without making too many mistakes. OOP can be effective to some extent during the initial design phase--when a program’s broad goals and large-scale structure is being imagined and sketched in. However, for day-do-day code writing, OOP is generally the single biggest obstacle to contemporary programmer productivity. Are results achieved faster? No, creating programs usually takes considerably longer than it does with more natural languages and more sensible approaches to modular design. Have bugs been reduced? No, they usually increase. Is program maintenance easier? No, OOP and C languages are notoriously counterintuitive and difficult to read.
==================================================
Is the object-oriented programming (OOP) paradigm overemphasized or overrated? - Quora
https://www.quora.com/Is-the-object-oriented-programming-OOP-paradigm-overemphasized-or-overrated
An important notion (that doesn't always apply, but seems to often fit) is the notion of the Hype cycle.
=====
Hype cycle - Wikipedia
https://en.wikipedia.org/wiki/Hype_cycle
=====
It wasn't as useful in handling naturally tabular data, which is why the OO databases remained a "niche" product and didn't supplant SQL databases (as many expected in the early 1990s or so).
=====
Some people tend to believe in this notion of a "silver bullet" - some concept that will revolutionize programming and remove all the annoyances in one fell swoop.
Such a thing will never happen... There is no one stop solution for all programming needs - no single language, paradigm, OS, or hardware architecture can replace everything else.
People who tout one paradigm over everything else lack maturity.
=====
I was an early adopter of C++ back in the 80's, and a strong believer in OO for a long time afterwards. I started to lose interest around 2000 or so, as it seemed like I was spending all my time thinking about the plumbing, and not on what I was trying to build. This timing also coincides with OOP's becoming more religion than paradigm, which I have little patience for.
==================================================
Why use OOP concepts anyway? - Quora
https://www.quora.com/Why-use-OOP-concepts-anyway
Look, I HATE IT when some architect imposes a forced OOP paradigm where it doesn’t fit. I hate it when we are forced to use MVC when nothing we’re doing is really a model, a view, or a controller.
==================================================
[UNCONVINCING]
[every one of these claims is doubtful]
[this 'pro' article is one of the best sources I've seen *against* OOP]
Object Oriented Programming
https://www.cs.drexel.edu/~introcs/Fa15/notes/06.1_OOP/Advantages.html?CurrentSlide=3
==================================================
[UNCONVINCING]
[not great either]
4 Benefits of Object-Oriented Programming | Robert Half
https://www.roberthalf.com/blog/salaries-and-skills/4-advantages-of-object-oriented-programming
==================================================
Goodbye, Object Oriented Programming – Charles Scalfani – Medium
https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53
1*cBFSQ9Ytv_D0jwGtpuL5WA.png
https://cdn-images-1.medium.com/max/1600/1*cBFSQ9Ytv_D0jwGtpuL5WA.png
=====
I was gung-ho to leverage the benefits of Inheritance, Encapsulation, and Polymorphism. The Three Pillars of the Paradigm.
I was eager to gain the promise of Reuse and leverage the wisdom gained by those who came before me in this new and exciting landscape.
I couldn’t contain my excitement at the thought of mapping my real-world objects into their Classes and expected the whole world to fall neatly into place.
I couldn’t have been more wrong.
=====
But the real world is filled with Containment Hierarchies. A great example of a Containment Hierarchy is your socks. They are in a sock drawer which is contained in one drawer in your dresser which is contained in your bedroom which is contained in your house, etc.
=====
[comments from the comment section:]
=====
People told me I’d never get a job if I didn’t know COBOL. That was 35 years ago.
Needless to say they were wrong.
=====
Very well written article, and I totally agree. After 20 years in the industry, I’ve never seen an OO codebase that is sane, clear or realizes any of the supposed advantages of OO.
There’s another OO problem I think many of us face. In the class room you’ll have this aha! moment when you see that a Horse Class inherits from an Animal Class. You intuitively understand this relationship from prior knowledge in the real world, and you can see this OO thing working.
Then you get into the real world where you work with classes named “AbstractFactoryFucker” that implements an interface “ThingsIterator” that has no code yet is an Abstract class to “HolyGoddlyClass”. And this six levels deep. None of these objects are actual objects you can relate to or intuitively understand by their name, so instead you have to keep a mental model of the entire thing in your head.
Or, as one of my managers said after presenting my first OO web application over 10 years ago: that’s a lot of crap to execute a SQL query.
He was right.
=====
accidental complexity is always present in OOP and it hinders productivity as well as the ability of writing simple code that deals with the business problem we are trying to solve.
=====
Like I always say: The only thing the Majority has over the Minority is Cardinality.
=====
I read an article much like this a couple if years back when I was still doing and liking OO. My reaction then was a religious “NO, you are wrong. OO is great, you just don’t get it!”. I have grown smarter since then. Thanks for a great article
=====
Many have reacted this article the way you did to earlier articles. I suspect that if I had read this article 20 years ago, that I might disregard it as the ramblings of the misguided or incompetent.
To learn and improve, you have to be dissatisfied with your current situation. This usually doesn’t happen early in your career since you’re not responsible for a large complex system. You also haven’t banged your head against the wall long enough.
If you remain in this industry long enough you will do one of 3 things, leave, dig in or strive for excellence. Those who leave go into management. Those who dig in become legacy, maintenance programmers for the rest of their careers.
The rest of us continually search for better.
=====
Very well observed and so true — I’ve had a similar experience where all the theory learned in college that sounded great never really panned out in the corporate environment. The OO purists spends more time ironing out the complexity from the sheets of simplicity than actually getting work done, and it’s amazing how much more productive in practice functional programming has become. At the heart of the problem in most real-world organizations is that code reuse is a lie — we never get to reuse code so the over-architecture and headache has a huge upfront cost with rarely any payback. I’m sharing this my dev team.
=====
Agree with this article. Reuse is damn hard when we implement OOP.
==================================================
[Brian Will]
Object-Oriented Programming is Bad - YouTube
https://www.youtube.com/watch?v=QM1iUe6IofM
[03:43]
elegance, simplicity, flexibility, readability, maintainability, structure
...
object-oriented programming, and abstraction-heavy programming in general, fails to deliver them
[25:46]
the walls have been prematurely erected
[26:15]
absence of structure is more structured than bad structure
...
it's actually better to start out with a free-form absence of structure, rather than impose a structure
[29:22]
analysis paralysis
[32:59]
jump all around the code to find any line of logic
[43:51]
I can tell you from personal experience of having read these books, that you don't need to read them, they don't have answers, they're not going to square the circle, and you're going to waste productive years of your life trying to live up to their ideals
===
[comments from the comment section:]
===
Near the end of my degree program I got an internship where they handed me a 1.5 million line pile of C++ mess they'd bought and asked me to port it from MFC to an embedded Linux platform. Naturally, my first step was to try and make sense of it. I downloaded Doxygen and had it print out some class diagrams for me. I expected it to look something like the pretty UML charts from all of the toy examples they used in school. Instead it was just a giant wall of spaghetti with every class connected to every other class in no coherent order. At the time I thought the code was just poorly thought out.
After graduating and seeing more real world examples I've come to realize that all object-oriented code ends up looking like this. Encapsulation simply isn't possible. Even in my own code I've spent weeks in analysis paralysis, exactly as you've described in this video, trying to figure out how to refactor my code to adhere to all of the exalted OO design principles and reach that "loose coupling" holy grail. You DO end up with these really ugly trees of classes under "manager" and "controller" god objects and their sub-objects, even though all of the programming bibles out there proclaim it a sin. Without garbage collection you practically HAVE to do it this way anyway in order for destructor chains to make any sense at all.
The cleanest "OO" code that I've seen (and written) ends up taking all of the functionality out of the classes and simply using them as storage constructs to be passed as arguments to static/stateless methods.
The cruelest joke though in the four years since I've graduated is that I only seem to be able to get Java jobs where people are still in love with AbstractProxyFactoryBeanManagerServiceDeluxeWithCheese style programming. I end up having to just keep my heretic beliefs to myself and write the same boilerplate code as everybody else. Since Java 8 I even have to make all of my methods return the same Optional<Whatever> objects since these people have forgotten how computer memory works and need such nightlights to ward off all of the big scary null pointer exceptions.
What kind of hell is this!?
==================================================
[Brian Will]
Object-Oriented Programming is Embarrassing: 4 Short Examples - YouTube
https://www.youtube.com/watch?v=IRTfhkiAqPw
[04:52]
just not doing it right, so here are 10 more principles and guidelines
...
beatings will continue until morale improves
[25:54]
because he was programming in an object-oriented style, he just didn't have the clarity to see how simple, what he was doing, really was
[27:08]
she explicitly concedes that object-oriented code is generally less comprehensible than procedural code, but she defends object-oriented code with the idea that: you're not supposed to understand the entirety of your code
==================================================
[Brian Will]
Object-Oriented Programming is Good* - YouTube
https://www.youtube.com/watch?v=0iyB0_qPvWk
[07:04]
problems with OOP
- conflates modules with data types
- overly optimistic about useful abstractions
- favors design with too many small pieces
===
[comments from the comment section:]
===
That wasn't real OOP. Real OOP has never been tried.
==================================================
All evidence points to OOP being bullshit
https://content.pivotal.io/blog/all-evidence-points-to-oop-being-bullshit
The object-oriented model makes it easy to build up programs by accretion. What this often means, in practice, is that it provides a structured way to write spaghetti code. — Paul Graham
=====
The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. — Joe Armstrong
=====
Java is the most distressing thing to happen to computing since MS-DOS. — Alan Kay
=====
[note: it appears that the Disqus comment section is no longer available, and so neither are these comments:]
=====
OOP effectively becomes bullshit when programmers decide: lets sit down and draw up one huge complex MONSTER design of a system and then implement all those complexities creating an unmaintainable mess
=====
almost no one who has invested time into learning something want to believe that their knowledge is in fact useless
...
Of course all the real excitement is around scripting languages these days. First it was ruby, then python, now go. People don't want a needlessly obtuse language then lends itself to inheritance hell. Object oriented programming languages have had their run, but they're definitely not the future.
=====
I've been speculating that OOP is a major cause of software bloat - extremely inefficient use of CPU and RAM, even in programs with relatively few features. (Sometimes this is known as Parkinson's law.) It seems logical, after seeing all the layers and layers of abstraction in Android API and iOS API. Anybody got any thoughts on this?
=====
The problem with modern day websites is that they are trying to be more than just websites, they are trying to be full blown "web applications" trying to replicate behavior of actual programs.
...
Back in the day webpages were usually faster than they are today even though the Internet was MUCH slower than it is today.
...
A lot of modern websites try to use Ajax to replace hyperlinks (because they are just not sexy enough), i.e. instead of just reloading the whole page, they reload the content (which is most of the page) and insert inside the main "" element of the page. In theory you may think this is a good idea but it is actually a very very bad idea, first of all the scriptwriter has to handle every possible network error that can occur and usually scripts do not handle errors as gracefully as the browser
...
Ajax also allows infinite scrolling, as in Facebook, Youtube and Tumblr, which is a horrible idea and obviously designed by people who have no idea how a computer actually works and where content is actually stored
=====
OOP is not as much fun to write in...it feels super convoluted and forced. I do not feel like im working the soil of the earth.
=====
Nice article. I have been a victim of OO design and programming for over 20 years. It never dawned on me that I am a victim of some sort of Ponzi Scheme of IT but I have always felt bad about the programs I was forced to design since the introduction of C++ in my company in the 90s. I always thought, it's just me and OO is the law of the land now so it must be me who is having a problem.
Recently I started to look around and I realized there are more people out there who see things my way and that's encouraging to know.
In my opinion, OOP is exactly the opposite of what they promised us. I remember arguments like "OO forces you to think a problem through before you start coding" - The opposite is true. Since it is so easy to imagine everything as an object, you just start coding objects and feel great about how natural it all falls together, but then the objects mutate into hideous abominations and in the end you end up with as many subroutine calls as any other design principle might create, just they are all listed under a class name ( and not necessarily under the one that's best suited)
Anyway, I'm only beginning to explore the field of criticism so I have not much to offer other than my personal experience with OO, but I'm glad to read blogs like these to learn more about the discussion.
=====
Kudos to the author, it takes balls to publicly question OOP these days.
=====
The central premise of original OOP was to stop thinking like a computer. OOP is not a different way to structure code. It is a new way to think about designing computer systems.
Programmers don't like doing that. Programmers like thinking about the steps a computer performs to carry out an action. They like thinking about data. They like thinking about actions that manipulate data.
=====
Remember - any idiot can write code a computer understands but the skill is in writing code that humans can understand as well!
=====
Understanding an OOP application that is written by someone who "thoroughly understands OOP concepts" is often a way worse experience than assembler spaghetti code ever was.
=====
Its like paying to have your furniture delivered only to realize the entire store came with it!
==================================================
Flaws of Object Oriented Modeling | Intel® Software
https://software.intel.com/en-us/blogs/2008/08/22/flaws-of-object-oriented-modeling/
Now it is almost impossible to follow the execution flow. When you want to know what happened in your application when the error message popped up you have to go over all the objects and all the classes that the execution flow went through and many times execution flow travels between several member functions before leaving to another object. Following the execution flow today is almost impossible.
=====
Many times I have seen 'Pure' Object Oriented design producing a code that is a collection of many three-line functions that call each other. Every button click in the application travels through ten or more small functions. You can no longer follow the execution flow by reading the code.
=====
The real problem that I have with OOP is the ARROGANCE that it has created in the software field. The smartest person in the world is of no use if they can't communicate and be reasonable.
=====
Take the best quality tool in the market and hand it over to two people - one can create a master piece and the other a mess!
=====
Object Oriented Programming: Its a bit like communism, a nice idea but it doesn't work?
=====
With that, I find a huge amount of problem with Window Media Player telling me that the video cannot be played because - the file is corrupt - or the website is down - or there is no Internet connection. This is because someone was such a good OO programmer that they completely ignored return values. This is so common that Exceptions are used to make programmers handle errors.. another bad bad thing that comes from OO paradigms...
=====
Only OOP can produce the term "Random Bug" which means "a bug that happens every now and then, not sure why". These bugs are "random" because they are related to flow control and only few OO expert have ever mentioned flow control as part of the system design.
==================================================
USENIX - Invited Talk: Objecting to Objects
http://static.usenix.org/publications/library/proceedings/sf94/full_papers/johnson.html
Object Oriented Programming (OOP) is currently being hyped as the best way to do everything from promoting code reuse to forming lasting relationships with persons of your preferred sexual orientation. This paper tries to demystify the benefits of OOP. We point out that, as with so many previous software engineering fads, the biggest gains in using OOP result from applying principles that are older than, and largely independent of, OOP. Moreover, many of the claimed benefits are either not true or true only by chance, while occasioning some high costs that are rarely discussed. Most seriously, all the hype is preventing progress in tackling problems that are both more important and harder: control of parallel and distributed applications, GUI design and implementation, fault tolerant and real-time programming. OOP has little to offer these areas. Fundamentally, you get good software by thinking about it, designing it well, implementing it carefully, and testing it intelligently, not by mindlessly using an expensive mechanical process.
=====
In the execution realm, OOP also burns cycles to achieve its ends. Many things that used to be structure references have become function calls (although some may be inlined back into structure references again). This not only costs the overhead of the call, but also tends to cripple optimizers (that are allergic to function calls in the inner loops of programs). This effect alone can easily cost a factor of two in performance. I believe that this effect alone makes OOP difficult to justify in any application where performance is important.
=====
At one point, "everybody" knew that PL/I had no recursive functions, ALGOL 68 was too big a language to be useful, Ada was too slow, and C could not be used for numerical problems. Some of these beliefs were never true, and none of them are true now, but they are still widely held. It is worth looking at OOP in this light.
==================================================
Build smaller, faster and better software ! (or “OOP is overrated”) – The Software Developer
http://cwsof.com/blog/?p=425
“There’s no evidence that the OOP approach is efficient for most programming jobs. Indeed I know of no serious study comparing traditional, procedure-oriented programming with OOP. But there’s plenty of anecdotal evidence that OOP retards programming efforts. Guarantee confidentiality and programmers will usually tell you that OOP often just makes their job harder.”
=====
“Object-oriented programming (OOP) is an ancient (25-year-old) technology, now being pushed as the answer to all the world’s programming ills. While not denying that there are advantages to OOP, I argue that it is being oversold.”
...
“Object-oriented languages tend to burn CPU cycles, both at compile and execution time, out of proportion to the benefits they provide.”
=====
“In the first edition of “The C++ Programming Language,” I didn’t use the phrase “object-oriented programming” because I didn’t want to feed the hype. One of the problems with OOP is exactly that unscrupulous people have hyped it as a panacea. Overselling something inevitably leads to disappointments. “
=====
“I have therefore been moving away from the object-oriented development principles that have made up the bulk of my 17 year career to date. More and more I am beginning to feel that objects have been a diversion away from building concise, well structured and reusable software.”
...
“I’m certainly building smaller, cleaner and better structured software than I ever was before.”
=====
“On the contrary, there is solid evidence that OOP doesn’t work. Just look around you at the numerous failed, over budget disasters in the IT industry.”
=====
“Bloat is a systemic problem, resulting from a software engineering culture encourages abstraction and layering, with a goal of rapid application development.”
==================================================
Object Oriented Programming is Inherently Harmful | Hacker News
https://news.ycombinator.com/item?id=8676872
I'm a Java programmer so work with OOP every day. I think it has it's pro's and con's like everything else.
My pet hate is how dogmatic some people get to the point where they get angry over the use of if/switch statements. "It's not good OOP, use polymorphism", well the goal isn't to pass an OOP exam, but rather to write clean maintainable code where possible. If an if/switch saves me writing 6 classes with 3 lines in each of them, then that's what I'll do.
=====
Ironically, they're guilty of an anti-pattern. The point of all these patterns is to only use them when they actually solve a code smell. If you introduce them early, then you have Needless Complexity, as they like to say.
=====
OO was originally created as a way to cleanly allocate memory on the heap. That's a fairly well solved problem now. The best parts of OO aside from heap allocation are encapsulation and polymorphic dispatch (two sides of the same coin). Closures and functions as fundamental units of decomposition handle that fairly well, especially when you couple that with type inferencing.
I'm not arguing that OO is bad. I'm arguing that it's no longer anywhere near as useful as it used to be, even when it was implemented and used properly.
=====
To make matters more difficult, you have to make these kind of decisions very early before you write your code. By the time you properly understand the problem, you will have invested in a particular solution. There is N>3 ways to do things and there is only one best way, so chances are you are doing it the wrong way.
=====
I figure as code evolves, it generally takes 3-4 rewrites to get class hierarchies to a point where it matches your domain and more often than not the solution involves shallow trees and the use of traits or mixins which is something traditional oop languages don't all support well.
The only harmful paradigm is "write only programming", everything else is negotiable.
=====
>I figure as code evolves, it generally takes 3-4 rewrites to get class hierarchies to a point where it matches your domain
That's not a good sales pitch for OOP.
=====
Sure, but sometimes strong opinions are necessary to make progress. If Dijkstra hadn't written "Go To Statement Considered Harmful", would we still be using them today? Probably not, but it probably helped bring quicker progress.
=====
In the same way, criticism against X can be an opportunity to learn and improve. Not hostility against people who like or are used to technology X.
=====
"... a computer model should be structured along three dimensions: data, functionality and events":
=====
What people argue against OOP is how it's applied to anything for any case. Creating new classes/type/abstract concept each time you want to realize something can often lead to code bloat. How many classes named "XXX_manager" can one encounter ?
> Sorry for shattering everyone's hopes and dreams of coding pure OOPless.
OOP tends to have state, which doesn't bode well will multithreading, which tend to favor functional programming. I don't know if the future is going to be massively multithreaded, but I just think that OOP is just another way to structure a program, nothing more. Processes and threads already are objects. Functions too. So why tell students to create new types all the time ?
=====
I've been working on leaving OO recently. This is my current API. No deep nested hierarchies of classes anymore!
self.player.addComponent(Controller())
self.player.addComponent(Shooter())
self.player.addComponent(Jumper())
self.player.addComponent(Life())
self.player.addComponent(CharacterPhysics())
People who generally code applications could learn a lot from game developers and game engines. I took inspiration from Stencil and HaXe (but using Swift and SpriteKit) http://www.stencyl.com
=====
[Design Patterns: Elements of Reusable Object-Oriented Software by the 'Gang of Four']
A lot of people crap on the GOF book because the patterns in it are either obvious or useless, but reading it does teach you some useful concepts, and for many people it will be their first direct exposure to something other than inheritance. Composition/Aggregation are great takeaways from that text.
=====
OO design should be done according to the YAGNI principle--You Aren't Going To Need It--and its corrolary--do it as soon as you need it.
=====
The age-old rule of thumb is that programmer productivity is language independent.
=====
I don’t think it ever became the answer to code reuse or code quality that proponents claimed.
=====
> Tools are everything. What makes or breaks a paradigm/language are tools
I completely agree. In my experience, and it's probably the same for many people, I spend a non-trivial amount of time not writing "primary" code. Instead I'm testing, debugging, dealing with build issues and dependencies, packaging, wrangling deployments etc...
=====
I really liked this link: http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfal... from the server. It is from 2009 so a bit dated, but it shows something which is prevalent today, objects obscure what they are doing, and they mix code and data, but data access is a lot slower than it used to be so data optimization is more important than ever.
=====
Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf
http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf
=====
OOP has the same relationship to programming that formalist literary critique does to writing: the willful denial of connection to reality. When you're solving a problem that's connected to the real world--perhaps you have a deadline, or a live human being will use your program at some point--it's often better to just go ahead and build something that works and can be easily explained to the person who will maintain it in the future.
As with formalism you should know how OOP works and how seriously others take it, so you don't get into fights with your relatives at Thanskgiving.
=====
The problem with OO - and this applies to Smalltalk too - is that class hierarchies are a bad fit for a changing business environment, being hard to refactor when previous assumptions change: inevitably some new case will come along which requires changes to the structures that were originally defined, and OO is harder to deal with in that context.
=====
This approach begins to suffer when application state is mixed between a remote server and a local client. Further, the physical metaphors of OOP suffer when removed from Smalltalk-like systems.
The rise of functional programming has as much to do with the rise of networked computing and shared data than anything else.
=====
Well, the OP notes some of the dangers of inheritance. I agree and saw the danger right away and, thus, in the code I write try not to use inheritance and so far have been fully successful.
==================================================
Why OO Sucks by Joe Armstrong
http://harmful.cat-v.org/software/OO_programming/why_oo_sucks
When I was first introduced to the idea of OOP I was skeptical but didn’t know why - it just felt “wrong”. After its introduction OOP became very popular (I will explain why later) and criticising OOP was rather like “swearing in church”. OOness became something that every respectable language just had to have.
...
Objection 1 - Data structure and functions should not be bound together
...
Objection 2 - Everything has to be an object
...
Objection 3 - In an OOPL data type definitions are spread out all over the place
...
Objection 4 - Objects have private state
...
Why OO was popular?
•Reason 1 - It was thought to be easy to learn.
•Reason 2 - It was thought to make code reuse easier.
•Reason 3 - It was hyped.
•Reason 4 - It created a new software industry.
I see no evidence of 1 and 2. Reasons 3 and 4 seem to be the driving force behind the technology. If a language technology is so bad that it creates a new industry to solve problems of its own making then it must be a good idea for the guys who want to make money.
This is is the real driving force behind OOPs.
==================================================
java - Is Object Oriented stuff really that important? - Software Engineering Stack Exchange
https://softwareengineering.stackexchange.com/questions/137372/is-object-oriented-stuff-really-that-important
Of course OOP/OOD is overrated. This trivial model is only usable for narrow set of problems. But you should not ignore it - otherwise you'll end up using the wrong tools for that rare and narrow areas where OOP really shines.
=====
Whereas I appreciate the sentiment expressed with regards to complexity, sadly in practice the opposite is true. OO languages have a knack for introducing unnecessary bloat and complexity. That's often not the language's fault. But I believe that if a technique is prone to cause so many people to use it incorrectly it may be somewhat flawed. No matter how nice it sounds in theory.
==================================================
object oriented - What makes OOP "good"? - Software Engineering Stack Exchange
https://softwareengineering.stackexchange.com/questions/198675/what-makes-oop-good
I would like to know why people like OOP. To be honest, combining procedures, types, and data structures into a single conglomerate seems bad to me. I'd much rather view data as simply data. I like to be able to think that I will pass the right data through a function and get the right output, and not have to consider that the data is capable of operating on itself.
=====
solving the problem is only 15% of software. Doing that in a way that is legible, maintainable, debuggable, extensible, portable to future coders is a bigger (more expensive) issue.
=====
there are dozens of better approaches. OOP is pretty useless outside of a very narrow field (namely, agent-based simulations). OOP does not help fighting the complexity - modularity does. People too often give credits to OOP which in fact belong to modularity, a much more generic concept.
=====
I'm no fan of OOP, but performance is not a good criticism. OOP has pretty performant implementations. The criticism is that it's not a particularly good paradigm, design-wise.
=====
I searched up on why OO sucks cuz it annoys me the giant circlejerk on it.
=====
K, well in practice OO uses far more memory (it by definition duplicates every function for absolutely no reason, taking up more memory), which then increases the pressure on the caches, slowing down execution, all for absolutely no benefit, or reason.
=====
Modularization is older than even structured programming; it is orthogonal of the paradigm. Same for abstraction, composability. Now, you may argue that OOP does these things better than other options, but that is an order of magnitude less convincing and still quite arguable. I've never heard 5 and 6 cited as advantages, but "Continuity" sounds like a consequence from modularization and abstraction, and "Hierarchy" sounds like it's paradigm-independent as well (in fact, it sounds so trivial that I can hardly imagine a scenario where it's not feasible). -1 to counter +1
==================================================
Is Object Oriented Programming Overrated ? Another View ! - CodeProject
https://www.codeproject.com/Articles/580877/Is-Object-Oriented-Programming-Overrated-Another-V
When one looks at OOP from the perspective of machine code and all the work a compiler must do to convert things like classes and objects into something the machine can work with, then one very quickly begins to see that OOP adds significant overhead to an application. Also if a programmer comes from a background of working with assembler, where keeping things simple is critical to writing maintainable code, one may wonder if OOP is improving coding or making it more complicated.
...
Appreciating machine code also affects my view of performance. Every CPU cycle counts.
==================================================
OOP is overrated. - Codecall
http://forum.codecall.net/blog/1088/entry-1063-oop-is-overrated/
In my Java class last summer, one of my teammates created the GUI for our project with Netbeans, and it created literally hundreds of class files the first time he compiled it. Fu¢k Netbeans! I'd rather code in machine language.
==================================================
OOP Is Much Better in Theory Than in Practice | Lambda the Ultimate
http://lambda-the-ultimate.org/node/489
If OOP so closely matched the real problem domain, then it would be easy. The fact that "after 10 years, people still don't get OOP" is not necessarily an indication of programmer quality (at least, not to as great an extent as many say). Rather, I think it points to a mismatch between OOP's stated advantages and its real-world use.
=====
For me, software is written by people following established procedures. From my experience, it is much more important for a company to be able to quickly implement, maintain and evolve a project, rather than code a perfect solution that no one but the original programmer knows how to handle. It is no coincidence that very advanced designs and tools are considered as a risk by managers.
=====
In terms of object oriented design & development I keep coming back to what the books say.
"how to make your company succeed with OO"
in the first chapter will tell you OO is easy & intuitive.
Later it tells you the programmers will have a major drop in productivity lasting from months to years.
Also later it tells you to hire several decades-experienced gurus for each project. This kind of puts the lie to the 'intuitivity' theory.
==================================================
[Richard Mansfield]
OOP Is Much Better in Theory Than in Practice
https://web.archive.org/web/20050121032229/http://www.devx.com/DevX/Article/26776
Like many ideas that sound good in theory but are clumsy in practice, object-oriented programming (OOP) offers benefits only in a specialized context—namely, group programming. And even in that circumstance the benefits are dubious, though the proponents of OOP would have you believe otherwise. Some shops claim OOP success, but many I've spoken with are still "working on it." Still trying to get OOP right after ten years? Something strange is going on here.
=====
That's why very few programming books I've read use OOP techniques (classes, etc.) in their code examples. The examples are written as functions, not as methods within objects. Programming books are trying to teach programming—not the primarily clerical and taxonomic essence of OOP. Those few books that do superimpose the OOP mechanisms on their code are, not surprisingly, teaching about the mysteries of OOP itself.
=====
It's a clerical system with some built-in security features. In my view, confusing OOP with programming is a mistake. OOP is to writing a program what going through airport security is to flying.
=====
Even after years of OOP, many—perhaps most—people still don't get it. One has to suspect that we're dealing with the emperor's new clothes when OOP apologists keep making the same excuses over and over: you don't understand OOP yet (it takes years of practice; you can't simply read about it in a book); your company isn't correctly implementing OOP, that's why you're facing so many programming delays and inefficiencies; you haven't transformed your databases into OOP-style databases; and on and on. The list of excuses why OOP isn't doing what it promises is quite long. The list of excuses is so long, in fact, that I've began to wonder whether OOP is simply the latest fad, like Forth, Pascal, Delphi, and other programming technologies before it. History has seen these "final best solutions" many times, when waves of professors applauded some idea (structuralism, Marxism, existentialism, logical positivism, etc.) only to turn like a school of fish when the next big idea came along.
=====
I find that leaving the data in a database and the data processing in the application simplifies my programming.
==================================================
industry standard - Are design patterns frowned upon? - Software Engineering Stack Exchange
https://softwareengineering.stackexchange.com/questions/329728/are-design-patterns-frowned-upon/329731
I had a discussion with one of our senior developers who's been in the business for 20 years.
...
The other thing too is that he avoids design patterns because most programmers don't understand them and they are not good from a maintenance perspective.
...
It's so strange hearing an opinion like this, considering that Stack Overflow mostly encourages people to follow industry standards.
=====
Personally I'm nervous of anything refered to as "best practice" (without justification) because it usually means "I don't know why this is a good idea but I want you to do it anyway; end of discussion"
=====
Design patterns existed before they had names. We gave them names to make talking about them easier. A pattern having a name doesn't make it a good thing. It makes it a recognizable thing.
=====
Agreed, with the caveat that, when most people use the term "design patterns" nowadays, they're usually referring to the Gang of Four.
=====
Note that what a professor who has never had any real-world experience considers "good" could vary radically from what a business trying to make money considers "good."
==================================================
realtimecollisiondetection.net – the blog » Design patterns are from hell^2!
http://realtimecollisiondetection.net/blog/?p=81
Far from “master programmers,” design patterns are the work of people who do conferences, talks, and books for a living, to further their own cause; they’re the work of academics who live in their heads and have never worked on real projects to see what kind of shit code their abstract ideas produce when put in practice; they’re the work of people who couldn’t care less about what toxic miasma they have unleashed because they’re too busy speaking at Software Development to push their consulting gigs to the fools who bought into the snake oil.
Design patterns are spoonfeed material for brainless programmers incapable of independent thought, who will be resolved to producing code as mediocre as the design patterns they use to create it.
=====
I’d agree with you that some of them are shovelware on paper.
=====
I realize reading the mindless drivel of Design Patterns might give some programmers instant satisfaction because everyone talks about patterns and they now feel smarter having read about them, but in reality these programmers would be better off beating their heads against Knuth because that will actually make them smarter, not just feel like they are. (Knuth is a hard read, but avoiding solving hard problems isn’t the way of becoming a master programmer any more than is studying Design Patterns. If Knuth is too much, read Skiena’s book.)
=====
Just want to share some personal experience on this. Back when I have just graduated, I found my self trying to understand why people programming certain way. At beginning, I thought those fancy patterns are really smart and ingenious that I would hope to use it somewhere.
After few years of experience now, I think of those fancy patterns useless but from a different standing… Most of them are not hardware aware as all. As console programmer, I think we need to put the hardware up front then any patterns or tricks. I am glad that when I start to write a new system now, first thing I think of is how can it takes advantage of the hardware rather then which “algorithm” or “data structure” I should use.
=====
Definitely true, and people certainly need to start favoring data-driven designs over code designs in this day and age of massively parallel computing (although the two need not be mutually exclusive). I’d take it a step further though and say that people who think too much about the specific hardware quirks that they’re dealing with and not enough about fundamental things like computational complexity, memory access patterns, etc. are also missing the boat though.
=====
What the Book from Hell did was to force standard terminology down everyone’s throat, instead of letting natural selection have its course. This has resulted in a bunch of mindless sheep now thinking that there is some sort of inherent value to “visitor patterns”, and worse, that anything categorized as a “pattern” is good.
=====
[the Book from Hell]
Design Patterns - Wikipedia
https://en.wikipedia.org/wiki/Design_Patterns
=====
I guess my main problem with design patterns is that it has never been clear to me exactly what they ‘do’.
Do they help me get a program working?
Can they make my program faster? Shorter? Use less memory?
Will they reduce the number of bugs in my program?
As near as I can tell, all of the benefits ascribed to design patterns derive from magical thinking rather than some natural reason. The idea that patterns somehow ‘help’ your code is analogous to ritualistic practices such as Feng-Shui or voodoo. In my opinion design pattern literature is just like astrological horoscopes in that they purports equally nebulous benefits.
=====
“Design patterns give us names for common stereotypes/abstractions in software design.”
No. These patterns are only “common” because someone wrote down some shit in a book and code monkeys started flinging it into every piece of code they write because they heard someone else say it was expert advice.
=====
AI programmers will recognize this as reinforcement learning using a negative payoff.
=====
And while this may seem harsh and overly judgmental, in my experience, the best programmers/engineers are the ones that think in terms of data and algorithms. Those are also often the best architects, because they truly understsand what encapsulation means or they otherwise would not be able to seperate data and algorithms (and I don’t consider encapsulation to be an OOP-only concept, I say this because Christer is obviously not an OOP fan!).
=====
We’ve all developed our own patterns over the years, and the wiser of us have managed to learn some tricks from each other. I try to stress for the students that these patterns are useful as options to consider, and only by understanding exactly how it works would you be able to apply them wisely. However, I see the blank stares in some of the faces, and I know they would rather just memorize “Plank” problems.
==================================================
[note: the whole video is great (duration: 07:43)]
[Casey Muratori]
Handmade Hero | Getting rid of the OOP mindset - YouTube
https://www.youtube.com/watch?v=GKYCA3UsmrU#t=1m52
[01:52 to 02:41]
I want the computer to put a red dot here, how do I do that?
[versus]
Oh do I need to abstract the concept of a screen, and red, should red be an object that, oh what is this, is a pixel an object or is it a group of objects, is there a container, do I have to ask a factory to get me a color and that color is red.
==================================================
[Casey Muratori]
Casey and the Holy OOP Grail - YouTube
https://www.youtube.com/watch?v=ZM1ZDaaEyMY
[02:24]
but the truth is, you never attain the things that it says you're going to get
==================================================
Is object-oriented programming really bad? - Quora
https://www.quora.com/Is-object-oriented-programming-really-bad
THe problems with OOP are:
1.It is incredibly distracting. It is very easy to end up in situation where you’ll be doing “illusory work”. For example, you can sink massive amount of time trying to come up with “perfect” (meaning “beautiful”) object hierarchy. Whil you’re busily splitting/merging classes, functionality of your project does not improve, you’re essentially wasting time while being fully convincing that you’re being useful.
2.There are people who treat it like religion. I’ve seen an article (discussing C# extension methods) saying, basically “I’ve found a way to write clean, maintainable and easy to read code, but it wasn’t OOP, so I concluded that it is evil and wrong”. This is just ridiculous.
=====
For example, they just replaced s.x = v with s.setX(v)
Now it was the same code and the same ideas, just lots of additional, useless cruft, all to make it look like the mighty OOP.
==================================================
Why Arc Isn't Especially Object-Oriented
http://www.paulgraham.com/noop.html
There is a kind of mania for object-oriented programming at the moment, but some of the smartest programmers I know are some of the least excited about it.
==================================================
Should I abandon OOP totally and move towards C or functional programming or should I read a good OOP book? Should I learn OOP or just pick up other languages like Haskell. - Quora
https://www.quora.com/Should-I-abandon- ... ke-Haskell
My subsequent experience with that project (which is still begin maintained after about 14 years) is that the OO stuff is more work to debug. I have gradually over the years flattened out a lot of the OO because it obscured some tricky problems that became more obvious with procedural code and were then easy to solve. Probably only about 20% of the project is still OO - fortunately that stuff seems to work ok, so it'll probably stay that way.
...
Some people mention that you can code 100 lines easily in procedural code, but once you work with "large" projects (10,000 or more lines) you will "get to appreciate OO". Well, the "little" project I'm currently working on is more than 20,000 lines. Quite a lot more, actually. And because it is properly designed and well written, it is easy to maintain, easy to debug, and by the way has a very low bug rate.
So why don't I work in OO? It is not so much that I don't like it. It is far more that I find it ineffective. I work far more efficiently - both at time of coding and during error checking and correction - by writing procedural code.
So, if you don't like working in OO - perhaps you shouldn't?
==================================================
Why did Dijkstra say that “Object-oriented programming is an exceptionally bad idea which could only have originated in California.”? - Quora
https://www.quora.com/Why-did-Dijkstra- ... -%E2%80%9D
OOP has its place - GUI toolkits are the most obvious example. But if you’re working on a project and someone leading it is trying to do “pure OOP”, run away. Unless the project fits into an extremely narrow band of things OOP is an exact fit for, you’re in the presence of a fetish, not an engineering principle. It’s great for learning programming and empowering neophytes, but sooner or later it becomes a ghetto, and if you want to grow, you need to move beyond it and treat it as a tool in the toolbox and nothing more.
=====
So Dijkstra was interested in formally proven and correct-by-construction programs using the formalism of Hoare triples. But you cannot apply Hoare triples to object-oriented programs hence you cannot prove their correctness. Therefore, for Dijkstra, OOP was crap.
To those who heard about “contracts”, “design-by-contract” (c) Bertrand Mayer and Eiffel, I’ve used that, I was part of research on that and I can tell you it doesn’t work. First of all class invariants are unsound and work only in simple cases. You have the whole bag of works with “callbacks”, mutual invariants (my invariant depends on invariant of another class) and so on. The formalisms to describe this — things like “object ownership” — are so complicated that they are unusable in practice and still forbid many use cases. Then to check pre- and postconditions you have to consider object reference aliasing which is an open problem yet. And again a complicated one.
Besides, I’m troubled by the fact we don’t have a mathematical model for OOP. We have Turing machines for imperative (procedural) programming, lambda-calculus for functional programming and even pi-calculus (and CSP by C.A.R. Hoare again and other variations) for event-based and distributed programming, but nothing for OOP. So the question of “what is a ‘correct’ OO program?”, cannot even be defined; (much less, the answer to that question.)
=====
Design patterns can be viewed as standardized ways to limit the arbitrary use of OO mechanisms, with the aim to improve reasoning about OO programs. Instead of ‘improved reasoning’, the benefits of design patterns are nowadays advertised as improved software qualities, such as understandability, verifiability, and modifiability.
But design patterns are a weak substitute for (elegant and usable) mathematical axiomatization, which we do have for structured programming.
=====
After more than 45 years in the field, I am still convinced that in computing, elegance is not a dispensable luxury but a quality that decides between success and failure; in this connection I gratefully quote from The Concise Oxford Dictionary a definition of "elegant", viz. "ingeniously simple and effective". Amen. (For those who have wondered: I don't think object-oriented programming is a structuring paradigm that meets my standards of elegance.)
=====
If, then, the campus is insufficiently shielded from those pressures and the market forces are given too free a reign, you can draw your conclusion: a flourishing snakeoil business, be it in "programming by example", "object-oriented programming", "natural language programming", "automatic program generation", "expert systems", "specification animation", or "computer-supported co-operative work".
=====
Structured programming beats Object oriented programming in terms of speed, size and effort.
==================================================
Why bad scientific code beats code following "best practices"
http://yosefk.com/blog/why-bad-scientific-code-beats-code-following-best-practices.html
This I can deal with, you see. I somehow rarely have a problem, if anyone wants me to help debug something, to figure out what these guys were trying to do. I mean in the software sense. Algorithmically maybe I don't get them fully. But what variable they want to pass to what function I usually know.
Not so with software engineers, whose sins fall into entirely different categories:
•Multiple/virtual/high-on-crack inheritance
•7 to 14 stack frames composed principally of thin wrappers, some of them function pointers/virtual functions, possibly inside interrupt handlers or what-not
•Files spread in umpteen directories
•Lookup using dynamic structures from hell – dictionaries of names where the names are concatenated from various pieces at runtime, etc.
•Dynamic loading and other grep-defeating techniques
•A forest of near-identical names along the lines of DriverController, ControllerManager, DriverManager, ManagerController, controlDriver ad infinitum – all calling each other
•Templates calling overloaded functions with declarations hopefully visible where the template is defined, maybe not
•Decorators, metaclasses, code generation, etc. etc.
The result is that you don't know who calls what or why, debuggers are of moderate use at best, IDEs & grep die a slow, horrible death, etc. You literally have to give up on ever figuring this thing out before tears start flowing freely from your eyes.
...
Simple-minded, care-free near-incompetence can be better than industrial-strength good intentions paving a superhighway to hell. The "real world" outside the computer is full of such examples.
==================================================
Why bad scientific code beats code following “best practices” (2014) | Hacker News
https://news.ycombinator.com/item?id=12377385
For ages now, I've been telling people that the best best code, produced by the most experienced people, tends to look like novice code that happens to work --- no unnecessary abstractions, limited anticipated extensibility points, encapsulation only where it makes sense. "Best practices", blindly applied, need to die. The GoF book is a bestiary, not an example of sterling software design. IME, it's much more expensive to deal with unnecessary abstraction than to add abstractions as necessary.
People, think for yourselves! Don't just blindly do what some "Effective $Language" book tells you to do.
==================================================
Links:
Object-Oriented Programming Is Bad? - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=17&t=59107
OOP: resources - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=17&t=51599
OOP considered harmful ?
https://www.lvguowei.me/post/anti-oop/
Links (sources):
What's Wrong With Object-Oriented Programming?
https://www.yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html
WhitePaperHasOOPFailed.pdf
http://4js.com/files/documents/products/genero/WhitePaperHasOOPFailed.pdf
Is the object-oriented programming (OOP) paradigm overemphasized or overrated? - Quora
https://www.quora.com/Is-the-object-oriented-programming-OOP-paradigm-overemphasized-or-overrated
Why use OOP concepts anyway? - Quora
https://www.quora.com/Why-use-OOP-concepts-anyway
Object Oriented Programming
https://www.cs.drexel.edu/~introcs/Fa15/notes/06.1_OOP/Advantages.html?CurrentSlide=3
4 Benefits of Object-Oriented Programming | Robert Half
https://www.roberthalf.com/blog/salaries-and-skills/4-advantages-of-object-oriented-programming
Goodbye, Object Oriented Programming – Charles Scalfani – Medium
https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53
Object-Oriented Programming is Bad - YouTube
https://www.youtube.com/watch?v=QM1iUe6IofM
Object-Oriented Programming is Embarrassing: 4 Short Examples - YouTube
https://www.youtube.com/watch?v=IRTfhkiAqPw
Object-Oriented Programming is Good* - YouTube
https://www.youtube.com/watch?v=0iyB0_qPvWk
All evidence points to OOP being bullshit
https://content.pivotal.io/blog/all-evidence-points-to-oop-being-bullshit
Flaws of Object Oriented Modeling | Intel® Software
https://software.intel.com/en-us/blogs/2008/08/22/flaws-of-object-oriented-modeling/
USENIX - Invited Talk: Objecting to Objects
http://static.usenix.org/publications/library/proceedings/sf94/full_papers/johnson.html
Build smaller, faster and better software ! (or “OOP is overrated”) – The Software Developer
http://cwsof.com/blog/?p=425
Object Oriented Programming is Inherently Harmful | Hacker News
https://news.ycombinator.com/item?id=8676872
Why OO Sucks by Joe Armstrong
http://harmful.cat-v.org/software/OO_programming/why_oo_sucks
java - Is Object Oriented stuff really that important? - Software Engineering Stack Exchange
https://softwareengineering.stackexchange.com/questions/137372/is-object-oriented-stuff-really-that-important
object oriented - What makes OOP "good"? - Software Engineering Stack Exchange
https://softwareengineering.stackexchange.com/questions/198675/what-makes-oop-good
Is Object Oriented Programming Overrated ? Another View ! - CodeProject
https://www.codeproject.com/Articles/580877/Is-Object-Oriented-Programming-Overrated-Another-V
OOP is overrated. - Codecall
http://forum.codecall.net/blog/1088/entry-1063-oop-is-overrated/
OOP Is Much Better in Theory Than in Practice | Lambda the Ultimate
http://lambda-the-ultimate.org/node/489
OOP Is Much Better in Theory Than in Practice
https://web.archive.org/web/20050121032229/http://www.devx.com/DevX/Article/26776
industry standard - Are design patterns frowned upon? - Software Engineering Stack Exchange
https://softwareengineering.stackexchange.com/questions/329728/are-design-patterns-frowned-upon/329731
realtimecollisiondetection.net – the blog » Design patterns are from hell^2!
http://realtimecollisiondetection.net/blog/?p=81
Handmade Hero | Getting rid of the OOP mindset - YouTube
https://www.youtube.com/watch?v=GKYCA3UsmrU#t=1m52
Casey and the Holy OOP Grail - YouTube
https://www.youtube.com/watch?v=ZM1ZDaaEyMY
Is object-oriented programming really bad? - Quora
https://www.quora.com/Is-object-oriented-programming-really-bad
Why Arc Isn't Especially Object-Oriented
http://www.paulgraham.com/noop.html
Should I abandon OOP totally and move towards C or functional programming or should I read a good OOP book? Should I learn OOP or just pick up other languages like Haskell. - Quora
https://www.quora.com/Should-I-abandon- ... ke-Haskell
Why did Dijkstra say that “Object-oriented programming is an exceptionally bad idea which could only have originated in California.”? - Quora
https://www.quora.com/Why-did-Dijkstra- ... -%E2%80%9D
Why bad scientific code beats code following "best practices"
http://yosefk.com/blog/why-bad-scientific-code-beats-code-following-best-practices.html
Why bad scientific code beats code following “best practices” (2014) | Hacker News
https://news.ycombinator.com/item?id=12377385
Additional links (mentioned in sources):
Hype cycle - Wikipedia
https://en.wikipedia.org/wiki/Hype_cycle
1*cBFSQ9Ytv_D0jwGtpuL5WA.png
https://cdn-images-1.medium.com/max/1600/1*cBFSQ9Ytv_D0jwGtpuL5WA.png
Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf
http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf
Design Patterns - Wikipedia
https://en.wikipedia.org/wiki/Design_Patterns
==================================================
EDITS
