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

231–240 of 557 posts

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

#231

Post by ianbicking »

joeldo wrote: post #127
ianbicking wrote: post #63

Earlier quoted context omitted.

I assume you are talking about React. It started fairly OOP. Now it's... something else? It's not functional. IMHO hooks and effects are a crazy form of OOP. It's like some weird dynamic scope data definition.

I'm not exactly sure how hooks are related to OOP. Their design was inspired by 'Algebraic Effects' which are more functional in nature than OO. This gives a good breakdown: https://overreacted.io/algebraic-effects-for-the-rest-of-us/

Ah, that does make more sense, and is a language feature I've often thought about. It's usually just a pattern and not a first class feature, but with many problems as a result (many of which React itself encounters).

Lots of use of context managers in Python are for accomplishing this. Smalltalk error handlers are like this (different than try/catch). Or Scheme's with-output-to-file... I got the sense that variables that start and end with stars in Common Lisp are used for this, but I was never clear if it was convention or an actual language feature.

I think I'd like it in React too if they just hadn't tried to be so clever.

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

#232

Post by ummonk »

kloch wrote: post #177
unnouinceput wrote: post #141

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/Julia_(programming_language)

> Performance approaching that of statically-typed languages like C I might have to give this a try. Is there any language other than assembly that can beat the performance of C?

Other zero-abstraction languages like Rust and Ada have comparable performance to C/C++. Fortran in particular, which has a lot of high performance code written in it, is sometimes faster than C due to optimization assumptions the compiler can make about Fortran code that it can’t about C code. Julia can be slower than these languages due to having a garbage collector and not being a statically compiled zero abstraction language (though it is designed to dynamically compile to overhead-free code), but for some tasks it can actually be way faster than normal implementations in C or assembly, due to its ability to dynamically compile code specific to the particular invocation of a function.

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

#233

Post by shepherdjerred »

djmetzle wrote: post #225

Meh. Is this a hot debate still? No mention of Ruby or smalltalk in this post, which i think of as "true" OO languages, down to the runtime. The ruby object model has its merits! Sandi Metz's POODR is a fantastic intro into OO _and_ a compositional approach to design. FP vs OO is always a false dichotomy for sure. Actors and messaging appear in FP languages. Inheritance surely has nothing to do with OO. Inheritance m…

I completely agree with this. I love writing functional Java. The issue is mutation, not OOP

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

#234

Post by unnouinceput »

kloch wrote: post #177
unnouinceput wrote: post #141

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/Julia_(programming_language)

> Performance approaching that of statically-typed languages like C I might have to give this a try. Is there any language other than assembly that can beat the performance of C?

It's not about the programming language per se, but the compiler/linker optimization(s). C/C++ have this magic aura of being fast because it has the most worked on compiler/linker. Once other programming languages come around that are attracting more programmers, then theirs compiler/linker will be the best from optimization point of view. Also CPU's/architecture's change all the time so even if now C/C++ have the best on classic x86-64, that can change if a better CPU with a different opcode comes along. I believe this will happen in 10 years where we'll see quantum CPU's with massive parallelism implemented at which time the entire 50-ish history of C/C++ will simply become obsolete and every language will actually have to start from zero in terms of transforming human language coding into CPU's opcode.

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

#235

Post by qsdf38100 »

kloch wrote: post #177
unnouinceput wrote: post #141

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/Julia_(programming_language)

> Performance approaching that of statically-typed languages like C I might have to give this a try. Is there any language other than assembly that can beat the performance of C?

Fortran, c, c++, rust, … are supposed to give you something as good as writing assembly manually . Generally, there’s no reason for a statically typed and compiled language to be slower than manually written assembly. In practice it depends on how good the compilers optimizations are and how skilled the assembly programmer is.

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

#236

Post by a-dub »

reificator wrote: post #218
a-dub wrote: post #157

Earlier quoted context omitted.

what about when the abstractions age and a new feature for a system needs the data from the components from another system? the long term answer is probably a refactor, but what's the common quick fix? copying/duplicating data between component types? systems that examine other components as well as their native ones? merging systems? asking the hard question... how does it stand up to the unpleasant cases?

> asking the hard question... how does it stand up to the unpleasant cases? It's the best tool I know of for a certain class of problem, that's all I'm claiming. Not evangelizing it as a magical cure-all for all domains, just explaining it in enough detail that it can be understood by someone outside the domain of gaming. > what about when the abstractions age and a new feature for a system needs the data from the co…

thanks for humoring me! i'm writing because i'm genuinely interested.

