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

Case against OOP is understated, not overstated (2020)

boxbase.org

Post reply on HN
Print view View original

281–290 of 557 posts

Re: Case against OOP is understated, not overstated (2020)

#281

Post by jodrellblank »

qsdf38100 wrote: post #251
dwohnitmok wrote: post #156

Earlier quoted context omitted.

I enjoyed the talk and agree with it in many ways, but perhaps a contrarian stance will stimulate some interesting discussion. Here's the steelman I can think of against that talk. Hickey's fundamental contention is that whether something is easy is an extrinsic property whereas whether something is simple is an intrinsic property. Whether something is easy is dictated often by whether it is familiar, whereas simplic…

This concept of "used to" vs "understand" reminds me of an interview with Feynman where IIRC he explains how can magnetism work at a distance to a layman person. He discusses about the "why" questions and how you keep getting deeper and deeper each time you ask "why". He concludes that his explanations won’t be satisfying for the other person, saying "I can’t explain this to you in terms you are more familiar with".…

It's the Feynamn "Fun to Imagine" video / series.

This bit is wher ehe says that about magnets: https://youtu.be/P1ww1IXRfTA?t=1300

Re: Case against OOP is understated, not overstated (2020)

#282

Post by halpert »

taurath wrote: post #14

In my mind, state is the real enemy impacting: comprehension, brittleness towards making changes, and the surface area exposed to potential bugs. OOP as frequently implemented, while claiming to encapsulate state, ends up creating so much more. In accordance with this view, I think project architecture should be approached with an emphasis around how much state is necessary for it to run. This is why simulations like…

Sorry, but state is everything. If you don’t have state, then you’re essentially doing useless work computing an answer that is already known. Computation is only useful because of state.

Re: Case against OOP is understated, not overstated (2020)

#283

Post by baryphonic »

butwhywhyoh wrote: post #166
agency wrote: post #70

Earlier quoted context omitted.

There's a really wonderful talk that I've recommended to almost everyone I've ever worked with called Simple Made Easy[1] by Rich Hickey. I also struggled to explain why I hated state so much. You can talk about races with shared mutable state but even single threaded code I found I couldn't stand it, that it made things harder to reason about and change. It's because state is complex , in the sense Rich discusses in…

The problem I have with talks like this is that they sound fantastic on the surface. They almost sound self-evident! "Duh! I want to make simple things, not easy things! That was great!" But where are the examples? Not a single example of something easy versus simple, or how something "easy" would resist change or be harder to debug. All of these concepts sound fantastic until you begin to write code. How do I apply…

