Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Rise and Fall of Object Oriented Programming

medium.com

Post reply on HN
Print view View original

11–20 of 29 posts

Re: The Rise and Fall of Object Oriented Programming

#11

Post by tabtab »

kryptonomist wrote: post #9

One use case where I found OO particularly unsuitable is applications that rely heavily on events. Trying to understand what's happening is hard, when any call to your object structure can trigger changes at any level of your hierarchy, triggering other changes again, and so on. Luckily, the rising popularity of Swift, Kotlin, and Go, will push for a more reasonable use of OO in combination with FP.

Re: One use case where I found OO particularly unsuitable is applications that rely heavily on events.

I agree. Events typically have to "belong" to something in OOP, but how they are best grouped or managed may not fit a single-item belonging-ness.

I'd like to see languages which are flexible in how events are organized in file systems. Their file grouping wouldn't have to reflect some object hierarchy or odd code structure, it would be organized how a team wants. Conway's law. A "header" would define the criteria for triggering. You could have wild-card based triggering and expression based triggering. wild-card triggering would be more efficient and orderly, but one needs expression-based triggering for certain circumstances.

Perhaps manage all those event handlers in an RDBMS. But our existing tools and IDE's are file-centric when they should be looking to be RDBMS-friendly. When you are dealing with thousands of fairly-similar things, such as event handlers, it's time to think about databases, not files and folders. OOP and files/folders don't scale very well.

Re: The Rise and Fall of Object Oriented Programming

#12

Post by tabtab »

jkoudys wrote: post #4

I've always felt so alone in my distaste for ORMs. They often lead to at worst taking way more data than you need and manipulating it all in a language that's not very good at it, or at best running some kind of query-builder which takes a far more complex configuration to get the same data that a simple query could. Objects make much more sense as something to build from a query, not something to be queried themselv…

ORM is one of those "dark grey boxes" we often have to deal with. When they work as intended, they can indeed save time, but when they don't, you have to fiddle in an organic fashion to solve or work around the problem, because otherwise they are thousands of line of code if you wish to dig in code-wise.

As an alternative, use stored procedures with Dapper, or use smaller sub-helpers that prepare most of the SQL statements or sub-statements for you but don't outright hide it. They assist in creating SQL (and prepared statement parameter mapping), but only assist, and are kept to less than a few hundreds of lines of code.

Other dark-grey-boxes include URL route mappers, seen in MVC stacks, and HTML formatters, such as Razor. When they don't work right you'll waste many many hour fudging with them. I'd often rather replace the URL router with Case/switch statements: it would be easier to debug; so what if it's a bit more typing. It's a white box.

Re: The Rise and Fall of Object Oriented Programming

#13

Post by Rooster61 »

tabtab wrote: post #10
MockObject wrote: post #7

> However, as the years went by, people started to realize that the strict approach to object orientation created a number of problems. These problems tended to be of the kind that makes code complex, hard to understand, and hard to test. No, ease of testing is one of the reasons for OO adoption, and probably the primary reason software is much more stable than it was in the mid 90s. > Many of those higher-level clas…

Re: Well, then it's broken and needs to be refactored. Refactoring means the original design didn't handle change well. Refactoring is badge of disgrace, and should not be considered a standard practice any more than putting out kitchen fires should be considered a standard practice of cooking. One of the key points of abstraction is to make the code change-friendly. If you have to refactor, the code failed that job.…

> Refactoring is badge of disgrace, and should not be considered a standard practice any more than putting out kitchen fires should be considered a standard practice of cooking.

You are taking the idea of refactoring to an extreme and then attacking it. Refactoring != complete structural overhaul (at least not always), and it certainly shouldn't be a badge of disgrace. It's a perfectly reasonable and acceptable practice to write code to make something work that might be kludgy or not so clearly written with the intention of refactoring once the overall solution is in mind. Programmers don't always have the luxury of designing it perfectly before implementation. That's just unrealistic in today's market.

Re: The Rise and Fall of Object Oriented Programming

#14

Post by vannevar »

royjacobs wrote: post #5

Isn't the argument that there is nothing inherently wrong with OOP but like all things, it shouldn't be used exclusively? For instance, working with language like Kotlin or C# it's fairly straightforward to get the best of both worlds: Use inheritance where appropriate, favor composition in all other cases. IMO being dogmatic about not wanting inheritance altogether will result in friction as well: The fact that Rust…

I would quibble with the implication that composition isn't OOP---mixins have been part of many OOP languages for a long time. Whether you create a new object via inheritance or via composition, it's still an object, typically with methods and state.

Re: The Rise and Fall of Object Oriented Programming

#15

Post by hinkley »

tabtab wrote: post #10
MockObject wrote: post #7

> However, as the years went by, people started to realize that the strict approach to object orientation created a number of problems. These problems tended to be of the kind that makes code complex, hard to understand, and hard to test. No, ease of testing is one of the reasons for OO adoption, and probably the primary reason software is much more stable than it was in the mid 90s. > Many of those higher-level clas…

Re: Well, then it's broken and needs to be refactored. Refactoring means the original design didn't handle change well. Refactoring is badge of disgrace, and should not be considered a standard practice any more than putting out kitchen fires should be considered a standard practice of cooking. One of the key points of abstraction is to make the code change-friendly. If you have to refactor, the code failed that job.…

