23 ms·

Why OO Sucks by Joe Armstrong (2000)

• jansan 6y ago
  Was this supposed to be posted on April 1st?
  • sodapopcan 6y ago
    Why? ...because Joe Armstrong is some random cynical nobody without a leg to stand on? :raised_eyebrow_emoji: https://en.wikipedia.org/wiki/Joe_Armstrong_(programmer) https://en.wikipedia.org/wiki/Joe_Armstrong_(programmer)
    • sodapopcan 6y ago
      I guess I should have put a /s here, but meh. Bring on the downvotes!!
      • FpUser 6y ago
        It is an army of FP / (insert your own pet paradigm) zealots making sure that there is but one ...
• thirtythree 6y ago
  Firefox says: Warning: Potential Security Risk Ahead
  • marsrover 6y ago
    Because it's not https.
    • TehCorwiz 6y ago
      The site redirects you to https. EDIT: Firefox redirects to https.
      • marsrover 6y ago
        I don't think that's correct. I curled it just to make sure and wasn't met with a redirect. Edit: Ah, firefox redirects you to https. I'm using chrome.
  • deleted 6y ago
    [deleted]
  • TehCorwiz 6y ago
    Same here. Dug in a little and found that it's using a self-signed certificate. From an e-commerce site I might be worried, with this one I'm assuming the site is making a political statement about the centralization of control of trust on the internet.
    • mr_toad 6y ago
      > self-signed certificate. Maybe it is, we can’t tell. Maybe the NSA signed it. Self-signed certificates can’t be trusted unless you have some way of independently verifying then.
• dboreham 6y ago
  "Data structure and functions should not be bound together": not if you don't want that, but often you do, to avoid constantly asking the question "where's the code that messes with this data?". "Everything has to be an object": obviously bad, but also not the case in most OO languages. So...bogus objection. "In an OOPL data type definitions are spread out all over the place": Huh? This one is made up. You can put all your <whatever> in one place if you want to. "Objects have private state": this is a feature not a bug. Exhibit A: JavaScript.
  • jrochkind1 6y ago
    in ruby everything is an object. Of all the things people complain about about ruby, I don't think that's one of them, I don't see how it's a problem.
  • k__ 6y ago
    I found JS to be one of the better OO implementations in the wild. All these OO additions since ES2015 felt like a step back to me.
  • sodapopcan 6y ago
    I mean, OO isn't impervious to this: "Where is the factory to create this object?" "Where are the factorIES that create this object???" "Where is the service to perform this action on this object?" "Where is the manager that coordinates these objects????" This can be solved with some knowledge of DDD (for example) which applies to both paradigms.
  • Igelau 6y ago
    > "Everything has to be an object": obviously bad Personally I prefer when it's all objects. Otherwise you wind up with primitive types that you can't do all the objecty stuff with. Then you wind up with hacks like Java's int vs Integer dichotomy. Compare this with Python where the internals of the integer type are so hidden that it can do things like seamlessly replace it with a bigint. What it is inside doesn't matter because you only care that it answers to the same messages.
    • 6y ago
• RcouF1uZ4gsC 6y ago
  Unfortunately, the article did not have what I think is the best Joe Armstrong quote on OOP. Here it is as quoted in: https://www.johndcook.com/blog/2011/07/19/you-wanted-banana/ https://www.johndcook.com/blog/2011/07/19/you-wanted-banana/ >I think the lack of reusability comes in object-oriented languages, not functional languages. Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.
  • colecut 6y ago
    Thanks, this added extra insight for me
• recursivedoubts 6y ago
  You gotta stick the state somewhere. OO isn't the panacea it was sold as, but it's worked out pretty well for a lot of software. Still, this quote is hilarious: "Object-oriented programming is an exceptionally bad idea which could only have originated in California." --Edsger Dijkstra
  • staticassertion 6y ago
    It's not about eliminating state it's about hiding it. OOP hides state, which means mutability is often shared and hidden.
    • sodapopcan 6y ago
      I'm ripping a quote from another HN user the last OO/FP discussion I read on so apologies if you see this and are like, "Hey! I said that!" buuuut: OO says: "State is hard—let's hide it!" (er, sorry, "encapsulate it") FP says: "State is hard—let's isolate it!"
      • bmitc 6y ago
        I think languages like F# and Racket get it right, because multiple paradigms are available to you. I like F#’s stance on functional-first programming. There are times in which you want to expose the underlying types and there are times you do not. When I recently started a ray tracer implementation, it was a good example of this. The vector, color, point, transform, world, camera, etc. types where all readily implemented by records and discriminated unions which properly isolated but exposed the types. However, for the matrix library, I chose to use F#’s Array.Parallel library and thus a 1D array as the underlying implementation, and this was a perfect use case for using a class. I wanted to hide the implementation of the matrices from the user of the type and encapsulate the internal behavior, only exposing a clean API. Even in that case, the matrix type was immutable because the operations on matrices would simply return new matrices. I think F#’s acceptance of multiple paradigms is really the way to go.
      • colllectorof 6y ago
