Object Oriented Programming is an expensive disaster which must end

http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end

by lkrubner • 12 years ago

103 119 12 years ago

JazCE• 12 years ago

i haven't read the whole text of this yet. but god damn it, all that text.. and that layout... thats a disaster that must end.

zo1• 12 years ago

At first I thought it was because I had javascript disabled on the site, but nope, enabling it didn't help one bit.

It's almost as if the site was designed to be solely read on some tiny-screened mobile device or something, with all that text squished in the middle.

blowski3• 12 years ago

With that much badly organised text, it's almost like it was designed never to be read at all.

musername3• 12 years ago

looks good on 4.3" indeed

blowski3• 12 years ago

If ever an article needed a tl;dr, then this is it.

As far as I can tell, the OP has seen something working in practice, and has set out to demonstrate why it doesn't work in theory.

radicalbyte• 12 years ago

You missed an important step: "couldn't understand how it worked".

Functional programming can be really awesome for some problems, as can OOP, imperative and declarative.

lmm• 12 years ago

I guess you can get away with attacking strawmen if you pre-emptively claim your opponents are no-true-scotsmaning you.

kitd• 12 years ago

He won't get away with anything in Scotland after that, especially calling them "Scottsmen".

colinramsay• 12 years ago

It doesn't bode well for this article when they make a mistake in the first line. It's "Scotsman", not "Scottsman".

chris_wot5• 12 years ago

Actually, he later calls it an Untrue Scottman.

musername3• 12 years ago

this is my experience whenever I argue against Object Oriented Programming (OOP): no matter what evidence I bring up for consideration, it is dismissed as irrelevant.

This, I thought before even reading the article. I know that frustration myself too well, but have to admit I am often in the wrong, asking the wrong questions, having false preconception.

Lloking at different impleme tations it's clear, experts aren't all that sure, either, even though most implementation specifics aren't detrimental to OOP, so language critizism in lieu of OOP concepts is clearly a strawman. then I stopped reading.

DanielBMarkham2• 12 years ago

But tell us how you really feel!

I had to bail out about 1/3rd of the way through. Wow, what a rant.

I don't mind the invective, and I'm becoming more skeptical of OOP the more I see larger-scale FP apps work. Mutable state and hidden dependencies are killing us. But I do not like the way this essay is arguing its case. Please do not trot out famous people, tell me their ideas, and then show me how things did not work out for them.

Frankly, I couldn't care less what Alan Kay thinks of OOP. Or Bjorne. Or any of the others. I'm sure they're nice people, and probably a million times smarter than I am. What I'm interested in is this: why do people who know multiple ways of creating a solution pick OOP? And does it fulfill the implied promises it makes to those folks?

The classic example is the statement "OOP is required for creating and maintaining large systems, because it forces developers to think about where things go first, ahead of what the system does."

So here we are presented with a problem: large-scale systems with lots of developers have a difficult time working without a clear definition of where everything goes and how it works together. From my experience that seems like a reasonable problem to consider. So let's talk about that problem, how OOP helps, and how OOP falls down on the job.

Repeat and rinse. Then we get a list of real-world problems that choosing OOP is supposed to help with. We also can start creating some success criteria for both OOP and non-OOP projects.

Otherwise, our arguments get caught up in personalities and theory-of-the-universe crap that doesn't really go anywhere. I can line up a dozen experts, cherry-pick some quotes, and rant away. A person disagreeing with me can do the same. Then we can each talk about how the theoretical system the other guy's way of solving things is built on a shaky foundation. The other guy will demonstrate that this is incorrect by citing an example. It's not productive.

The reason it is not productive is that it is trying to make a universal case based on theory, as if programming were some sort of extension of calculus or geometry. Yes, I understand the association with category theory and such, but programming is the act of multiple humans coming together and creating some better way of doing things for another group of humans. Yes, languages are mathematical, but programming isn't. You want better programming, you'd better start listing out a bunch of ways humans screw the pooch when they're trying to make stuff, then try to help them stop doing that. You don't trot out the set theory books. Wrong answer.

Think in terms of machine language. At the end of the day, bits gotta go somewhere -- both data bits and coding bits. Instead of trying to say "well, we always do things this way because $FamousAuthorX told us", it might be much better to say "we have this process that allows us to dynamically change the method of grouping that proceeds like so"

