7 ms·
OOP is shifting between domains, not disappearing
- xnx 1y ago> Perhaps a sneaky HTTP request to localhost for desert. Typo: dessert
- notorious_pgb 1y agoI think that "OOP" is an incredibly overloaded term which makes it difficult to speak about intelligibly or usefully at this point. Are we talking about using classes at all? Are we arguing about Monoliths vs [Micro]services? I don't really think about "OOP" very often. I also don't think about microservices. What some people seem to be talking about when they say they use "OOP" seems strange and foreign to me, and I agree we shouldn't do it like that. But what _other_ people mean by "OOP" when they say they don't use it seems entirely reasonable and sane to me.
- TZubiri 1y ago"I don't really think about "OOP" very often. I also don't think about microservices." Why even comment in an article about those topics then?
- notorious_pgb 1y agoPrimarily poor wording on my part. I think in terms of language features and patterns which actually mean something. OOP doesn't really mean anything to me, given that it doesn't seem to mean anything consistent in the industry. Of course I work with classes, inheritance, interfaces, overloading, whatever quite frequently. Sometimes, I eschew their usage because the situation doesn't call for it or because I am working in something which also eschews such things. What I don't do is care about "OOP" is a concept in and of itself.
- potatopan 1y agoWell.. I don't understand how you can read a confused and muddled article by someone who doesn't want to know the difference between JavaTM and one of its notable choices in the many dimensions of language choices and not wish to be a little more enlightened as to the difference between hiring an OOP monkey or a VMware jockey to smash some bits about.. The article is like a poster child for taking an hour to learn what your profession is about.
- notorious_pgb 1y agoRespectfully, it's not clear to me what you're saying. You're clearly displeased with both the author of the article and with myself, but beyond that, I'm not sure what your thesis is.
- potatopan 1y agoWe give features of a profession terms so we can refer to them independently and make reasonable discussions that don't confuse people as to which traits we think something that is neither Java nor Python (and so need not match either of them on every dimension) should have. For example, I hate Java because of OOP, but strong typing can make a lot of bad in a language tolerable. Does the writer of the article agree with me? They don't seem able to understand whether they do.
- hombre_fatal 1y agoIn a comment about nailing the jargon, kinda ironic that you probably meant to say static typing rather than praise Java for its mediocre strong typing.
- potatopan 1y agoTechnically maybe yes, but that would confuse me with some of my colleagues that like explicit static types. I like type inference systems but loath type confusion.
- cpursley 1y ago> overloaded I see what you did there
- kragen 1y ago> Are we talking about using classes at all? Using classes hasn't been a part of the definition of OOP since the Treaty of Orlando. Pre-ECMAScript-2015 JS is a mainstream OOP language that doesn't have classes, just prototypes. (Arguably ECMAScript 2015 classes aren't really classes either.)
- the__alchemist 1y agoI think this is some combination of strawman, and subset of all cases. You can lament complications of OOP. You can also lament the complications of docker, kubernetes, HTTP APIs etc. These aren't mutually exclusive, and they don't span the breadth of programming techniques. I prefer avoiding all of these. Anecdotally, I've replaced OOP with plain data structures and functions.
- mickduprez 1y ago>> _Anecdotally, I've replaced OOP with plain data structures and functions._ I think this is why FP is becoming more popular these days but I'm not sure some people get why. The problem with OOP is you take a data set and spread it all over a 'system' of stateful (mutable) objects and wonder why it doesn't/can't all fit back into place when you need it to. OOP looks great on paper and I love the premise but... With FP you take a data set and pass it through a pipeline of functions that give back the same dataset or you take a part of that data out, work on it and put it straight back. All your state lives in one place, mutable changes are performed at the edges, not internally somewhere in a mass of 'instances'. I think micro services et al try to alleviate this by spreading the OO system's instances into silos but that just moves the problems elsewhere.
- baq 1y agoIME microservices solve engineering process problems (i.e. synchronization, enforcement of interface boundaries, build and test scale issues), not technical problems in the product.
- mickduprez 1y agoI agree, very true when used for purposes as you noted. I guess my point was more about using them as a way solve the underlying problems a large OO system can develop. Microservices enforce you to package data sets for transport, it's very functional if you only take the data and transport into consideration, the mess can still happen within the microservice though.
- 1y ago
- bauble 1y agoThis is so much nonsense. Contracts and interfaces have little to do with OOP. If you don't like inheritance, then talk about OOP. It's fine. Many people, including myself, don't like inheritance. On the other hand, if it's interfaces and contracts that have you bothered, parse-dont-validate to your heart's content. If the domain allows it. Just don't drag unrelated concepts into this particular discussion.
- bluGill 1y agoOOP is about messages according to the inventor - messages are about the interface. People get confused with objects which languages without messages don't have (you can get them, but they are not first class in the language) Even plain objects though, the point isn't the inheritance! The point is to put an interface on the data. Inheritance is sometimes useful because, but there is a reason we keep screaming "prefer composition to inheritance" (even though few listen)
- bluGill 1y agoJust noticed that I wasn't clear - there are languages that have OBJECTS that do not do message passing. Message passing seems to be dynamic (duck type) function calls, which is debatable if it is worth it over static typing. You can get message passing in any language, but it is a lot more work and of questionable benefit vs static interfaces (there are pros and cons)
- 1718627440 1y agoI agree with you, that inheritance isn't all of OOP, but I think it is one of THE unique selling point of OOP. All the other things like abstraction, interfaces, encapsulation, polymorphy, etc. all exist(ed) before and without OOP.
- Brian-Watkins 1y ago[flagged]
- Jtsummers 1y agoAnother one, apparently: https://news.ycombinator.com/user?id=Jeff-Collins https://news.ycombinator.com/user?id=Jeff-Collins https://news.ycombinator.com/user?id=alan-jordan13 https://news.ycombinator.com/user?id=alan-jordan13 I wonder what asshole thinks this is a good idea.
- mrkeen 1y ago> Other bright sparks jumped in on the action: what if this separation did not rely on the personal hygiene of the programmers - something that should always be called into question for public health reasons - and was instead enforced by the language? Components might hide their implementation by default and communicate only though a set of public functions, and the language might reject programs that tried to skip around these barricades. How quaint. Sounds like C. When was the last time you did OO against a .h file without even needing access to the .c file? > And so, the process/network boundary naturally became that highest and thickest wall I've had it both ways. Probably everyone here has. It's difficult to make changes with microservices. You gotta open new routes, and wait for people to start using those routes before you close the old ones. But it's impossible to make changes to a monolith: other teams aren't using your routes, they're using your services and database tables.
- fhd2 1y ago> Sounds like C. Data hiding is just one of the concepts of OOP. Polymorphism is another one. How that's implemented is another question. You can do OOP in plain C, several libraries kinda did that, like GTK. Other languages tried to support these concepts with less boilerplate, giving rise to classes and such. But OOP is not about language features, it's fundamentally a way of designing software.
- 1718627440 1y agoPolymorphism is trivial in C and even less restrictive than in other OOP-first languages. The reason why GTK (actually GObject) is so overengineered is not due to classes, but because it allows to create classes and types at runtime.
- marcosdumay 1y agoIt's older than C. But yes, C does module encapsulation. C is capable enough to program in a way that is basically OOP and without using non-idiomatic code. The C++ object system wasn't created in a vacuum.
- 1y ago
- bloppe 1y agoSomeone is bound to quote Dijkstra here: > To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.
- colordrops 1y agoNonsense. Network service layer separation solves a different problem than OOP. It doesn't replace it. Services and containers bring features and capabilities that OOP doesn't provide. It's orthogonal.
- WCSTombs 1y agoBut I think that's really the point: it gets applied to problems it was clearly not meant to solve. The article doesn't really get into that, but that's how I'm reading it because I've seen it happen. To some programmers, every component of a program is its own service, even when there's no need to have multiple processes. The only tool they have is that hammer, so everything has to be a nail.
- WCSTombs 1y agoTL;DR: OOP is being replaced by microservices (and even more extreme ideas), which is much worse. Yeah, I have to agree with this author. I will say that service-oriented architecture does have some advantages, and thus sometimes it's the right choice. Parallelism is pretty free and natural, you can run services on different machines, and that can also give you scalability if you need it. However, in my experience that architecture tends to be used in myriad situations where it clearly isn't needed and is a net negative. I have seen it happen.
- sroerick 1y agoI'm not really qualified to talk about either topic at length, but my impression is that the Microservice crowd is kind of a different group than the anti-OOP crowd. As a total beginner to the functional programming world, something I've never seen mentioned at length is that OOP actually makes a ton of sense for CRUD and database operations. I get not wanting crazy multi tier class inheritance, that seems like a disaster. In my case, I wanted to do CRUD endpoints which were programmatically generated based on database schema. Turns out - it's super hard without an ORM or at least some kind of object layer. I got halfway through it before I realized what I was making was actually an ORM. Please feel free to let me know why this is all an awful idea, or why I'm doing it wrong, I genuinely am just winging it.
- TZubiri 1y ago"OOP actually makes a ton of sense for CRUD and database operations." Not at all OOP is great at simulations, videogames, emergent behaviour in general. If you do crud with oop you will complain about overengineering.
- jay_kyburz 1y agoEven in video games, I avoid inheritance, I always much prefer composition. Build a complex object from many small objects, then vary behavior with parameters rather than deriving a child class and overriding methods.
- TZubiri 1y agoRight that's still OOP.
- jay_kyburz 1y agoOh yeah, just saying inheritance is the part I don't like.
- 1718627440 1y ago
- TZubiri 1y agoI had a job interview where the guy asked me something along the lines of do I have experience with OOP or Microservices，or both. So I answered how I like both and feel that MS are Objects at the network layer, the dude cut me off and told me to stick to the question. Absolutely gut wrenching, I was being evaluated by who knows who, in a slot of 30 minutes, maybe his entire job was repeating the same set of questions 16 times per day and he was unironically writing down yes/no next to "Microservices?" "OOP"?
- larodi 1y agodo not iterate the bad feeling of this, the guy was not the level to understand the abstraction both give. while i have felt this sentiment towards things being reinvented, we have to assume some innovation is incremental, and the new thing looks like the old but allows kool new stuff such as networking.
- phkahler 1y ago>> So I answered how I like both and feel that MS are Objects at the network layer, the dude cut me off and told me to stick to the question. OMG! As an interviewer I would have asked you to elaborate on that response. Perfect opportunity to see if and how the candidate thinks and how deep some pocket of understanding goes.
- CuriouslyC 1y agoMicroservices are a bad pattern. Function as a service is better, because that architecture tends to assume vertical integration within the function and you can leverage a shared business logic library across an organization. Having service-to-service communication is the thing that makes microservices suck, if you can give people autonomy while having a shared systems language and keeping computation on one system it works ok.
- epolanski 1y agoMicro services are neither bad or good, they are simply misunderstood. They are a solution to communication and organizational challenges, not a technical one. As every other solution they have cons, some of which you have outlined.
- sgarland 1y agoNah, I’ll agree with parent: they’re objectively bad. They turn what could be IPC into network calls, and because everything uses frameworks and ORMs, it’s all slow as hell. “We can move faster” (but at the cost of our product being slower).
- Zanfa 1y agoI keep seeing this implication that microservices somehow allow teams to move faster, but every company I've seen them at has moved at a snails pace mostly because of the clusterfuck of microservices. What would've been a trivial change in a monolith became a cross-team nightmare.
- epolanski 1y agoBecause, as I said in a previous post, they are adopted as a technical rather than organizational solution. Which means that either these organizations adopted the wrong technological solution for their problem without really understanding it, or that they should've tackled their organizational issues instead which could've been unrelated from microservices being the actual solution. Gonna give you an example. Dazn, the european sports streaming service unicorn, adopted both microservices and microfrontends as an organizational solution: they had multiple teams across different offices in the world, and this posed a lot of organizational strains. There's a series of talks (he mostly focuses on micro frontends, but the concepts are the same) on Youtube from Luca Mezzalira (principal serverless engineer at AWS, previous chief architect of Dazn) on the topic, and he does *not* shy away from the idea of micro services and micro frontends being a subpar technical solution more often than not. But sure, if you adapt micro services because you don't know what you're doing and you're not understanding the engineering difficulties, then you're shooting yourself in the foot and I've seen the very same phenomenon you describe: short-term velocity gains with long term penalties.
- epolanski 1y agoMany great design patterns have come from OOP and have found their home in functional languages or libraries. Dependency injection has to be the most successful one, but there's at least another dozen good ideas that came from OO world and has been found to be solid. What has rarely proven to be a good idea instead is inheritance at behavior level. It's fine for interfaces, but that's it. Same for stateful classes, beyond simple data containers like refs. You can even have classes in functional programming word, it's irrelevant, it's an implementation detail, what matters is that your computations are pure, and side effects are implemented in an encoded form that can be combined in a pure way (an IO or Effect data type works, but so can a simple lazy function encoding).
- 1718627440 1y agoI think the opposite is true, many good patterns have been combined and are now called OOP. Most were already common before that and had another name.
- tehjoker 1y agoThere is a kernel of insight here that is pretty valuable. Interfaces are a form of security and is a result of a loss of trust. It's interesting to think about how far trust can be extended before it breaks down.
- lelandbatey 1y agoThe idea of "we are replacing <thing> with microservices, which is much worse" is true for almost any <thing>, OOP or not.
- PaulDavisThe1st 1y ago> At around the same time, some bright spark realised that programmers - a population of people not known for good hygiene [ ... ] OK, I'm out.
- gwbas1c 1y agoOh gosh I clicked "Enter the tarpit". I hope I didn't blacklist my IP or something. Silly link, though. I highly suggest going back and clicking on the link.
- nobodyandproud 1y agoFrom one rambler to another: I’m not sure who or what this aimed at, as it goes all over the place. Cloud: Separating resources from what gets deployed is a classic separation of concerns. I don’t miss the days where I had to negotiate with the IT team on hardware, what gets run, and so on. Personally, I believe the next evolution is a rebalkanization into private clouds. Mid-to-large companies have zero reason to tie their entire computing and expose information to hosting third parties. OpenAPI: The industry went through a number of false starts on formal remoting calls (corba, dcom, soap). Those days sucked. The RESTful APIs caught on, and of course at some point, the need for a formal contract was recognized. But note how decoupled it is from the underlying stack: It forces the engineers to think about the contract as a separate concern. The problem here is how fragile the web protocol and security actually is, but the past alternatives offer no solution here.
- prewett 1y agoIt's unclear to me what the author thinks OOP is, and what he thinks we are replacing it with. The main point of OOP to me is hiding internal state. So OOP is great for user-interface, because there's all kinds of state there (not just the model, but the internal state of the UI element, like the scroll position of a list or the selection range of a text edit). Microservices, in fact, could be considered "network objects" and a microservice framework as network OOP. The problem there is that normal making a function call is straight-forward. The call produce a failure result, but the call actually happens. On the network, the call might not happen, and you might not be aware that the call cannot and will not happen for some seconds. This is not likely to simplify your code... OOP can be just about structuring code, like the Java OOP fundamentalism, where even a function must be a Runnable object (unless it's changed since Oracle took over). If there's anything that is not an object, it's a function! Some things are not well-suited to OOP, like linear processing of information in a server. I suspect this is where the FP excitement came from. In transforming information and passing it around, no state is needed or wanted, and immutability is helpful. FP in a UI or a game is not so fun (witness all the hooks in React, which in anything complicated is difficult to follow), since both of those require considerable internal state. Algorithms are a sort of middle ground. Some algorithms require keeping track of a bunch of things, others more or less just transform the inputs. OOP (internal to the algorithm) can make the former much clearer, while it is unhelpful for that latter.
- gwbas1c 1y ago> It's unclear to me what the author thinks OOP is, and what he thinks we are replacing it with. The author is complaining about bloat. The thing is, in this case, the bloat has highly tangible costs: Spreading an application across multiple computers unnecessarily adds both operation costs and development costs.
- bloppe 1y agoUnnecessarily is the key word here. Sometimes, although admittedly rarely, the benefits do outweigh the costs, and it is necessary. The problem is that if you grow your monolith to the point that it becomes necessary to split it up, now you generally have a long, expensive and error-prone migration on your hands. If you architect you system with this eventual transition in mind from the start, though, it can be much less painful.
- geon 1y agoMicroservices are a great solution to the problems you run into at high scale. But they come at great cost. If you don't actually HAVE the problems they solve, do everything in your power to avoid them. If you can just throw money at larger servers, you should not use microservices.
- gwbas1c 1y ago> Every call across components acrues failure modes, requires a slow march through (de)serialisation libraries, a long trek through the kernel’s scheduler. A TLB cache invalidation here, a socket poll there. Perhaps a sneaky HTTP request to localhost for desert. And this has tangible costs, too. I saved more than $10k a month in hosting costs for a small startup by combining a few microservices (hosted on separate VMs) into a single service. The savings in development time by eliminating all of the serialization layers is also appreciable, too.
- OhMeadhbh 1y agoI think it would be very nice if the author provided citations for their assertions about how OOP was adopted. I was alive and gigging as a coder in the 80s when people had interminable arguments about Structured Programming, unstructured programming, OOP and every now and again LISP or FORTH. None of what the author mentions rings true. Standard interfaces came DECADES before anyone started talking about OOP. Rationalizing standard interfaces was mentioned in mythical man month. Structured Development was all the rage in the early 80s when I started selling 6502 op codes. Half the people I talked to in the 80s insisted C++ WAS OOP while the other half found that quote from Alan Kay who said C++ wasn't what he was thinking of when he invented the term "Object Oriented Programming." I think the author is correctly picking up on how messy changes in best common practice can be. Also, different communities / verticals convert to the true religion on different schedules. The custom enterprise app guys are WAAAAY different than games programmers. I'm not sure you'll ever get those communities to speak the same language. OOP is dead. Long live OOP.
- geophile 1y agoNo, "we" are not replacing OOP with something worse. "We" are replacing layers of stupid shit that got layered on top of, and associated with OOP, with different renderings of the same stupid shit. I have been programming since 1967. Early in my college days, when I was programming in FORTRAN and ALGOL-W, I came across structured programming. The core idea was that a language should provide direct support for frequently used patterns. Implementing what we now call while loops using IFs and GOTOs? How about adding a while loop to the language itself? And while we're at it, GOTO is never a good idea, don't use it even if your language provides it. Then there were Abstract Datatypes, which provided my first encounter with the idea that the interface to an ADT was what you should program with, and that the implementation behind that interface was a separate (and maybe even inaccessible) thing. The canonical example of the day was a stack. You have PUSH and POP at the interface, and the implementation could be a linked list, or an array, or a circular array, or something else. And then the next step in that evolution, a few years later, was OOP. The idea was not that big a step from ADTs and structured programming. Here are some common patterns (modularization, encapsulation, inheritance), and some programming language ideas to provide them directly. (As originally conceived, OOP also had a way of objects interacting, through messages. That is certainly not present in all OO languages.) And that's all folks. All the glop that was added later -- Factories, FactoryFactories, GoF patterns, services, microservices -- that's not OOP as originally proposed. A bunch of often questionable ideas were expressed using OO, but they were not part of OO. The OOP hatred has always been bizarre to me, and I think mostly motivated by these false associations. The essential OOP ideas are uncontroversial. They are just programming language constructs designed to support programming practices that are pretty widely recognized as good ones, regardless of your language choices. Pick your language, use the OO parts or not, it isn't that big a deal. And if your language doesn't have OO bits, then good programming often involves reimplementing them in a systematic way. These pro- and anti-OOP discussions, which can get pretty voluminous and heated, seem a lot like religious wars. Look, we can all agree that the Golden Rule is a pretty good idea, regardless of the layers of terrible ideas that get piled onto different religions incorporating that rule.
- senderista 1y ago> And while we're at it, GOTO is never a good idea, don't use it even if your language provides it. Good luck with that if you're a C programmer.
- phplovesong 1y agoOOP today is really CBP (class based programming). Its really just imperative code hidden in methods that work on mutable state. Its gross. This is most common in Java, PHP and the likes.
- tantaman 1y agoThere's a time and a place for all of these things. Like everything in life, many people pick the wrong time and wrong place.
- dariosalvi78 1y agoI think that the author is confusing OOP with Java. And I agree, Java is great and had most of the things we do now with overbloated infrastructures at least a couple of decades ago. We like to reinvent the wheel, that's what we do, but each time we give it another name. Then we complain about the old good time when everything could run on a Pentium and 64MB RAM.
- ChrisMarshallNY 1y agoI have found that Protocol-Oriented Programming is basically "OOP without classes." Protocols have their issues, though[0]. Not exactly the same results. [0] https://littlegreenviper.com/the-curious-case-of-the-protocol-default/ https://littlegreenviper.com/the-curious-case-of-the-protoco...
- almosthere 1y agoI've been equally happy with oop and non-oop and have been programming for 35 years of my life between c/c++/java/python/go/ts. I'd say that right now the edge is with non-oop. But dare I say too, llms will make this battle mean less than it did 5 years ago. Look, I'm not looking to battle llms vs not - but the bottom line is that nearly all code in a 10 years time will be written and/or managed 99% by llms.
- crabmusket 1y ago> In times of old, people wrote programs. Things were easy and simple. Fake history; the term "software crisis" was coined in 1968: https://en.wikipedia.org/wiki/Software_crisis https://en.wikipedia.org/wiki/Software_crisis I get that the writing is tongue-in-cheek, but telling just-so stories about how things were so much better in the old days doesn't help anyone. I also resent our modern problems, but I don't kid myself that I'd enjoy vintage problems any better.
- aj_hackman 1y agoIn times of old, people wrote COBOL and BASIC.
- nine_k 1y ago> OpenAPI schemas replace type-checkers, docker compose replaces service factories, Kubernetes replaces the event loop. Every call across components acrues failure modes, requires a slow march through (de)serialisation libraries, a long trek through the kernel’s scheduler. This has nothing to do with OOP, and can be made out of structured-programming components, or even purely functional components. In fact, stateless services are a staple of horizontal scaling, and could be a poster child of FP taking over the real world (along with React). What made OOP problematic was mostly shared and concealed mutable state, and the ill-conceived idea of inheritance. Both of these traits are being actively eschewed in most modern software: mutable state is largely separated into databases, inheritance is often rejected in favor of composition. These are all practical, non-ideological choices, ways to relieve well-known pains. It this regard, OOP is on its way out, even in strongholds where it's ingrained into the very fabric, like JVM languages. The complaints of the author are mostly about component-based architecture, with limited compile-time trust (know thy vendor) and large run-time distrust (every network request should be seen as a potentially malicious request). This is the price that we pay for having so many ready-made building blocks to choose from, and for the ability to make our services available (or access someone else's services) anywhere on the planet, 24/7. Highly scalable architectures with their complexity were invented by companies who needed them, like, well, Google or Amazon. There is no good way to serve billions of requests daily. If you serve mere millions, you may not even need all that, and make do with a few beefier boxes. It has nothing to do with OOP, again.
- mwkaufma 1y agoPet Peeve Trifecta: (1) Wielding "OOP" as a pejorative without justification or context. (2) Transferring critiques from one subject to another via superficial similarities. (3) Patronizing twee storybook tone.
- tedggh 1y agoThe problem with OOP is that it becomes a death trap for those who like to over-engineer things. It’s like a cabinet full of booze in the house of an alcoholic. I worked with this guy, who loved to tell everyone very proudly that he was a self taught OO developer. Working on his code was truly miserable, an over-engineered mess of deep inheritance hierarchies that had absolutely no reason to exist other than make the codebase impossible to maintain. He also happened to love Regex and would write 50+ character Regex that could have been done with 3-4 lines of human readable code with zero performance penalty. But he loved intriguing one liners. Design patterns in OOP are great if you are disciplined enough to use them when they really matter. If you use them to just signal expertise with convoluted code and excessive abstractions they backfire really bad.
- munksbeer 1y agoHave you ever worked with functional code from people who like to over-engineer things? I've seen code from people who got the FP "buzz" and suddenly everything had to be FP. It was a nightmare. The reality is as it always has been, the best programmers write simple, understandable code, regardless of the paradigm they choose.
- pjmlp 1y agoThe irony of all OOP bashing, is that with exception of C, most modern languages have OOP support, even if people think they are doing imperative programming, the data types are instances of object types, with respective encapsulation, methods and polymorphysm. Also even those recent ones that boost about not being OOP, have type systems that from computer science OOP type theory point of view, support OOP concepts (OOP is not class based inheritance and nothing else). Naturally since not everyone is doing type theory studies on CS degrees, or attending CS degree to start with, then we get all these discussions about what is OOP or not.
- nilirl 1y agoThis post does a great job of limiting its terribleness by being short. I read it twice; twice I got nothing. It is incoherent. Vaguely attempting to take a swing at ... modularity???
- sevensor 1y agoNow that the pendulum has finally swung back from OOP, has OOP become a generic term for any poorly thought out conceptual muddle? “Welcome to Intertrode. You’ll be working on the big refactoring project. Our legacy system was designed by our old principal engineer, Larry. Unfortunately, he OOPed all over the codebase.”
- lemonwaterlime 1y agoThe author was a bit poetic in writing this post and most commenters seemed to have missed the point. When he starts talking about the “hygiene of the programmer”, he is referring to the concept of a “code smell” rather than making literal statements about the literal cleanliness of programmers. From there, he is saying that the industry has distanced itself from object-oriented programming because it often causes problems and added “smells” to the architecture of code bases. This is regardless of what your specific definition of OO is. Finally, he ends by raising awareness around the fact that even if people claim to not use much OO in their codebases, when you look at the total architected solution, those various services like Docker and so on are themselves various Gang of Four style OO patterns. Because we talk about OO in code, we are not watching the OO that happens around the code.
- tracker1 1y ago> we have replaced it with a behemoth with precisely the same flaws - but magnified tenfold. OpenAPI schemas replace type-checkers, First, OpenAPI schemes aren't a replacement for type checkers, they allow for tooling to be built around the scheme and even generated code to be created instead of bespoke implementations for every client language. You still should do input (and even response) validation. > docker compose replaces service factories, Compose is a self-documenting set of services to run together in predictable ways in containerized environments. > Kubernetes replaces the event loop. K8s expands this to more complex orchestration across multiple systems. > Every call across components acrues failure modes, You can containerize fairly monolithic code pretty easily... especially with related services that run as a set... nothing requires micro services or complex orchestration in practice. I think of it as a set of predictable extensions to 12-factor apps. > requires a slow march through (de)serialisation libraries, a long trek through the kernel’s scheduler. A TLB cache invalidation here, a socket poll there. Perhaps a sneaky HTTP request to localhost for desert. This is how all client-server systems work... there's some level of (de)serialization involved and a system of coordination between clients a servers... nothing special here. HTTP just has the benefits of being human readable and standardized with tooling for security, authentication, proxies, caching, etc as wrappers and add-ons. These have nothing to do with OOP or not. For that matter, OOP itself isn't necessarily a panacea... I've always favored utility/worker processes (even in a class based language) separated from state or storage objects that don't have internalized objects... exceptions maybe for attribute markup for type validation if the language supports it. The rant as a whole doesn't make a lot of sense... if you want to rail against the complexities of micro-services and orchestration, which trades in-application complexity for deployment/orchestration complexity, that's a fair argument to make... especially when the same people are responsible for both. But that isn't an OOP thing at all.