• jasode 6y ago
  Fyi... the previous submission 2 years ago attracted 380 comments and the top comment says Joe Armstrong changed his mind on some of it. Apparently, the original blog post is actually dated 2000 and not 2019. HN's "past" link: https://hn.algolia.com/?query=Why%20OO%20Sucks%20by%20Joe%20Armstrong&type=story&dateRange=all&sort=byDate&storyText=false&prefix&page=0 https://hn.algolia.com/?query=Why%20OO%20Sucks%20by%20Joe%20...
  • SatvikBeri 6y ago
    For people on mobile, here's Armstrong's quote, via @rhblake: "I wrote a an article, a blog thing, years ago - Why object oriented programming is silly. I mainly wanted to provoke people with it. They had a quite interesting response to that and I managed to annoy a lot of people, which was part of the intention actually. I started wondering about what object oriented programming was and I thought Erlang wasn't object oriented, it was a functional programming language. Then, my thesis supervisor said "But you're wrong, Erlang is extremely object oriented". He said object oriented languages aren't object oriented. I might think, though I'm not quite sure if I believe this or not, but Erlang might be the only object oriented language because the 3 tenets of object oriented programming are that it's based on message passing, that you have isolation between objects and have polymorphism. Alan Kay himself wrote this famous thing and said "The notion of object oriented programming is completely misunderstood. It's not about objects and classes, it's all about messages". He wrote that and he said that the initial reaction to object oriented programming was to overemphasize the classes and methods and under emphasize the messages and if we talk much more about messages then it would be a lot nicer. The original Smalltalk was always talking about objects and you sent messages to them and they responded by sending messages back."
    • goatlover 6y ago
      Sure but Smalltalk also has classes and inheritance where messages are passed between objects. Kay invented the term, but he doesn't control the design of other languages or how OOP ended being understood. Simula also proceeded Smalltalk, and it influenced the design of the C++ object system.
• UweSchmidt 6y ago
  So what's the alternative?
  • recursivedoubts 6y ago
    same alternative there always has been: functional programming no, it won't make coding any better yes, we'll keep hearing about it forever
    • staticassertion 6y ago
      Armstrong isn't even talking about functional programming, he's obviously talking about messaging and actor systems.
• mdswanson 6y ago
  This reads like someone using functional arguments to disparage OO. It also sounds like someone who hasn't written enough OO to understand its benefits.
• deleted 6y ago
  [deleted]
• dang 6y ago
  If curious, past threads: Why OO Sucks by Joe Armstrong (2000) - https://news.ycombinator.com/item?id=19715191 https://news.ycombinator.com/item?id=19715191 - April 2019 (380 comments) Why OO Sucks - https://news.ycombinator.com/item?id=9481369 https://news.ycombinator.com/item?id=9481369 - May 2015 (16 comments) Joe Armstrong: Why OO Sucks - https://news.ycombinator.com/item?id=4245737 https://news.ycombinator.com/item?id=4245737 - July 2012 (256 comments) Why OO Sucks - https://news.ycombinator.com/item?id=474919 https://news.ycombinator.com/item?id=474919 - Feb 2009 (114 comments)
  • wrnr 6y ago
    Thanks, This it's one of those discussion people keep having at nausea, one of those simulacrums people invent so they have something to feel superior about.
    • nanis 6y ago
      > at nausea In case the error was unintentional, _ad nauseam_. [1]: https://en.wikipedia.org/wiki/Ad_nauseam https://en.wikipedia.org/wiki/Ad_nauseam
    • hombre_fatal 6y ago
      Or craftspeople enjoy talking about their craft, and we crowd around shared negative experiences because humans like to commiserate.
      • wrnr 6y ago
        Sure explains why I don't like talking ad ofter software engineers
        • hderms 6y ago
          In my experience it's 50% commiserating and 50% optimistic daydreaming. I prefer the latter but the former has its place.
    • deleted 6y ago