This is much better because it starts with the problem and lets the solution evolve. Instead of starting with already knowing the solution and then just taking the problem and a big hammer and making it all work [insert long argument for mixed-mode languages here, like Ocaml or F#]

ADD: I also note that developers love making things complicated, and OOP is like a massive playland where you can run off and make complicated stuff all day long. Become your inner architecture astronaut. This is extremely difficult for many to resist.

JackMorgan• 12 years ago

I decided to just simply stop arguing and just learn every style I could. As much as I want to be a white knight who "saves" software engineering by convincing everyone to use the most efficient way to work, it's never going to happen. I'm not even sure I know the must efficient way.

The biggest obstacle is the anti-intellectualism which weighs down every argument. Very few people even want to learn something new, they just want the ego boost of knowing they shouldn't have to.

So now I lead a study group reading through SICP and I call it a day. Better to train up a cohort of people who want to learn than argue with those who even if proved 100% wrong will never budge.

DanielBMarkham2• 12 years ago

Bingo.

Key question to ask yourself: assuming you had a good team that could talk about things, if the other three guys on your team wanted to try something new, but you thought it was a bad idea, would you keep an open mind and give it a good shot? Or would you dig in and come up with the 74 thousand reasons it sucks?

There are a lot of really smart guys out there that can argue any subject from any angle better than anybody else in the room. They view conversations as debates and discussions around direction as something that can be "lost" or "won". There's a right and wrong answer, and these guys are almost always right.

Don't be one of those guys.

theforgottenone• 12 years ago

You really should care more about Kay has to say. There are few truly brilliant people out there, and Kay is one of them.

lucozade• 12 years ago

A little bit of data hiding wouldn't have gone amiss.

thomasfl• 12 years ago

Spot on!

buro9• 12 years ago

Has anyone made it all the way through? Could you provide a tl;dr that offers more insight than the title and last line.

zorbo4• 12 years ago

Having programmed a lot of OO in Python and PHP (yeah, yeah, I know, but its OO implementation is actually rather good), I always felt OO was a pretty good way of doing things...

Until I hit the Java scene. Boy, is it a big mess. There I found some of the worst unreadable, unmaintainable, ungrokable, complex and brittle code I've ever seen. And that's not an exception, rather it's the standard. I suddenly understood why Python's logging implementation is such a disaster. It was ported from Java. I'm sorry if this offends the java programmers, but it feels like idiomatic java is just abstractions piled on abstractions upon patterns, in the hope of somehow making things more understandable or robust. It doesn't.

I've always thought of OO as simply abstraction and encapsulation. Functions on steroids, if you will. If something doesn't fit the OO paradigm, I don't try to shoehorn it in (which patterns seem to especially made for). If you manage to avoid doing that, OO works rather well if you ask me.

chriswarbo5• 12 years ago

One of the major points of the article is the "no True OO Programmer" fallacy:

this is my experience whenever I argue against Object Oriented Programming (OOP): no matter what evidence I bring up for consideration, it is dismissed as irrelevant. If I complain that Java is verbose, I’m told that True OOP Programmers let the IDE take care of some of the boilerplate, or perhaps I am told that Scala is better. If I complain that Scala involves too much ceremony, I’m told that Ruby lacks ceremony. If I complain about the dangers of monkey-patching in Ruby, I’m told that True OOP Programmers know how to use the meta-programming to their advantage, and if I can’t do it then I am simply incompetent. I should use a language that is more pure, or a language that is more practical, I should use a language that has compile-time static data-type checking, or I should use a language that gives me the freedom of dynamic typing. If I complain about bugginess, I’m told that those specific bugs have been fixed in the new version, why haven’t I upgraded, or I’m told there is a common workaround, and I’m an idiot if I didn’t know about it. If I complain that the most popular framework is bloated, I’m told that no one uses that framework any more. No True OOP Programmer ever does whatever it is that I’m complaining about.

davelnewton5• 12 years ago

The same goes the opposite direction, though. While I'm sure your actual arguments are more cogent, simply complaining about something specific isn't an argument against OOP in general.

And I doubt that anybody claims Java isn't verbose, or that the IDE "handles" it--regardless of who's doing the typing, Java is verbose. The only people that hold up Java as a good example of OOP are people that don't really know any other version.

andybak• 12 years ago

I think there is a similar flaw in your argument as follows.

You: OO is flawed because of x

Me: But OO language a doesn't have a problem with x

You: Ah but language a has problems with y

Me: Yes but language b doesn't

etc...

You conclude OO is inherently flawed

I conclude that there are now languages without flaws...

zorbo4• 12 years ago

The article pulls a Fallacy fallacy, otherwise known as an "argument from fallacy". Basically what he says is "none of the arguments against me are correct, because fallacy X". I simply ignore such statements, because they make discussion impossible.

yxhuvud• 12 years ago

One really big problem with how your argument is structured is that you cherry pick warts from OO languages, while at the same time cherry picking good solutions from FP languages.

It would be quite simple to turn the argument around by doing the exact opposite thing - cherrypicking nice things from OO languages and warts from FP languages and then use the same argument about scotsmen in the other direction.

Arguments about whole categories of languages when not limiting yourself to least common denominators end up stupid pretty fast as it is always possible to find one example or another that fit the point you want to claim.

mcphage• 12 years ago

That's not really the No True Scottsman falacy, though. A NTSF would be something like:

A: Java is too verbose.

B: Java isn't really a OOP language.

This is more like:

A: Java is too verbose.

B: Sure, but that's a statement about Java, not a statement about OOP.

If you list a bunch of criticisms of OOP languages, that doesn't mean that those criticisms automatically become criticisms of OOP as a concept, merely those of the languages themselves. Especially when you can find OOP languages that don't match that criticism. Java is verbose, yes. But it doesn't mean OOP languages are verbose (what the article author would like to claim), and it doesn't mean that Java isn't an OOP language (what the author believes other people use to deflect the criticism). It means that Java is verbose.

peterashford4• 12 years ago

It's amazing that Java powers all those banks and corporations given how unmaintainable, ungrokable, complex and brittle it is. The fools.

cturner• 12 years ago

What are examples of a good approaches to generic logging? In the past I've found log4j and the python stdlib logging to be frustrating to work with. But when I had a shot at writing my own approaches, I found it to be one of those domains that's harder to deal with than it looks. Someone will have though - interested to know of a good approach.

MrDosu8• 12 years ago

There are multiple approaches (my favs being dependency injection or aspect oriented). The actual case of a dependency affecting an entire application is called a "cross cutting concern", there is great literature to be found under that term that explains it better then I ever could. It highly depends on the use case though, just have it in your toolbox (and dont get in the habit of argueing when you are tasked to build a house whether you should use the hammer OR the saw like some peeps in this thread. Select the right tool for the right circumstance dont just limit yourself to one).

yoodenvranx• 12 years ago

What I would love to see monthly or quarteryearly "competition" between functional and object oriented programmers. For each competition a jury selects a problem and then everybody can try to solve this problem as nice and clean as possible for his preferred programming language / paradigm. The best solutions are then judged / commented on by experts and put on a website. By this you would have perfect examples how each language / paradigm deals with a certain problem.

This is something I miss from the discussion: for each computational problem there is one tool which is "best" to solve it. Sometimes it is some esoteric Haskell magic and sometimes it is some lowlevel C++ bit manipulation.

BozeWolf• 12 years ago

Functional has not much to do with object oriented. Scala for example is both functional and OO. I think you mean the competition between imperative and functional languages.

aikah3• 12 years ago

It's not clear where the line is to me.I mean,it's obvious fr Erlang or Haskell.But isnt clojure imperative to some extent?

While I understand the notion of pure FP.Shouldnt we say that FP is more of a toolbox that can be used in many languages,some making it easier than others. I mean FP in Java 7 is a pipe-dream while any language that has lambdas can be considered as functional? or should lazy evaluation be another precondition?

that's a question.

d--b2• 12 years ago

Oh come on! Now some kids are going to drop out of college to make this idea a startup...

physical_salmon• 12 years ago

More of this. This endless debate about what is better - functional or OO is leading nowhere. The OO side is winning, since the majority of the industry is using it. The way to tear down the OO "hype", is by replacing things used in the industry with better alternatives written in a functional language.

Git (C) has eaten up both Darcs (Haskell) and Mercurial (Python), even though Python and Haskell are "clearly" superior languages, according to some.

ygra• 12 years ago

Git's success has probably little to do with its implementation language.

TheLoneWolfling• 12 years ago

Look at The Computer Language Benchmarks Game.

It would be interesting to do a contest where each month a jury selects one of those problems and everyone focuses on that problem. The "boilerplate" is already there.

platz• 12 years ago

Coding to beat a benchmark problem is different from producing good code in the general case.

igouy• 12 years ago

The web development platform comparison

https://www.plat-forms.org/

chris_wot5• 12 years ago

My goodness this guy takes a long time to get to any point!

Right now I've gotten to the point where he writes "We should note the irony that they are using Linux to explain OOP concepts, even though Linux is written in C, which is not an OOP language."

And yet... it implements OO concepts throughout the kernel. He then quotes Torvalds' comment about C++, yet does not mention that OO concepts are used.

This guy references the most random things. Some guy on HN and a Kuro5hin article from 2002 (he ought to look up my article on Buddhism, which shows that anyone could write anything on K5)...

No offense, but this massive rant could do with a copyeditor. More brevity would help me understand what point he is trying to make.

gone35• 12 years ago

A wall of text indeed: at 30,000 words (including quotes), it's about the same length of a 100-page novella. You and the other commenters were not exaggerating.

Interestingly enough, 30,000 words is also a common 'crisis point' among aspiring writers[1]. Maybe that's what forced the article short.

[1] http://emmadarwin.typepad.com/thisitchofwriting/2011/07/the-...

smenko2• 12 years ago

Mate, you should learn Scala before writing about it...

scala> def hasUppercase(s: String) = s.exists(_.isUpper)

hasUppercase: (s: String)Boolean

scala> hasUppercase("Charlie Brown")

res2: Boolean = true

scala> hasUppercase("schmuck")

res3: Boolean = false

chriswarbo5• 12 years ago

From TFA:

Please note that, below, when I refer to a multi-paradigm language, such as Scala, as an OOP language, I am specifically referring to the OOP qualities in that language. And I would like you to ask yourself, if you use a multi-paradigm language to write in the “functional” paradigm, are you actually gaining anything from the OOP qualities of that language? Could you perhaps achieve the same thing, more easily, using a language that is fundamentally “functional”, rather than object oriented?

smenko2• 12 years ago

Yes, isUpper is a method on Char, _.isUpper is a lambda that is given to exists, which is a method on the trait TraversableOnce, which String happens to implement, along with many other things, such as Option and Future. Where's the OO and where's the functional? In the Clojure example in the OP does the author realise that all of those things are in effect Java objects? Does any of this make the code better or worse?

But that's not the point, the Scala code provided there is beyond ignorant, whoever wrote that has no right to be judgemental of the language or its founding paradigms.

frowaway001• 12 years ago

are you actually gaining anything from the OOP qualities of that language

Yes.

Could you perhaps achieve the same thing, more easily, using a language that is fundamentally “functional”, rather than object oriented?

No.

(That was easy. :-D)

kevinkyyro3• 12 years ago

This blew my mind. The "scala" example he used was literally a java code snippet pulled from here http://batsov.com/articles/2011/05/12/jvm-langs-clojure/

IT'S LITERALLY JAVA SYNTAX, COMPLETELY INVALID SCALA.

Fice2• 12 years ago

One more quote by Alan Kay:

«OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them.» (E-mail to Stefan Ram, 2003, http://www.purl.org/stefan_ram/pub/doc_kay_oop_en)

d--b2• 12 years ago

It reminds me of the time when Linux users were ranting about Windows... Somehow everybody ended up with a Mac. Hold on Lawrence, things are going to get better.

mojuba5• 12 years ago

No True Essay Writer steals reader's time. (This guy used some EssayFactoryFactory I suppose?)

flohofwoe• 12 years ago

Another 'the sky is falling' article ;) Can someone provide a TL;DR who worked through the entire write-up? When I hear 'OOP must die' I can't help but think that we're throwing away the good bits too and will reinvent the wheel in a few years.

It would be good to define the absolute essence of OOP first, because in 30 years it has been overloaded so much with different meaning that it means everything today. For instance:

- It was a hype/next-big-thing/snake-oil-salesman-material: CORBA and COM used to the silver bullets in the 90's which would solve all software development problems by building applications from reusable components which could interact with each other (but in reality, the only thing that came out of it was embedding Excel tables into Word documents). If this is the essence of OOP, then yes, it deserves to die.

- If it the software design principle of thinking 'object oriented'? Then this is already a 2-edged sword. The main problem here is to fall into the trap of trying to model a software system after the real world (the animal-cat-dog problem). Is inheritance, polymorphism, encapsulation, message passing a bad thing? I would say mostly not, but it can be abused, most of these solved actual real-world problems.

- Are the OOP language features the essence of OOP? 'Everything is an object'? Multiple inheritance? Here it gets fuzzy because languages (and their standard frameworks) are so radically different.

To me the pragmatic essence of OOP is that it groups the data and the code which works on that data. If there's a pure C library which has a function to create some sort of 'context' and then has functions which take a context pointer as argument, then this is object-oriented to me. Most other features, like classes, inheritance, runtime polymorphism is just sugar-topping; useful in some cases, but not the essence.

Even with this simple definition, it is easy to fall into the real-world-object trap by designing complex systems as some sort of object-soup which communicate through messages. That's hard to debug and optimise for performance (but it's still easier to maintain then having one big soup of global functions and variables).