This is the sort of thinking that leads to analysis paralysis, and massive overengineering for what-ifs. Yes, the design you had when you had a smaller customer base in mind and when you were deep in Dunning-Kruger territory about your problem domain is not going to work once you actually know what the fuck you're doing. Shit happens, get over it. And yourself.

Being bad at refactoring will only make the experience more painful. Same with unit tests. Same with deployment. Same with pretty much everything.

> Refactoring means the original design didn't handle change well. Refactoring is badge of disgrace

I'm not sure how you intended this, but this reeks of shame-based project management, which is a bane and a scourge of the industry. Get out of here with your failure talk. You're spooking the natives.

Re: The Rise and Fall of Object Oriented Programming

#16

Post by hinkley »

yoz-y wrote: post #6
jkoudys wrote: post #4

I've always felt so alone in my distaste for ORMs. They often lead to at worst taking way more data than you need and manipulating it all in a language that's not very good at it, or at best running some kind of query-builder which takes a far more complex configuration to get the same data that a simple query could. Objects make much more sense as something to build from a query, not something to be queried themselv…

I tent to consider database querying as constraint oriented programming, so indeed it does not fit either OOP or FP model. However, I do think that mapping database records to objects can be useful once they are in the program space.

There's loads and loads of literature on this, but I never felt it as strongly as with Angular. No matter how you represent the data, you want one layer of the code to be responsible for final dispensation on the organization and data munging (maps to arrays, arrays to maps, undefined -> empty set, etc). Everything else in the system should treat those fields in a homogeneous manner, and if you don't like the way the data is shaped, you know exactly where the problem is.

ORM or not, there's going to be a clear spot in the code where any mismatches between the backend and the frontend will be found. Or you're going to play whack-a-mole forever, and ramping up new employees will be a strain.

Re: The Rise and Fall of Object Oriented Programming

#17

Post by hinkley »

daveslash wrote: post #3

To those who enjoyed reading this article, I'd also recommend this one. https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...

My main beef with this genre of article is that code is for humans, and if you don't think humans like nouns, bring an object to work that nobody there has every seen, and count how many people ask what it is before they ask what it does.

For many people, that kingdom of nouns lives in their brains. I'm not saying I agree with this entirely. I don't even think I'm saying we shouldn't fight it - I certainly have felt the pain of people wanting to pigeonhole me at work by noun instead of looking at what verbs I'm capable of.

But it's out there, and you don't have to look very hard to find it.

Re: The Rise and Fall of Object Oriented Programming

#18

Post by MockObject »

tabtab wrote: post #10
MockObject wrote: post #7

> However, as the years went by, people started to realize that the strict approach to object orientation created a number of problems. These problems tended to be of the kind that makes code complex, hard to understand, and hard to test. No, ease of testing is one of the reasons for OO adoption, and probably the primary reason software is much more stable than it was in the mid 90s. > Many of those higher-level clas…

Re: Well, then it's broken and needs to be refactored. Refactoring means the original design didn't handle change well. Refactoring is badge of disgrace, and should not be considered a standard practice any more than putting out kitchen fires should be considered a standard practice of cooking. One of the key points of abstraction is to make the code change-friendly. If you have to refactor, the code failed that job.…

> Refactoring is badge of disgrace, and should not be considered a standard practice any more than putting out kitchen fires should be considered a standard practice of cooking.

I can only grant you the benefit of the doubt and assume you aren't quite using the word the way the rest of the industry does.

Replacing two similar code fragments with two calls to a single method is an example of refactoring. In no universe would that ever be considered any sort of kitchen fire.

Re: The Rise and Fall of Object Oriented Programming

#19

Post by 0815test »

ashleyn wrote: post #8
royjacobs wrote: post #5

Isn't the argument that there is nothing inherently wrong with OOP but like all things, it shouldn't be used exclusively? For instance, working with language like Kotlin or C# it's fairly straightforward to get the best of both worlds: Use inheritance where appropriate, favor composition in all other cases. IMO being dogmatic about not wanting inheritance altogether will result in friction as well: The fact that Rust…

Inheritance is so natural to a GUI data structure. UI in Rust is incredibly painful. Probably a reason behind the CPU-wasteful "immediate mode" fad.

Implementation inheritance may have its uses, but it's not for the faint of heart. Its defining feature is _open recursion_; that is, defining an object's external interface (its bundle of public and protected methods) in terms of itself (in that any method may be defined as calling any other method of the same external interface) and then leaving the whole thing open for arbitrary overriding in "derived" classes, via a "tying the knot" trick. Most treatments of OOP brush over this feature, but it creates a huge amount of complexity. It is even proper to say that something like this should be avoided at all costs, IMHO.

Re: The Rise and Fall of Object Oriented Programming

#20

Post by professorTuring »

This article only says one truth: OOP is not as famous as it used to be.

The rest of it it's completely mistaken. The writer has no clue about OOP.

Let me tell you the problem with OOP. Everybody said "use objects" you will re-use them over and over, not only for this project but projects in the future as well.

But we already have libraries and I still yet to find someone (or enterprise) reusing its own code.

Every respectable programmer knows he must refactor his old code again because it's not so good anymore.

Post reply on HN