• kabdib 6y ago
  Years ago, I maintained (tongue in cheek) that OOP was a great paradigm not because it was inherently better, but because it was so bad that you had to rewrite your code several times to make it work. And once you've written something three or four times you begin to figure out your mistakes. Then that Gang-of-Four "Design Patterns" book became popular and really screwed things up. I swear I didn't see factories-making-factories-making-factories until that thing was published, then I couldn't go a day without encountering yet another SingletonFactoryWorkerVisitor or whatever was cool that week, ugh. I'm joking, of course. Except about Gang-of-four. And rewriting your code.
  • pwdisswordfish6 6y ago
    > I swear I didn't see factories-making-factories-making-factories until that thing was published No? That's a pretty good description of the sort of metaprogramming that Lisp gives you, and Lispers are really enthusiastic about that kind of thing. People will dispute the parallels, but the real difference comes down to: - non-Lisp languages being significantly less powerful - Lisp's veneer of respectability ... which shouldn't be all that odd, considering the person who gave us "design patterns" was Dick Gabriel, a Lisper. At least the "SingletonFactoryWorkerVisitor" programmers use a nomenclature that reflects the ontology the object is supposed to fit into.
    • kabdib 6y ago
      My guess is that LISP programmers are largely a self-selected group of pretty decent hackers. I'm basing this on some exposure to Lisp Machines in the 1980s, and some Common LISP stuff in the 90s. Generally adults. LISP is my favorite language I'll never ship a product in (well, okay, after SmallTalk :-) ). The Gang-of-Four-driven stuff I saw in C++ and Visual Basic (late 90s and early 00s) still gives me the shivers. Like, "Hey, factories are cool, let's make a bunch of them for no reason because we might need the flexibility someday." Sigh.
    • marcosdumay 6y ago
      There is an effect where some things work well on some languages, but fail completely when translated to others because of superficially unrelated features. Compile and run time code generation seem to be one of those things. Having a mostly pure language (even when there aren't guarantees) makes them much saner. 1 - Pre-compile time generation, by its turn seems to never work very well. And if there is developer interaction between the code generation and compiling, than it's always a disaster.
• LoveMortuus 6y ago
  What if all this... A sucks use B... Is just... Different strokes for different folks? Meaning, due to our brains being differently wired some forms of programming might be easier to understand and use for some people while other for others
  • setr 6y ago
    If you assume "brain wiring", then you're basically making the case that everything is relative, and there's really no way to improve things beyond the state they're in. Programming can never get any better, and languages can never improve, because it's all different strokes for different folks. But we definitely know how to make things worse for just about everyone. Use brainfuck. Or Piet. Or a straight-up turing machine. And if we can make things (pretty much) objectively worse, then it's very likely we can make things objectively better. And there's not much reason to assume we've already reached some kind of end-game, where we're at the tip of the spear for language design, or even the core fundamental models of design. I mean shit, we're only like 60 years into the subject. The legendary programmers of lore still walk the earth. It might take some rewiring, but I for one believe there is a much better world for us to program in, than C, Java and C#. I think much more likely than different "brain wiring" is universal brain damage, from working, breathing, living, with the languages we know, love and despise today. Brain damage might be harder to fix however; in which case we're dealing with language advances one funeral at a time.
• johnnyAghands 6y ago
  Lost this guy way too soon :(
• debacle 6y ago
  As soon as someone identifies an enterprise programming paradigm that is better for 100+ software engineers touching the same codebase, OO will be replaced. Many of the theoretical advantages of OO in low level programming low level don't apply to modern, high level languages, however the encapsulation, convention, and principles (SOLID) of modern OO development are unassailable by current alternatives as the best way to throw that number of software engineers at a single project.
  • titzer 6y ago
    If you think a programming paradigm is going to save you, then you are lost. What makes enterprises work are: - clear responsibilities - clear requirements - clear interfaces - clear ownership - good tests - good communication
    • FpUser 6y ago
      What requirements, what interfaces? We make and brake things every day.
• bmitc 6y ago
  I like Elixir and Erlang so agree with the the typical arguments against OOP, but I actually think value-based (as opposed to reference based) OOP works quite well and jives with functional programming. The best examples of this, that I know of, are LabVIEW, with its dataflow and value-based OOP that includes interfaces, and F#’s object programming, where immutable types such as records and discriminated unions can implement interfaces.
  • JoeyJoJoJr 6y ago
    I rarely see points like your’s raised (reference based versus value based) in the OOP vs FP debate, but these nuanced points really play a big role in the ability to produce quality code. I have constantly gone back and forth on my opinion on OOP vs FP, and it mostly comes down discovering an expressive feature of a new language tipping me back to the other side. Using an OOP language with structural typing was one of these instance. Structural typing isn’t really an OOP thing, but that highlights how blurry the lines can actually be as to what is considered as OOP vs FP.
• staticassertion 6y ago
  Armstrong's death was one of the few that I was sort of hit by, despite not knowing him personally. I've watched so many of his talks, read as much as I could from him, and I've generally found him to be quite an inspiration and seemingly a great guy. More on the point of the article, it's sort of fun to think about the fact that "OO Sucks" is sort of ironic given Alan Kay's initial description of OO was closer to actors than what we think of OO today (he acknowledges this at a later time). As Kay puts it: I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea. The big idea is "messaging" [..] The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. [0][1] This is very much in the spirit of Armstrong's quote in the article: > Since functions and data structures are completely different types of animal it is fundamentally incorrect to lock them up in the same cage. Armstrong talked a lot about how shared mutable state was wrong on a fundamental level - it "breaks reality(/causality)" and that sort of thing. Again, sort of fun to think about the fact that the core ideas with actors seemed to have an origin in an early focus on asynchronous 'cell'-like computers, like the JOHNNIAC in 1953[2], even though the foundation of the model wasn't named or formalized until the 70s. "Its designers began with the hope of stretching the mean free time between failures and increasing the overall reliability by a factor of ten". Systems like JOHNIAC where IAS machines - asynchronous CPUs. These worked through causality, not synchronization. In Armstrong's thesis[3] 'Making reliable distributed systems in the presence of software errors' he references papers like [4] 'Why do computers stop and what can be done about it? Technical Report 85.7, Tandem Computers, 1985.', which talks again about isolated processes and transactions as a foundation to reliable computing - over 30 years later. This whole area is so deeply fascinating with a century of repeating, refining ideas, and I found that just by reading what I could from Armstrong I had a sort of rough guide through this area. There are these cool ties to early ideas about AI, and I guess a lot of people though that languages should model life, and later Kay talks about this as well, and funny enough AWS now has "cell based architecture" - their discipline built around isolation and fault tolerance. A lot of this is sort of just random connections from jumping from paper to paper - but I just found it all really cool. Reading this thread, it almost seems like people don't know who Joe Armstrong is? Or at least they've missed a lot of the point. This isn't an "X vs Y" from some rando, he built Erlang. It's also not about functional programming. I highly recommend reading what he has to say, and watching his talks. [0] http://wiki.c2.com/?AlanKayOnMessaging http://wiki.c2.com/?AlanKayOnMessaging [1] https://computinged.wordpress.com/2010/09/11/moti-asks-objects-never-well-hardly-ever/ https://computinged.wordpress.com/2010/09/11/moti-asks-objec... [2] https://www.rand.org/content/dam/rand/pubs/research_memoranda/2005/RM5654.pdf https://www.rand.org/content/dam/rand/pubs/research_memorand... [3] https://www.cs.otago.ac.nz/coursework/cosc461/armstrong_thesis_2003.pdf https://www.cs.otago.ac.nz/coursework/cosc461/armstrong_thes... [4] https://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf https://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf
• bedobi 6y ago
  As a professional dev who has made a career out of working in "OOP" languages and codebases, I kind of agree. The reason why Functional Programming concepts are increasingly adopted by "OOP" languages is because Functional Programming is objectively better.
  • goatlover 6y ago
    What makes functional programming objectively better? Are there studies which show this to be the case? What does better mean? Better for some people who prefer the functional approach? Better for some languages which support functional programming? Better in some situations which functional programming is well suited? Or just always better for everyone?
    • bedobi 6y ago
      Just look at all the "OOP" languages where both the language developers and the user community are coming around to the facts that * immutability and absence of state is preferable to mutation and statefulness * Option/Maybe types (or "nullable types" which are a shoddy implementation of the same thing) are better than null * Either/Result types are better than exceptions * making things implement map, filter etc and sending in a function that describes what you want to do is better than manually eg looping through lists etc etc etc etc Anyone who doubts how endorsed this is, just read what Brian Goetz and Josh Bloch have to say about how to code in Java. Just imagine if these languages had been implemented with these ideas in mind from scratch instead of the current situation of trying to adopt and retrofit this style when the core libraries fundamentally don't support it. The current trend of "OOP" languages is basically inexorably heading towards FP and abandoning the old school "OOP" style. Eventually they will only be nominally "OOP", mostly in order to please people who have irrational attachments to labels like that, but be way more FP in nature and in all but name. For what it's worth, people shouldn't be irrationally attached to the "FP" label either. Labels aren't important - what matters is the code, how easy or hard it is to reason about it, how well it avoids entire categories of defects from even being possible etc etc. https://proandroiddev.com/kotlin-avoids-entire-categories-of-java-defects-89f160ba4671 https://proandroiddev.com/kotlin-avoids-entire-categories-of...
• deleted 6y ago
  [deleted]
• mumblemumble 6y ago
  > Data structure and functions should not be bound together Maybe not always. I suspect, based on Kay's writings, that Smalltalk's "everything is an object" thing was more about experimentation. They were trying to push one simple idea as far as possible, in order to see just how far they could push it. It turns out you can go pretty far. That doesn't necessarily mean you need to. That said, the most popular language that shies away from "everything is an object" - Java - does so in a way that doesn't work well. Primitives are not objects, sure, but primitives then integrate poorly with the rest of the language (especially since Java 5), and more complex data structures must be objects, even if you don't want them to be. Ironically, my favorite language for showing the nice things you can get by relaxing the "everything is an object" ethos, F#, actually does make everything into an object. (It has to, because .NET.) But it doesn't force you to think about them as if they were objects when you don't want to. So the mental space you live in when you're using the language feels primarily functional. But sometimes objects are useful. The key distinction here - and the thing that Armstrong seems to miss in this essay - is that methods aren't just functions that have been glued to some data. Technically I suppose they are - that's certainly how it works when you roll your own OOP in a language like C - but it turns out the whole is more than the sum of its parts. Because you get a really useful thing that isn't so convenient to do when you keep your functions and your data separate: dynamic dispatch. Dynamic dispatch - not encapsulation - is the killer feature of objects. Late function binding allows you to operate over heterogeneous inputs where the only thing you want to enforce is that they obey a protocol, without having to do mess of explicit conditional branching or having to have all the details pinned down at compile time. Functional languages without any OOP facilities run into convenience problems here. Typeclasses cover some of the same use cases, as well as others that objects and interfaces don't handle very well at all, but they're statically bound, so they can be somewhat less flexible. It's often stated that design patterns are just a way of making up for a missing feature in your language. Well, the command pattern is what you do when your language doesn't support OOP. (For another example of where Armstrong was clearly operating under some misapprehensions when he wrote this, look at the truly bizarre statement he makes in the last paragraph of section 3.)
  • hderms 6y ago
    Yeah an example of typeclasses being less flexible to me is if what you really want is OOP polymorphism for something like being able to choose what code to run based on configuration. Given that you can add objects to your class path at runtime, you can clearly get some extreme flexibility out of a system without clear parallels in typeclass based polymorphism. Obviously this isn't something you'd want to do all the time, but it's an example of something I think about periodically when comparing the two approaches. With typeclasses, polymorphic behavior is driven strictly by the type, and one must follow that thought to it's conclusion to see the difference. Sometimes it's more useful, sometimes not.
• bluedino 6y ago
  Are there non-object oriented languages that are popular today? Python, Ruby, JavaScript, even PHP. I’d like to hear some things from people who only started programming in languages like that and know no other way, but have maybe learned C or something.
  • ByteJockey 6y ago
    I picked up languages like that first and then picked up c later. I tend to miss lambdas more than classes in c. I'm not big on large class hierarchies, so classes tend to be more about conceptual organization to me. And throwing a bunch of related function pointers into a struct and passing a pointer to the struct itself almost kinda looks like a class if you squint hard enough. It keeps everything organized. Packing everything I need into a custom struct, coercing it to a void pointer, and passing it somewhere to emulate a closure, on the other hand, feels dirty.
  • Jtsummers 6y ago
    Well, to the extent that TIOBE is good for anything I suppose it's good for this. The #1 language for March 2021 is C, a decidedly non-OO language. #2-8 are all OO languages or languages that promote an OO style. #9 is assembly (really?). #10 is SQL, hardly OO, it's a declarative language with no pretensions of OO-ness that I've noticed. #11 is Go which is only kind of an OO language, but not really in the sense most people mean when they discuss OO. Of #12-20, most are arguably OO languages of various flavors except for R, Perl, Matlab, and maybe Classical VB (only because I don't know exactly what they mean by that, how far back do we have to go to get to Classical VB? The fall of the Roman Empire? Is it primarily used with an abacus?). Below the top 20 down to 50, the remaining languages are mostly not OO languages, or their OO components are best considered a secondary or tertiary feature (Ada, for instance). So, yes there are popular non-OO languages today. No, they probably don't dominate in overall interest or use, at least outside certain domains. But people are even putting Javascript on microcontrollers these days so it won't be long before it's OO everywhere. Hell, OO (via Java) has already been to Mars. https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/
    • bluedino 6y ago
• rawgabbit 6y ago
  I have no evidence other than the observation that OO mimicked the taxonomy used in the natural sciences. Example: Homo sapiens is of the class mammalia and of the kingdom animalia. This taxonomy originated from Aristotle to describe the world. [1] The problem is that software is needed not to take a static snapshot of the world (state). Software is needed to automate and report on changes (transactions). Aristotle wrote about change and thought about change in four ways. The material from where object came from. The form or template or shape of the change. The efficiency or agent that caused the change. The purpose or reason or final cause of why the change was made. So instead of classes and methods. If we followed this paradigm, we could be now discussing forms and changes. Of course business folks would think this is all silly. They speak the language of accounting which records transaction entries in a journal. Each month the books are closed and the transactions are summarized as the closing balance. Instead of classes, the talk about general ledger codes. Instead of methods, they talk about entries and reverse entries to correct an error. Instead of state, they talk about auditing the entries to verify the balance. [1] https://davesgarden.com/guides/articles/view/2051 https://davesgarden.com/guides/articles/view/2051
  • millstone 6y ago
    OOP (as Alan Kay conceived it) was explicitly inspired by biology. Objects are cells and communicate through exchanging messages. State is local and hidden, and data itself disappears, which means that the program as written may be ignorant of how operations are performed.
• weavejester 6y ago
  I'd suggest that OOP has it's niche. Primarily it's a methodology for limiting the effects of changing state while keeping the codebase performant. Removing state where possible is obviously going to be the safer course of action, but immutable data structures are not as efficient as their mutable cousins. This may not matter for much software, but where it does, OOP isn't the worst solution when used selectively. The problem with OOP in 2021 is that it tends to be the default, when arguably starting from safety and working back toward performance would be a better approach.
  • millstone 6y ago
    "Safety" and "performance" are not always the most important considerations. For example, Apple uses OOP so that its frameworks can evolve without breaking client apps. NSDictionary is a dynamic object because it permits the implementation to be changed or replaced, and this comes at a cost of performance.
    • weavejester 6y ago
      Polymorphism isn't a trait unique to OOP; most, if not all, FP languages have that as well.
      • millstone 6y ago
        Right. But OOP makes it central, and builds around it, while FP de-emphasizes it in preference to ADTs. Strings are a good illustration. Instead of an abstract polymorphic String type, Haskell provided a concrete String type as an ADT. This proved too inflexible, which is why we have Text, lazy Text, ShortText, etc. Compare to NSString which also has multiple representations but hides them behind a single polymorphic interface.
        • javcasas 6y ago
          Or you use -XOverloadedStrings and then you also have in Haskell multiple representations that follow a single polymorphic interface.
• kietay 6y ago
  I agree with Martin Odersky that functional programming within an OO approach to code organisation is the most sensible trade off between maintainability and bug reduction.
• asdfasgasdgasdg 6y ago
  A bunch of these objections are incorrect, or at a minimum apply only to certain implementations of OOP (both from an organizational and linguistic perspective). "Everything has to be an object" is only true in some languages, and even then it's a questionable claim. If I have a Java class that has public data members only, how is that materially different from a data structure? "Data type definitions are spread out all over the place" Again, a questionable assertion. It's plenty easy to define all your data types in one package or header file in Java or C++. Some folks choose not to organize it that way, but that's a different and substantially weaker objection. "Objects have private state" Unless you want all parts of your system to be able to depend on the internal state of all other parts of your system, some kind of state access control is going to be necessary. I'm not aware of any system, OOP or not, where the internal details of, e.g., the Mutex datatype are available for inspection. This is private state by a different name. "Why was OO popular?" I have a simpler explanation. For many years, the most performant unmanaged language with something even close to resembling a strong or useful type system was primarily an OO language (C++). There were no close competitors. And the fastest managed language was also an OO language (Java). I also deny the proposition that OO is materially harder to learn than other paradigms, supposing you want to learn in those other paradigms how to do the sorts of things that come built-in in OO languages.
• 3grdlurker 6y ago
  This is probably an unpopular opinion but I really can’t wrap my head around the arguments for FP and against OOP. By the end of the day, regardless of which paradigm you choose, you’re still just defining concepts, and every concept has properties (both externally visible or not) and functions. The problems raised against OOP always seem to be a problem with the average programmer’s lack of understanding of ontology, so then they put structure and function inside concepts where they shouldn’t be. This lack of understanding of ontology is why, in my opinion, there’s equal opportunity for both paradigms to write equally ugly and horrible code. I mean, I’ve seen people use RxAnything in a modern, expressive programming language that allows both OOP and FP, and still they ended up defining massive view controllers, incomprehensible interface names, extensions that apparently exist but aren’t visible to the programmer from anywhere, property assignments that apparently invoke functions under the hood, etc. If programmers write horrible code with OOP and they still write horrible code with FP, maybe it’s not the paradigm that’s the problem, and maybe it’s the common denominator: the programmer.
  • dionian 6y ago
    I happily use fp+oop in scala and i agree with what you say about rxjava and also most scala code is bad the benefit of FP as a practice is more modular functionality. imperative code isnt always tangled, but it often is. OOP is for more modular data
  • josephg 6y ago
    > you’re still just defining concepts, and every concept has properties Sure; but lots of concepts (maybe most) are best expressed as either functions or bare data. OO isn't "bad" - but its massively overused. Lots of programmers (and programming languages) consider it the default abstraction, even when it doesn't make sense. Encapsulating state within a class, with lifecycle methods often makes code more complex, longer (~50% more LoC is common), slower (due to heap thrashing and the inability to vectorize operations), and harder to reason about. For example, modern javascript has a built-in library for converting binary data to text (either UTF-8 or other formats). This should be a method decodeText(arrayBuf, 'utf-8'). But the API designers instead made a class you need to instantiate first. ( d = new TextDecoder('utf-8'); d.decode(arrBuf) ). This is a strictly worse API, which invokes awful questions like "Is it expensive to instantiate?" "Should I cache it?" "Is there extra hidden state in the text decoder?" I agree that people can write awful code in any language. I've certainly managed to make messes at one time or another in just about every language I've learned well. But my personal dislike of OO comes from the exhausting, never ending fights I've had trying to convince coworkers to use simple functions and bare structs when appropriate. And to please stop trying to force every program, no matter the language, to look like bloated Java code.
• rubyist5eva 6y ago
  I highly recommend "Object Oriented Programming is Bad" and "Object Oriented Programming is Embarrassing" on Youtube. https://youtu.be/QM1iUe6IofM https://youtu.be/QM1iUe6IofM https://youtu.be/IRTfhkiAqPw https://youtu.be/IRTfhkiAqPw
• edwinyzh 6y ago
  Try tell that to Anders the creator of C#, TypeScript and Delphi, to the creator of Java, to the creator of Python. Thanks.
• inopinatus 6y ago
  The irony of course being that Erlang ranks as one of the most OO languages, if one accepts the Alan Kay concept of OOP, which is rather more behavioural than structural, and thereby entirely compatible with the functional paradigm and algebraic forms generally. See also https://www.youtube.com/watch?v=fhOHn9TClXY https://www.youtube.com/watch?v=fhOHn9TClXY
• 3pt14159 6y ago
  I've said this multiple times over multiple years and I'll say it again just because so many green developers get misled. Object oriented programming is good. Not in absolutely every situation, but for most business applications it's better than the alternatives. The reason it's good is that it is productive. Objects map neatly to records, which pushes global state persistence and all the hairiness of locks to a good RDMS like Postgres. It's naturally normalized, but can be denormalized without much work, and in exchange for bundling state with functions you get easier introspection which is especially helpful in debugging. These conversations are better done with examples. Say you want to build a social network around videos, like YouTube. Say a user can block another user and, thus, stop them from commenting on their videos. Would you rather type out this: user.blocked_by? other_user Or this is_blocked(user, other_user) When doing the check? Personally, seeing the the is_blocked? method on a user makes it easy for me to understand. Who has blocked whom is more natural to talk about when there is a primary object subjecting the other object to a test. For all the anti-OO stuff out there, it all boils down to the same thing in the end. For business logic, your functions need to know so much about the data that they are operating on that it's pointless to try to avoid bundling the state. I'm never going to pass a cheeseburger into my is_blocked function so why on earth would I avoid bundling state and operation together? It's like a map of a city trying to avoid listing shops since "maps should be about roads and geography, not shops." A pointless dogma that doesn't actually help programs get built. Most successful startups use OOP and there is a clear reason for that: It's more productive. Now, do I use OOP when I'm doing data science stuff? Mostly no. I don't need it there. But where it works, it's magic.
  • joe_the_user 6y ago
    Object oriented programming is good. Not in absolutely every situation, but for most business applications it's better than the alternatives. The thing about OO is that as far as I can tell, it's natural. Whatever OO is criticized, people point out that the standard OO example is "car" but the typical OO object in practice is "network credentials permissions". So what? The usefulness of OO is exactly that allows, partially, some totally fungly thing like "network credentials permissions" to be treated, sort of, like a thing, we sort of, understand, a fricken car. And further thing is, the fp thing seems to be something like "we don't do objects at all but we do really elaborate Turing complete types, please don't ask us what the difference is, you wouldn't understand. Don't ask us whether types have private data. Especially don't ask if integers have private bits..."
• spankalee 6y ago
  There are all pretty terrible objections, IMO. The first objection is extremely debatable. By packaging state and behavior and using interfaces and/or inheritance you can do certain things very flexibly that are just harder otherwise. The next two don't apply to OOP in general. In most OOP languages I use not everything has to be an object, and you can put interfaces all in one place it you want, And the last is just wrong. State exists, even in functional patterns which tend to hide the state in closures even more strictly than objects! Monads aren't particularly different from object state in that you'll need some way to inspect the state, it's not always visibly locally from the PoV of the consumer of the object or monadic API.
  • jtdev 6y ago
    Yes! Every functional codebase I see seems to be littered with the artifacts of an effort to escape the reality that the known universe and everything that happens within it is stateful... including our code. It’s inescapable, so why does the FP crowd make state even more difficult to reason about through batshit crazy abstractions? I’m honestly completely baffled by the FP movement and the trend of talking down OOP as some simpleton concept that should be abandoned.
    • antonvs 6y ago
      Nothing in the universe is stateful. You only think otherwise because you impose an object abstraction on things and treat their evolution over time in a non-rigorous way. This lack of proper modeling of the effects of time on a system is what leads to all the problems with managing state. FP makes this relationship of change to time explicit. Instead of having a "single object" that "changes state" when some event occurs, you have two objects - one before the event, one after. Systems that rely on mutable state conflate these two and then force you to deal with the consequences of that conflation.
      • goatlover 6y ago
        Does that mean computers aren't stateful? You have one computer before an event and another after?
• euske 6y ago
  I think, as of 2021, terms like "OO" or "OOP" (as well as "AI") should be avoided from serious technical discussions. Its definitions diverge a way too much from person to person, and it often leads to blanket statements (like "why OO is bad"), added confusion and result in unnecessary drama. We always strive for clarity.
  • m463 6y ago
    I think just being aware of ambiguity and the damage it can do can help fix a lot of things. Just think how "free", "justice", "advertising" can all be used to unwittingly miscommunicate, or deliberately mislead.
• dragonwriter 6y ago
  > Objection 3 - In an OOPL data type definitions are spread out all over the place Conventionally, that's true in non-OO languages with a good reuse story: functions are usually packaged with the definitions of and factories for the data structures they work on in modules.
• m463 6y ago
  I think a lot of people think they need OO but they really just need modularity.
  • flavious 6y ago
    Contracts are actually quite necessary for modularity. In OOP we have data types (interfaces, classes). As long as other paradigms provide contracts/abstractions, modularity can be achieved there also. Faked modularity doesn't count. Leaky abstractions neither.
• FpUser 6y ago
  It is not OO that sucks. Sucks is the article which makes numerous unproved and false statements. So many things Joe says are plain wrong. In my opinion it never hurts to actually know the subject before talking about it.
  • Arch-TK 6y ago
    Why don't you provide some examples and maybe explain why you think they're false?
    • FpUser 6y ago
      Sorry I am not here to write lengthy topics. I'll give you one glaring example: "In an OOPL data type definitions belong to objects. So I can’t find all the data type definition in one place" Absolutely wrong. Nothing prohibits you to define all prototypes, data structures and whatever the f.. one pleases in a single place. The author just has no clue what he is talking about. And any normal versatile language supports numerous paradigms so one does not use the hammer where screwdriver is needed.
• xyzzy21 6y ago
  There absolutely are reasonable metaphors to actual real things that map very well to OO. So baby meet bath water. I already know in my head what this person looks and sounds like in person.
  • antonvs 6y ago
    Your comment makes it sound like you think Joe Armstrong is some random blogger. He created the Erlang programming language which was massively influential in the software industry, even though it's not one of the usual "mainstream" languages. I chatted with him in a bar at MIT. I suspect your ideas about what he looks and sounds like in person wouldn't have survived a meeting with him. From what I can tell, his attitudes to these subjects were strongly rooted in pragmatism. He was dealing with and finding ways to solve real-world issues in large-scale distributed telecom systems. The solutions he came up with are still used in many large-scale distributed systems today.
• bccdee 6y ago
  Objects are a useful pattern. Hiding data behind a suite of methods is great if you need to polymorphically treat a set of disparate data types in the same way, or if you want to expose an API to consumers and then change the implementation behind the scenes. The problem with object-oriented programming IMO is that it demands we use this pattern even when it doesn't make sense. Sometimes you should just use a struct or a function. And when you abstract things that didn't need to be abstracted, your code becomes bloated and hard to understand. OOP also encourages an outlook where objects are things with agency which do things and have responsibilities. Data should, more often than not, just be data; when you think of data as being the thing that has the agency, you risk winding up with classes like `ThingDoer` that have methods like `ThingDoer.doThing()`.
• ibeckermayer 6y ago
  > Objects bind functions and data structures together in indivisible units. I think this is a fundamental error since functions and data structures belong in totally different worlds. Why is this? > *Functions do things. They have inputs and outputs. The inputs and outputs are data structures, which get changed by the functions. In most languages functions are built from sequences of imperatives: “Do this and then that …” to understand functions you have to understand the order in which things get done (In lazy FPLs and logical languages this restriction is relaxed). > Data structures just are. They don’t do anything. They are intrinsically declarative. “Understanding” a data structure is a lot easier than “understanding” a function. Functions are understood as black boxes that transform inputs to outputs. If I understand the input and the output then I have understood the function. This does not mean to say that I could have written the function. Mostly trivial definitions plus a bizarre definition of "understand" for functions, the relevance of which is unclear. > Functions are usually “understood” by observing that they are the things in a computational system whose job is to transfer data structures of type T1 into data structure of type T2. Not even true. Oftentimes a function's job is to change the state of a data structure, or compute a new structure of the same type. > Since functions and data structures are completely different types of animal it is fundamentally incorrect to lock them up in the same cage. Sloppy metaphor that doesn't follow from any of the previous gibberish.
• avereveard 6y ago
  Object oriented programming is about messaging, not functions. Keeping data structures close to the code that uses them is just being sane.
• JoelJacobson 6y ago
  "In an OOPL data type definitions belong to objects. So I can’t find all the data type definition in one place. In Erlang or C I can define all my data types in a single include file or data dictionary. In an OOPL I can’t - the data type definitions are spread out all over the place." To me, this is the main argument. In many cases, I think we can go even further, defining the entire data model in SQL, letting it be the single source of truth on what the data model is, letting all code outside of the database adhere to it. The inverse of an ORM.
• InukthePerson 6y ago
  We've had FP, we've had OOP, the next paradigm to look out for is Data Oriented Programming. Tools like ECS with their systems and components have started to become rather popular in the gaming world, and is slowly spreading outside it while we find applications for it. I understand it's not the best tool for the job, and object oriented is most likely is here to stay, but we need to broaden our horizon so we have more tools where applicable!
• nielsbot 6y ago
  Edit: Looks like this may have been addressed in a later interview? https://www.infoq.com/interviews/johnson-armstrong-oop/ https://www.infoq.com/interviews/johnson-armstrong-oop/ (shared by frederikholm below) This is a critique of mainstream "OOP". But the term "Object oriented programming" as coined by Alan Kay meant something different[1]. He was referring to something like actors: Tiny independently-operating machines (which, yes, contain hidden state) that provide answers in response to messages sent to them. You intentionally can't know how they work--they should behave as little computers. I think this is a powerful paradigm which has still not been fully realized. (NSDistantObject in Object-C comes close?) I am excited for the new async/await stuff coming to Swift since it's explicitly moving towards an actor-based programming model. (While Swift, in general, tries to eliminate some of the negative aspects of previous implementations of OOP.) [1] http://www.purl.org/stefan_ram/pub/doc_kay_oop_en http://www.purl.org/stefan_ram/pub/doc_kay_oop_en
  • kimi 6y ago
    > Tiny independently-operating machines (which, yes, contain hidden state) that provide answers in response to messages sent to them. You intentionally can't know how they work--they should behave as little computers. You mean... like an Erlang process? :)
    • nielsbot 6y ago
      Maybe? You tell me. :) Do you communicate with them via messages? I guess I am biased because I always think of messages more like Obj-C/Smalltalk style obj doSomethingWithArgument: arg1 otherArgument: arg2 Vs something more like a protobuf or whatever. I guess as long as a message send in the language looks like a method invocation it's all equivalent.
      • fredrikholm 6y ago
        https://www.infoq.com/interviews/johnson-armstrong-oop/ https://www.infoq.com/interviews/johnson-armstrong-oop/ "Is Erlang object oriented?" "From that point of view, we might say it's [Erlang] the only object oriented language and perhaps I was a bit premature in saying that object oriented languages are about."
