6 ms·
On the contrary, I think that's a self-fulfilling perception. If assets are already organized as objects, then it'll continue to work well with oop. But if you
by kortex 4y ago
On the contrary, I think that's a self-fulfilling perception. If assets are already organized as objects, then it'll continue to work well with oop. But if you take the approach from the get-go to use data and FP approaches, things can be quite nice. Examples:
- interface/trait based programming / structural subtyping (widely used in go/rust, increasingly in TS and python)
- terraform
- react
- aws lambda / cloud functions
- flow-based data processing (the whole of deep learning, spark/hadoop)
- and of course, anything declarative DSL based (SQL, jq and friends)
So I would counter that the more valuable skill is "how do I solve problems in terms of applying and composing transforms to data"
To clarify, since everyone has their own definition of OOP, and of the four pillars, Abstraction, Polymorphism, aren't at all unique to OOP, and Encapsulation is just Abstraction: the defining features of OOP are inheritance and poking-and-prodding-state into opaque objects. Inheritance is subsumed by interfaces / structural subtyping, and poking at state is contrasted with reactor patterns, event sourcing, persistent data structures, etc.
Oop really shines at the middlin-low level, in languages without a lifetime (state for things like IO resourcese, at the GUI widget level, and the (micro)service level, which is more like the original smalltalk sort of objects, in which case inheritance isn't a think.
- munificent 4y ago> On the contrary, I think that's a self-fulfilling perception. So is using SQL. My point, as well as the parent author's point, is that I've found a technology that has been a useful source of value for my entire career. I make no claims that there aren't other useful sources of value, but I've never for a second regretted the time I've spent getting better at writing object-oriented code. I'm also quite comfortable writing functional and dataflow-oriented code, but I've never found those to be as exciting as some people seem to.
- kortex 4y agoFair enough! And yeah, since OOP is everywhere, there's zero downside to getting better at it. > I've never found those to be as exciting as some people seem to. It's less about excitement (for me at least) and less about the hair pulling associated with reasoning about complex state. I find the more independent attributes an object has, the harder it gets to reason about, unless I can serialize the whole thing (which usually goes against encapsulation). I'd say that's the number 1 thing I do to get "better at OOP": have a healthy suspicion towards any long-lived object I can't serialize/deserialize using primitive types.
- Scarbutt 4y agoReact is implemented using OOP, which I think is great for libraries that are defining and defending boundaries.
- continuational 4y agoHooks is not really OOP. The original OOP interface was abandoned because it lead to a very complicated lifecycle that was hard to reason about.
- pjmlp 4y agoExcept the little detail that JavaScript is an OOP language in the linage of SELF, where even basic types have methods.
- Scarbutt 4y agoI'm referring to the implementation of React, not its API.
- yamtaddle 4y agoCan confirm, unless it's changed radically since I last looked at it, yes, everydamnthing in React ends up as an object representing a component, and I don't just mean in the way that JS functions are technically also objects.
- mirekrusin 4y agoNo, it's not.
- yamtaddle 4y agoIt is, in large part, right down at what you might call the heart of the whole thing. Though I haven't read the React source code since a bit after Hooks were added so I guess maybe that's changed—though I doubt it.
- kortex 4y ago