If you want functioning, robust, maintainable software (or even better, software that doesn't require maintenance), then spend a long time modeling the problem domain. Build it as a system of types, a protocol, perhaps even a language (or at least an AST with semantics). Prove things about this model, particularly some useful things about soundness, consistency and (in)completeness. Learn all the funky symbols people use in the literature, learn about the strange tools you weren't told about in undergrad like dependent typing or higher-order contracts or CRDTs and lattices. Spend a lot of time doing this. Then, when you have determined the essential shape of the domain and nothing more, implement the software. At that point, the code almost writes itself.

I submit that if we did that, we would have excellent, elegant, simple software, but following the process would be incredibly hard. So hard, in fact, that it couldn't possibly be distilled into a conference talk.

Re: Case against OOP is understated, not overstated (2020)

#284

Post by FpUser »

paragraft wrote: post #77
FpUser wrote: post #57

Earlier quoted context omitted.

What it the name?

React, presumably, with its approach that a UI is well described by nested functions operating on state. It's a good point. I remember long discussions on mailing lists for various FP languages conceding that UI toolkits were the one area where OOP seemed the natural fit. Haven't seen many of those discussions since React emerged.

Ah that one. Sorry but in my book React is an abomination. Speed of developing decent UI in React vs for example something like ages old Delphi is incomparable. The last one wins hands down.

Re: Case against OOP is understated, not overstated (2020)

#285

Post by deltaonefour »

zozbot234 wrote: post #35
jiggawatts wrote: post #23

I don't quite understand what this is trying to say. It's a summary review of some reviews? Or something. It's not even clear if the author of this post agrees or disagrees with the claim in the YC News title. It's peppered with sentences like: "That you don't understand something doesn't mean it's flawed or bad." Precisely. Many of the arguments against OO are from academics that don't write real-world, large-scale…

Rust is not an "anti-OO" language. It has a basically complete featureset for OO programming with the one exception of implementation inheritance. It is fully usable for programming "in the large".

You can say this for ANY language. Literally any language that can assign a function to be part of some struct could be "OO"... which is basically any language including C.

So given the pervading reality, colloquially when we say the term "Object Oriented Language," we are not referring lisp or C or haskell even though all of those language are technically OO.

The same can be said for Rust. Rust is NOT OO.

Re: Case against OOP is understated, not overstated (2020)

#286

Post by Const-me »

deltaonefour wrote: post #108
dboreham wrote: post #95

Conjecture: programming is hard, especially as the scope of the system becomes larger and the problem domain more complex. This means that all programming tools and techniques have at least some problems and downsides. It also means that any solution involves trading off various factors, e.g. code is fast or easy to read but perhaps not both. All this means that you can pretty much point to anything in our field and…

>But FP isn't used so much for real world solutions It's taken over the front end. The react paradigm is FP. SQL read queries are FP.

> The react paradigm is FP.

https://reactjs.org/ homepage writes "Build encapsulated components that manage their own state" That's a textbook definition of OOP.

Re: Case against OOP is understated, not overstated (2020)

#287

Post by FpUser »

baryphonic wrote: post #283
butwhywhyoh wrote: post #166

Earlier quoted context omitted.

The problem I have with talks like this is that they sound fantastic on the surface. They almost sound self-evident! "Duh! I want to make simple things, not easy things! That was great!" But where are the examples? Not a single example of something easy versus simple, or how something "easy" would resist change or be harder to debug. All of these concepts sound fantastic until you begin to write code. How do I apply…

If you want functioning, robust, maintainable software (or even better, software that doesn't require maintenance), then spend a long time modeling the problem domain. Build it as a system of types, a protocol, perhaps even a language (or at least an AST with semantics). Prove things about this model, particularly some useful things about soundness, consistency and (in)completeness. Learn all the funky symbols people…

Domain knowledge is very important. In the real world however by the time you finish this type of process the competition will have had the product out already. It may not be that perfect castle in the sky but it will work and if you have revenue you will have time and means to improve.

Re: Case against OOP is understated, not overstated (2020)

#288

Post by deltaonefour »

everyone wrote: post #16

People spend way too much time arguing about this.. If you're a good programmer u will be able to do excellent maintainable work in any language you're experienced with. If you're bad you will make a mess in any language. It'd be like carpenters saying "spruce is terrible if you make anything from spruce its fucked, you have to use oak." ; A good carpenter will be able to make something amazing from spruce. Like carp…

You don't understand. This is not what FP programmers are arguing about.

What FP programmers are arguing about is that all code becomes shit if you do OOP. It doesn't matter how good you are.

They argue that if you do FP your code is much less likely (note the word likely) to be shit.

The analogy to carpentry or craftsmanship is bad. Programming is about managing complexity to a degree no one can fully hold in their head or understand. You can't just be a "master" craftsman and write an entire OS with zero technical debt.

The argument here is that if you use FP over OOP your code will have magnitudes less technical debt.

Re: Case against OOP is understated, not overstated (2020)

#289

Post by edwinyzh »

_9omd wrote: post #268

I never understand all the hate for certain tools. OOP is a tool, FP is a tool, and other programming paradigms are different tools. If you're bad a software architecture and you tend to write convoluted OOP software, you're probably also going to make a mess using FP as well. Applied correctly, they can both be great tools for different problem sets. Writing something that inherently has a lot of state, like a simul…

Correct. Complains against OOP is like complaining a hammer not suitable for a task which you should have picked up a wrench in the first place.

Re: Case against OOP is understated, not overstated (2020)

#290

Post by galaxyLogic »

Take any Object-Oriented language. Then modify its definition so that any class can have just a single method (as opposed to any number of methods).

You now have a new language which you could call a procedural- or functional language based on the set of features that were present in the language you started from. But it is no longer an Object-Oriented language.

To make it more concrete start with Java compiler but modify it so it only allows max one method per class.

You now have NOOP-Java. (Non Object-Oriented Java).

Are you happy? Is this NOOP-Java somehow better than the plain old Java? If not really then removing the OOP-ness did not really help did it?. OOP is good. You want to keep OOP, not remove it.

OOP lets you have multiple functions associated with a data-structure the details of which you hide behind those functions (a.k.a. methods). I think THAT is the essence of OOP. You can have multiple functions attached to the same data-structure and only those specific functions can read and write that data-structure.

Isn't that something that really is so useful that getting rid of that feature, getting rid of "OOPness", would be crazy?

Post reply on HN