• gokr 6y ago
  This is kinda funny. I wrote a "rebuttal" article back in 2009: http://goran.krampe.se/2009/06/26/joe-is-wrong/ http://goran.krampe.se/2009/06/26/joe-is-wrong/ ...and then I met Joe not long after and we also discussed this in fact. He then told me that he felt my article was fair (!) and that he had *changed his opinion on OO since writing that article*. IIRC his exact words were something along the lines of "I did not understand OO when I wrote that article". Now... he also argued Erlang is in fact VERY OO, and in some ways he is correct, since its very focused around autonomous "parts" communicating solely via messages. Finally, I haven't read all 162 comments here - but OO is not "bad" nor "the holy graal". There are different ways of doing programming, and its as simple as that. I can find joy in simple imperative coding as much as I can long for the days I was working in pure OO in Smalltalk. :)
  • diggan 6y ago
    > Finally, I haven't read all 162 comments here - but OO is not "bad" nor "the holy graal". There are different ways of doing programming, and its as simple as that What are we programmers supposed to do with all of our free-time unless argue about what is the holy grail versus which is not?! I feel so empty. Jokes aside, I think this is the most important point really. There is no single language/paradigm that works best for everything, it all really depends on the context, environment, and so much more. It's easy to forget on the internet, that someones environment might be vastly different than yours, and think your solution will work for others because you miss their context. OOP is hated all around the world, and still solves problems. Functional programming is loved all around the world, but is still not the right solution for everything.
    • gokr 6y ago
      "hated all around the world" sounds a bit harsh :) Sure, lots of people like "throwing hate" at it, but AFAICT it's mostly "bad use" that gets people riled up like insane deep inheritance or overly complicated frameworks. Also, it seems especially young guns feel cool by claiming FP is superior ;) AFAIK OOP languages are still ruling the whole GUI space, which is reasonable since GUI was the main driving force behind it (see history of Smalltalk) and the domain is such an obvious candidate for composition of separate independent elements. What languages are primarily used for GUIs today? Java, C#, Swift, ObjC, C++, Dart, Kotlin ... and the list can probably be made much longer. On the web ... well.
• valenterry 6y ago
  OOP just isn't really defined. Maybe originally there were some more precise definitions, but nowadays everyone understands a different thing. Therefore it's pretty meaningless to argue about OOP without giving a definition beforehand. Just looking at the threads here, there are so many discussions and contradictions simply because people make different assumptions and it often boils down to the true scotsman problem.
  • chriswarbo 6y ago
    I agree, and find a large proportion of https://softwareengineering.stackexchange.com https://softwareengineering.stackexchange.com is people arguing backwards, starting from 'OOP is the best way to solve this' and then trying to figure out what they mean by 'OOP' that context.
• p0nce 6y ago
  Every argument against OO seems to ignore the success of OO programs in the wild. Where are all the non-OO competitors?
• AzzieElbab 6y ago
  I always thought of OOO as a dsl. An object with methods and properties has an easier mental model than state transitions. You can still implement such objects with immutable state under the hood
• agumonkey 6y ago
  Rarely seen such a sad thread on HN :)
• jonjacky 6y ago
  Also: Why do we need modules at all? by Joe Armstrong http://erlang.org/pipermail/erlang-questions/2011-May/058768.html http://erlang.org/pipermail/erlang-questions/2011-May/058768...