11 ms·

Object Oriented Programming is an expensive disaster which must end

103 points by lkrubner 12y ago

deleted 12y ago
[deleted]
geoom 12y ago
I think he should changes the headline to "Poor OO Programming Language Implementation is an expensive disaster which must end"
JazCE 12y 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 12y 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.
  - blowski 12y ago
    With that much badly organised text, it's almost like it was designed never to be read at all.
  - musername 12y ago
    looks good on 4.3" indeed
- blowski 12y 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 12y 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 12y ago
I guess you can get away with attacking strawmen if you pre-emptively claim your opponents are no-true-scotsmaning you.
- kitd 12y ago
  He won't get away with anything in Scotland after that, especially calling them "Scottsmen".
colinramsay 12y ago
It doesn't bode well for this article when they make a mistake in the first line. It's "Scotsman", not "Scottsman".
- chris_wot 12y ago
  Actually, he later calls it an Untrue Scottman.
musername 12y 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.
DanielBMarkham 12y 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.
lucozade 12y ago
A little bit of data hiding wouldn't have gone amiss.
- thomasfl 12y ago
  Spot on!
buro9 12y 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.
zorbo 12y 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.
- chriswarbo 12y 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.
  - davelnewton 12y ago
yoodenvranx 12y 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 12y 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.
  - aikah 12y 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.
    - kevinkyyro 12y ago
      It seems practical to say a functional language has first-class functions and a purely functional language has first-class functions and no mutable state -- purely functional -> functional and not imperative. I would identify a language as distinctly imperative if it has mutable state and has statements, e.g. operations with side-effects that have no return values (ex: loops, if's, void methods) -- not to be confused with expressions, which may have side effects, but always have return values. So, if you look at the matrix of possibilities based on these classifications, a language can be any combination of (OO or not OO) and (functional and/or imperative). It is trickier yet when many languages support multiple paradigms but encourage a subset. Or if you choose to restrict functional to require anonymous functions _without_ syntactic sugar. Does that help though?
chris_wot 12y 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 12y 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-30k-doldrums.html http://emmadarwin.typepad.com/thisitchofwriting/2011/07/the-...
- deleted 12y ago
  [deleted]
smenko 12y 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
- chriswarbo 12y 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?
  - smenko 12y 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 12y 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)
- kevinkyyro 12y 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/ http://batsov.com/articles/2011/05/12/jvm-langs-clojure/ IT'S LITERALLY JAVA SYNTAX, COMPLETELY INVALID SCALA.
Fice 12y 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 http://www.purl.org/stefan_ram/pub/doc_kay_oop_en)
d--b 12y 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.
mojuba 12y ago
No True Essay Writer steals reader's time. (This guy used some EssayFactoryFactory I suppose?)
flohofwoe 12y 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++).
mojuba 12y 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?
- MrDosu 12y 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?
  - louthy 12y ago
    It can be written: return (NULL != lpDataPointer)
    - MrDosu 12y ago
      I know, it can also be written in many other ways. What decides which one is more correct if they are all semantically equivalent? Is it less characters? Is it using exactly as many 'e's as 'a's? Is it the unnecessary braces?
      - mojuba 12y ago
        There is probably no "correct" way of writing this, but there are ways of making your next code maintainer's life easier (which might be you in a few months from now). One line is easier to read and understand than 10, especially if that one line is just "return p".
johan_larson 12y ago
Another day, another FP evangelist.
aikah 12y 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.
Fice 12y 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.
- yogthos 12y ago
  OOP ideas aren't exclusive to that paradigm, turns out that things like polymorphism work very naturally in a functional language.
davelnewton 12y 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 12y 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.
nbevans 12y 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.
- davelnewton 12y ago
  I have to assume you're being funny. Otherwise I'd like a batch of whatever it is you're smoking.
  - nbevans 12y 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.
    - davelnewton 12y ago
      Now I know you're being funny; brilliant :) Oh, as for "us guys"--guess what? Some of "us guys" use the appropriate tool for the job, whether it's OOP, FP, IP, etc. and have been doing so for decades.
alkonaut 12y 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).
- yogthos 12y ago
  The good parts of OO aren't exclusive to it though. For example, Clojure provides protocols (http://clojure.org/protocols http://clojure.org/protocols) and multimethods (http://clojure.org/multimethods http://clojure.org/multimethods) which result in far more flexible polymorphism than a language like Java.
  - alkonaut 12y 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 12y 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 http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design).
