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

The faster you unlearn OOP, the better for you and your software

dpc.pw

Post reply on HN
Print view View original

241–250 of 252 posts

Re: The faster you unlearn OOP, the better for you and your software

#241

Post by mercer »

koonsolo wrote: post #193
hliyan wrote: post #122

Earlier quoted context omitted.

OOP in that sense leans very close to concepts of normal humans. Objects, things objects can do, objects have separate responsibilities, etc. This is not entirely accurate. Human languages are closer to functional languages: they have verbs that operate on nouns. Verbs are not attached to nouns, but rather, the operation of the verb is dependent on the noun.

Yet OOP reads more like English and functional programming more like math.

That's bullshit. Consider a recipe:

Heat 2 tablespoons olive oil in a large skillet or paella pan over medium heat. Stir in garlic, red pepper flakes, and rice. Cook, stirring, to coat rice with oil, about 3 minutes. Stir in saffron threads, bay leaf, parsley, chicken stock, and lemon zest.

I'm not saying there's no place for OOP in the English language, but I strongly disagree that OOP always, or even most of the time, reads as OOP.

Re: The faster you unlearn OOP, the better for you and your software

#242

Post by mercer »

Const-me wrote: post #63

OOP is not a silver bullet but for some classes of problems it's the best tool available. That's the reason why all good rich GUI frameworks are OOP-based, including HTML DOM we use on the web. GPU APIs, OS kernel APIs are OOP-based as well.

I don't necessarily disagree, but wouldn't you agree that libraries like React seem to pull GUI's toward a more FP approach?

Re: The faster you unlearn OOP, the better for you and your software

#243

Post by wffurr »

ubercow13 wrote: post #138
jbverschoor wrote: post #133

Earlier quoted context omitted.

Ok nice, then you get a huge if tree for all different monsters and weapons.

How's that any different to a 'classical OOP' approach?

You can have free functions that operate on your classes instead of shoehorning every operation into one class or another or creating new ones from whole cloth just to hold a function (e.g. the Hit class mentioned earlier).

Writing methods makes it easy to add new types but not methods; you have to change every class to implement a new method. Writing functions makes it easy to add new function, but you have to update every function for a new type.

Each has its place, and issues arise when certain languages (e.g. Java) or paradigms ("classical" OOP) make it impossible to use one or the other style.

Re: The faster you unlearn OOP, the better for you and your software

#244

Post by Const-me »

mercer wrote: post #242
Const-me wrote: post #63

OOP is not a silver bullet but for some classes of problems it's the best tool available. That's the reason why all good rich GUI frameworks are OOP-based, including HTML DOM we use on the web. GPU APIs, OS kernel APIs are OOP-based as well.

I don't necessarily disagree, but wouldn't you agree that libraries like React seem to pull GUI's toward a more FP approach?

This react? https://reactjs.org/ Their web site says following:

> Component-Based

> Build encapsulated components that manage their own state, then compose them to make complex UIs.

Wouldn't you agree that components managing their own state is a textbook definition of OOP?

They even have inheritance-based examples on their main page:

> class HelloMessage extends React.Component

Re: The faster you unlearn OOP, the better for you and your software

#245

Post by itronitron »

coldtea wrote: post #81
itronitron wrote: post #29

Earlier quoted context omitted.

The Java Swing API is a good example of OOP done well.

Huh? If there was a worse example of over-engineering and crappy difficult to use API that would be Swing.

Swing can't be the worst example, it has no JButtonFactory.

Re: The faster you unlearn OOP, the better for you and your software

#246

Post by in9 »

I really think these kind of articles are valuable in the sense that they make us question the way we code our applications.

But I still think it's too easy to point to a problem without discussing possible solutions. I know the functional paradigm, focused on data streams and procedures, is where he is pointing at. But how does this facilitate the graph reference problem, for example?

The thing with oop, besides that is easy, is that is diffuse. Any o'll tutorial will have an order+client example.

Re: The faster you unlearn OOP, the better for you and your software

#248

Post by mercer »

Const-me wrote: post #244
mercer wrote: post #242

Earlier quoted context omitted.

I don't necessarily disagree, but wouldn't you agree that libraries like React seem to pull GUI's toward a more FP approach?

This react? https://reactjs.org/ Their web site says following: > Component-Based > Build encapsulated components that manage their own state, then compose them to make complex UIs. Wouldn't you agree that components managing their own state is a textbook definition of OOP? They even have inheritance-based examples on their main page: > class HelloMessage extends React.Component

Yeah, that's a fair point. React isn't purely functional, but in practice I'd say it still leans heavily toward a functional approach

You're encouraged to keep state only in top-level components, or in a functional-style state management library like Redux, and pass the data as props/parameters to pure components that are just functions. There's a huge emphasis on immutable data, and composing your various components/functions, passing them as props, etc.

The fact that React switched to using classes makes it seem less functional than it is, and honestly I'm not entirely sure why they decided to do so.

Anyways, you're not wrong, but the point I was trying to make is that React is definitely much more functional than other/older approaches to GUIs, and is popular in (large?) part because of that difference in approach.

Re: The faster you unlearn OOP, the better for you and your software

#249

Post by Const-me »

mercer wrote: post #248
Const-me wrote: post #244

Earlier quoted context omitted.

This react? https://reactjs.org/ Their web site says following: > Component-Based > Build encapsulated components that manage their own state, then compose them to make complex UIs. Wouldn't you agree that components managing their own state is a textbook definition of OOP? They even have inheritance-based examples on their main page: > class HelloMessage extends React.Component

Yeah, that's a fair point. React isn't purely functional, but in practice I'd say it still leans heavily toward a functional approach You're encouraged to keep state only in top-level components, or in a functional-style state management library like Redux, and pass the data as props/parameters to pure components that are just functions. There's a huge emphasis on immutable data, and composing your various components…

> You're encouraged to keep state only in top-level components

Doesn't state grow unmanageably large for complex GUIs?

> React is definitely much more functional than other/older approaches to GUIs

I'm not sure about that. Take a look, both projects are much older: https://github.com/dotnet/reactive https://reactiveui.net/

Re: The faster you unlearn OOP, the better for you and your software

#250

Post by mercer »

Const-me wrote: post #249
mercer wrote: post #248

Earlier quoted context omitted.

Yeah, that's a fair point. React isn't purely functional, but in practice I'd say it still leans heavily toward a functional approach You're encouraged to keep state only in top-level components, or in a functional-style state management library like Redux, and pass the data as props/parameters to pure components that are just functions. There's a huge emphasis on immutable data, and composing your various components…

> You're encouraged to keep state only in top-level components Doesn't state grow unmanageably large for complex GUIs? > React is definitely much more functional than other/older approaches to GUIs I'm not sure about that. Take a look, both projects are much older: https://github.com/dotnet/reactive https://reactiveui.net/

> Doesn't state grow unmanageably large for complex GUIs?

Yes, and there are various ways to make this less of a problem. Still, React generally favors explicitly passing props down the component hierarchy, keeping the actual UI bits pure functions and composing them in various ways that is typical of FP.

> I'm not sure about that. Take a look, both projects are much older: https://github.com/dotnet/reactive https://reactiveui.net/

Perhaps I should've specified that React, as a very popular 'GUI' library, is much more functional than many of the very popular libraries that came before it.

Anyways, my point was not that it's the first of its kind, or 'fully' FP, but rather that it's an example of how FP-style UI libraries can be a good solution, and even be popular because they're less OO in nature.

Post reply on HN