291–300 of 312 posts
Earlier quoted context omitted.
Not just invariants, covariants as well. State and zip code always change together. Having had to fix code that passed 5 variables around for an address (which needed to go to 6 for “address 2”) I replaced it with an address object.
You can have an address struct, and functions that manipulate it in controlled ways (like always updating the state when the ZIP changes), in every language, whether OOP or not.
This doesn't speak to what I consider some of the most dangerous parts of OOP, which include the assumptions that tightly binding data and code is helpful, and that statefulness is fine to freely sprinkle throughout your program.
"Tightly binding data and code" allows you to maintain complex invariants via code, and to abstract away from the specifics of any single implementation. Statefulness per se is quite manageable; what's not manageable is shared, mutable state that isn't isolated to a single, modular, highly cohesive "unit" of code that can be understood in its totality. The real issues with OOP have to do precisely with things that br…
Well put. To turn it around, the ideal of state management is:
- Immutable, isolated state
- State operations are singular - I guess meaning centralized as well as atomic
- State operations are modular and cohesive units of code
- Can be understood in its totality - which implies centralized state management, where operations are not scattered thoroughout and intertwined with, for example, UI code
In my experience, I generally agree with the sentiment against "proper" OOP, as an accepted or preferred style of code organization. This is related to some fundamental truths and advantages that the rising popularity of functional programming is revealing.
Even in the world of UI and software for the web, the classic OOP patterns are getting "disrupted" in a healthy way, and it seems to be moving in the direction of composing immutable states, idempotent functions with no side-effects, where state changes and effects are centally managed in an isolated way.
Earlier quoted context omitted.
Of course the biggest gain of ORMs is initial dev speed. If you're going to stand up a business in a week or a month, Django ORM and its migrations are going to get you a pretty darn good solution without spending hours and hours thinking about your RDB design and handling many-to-many relationships "by hand".
Yeah, why spend hours on the most important part of the application and likely the most important part of the business when you can gloss over with with an ORM and not worry about designing the database until it comes back to bite you in the ass when you can no longer grow your business because of the incredibly stupid thing you did which is not designing your database. Frankly, those businesses deserve to fail if th…
I've never seen a business go bankrupt because of the DB, but I've seen plenty never make it to market because all their money was burned in development. This is stupid and a great example of how shitty engineering can doom a project.
Most important thing is to determine if people are actually gonna buy your app, if you can make a business out of it. Like it or not, marketing is the most important part of the business.
Earlier quoted context omitted.
You can have an address struct, and functions that manipulate it in controlled ways (like always updating the state when the ZIP changes), in every language, whether OOP or not.
That is OOP, regardless of what the language is.
For me, true OOP requires some sort of inheritance and/or runtime method dispatch, at least.
Earlier quoted context omitted.
It's the most successful programming paradigm in history. I feel like being anti-OOP is like being anti-vax. It's so successful and ubiquitous that it's success becomes invisible and so people only focus on the failures or misuse. Complaining about OOP requires an entire object-oriented software stack to post your argument.
Hacker news was written in Arc, which, AFAIK, explicitly has no object-oriented features.
Earlier quoted context omitted.
A good example would be a complex state machine, where you rely on the fact that the state is only modified by the state machine code to make sure it remains well-formed, and the control-flow itself heavily relies on the state being well-formed (think of a TLS session, for example). But then again, what you want there is modularity, which OOP provides, but is also well-supported in other paradigms.
Yeah but you don't need OOP to do that. See opaque pointer's in a number of non OOP languages.
The author is in desperate need of an actual understanding of OOP, an understand of what OOP looks like in practice, and the most basic understanding of other programming paradigms (or at least a rudimentary understanding of what’s meant by procedural, structural and functional programming.)
Earlier quoted context omitted.
Which FP languages do you think would be good for managing state? I've read here on HN the idea that FP is appropriate when you can think of your program like a pipe (data comes in, data goes out). To me, significant amounts of state would be antithetical to that. Is that view mistaken?
That's a good way to put it. I've thought of it as "FP is good if you can think of your program as a single possibly recursive data transform, even if it's a very elaborate one." AFAIK it is theoretically possible to model any program that way, but it's only convenient for some problems.
In my experience (20 years of OO programming and 5 of fp)... Almost all programs are better modeled as data transformations (recursive or otherwise). One time I did come across a data structure where this did not work, but I was not convinced that the layout of the data structure itself was wisely designed (it was tied to a legacy Django ORM layout).
Earlier quoted context omitted.
This is a common misunderstanding. Structural programming like this is clearly similar to what we think of as OO. But it existed before OO and is still heavily practiced in non-OO languages such as C. The main feature that OO added to this was dynamic function dispatch via inheritance. The specific function that gets called at runtime depends on the type of the struct. Inheritance has proven powerful but often result…
... and this inevitable pedantry is why I thought twice about replying to OP.
https://blog.cleancoder.com/uncle-bob/2018/04/13/FPvsOO.html