kelvin0 12y 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 12y ago
It's hard to take an argument about Java's verbosity and FP's expressiveness seriously when it runs to 30K words.
insertion 12y 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?
- yogthos 12y ago
  You can take a look at how apps are structured in Clojure with the [Luminus](http://www.luminusweb.net/docs http://www.luminusweb.net/docs) microframework as an example.
- chriswarbo 12y 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 http://en.wikipedia.org/wiki/Standard_ML#Module_system ) Encapsulation is better served by lexical scope ( http://en.wikipedia.org/wiki/Scope_(computer_science)#Lexical_scoping http://en.wikipedia.org/wiki/Scope_(computer_science)#Lexica... ) Data is better modelled by algebraic datatypes ( http://en.wikipedia.org/wiki/Algebraic_data_type http://en.wikipedia.org/wiki/Algebraic_data_type ) Type-checking is better performed structurally ( http://en.wikipedia.org/wiki/Structural_type_system http://en.wikipedia.org/wiki/Structural_type_system ) Polymorphism is better handled by first-class functions ( http://en.wikipedia.org/wiki/First-class_function http://en.wikipedia.org/wiki/First-class_function ) and parametricity ( http://en.wikipedia.org/wiki/Parametric_polymorphism 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 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) 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 12y ago
Might be interesting to compare to https://news.ycombinator.com/item?id=8411225 https://news.ycombinator.com/item?id=8411225
axilmar 12y ago
I've written my rebuttal here: http://axilmar.blogspot.gr/2014/10/object-oriented-programming-is-disaster.html http://axilmar.blogspot.gr/2014/10/object-oriented-programmi....
- chris_wot 12y ago
  That's awesome :-) but... how did you manage to get through that massive rant and extract the author's main points?
  - axilmar 12y 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.
- nbevans 12y 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?
  - peterashford 12y 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.
    - nbevans 12y ago
      I don't believe you. Are you mistaking DI for meaning a full blown IoC framework? DI is merely the abstract computer science concept. In FP land we call it partial application or P/A. But it is essentially the same thing. I honestly cannot fathom how a large project would look without DI. It must be hideous with massive amounts of coupling all over the place i.e. not something to be proud of. Refactoring must be very hard. I would have to take a few guesses to know what an AbstractFactory is. That is a "J2EE Javaism" and always has been. So you aren't alone there ;)
gtirloni 12y 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 12y 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?
  - gtirloni 12y 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.
- chriswarbo 12y ago
  It's not an introduction, but this page collects a lot of nice info for Haskell: http://dev.stephendiehl.com/hask/ http://dev.stephendiehl.com/hask/ As for "best practices", there are some interesting answers on http://stackoverflow.com/questions/842026/principles-best-practices-and-design-patterns-for-functional-programming 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()`
bigpeopleareold 12y 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 12y 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 12y 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.
peterashford 12y ago
"Here, truly, we run into the mental weaknesses of the Blub programmer" Oh, put your sense of superiority away!
recursion1133 12y ago
The whole point of OO was to allow more complex programs with reusable pieces/pieces that can be edited in isolation/exchangeable pieces, while also organizing everything. Saying to write everything procedurally, thus, removing features, seems inane to me.
unsupak 12y ago
click bait
kevinkyyro 12y 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 12y 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....

103 points by lkrubner 12y ago

deleted 12y ago

[deleted]

geoom 12y ago

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

JazCE 12y 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 12y 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.
- blowski 12y ago
  With that much badly organised text, it's almost like it was designed never to be read at all.
- musername 12y ago
  looks good on 4.3" indeed
blowski 12y 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 12y 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 12y ago

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

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

colinramsay 12y ago

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

chris_wot 12y ago
Actually, he later calls it an Untrue Scottman.

musername 12y 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.

DanielBMarkham 12y 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.

lucozade 12y ago

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

thomasfl 12y ago
Spot on!

buro9 12y 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.

zorbo 12y 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.

chriswarbo 12y 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.
- davelnewton 12y ago

yoodenvranx 12y 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 12y 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.
- aikah 12y 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.
  - kevinkyyro 12y ago
    It seems practical to say a functional language has first-class functions and a purely functional language has first-class functions and no mutable state -- purely functional -> functional and not imperative. I would identify a language as distinctly imperative if it has mutable state and has statements, e.g. operations with side-effects that have no return values (ex: loops, if's, void methods) -- not to be confused with expressions, which may have side effects, but always have return values. So, if you look at the matrix of possibilities based on these classifications, a language can be any combination of (OO or not OO) and (functional and/or imperative). It is trickier yet when many languages support multiple paradigms but encourage a subset. Or if you choose to restrict functional to require anonymous functions _without_ syntactic sugar. Does that help though?

chris_wot 12y 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 12y 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-30k-doldrums.html http://emmadarwin.typepad.com/thisitchofwriting/2011/07/the-...
deleted 12y ago
[deleted]

smenko 12y 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

chriswarbo 12y 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?
- smenko 12y 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 12y 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)
kevinkyyro 12y 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/ http://batsov.com/articles/2011/05/12/jvm-langs-clojure/ IT'S LITERALLY JAVA SYNTAX, COMPLETELY INVALID SCALA.