Data-oriented-design is one obvious answer to fix some OOP-design-problems. First concentrate on the data, not the code, divide it into 'hot and cold' data, group by access patterns, think about cache misses. After that, the code that works on that data usually 'writes itself'.

And, IMHO OOP itself is completely orthogonal to the really hard problems: memory safety and lifetime management without runtime overhead, concurrency, reducing complexity and improving maintainability of big software systems.

Your mileage may vary of course, my background is games programming, and I started with Z80 assembly, dabbled a bit with Pascal, Forth and Lisp in the 80's before coming to C, then C++ and Python, and I tend strongly towards Rust for future work. I'm only using the parts of C++ that I feel improve on raw C (there once was an object-oriented UI framework on the Amiga called Intuition which bolted classes and methods on top of C, that was the point where I thought that it's really time to learn some C++).

aikah3• 12 years ago

To me the pragmatic essence of OOP is that it groups the data and the code which works on that data. If there's a pure C library which has a function to create some sort of 'context' and then has functions which take a context pointer as argument, then this is object-oriented to me. Most other features, like classes, inheritance, runtime polymorphism is just sugar-topping; useful in some cases, but not the essence.

You nailed it.It's just more elegant to group things as a class than having fopen,fread,fclose where you pass a resource as a first argument. Polymorphism then is the consequence of that design since you could have the same interface for a file,a socket,an archive or whatever. When in use,you can ignore the nature of the resource and just remember it can be opened,read or closed,which allows to write abstract logic on top of it.

musername3• 12 years ago

I see no reason pure modularization wouldn't achieve the same thing. In fact, that's what I took OOP to mean for a long time. But it doesn't need to be bound to the data, or mutable as in not functional. If member functions return objects and data, they can be used in a functional approach and to construct polymorphism or inheritance through currying.

Are the OOP language features the essence of OOP? 'Everything is an object'? Multiple inheritance?

if an object can be reduced to a symbol like a void-pointer to data or a function that returns data and this object can be related to others on a graph, then that's still general enough.

Imperative Programms as well as Object models can be well organized in graphs. The CPU or bytecode doesn't know about objects anyway. So it's an abstraction and you need to applay that in a moderate fashion, depending on the complexity of the problem, so for simple or efficient procedures imperative style is not to be replaced by OOP. fopen, fread etc. all are abstractions of underying system calls, but depend on speed, so light OOP is a good fit there,

MrDosu8• 12 years ago

Basic tl;dr: Some HN users where mean to the writer so he went on a big rant on how they were all wrong while spouting wild irrelevant technical reasons why tools that are designed to model certain classes of real world systems are completely false and everyone in the world is too dumb to acknoledge his genius.

mojuba5• 12 years ago

Mediocre and bad code tends to multiply entities. On a small scale it's usually redundant global and local variables, or just plain stupid code like this:

    if (NULL == lpDataPointer)
    {
        /* Return FALSE */
        return FALSE;
    }
    else
    {
        /* Return TRUE */
        return TRUE;
    }

Now give the same programmer an OOP language and see what happens. Even a bigger disaster masqueraded as an OOP system.

I know I kind of repeat the author's True Scotsman's metaphor, but my point is, you can't kill a return operator or, say, code comments just because the majority of code around us tends to misuse it. Unfortunately for the OOP paradigm it makes multiplying even bigger entities easier, and at the same time its learning curve invites lo-fi coding.

Who's to blame?

MrDosu8• 12 years ago

Whats wrong about the above code? Does it not do what it means to do? Is your personal feeling for how this construct should be written syntactically any measure of intelligence?

louthy3• 12 years ago

It can be written:

    return (NULL != lpDataPointer)

johan_larson• 12 years ago

Another day, another FP evangelist.

aikah3• 12 years ago

Functional languages such as Haskell, Erlang and Clojure offer powerful approaches to the problems that software developers have always faced.

So do JAVA,Ruby,C#,...

Why do FP folks always try to sell the fact the "OOP=bad / FP=good"?. I'm found of OOP, i'd never say "FP=bad",that would be ridiculous,FP concepts are interesting,i'd even say FP is fun.

Both are tools in my box.

Now if the problem is JAVA,good,we can talk about JAVA shortcomings.But JAVA is only one implementation of OOP concepts.

Fice2• 12 years ago

In the article and elsewhere Clojure is often used as an example of an anti-OOP language, yet by either Alan Kay's definition (quoted in my previous comment) or by Bertran Meyer's definition^1 Clojure uses the object oriented paradigm. Clojure is more object oriented than PHP or C++ which only provide some OO-inspired data abstraction mechanisms, but are not based around them.

^1 «Object oriented software construction is the building of software systems as structured collections of implementations of abstract data types.» Bertran Meyer. Object Oriented Software Construction, 2nd edition, 1997.

yogthos3• 12 years ago

OOP ideas aren't exclusive to that paradigm, turns out that things like polymorphism work very naturally in a functional language.

davelnewton5• 12 years ago

Too... many... quotes...

An unreasoned rant that's more parody than substance. Seems more a derivative pile-on than anything new or valuable.

robmccoll• 12 years ago

Procedural programming for the win. One can write in an object-oriented style or functional style in C, but the language has enough of a barrier to entry to writing code of these varieties that most people write KISS procedural code unless the particular situation really benefits from doing otherwise.

nbevans6• 12 years ago

This is a truly fantastic post. It isn't a rant. It's a story of enlightenment that I encourage all HN'ers to read and absorb.

Disregard or play down the contents of this fantastic post at your peril. Understanding it and groking it could save you 5 years, 10 years or even a lifetime of writing software in the wrong way.

davelnewton5• 12 years ago

I have to assume you're being funny.

Otherwise I'd like a batch of whatever it is you're smoking.

nbevans6• 12 years ago

See, this is the brilliance of HN.

Not only is the OP mistaken as being almost a troll post but anyone who actually warns "er, no guys, this post is for real and you need to understand it or at least respect it to move forward in your careers" is also mistaken as "just being funny".

Just to clarify. No the OP is not a troll post or anything like it. It is deadly serious. And I am also being completely serious.

The OP is just someone who reached the end of his learning path of OOP. He found all its flaws and weaknesses and then discovered there is a whole other world out there called FP and that there are even languages which combine the best parts of OO and FP into one. Why is this considered a problem? Some people almost seem insulted by it. He is just trying to help you guys realise that the floor on which you're standing is not quite as solid as you mistakenly think.

As I said, it is a story of enlightenment. Discredit it at your peril, as you are only harming your own self development as a programmer. There is nothing wrong in learning FP and adding it to your toolbox. This doesn't mean you have to "give up" on OO. It just means you have two tools to select from rather than just one.

Observation: Unless they are famous or head up some popular OSS project, it seems that software developers are incapable of identifying or even respecting those who are clearly more knowledgeable/experienced than themselves.

alkonaut2• 12 years ago

What OO brought to The table (and what many advocates of FP are forgetting) is context sensitivity, that is, functions/methods are brought in scope by the owning object rather. Typing dog.bark() is a thousand times more powerful in terms of tooling than bark(dog) or SomeDogPackage::bark(dog). I prefer the FP style of coding but I can't see average devs giving up on Java/C# style tools.

Sure OO brought a lot of little code smells too, and we often end up making bad code, but it's not like we have to. Polyglot programmers that use e.g. Java+Scala or C#+F# probably make their OO code much better than others. I have almost completely stopped using mutable objects, long inheritance chains and nulls in C#, as an influence from F#.

For some scenarios having mutable objects is a near perfect fit (scene graphs for games or UI:s are good examples of code where both FP and non-object imperative usually looks worse).

yogthos3• 12 years ago

The good parts of OO aren't exclusive to it though. For example, Clojure provides protocols (http://clojure.org/protocols) and multimethods (http://clojure.org/multimethods) which result in far more flexible polymorphism than a language like Java.

alkonaut2• 12 years ago

I agree many parts can be brought to FP but most importantly the languages of the future must be developed with tools in mind and in tandem with the tools. Too often new langs seem to be developed as command line compiled experiments which only (much) later get IDE support. At that point some decision may already have been made that makes tooling harder, such as not allowing or encouraging methods "on" types.

reacweb• 12 years ago

Object Oriented Programming is not for all developers the same way that some excellent developers have problems with functional programming. I think OO is very well suite for bottom up way of thinking (http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design).

kelvin0• 12 years ago

This is like reading John Galt's long winded speach in Ayn Rand`s Atlas Shrugged (and I shuddered ...) There are things I will never be able to 'un-read' ;)

notacoward• 12 years ago

It's hard to take an argument about Java's verbosity and FP's expressiveness seriously when it runs to 30K words.

insertion• 12 years ago

As someone who is more familiar with OOP, I would love to see examples/hear more alternative approaches to organising code.

Let's say that you want to design a CRUD app, but you're not going to use OOP. What are some of the ways you could choose to structure your code? Would you still use a pattern like MVC?

yogthos3• 12 years ago

You can take a look at how apps are structured in Clojure with the [Luminus](http://www.luminusweb.net/docs) microframework as an example.

chriswarbo5• 12 years ago

My main issue with OOP is that classes/objects conflate a whole bunch of notions, and end up not being very good at any of them.

Modularity and design-by-contract are better implemented by module systems ( http://en.wikipedia.org/wiki/Standard_ML#Module_system )

Encapsulation is better served by lexical scope ( http://en.wikipedia.org/wiki/Scope_(computer_science)#Lexica... )

Data is better modelled by algebraic datatypes ( http://en.wikipedia.org/wiki/Algebraic_data_type )

Type-checking is better performed structurally ( http://en.wikipedia.org/wiki/Structural_type_system )

Polymorphism is better handled by first-class functions ( http://en.wikipedia.org/wiki/First-class_function ) and parametricity ( http://en.wikipedia.org/wiki/Parametric_polymorphism )

As for an alternative to "CRUD app using MVC", I'd probably recommend Functional Reactive Programming ( http://en.wikipedia.org/wiki/Functional_reactive_programming ). MVC is a way to architect interactive simulations and games, developed in the live environment provided by SmallTalk.

However, I imagine your intention was for something closer to the server-side code of a form wizard on a Web page, rather than a game. In which case, I'd avoid MVC-style approaches completely, since they're inappropriate. It's much more straightforward to model servers as UNIX pipelines turning HTTP requests into HTTP responses ( http://en.wikipedia.org/wiki/Pipeline_(Unix) )

Pipelines turn out to be a great fit for functional programming: lots of small, single-purpose pieces, composed together into a server which requests flow into and responses flow out.

theoh• 12 years ago

Might be interesting to compare to https://news.ycombinator.com/item?id=8411225

axilmar3• 12 years ago

I've written my rebuttal here:

http://axilmar.blogspot.gr/2014/10/object-oriented-programmi....

chris_wot5• 12 years ago

That's awesome :-) but... how did you manage to get through that massive rant and extract the author's main points?

axilmar3• 12 years ago

I just read it, skipping the non-essential parts, after quickly scanning them.

I might have missed one or two points, but it doesn't really matter.

nbevans6• 12 years ago

You don't come across well in this at all. 200 classes in a OO project is pretty small really. And you've never used DI ever? Really?

peterashford4• 12 years ago

I've written large systems in Java, C++ and yes, I have never ever used DI. Nor even seen any kind of AbstractFactory in Java.

axilmar3• 12 years ago

I have never used DI in my 16 year professional career in C++ and Java land.

gtirloni2• 12 years ago

Say I want to migrate from OOP to Functional and avoid doing things the wrong way the first time, like we supposedly did with OOP and it's too late to fix. What book/code/etc is a good reference for high-quality, practical proven Functional programming best practices?

tome• 12 years ago

It might be easier for those in the know to make a recommendation if they have an example of the kind of book/code/etc you're looking for on the OO side. What do you recommend for high-quality, practical proven OO programming best practices?

gtirloni2• 12 years ago

I have no idea. Programming is not my main area and thus I look for advice from other people to avoid doing stupid mistakes by following best practices. That being said, OO people will often point me to the design patterns book, etc. Is something similar needed for FP?

I've got the Haskell Craft book but haven't practiced enough. It seems good enough for me but, as people are learning more and more about using OO and FP in the real world (thus such criticism), I would like to keep current.

chriswarbo5• 12 years ago

It's not an introduction, but this page collects a lot of nice info for Haskell:

http://dev.stephendiehl.com/hask/

As for "best practices", there are some interesting answers on http://stackoverflow.com/questions/842026/principles-best-pr...

There certainly aren't as many 'design patterns' style things in functional programming as there are in OO. In general, it seems to be because:

- FP systems are much smaller than OO systems (due to conciseness and not as much large-scale use)

- FP favours immutability over encapsulation, so you can re-use existing map/fold/filter/etc. functions rather than having to rewrite them in small pieces spread throughout your app. Hence you don't need to decide how they're implemented.

- Pure functions take everything in via arguments and give everything out via return values. There aren't many ways to get that wrong. In OO any method can affect the application in all kinds of ways, so there are all kinds of ways to get it wrong, requiring best-practices to avoid them.

- In FP, we're generally turning some input into some output. If we're writing code that doesn't seem to get anything from our input closer to something in our output, we should stop and think for a minute. In OO we're encouraged not to think in terms of solving a problem: instead we try to define ontologies and hierarchies, implement models of the domain, etc. only then, once we've bootstrapped a simulation of our business entities and their interactions, do we write the actual code for the problem we have: `Order::newFromFile('input.csv').ship()`

louthy3• 12 years ago

A few books that helped me:

* Real-World Functional Programming - With Examples in F# and C# by Thomas Petricek

This helped me a lot because I'd been working solidly with C# for 8 years leading up to it (C++ before, and C before that), so I was very much in C mode. It presents reasons for the functional approach and shows side-by-side C# and F# examples of the various topics covered. It also takes a more practical approach, rather than 'yet another fibonacci example' which you'll see on lots of functional programming tutorials.

* Programming in Haskell by Graham Hutton

Basically a text-book on learning Haskell, but covers a lot of fundamentalist functional thinking.

* Pearls of Functional Algorithm Design

Once you have the basics of functional programming knocked then go for this. It teaches you how to think about reducing problems.

bigpeopleareold• 12 years ago

I read this all the way through because I love reading articles that bash OOP. I haven't read an OOP-bashin' article in awhile, so it is great to read a good ol' bashin' that is current. There were a number of times I giggled, like with the "fat models" debate in Rails, or the number of times where he said people wasted their best moments of their career worrying about clean OOP code.

I have bookmarked this good ol' OOP bashin' and I am considering it a must-read going forward, because I love me some OOP bashin'.

FallDead• 12 years ago

I think articles like these are akin clickbait. Mature developers understand that every paradigm has it's place. I mainly use functional for data processing and pipelining, and OOP for object modeling.

greymarch• 12 years ago

Good heavens. What a mess. This guy rambles on forever, and steps on his own points over and over again. I am desperate to leave comments on the actual site, and apparently 2 comments have been left, but I dont see the comments on the actual site nor is there a way to post a comment on the actual site. I am guessing whomever runs this site shut-down the comments section because this joker made an ass of himself with his endless rambling.

peterashford4• 12 years ago

"Here, truly, we run into the mental weaknesses of the Blub programmer"

Oh, put your sense of superiority away!

unsupak• 12 years ago

click bait

kevinkyyro3• 12 years ago

My main problem with the proposition that "OOP is awful" is that the argument is basically "it's not the best so it's the worst".

The expression problem is not solved by every language, but basically because Lisps and Haskell solve it in their own ways, it is concluded that OOP is worthless.

There are a number of practical reasons OOP could be liked, other than the marketing of it to the Enterprise. It's a natural way to model real things. The syntax lends itself to things like auto-complete (foo.ba<tab>). And being liked is enough to make it not-awful if the people who like it are skilled enough -- it's sufficient even to say it can be better than other paradigms for some people.

Don't mistake that for me saying that OOP is the best at anything, but it's not the worst at everything.

frankz00• 12 years ago

TLDR. I think the "frameworks" associated with OOP are the expensive disaster. And MVC kind of pees in the face of OOP in my opinion....

geoom• 12 years ago

I think he should changes the headline to "Poor OO Programming Language Implementation is an expensive disaster which must end"

Object Oriented Programming is an expensive disaster which must end

Related Stories