so it seems like then, that the discipline in building a system in this fashion revolves around responsibility for updates (which system is the sole updater of a given type of component) and the sequencing of those systems (ensuring that all the systems that update components that are used by a given system have completed their updates, possibly with some sort of record level update indication that allows for downstream systems to begin processing before upstream systems have completed all their records).

do any of the ecs libraries provide facilities for these problems, or are they typically built into a game engine framework?

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

#237

Post by lolinder »

jshen wrote: post #188
taurath wrote: post #91

Earlier quoted context omitted.

> This is primarily because of inheritance, which seems counter-intuitive I agree that inheritance creates a lot more problems, but the usages of non-static methods and internal state even in classes with no usage of inheritance can feel just as bad, when you have a high level method utilizing instantiated objects. Internal state as a whole can be avoided fairly often

I don’t see much difference between some_state.do_stuff() do_stuff(some_state)

They're just different syntaxes for the same thing. I think what OP is driving at isn't the syntactic difference but making immutable what doesn't need to be mutable. You could do that with either syntax.

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

#238

Post by jolux »

dwohnitmok wrote: post #229
jolux wrote: post #208

Earlier quoted context omitted.

There's a lot to think about in your comments in this thread but I have a nitpick about functional programming style here. > In fact maybe it's nicer to have that implicit state strewn everywhere instead of having to carry around values which are irrelevant for the bulk of a function body and only relevant for a single part of a subfunction. I would call this an anti-pattern in FP. It's often a symptom of trying to r…

> Threading mostly-irrelevant state through a bunch of different functions is a sign that your program is under-abstracted. The problem is that often you do want fairly complex state in the leaves of the tree, but want very little of it in anything else. Web browsers are a classic example of this. Pure FP solutions such as Elm that completely eschew the idea of local mutable state require a lot more ceremony to imple…

I will say plainly that I think there are situations in which mutability offers more elegant solutions than immutability, but I think most languages that offer it do it badly. I’m most experienced programming the Erlang platform via Elixir, and I think it offers a really nice midpoint between locality of state and purity. Within a process everything is immutable, and mutation requires sending a message to a process that will have a function specifying an explicit, pure state transformation from that message. Just about the only thing I don’t love about Elixir is the lack of real types.

I’m also very pragmatic and to the example of a web browser I would say, most applications are not web browsers. The overwhelming majority aren’t, in fact. I’ve chosen at this point in my career to mostly focus on enterprise software development, which I believe was Rich’s original field as well, and I’ve seen an enormous number of solutions with too much state cast about everywhere that benefit massively from centralizing the state high in the tree and really thinking through the data model carefully. So I stand by the principle I advocated originally, but it’s not universally applicable. It’s my belief that one of the core virtues of software development is knowing when to apply which principles.

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

#239

Post by dwohnitmok »

john-shaffer wrote: post #224
dwohnitmok wrote: post #179

Earlier quoted context omitted.

First off I don't think this is quite the way Hickey thinks about the issue (though I suspect he would agree about the working memory part), especially with the comment about etymology /s!(it's a meme in Clojureland that every Hickey presentation and library must contain at least one slide on/mention of etymology) In particular Clojure as a whole embraces an ideology of "open systems" vs "closed systems" where we sta…

In production, I may only want one connection pool to a DB, and in that case global state is pretty much equivalent to passing state as an argument. Development in a Clojure REPL is a different story. I have one connection pool for the dev server, and a separate pool to run tests against. The test db is re-created from a template between each test run, without affecting the dev db at all. I can trivially have multipl…

To continue with my devil's advocacy...

> It is just the natural result of passing state as explicit arguments.

But nothing you've mentioned here is intrinsic to mutable state. It seems like all that's happened is you identified a part of your program that you wanted to be configurable and exposed a configuration knob. If for example you wanted to make it so that there is a test mode that where you want to prefix "test-" to every string written to the DB that would also probably involve a new argument somewhere. There's nothing here special about the mutable state part of it.

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

#240

Post by wackro »

zamalek wrote: post #206

My issue with OOP is: Design Patterns: Elements of Reusable Object-Oriented Software. I don't take issue with the authors, with their insights, or anything related to the content of the book. It's that the book exists at all: it's a book filled with solutions to imaginary problems. When using a procedural language the first thing you do is start implementing a solution. When using OOP, you first have to solve the ima…

>solutions to imaginary problems

This is a fundamental misunderstanding of what patterns are. The GOF book is used to this though.

A design pattern is someting that will naturally crop up if you adhere to certain design principles. If you follow a principle of separating instantiation logic from other logic then you will start to see factories. If you combine multiple complex parts of your code into simpler ones then you will see facades.

GOF is a reference book for some patterns that have been observed as being common, with examples that are essentially academic. It is not a how-to guide for OOP.

Post reply on HN