Fice 12y 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 http://www.purl.org/stefan_ram/pub/doc_kay_oop_en)

d--b 12y 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.

mojuba 12y ago

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

flohofwoe 12y 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++).

mojuba 12y 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?

MrDosu 12y 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?
- louthy 12y ago
  It can be written: return (NULL != lpDataPointer)
  - MrDosu 12y ago
    I know, it can also be written in many other ways. What decides which one is more correct if they are all semantically equivalent? Is it less characters? Is it using exactly as many 'e's as 'a's? Is it the unnecessary braces?
    - mojuba 12y ago
      There is probably no "correct" way of writing this, but there are ways of making your next code maintainer's life easier (which might be you in a few months from now). One line is easier to read and understand than 10, especially if that one line is just "return p".

johan_larson 12y ago

Another day, another FP evangelist.

aikah 12y 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.

Fice 12y 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.

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

davelnewton 12y 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 12y 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.

nbevans 12y 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.

davelnewton 12y ago
I have to assume you're being funny. Otherwise I'd like a batch of whatever it is you're smoking.
- nbevans 12y 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.
  - davelnewton 12y ago
    Now I know you're being funny; brilliant :) Oh, as for "us guys"--guess what? Some of "us guys" use the appropriate tool for the job, whether it's OOP, FP, IP, etc. and have been doing so for decades.

alkonaut 12y 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).

yogthos 12y ago
The good parts of OO aren't exclusive to it though. For example, Clojure provides protocols (http://clojure.org/protocols http://clojure.org/protocols) and multimethods (http://clojure.org/multimethods http://clojure.org/multimethods) which result in far more flexible polymorphism than a language like Java.
- alkonaut 12y 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 12y 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 http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design).

kelvin0 12y 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 12y ago

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

insertion 12y 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?

yogthos 12y ago
You can take a look at how apps are structured in Clojure with the [Luminus](http://www.luminusweb.net/docs http://www.luminusweb.net/docs) microframework as an example.
chriswarbo 12y 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 http://en.wikipedia.org/wiki/Standard_ML#Module_system ) Encapsulation is better served by lexical scope ( http://en.wikipedia.org/wiki/Scope_(computer_science)#Lexical_scoping http://en.wikipedia.org/wiki/Scope_(computer_science)#Lexica... ) Data is better modelled by algebraic datatypes ( http://en.wikipedia.org/wiki/Algebraic_data_type http://en.wikipedia.org/wiki/Algebraic_data_type ) Type-checking is better performed structurally ( http://en.wikipedia.org/wiki/Structural_type_system http://en.wikipedia.org/wiki/Structural_type_system ) Polymorphism is better handled by first-class functions ( http://en.wikipedia.org/wiki/First-class_function http://en.wikipedia.org/wiki/First-class_function ) and parametricity ( http://en.wikipedia.org/wiki/Parametric_polymorphism 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 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) 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 12y ago

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

axilmar 12y ago

I've written my rebuttal here: http://axilmar.blogspot.gr/2014/10/object-oriented-programming-is-disaster.html http://axilmar.blogspot.gr/2014/10/object-oriented-programmi....

chris_wot 12y ago
That's awesome :-) but... how did you manage to get through that massive rant and extract the author's main points?
- axilmar 12y 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.
nbevans 12y 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?
- peterashford 12y 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.
  - nbevans 12y ago
    I don't believe you. Are you mistaking DI for meaning a full blown IoC framework? DI is merely the abstract computer science concept. In FP land we call it partial application or P/A. But it is essentially the same thing. I honestly cannot fathom how a large project would look without DI. It must be hideous with massive amounts of coupling all over the place i.e. not something to be proud of. Refactoring must be very hard. I would have to take a few guesses to know what an AbstractFactory is. That is a "J2EE Javaism" and always has been. So you aren't alone there ;)

gtirloni 12y 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 12y 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?
- gtirloni 12y 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.
chriswarbo 12y ago
It's not an introduction, but this page collects a lot of nice info for Haskell: http://dev.stephendiehl.com/hask/ http://dev.stephendiehl.com/hask/ As for "best practices", there are some interesting answers on http://stackoverflow.com/questions/842026/principles-best-practices-and-design-patterns-for-functional-programming 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()`

bigpeopleareold 12y 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 12y 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 12y 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.

peterashford 12y ago

"Here, truly, we run into the mental weaknesses of the Blub programmer" Oh, put your sense of superiority away!

recursion1133 12y ago

The whole point of OO was to allow more complex programs with reusable pieces/pieces that can be edited in isolation/exchangeable pieces, while also organizing everything. Saying to write everything procedurally, thus, removing features, seems inane to me.

unsupak 12y ago

click bait

kevinkyyro 12y 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 12y 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....