Live data from Hacker News

OOP Is Dead, Long Live OOP

gamedev.net

261–270 of 357 posts

Re: OOP Is Dead, Long Live OOP

#261
post #148

Earlier quoted context omitted.

It looks like that you are working on stuff that may not benefit from OOP. You seem to be doing heavy « computations », you care more about the data than the logic around it. Probably Haskell suits your usecases more.

Actually I work primarily on web services. We benefit from Haskell in that HKTs allow us to model our service completely in the type system. Our Rest and GraphQL API are completely modeled in a type level DSL. Once we've ingested data, which can then be validated automatically using types, we can then express our data transformation in a way that makes the transitions extremely transparent in our code. Our backend se…

I do think this echoes fooyc's point though: this does not sound like an area that would benefit from OOP. Sounds like an ideal use-case for functional.

Re: OOP Is Dead, Long Live OOP

#262

Earlier quoted context omitted.

My personal anecdotal experience is that OOP lends itself well to very very large codebases. A language like java with packaging, classes, and encapsulation strongly encourages some meaningful organization. Even if that organization is implemented poorly by the user, it's better than what I have seen users create in the real world with languages like C. If you have a project where a single person could reasonably und…

I was a programming teacher some years ago and I would sometimes grade two submissions, which had both gotten full marks from the automated tests but where one was 150 loc and the other 500 loc. The most surprising part was that if I read the longer submission first, it would never really seem like there was that much excess code to take away. But obviously there was. > My personal anecdotal experience is that OOP le…

I have a hard time getting on board with the "waste" or loc argument. The things that matter most to me are readability, organization, maintainability, etc. If the structure that provides those things results in there being more lines of code, or more "waste" then that's a price I'm happy to pay.

The context you describe being a teacher is exactly the kind of case I was suggesting OOP may not be beneficial. If you're in a programming class you are generally not maintaining code bases with millions upon millions of lines of code. In that case, in a case where a single person is likely capable of understanding the entire code base, OOP probably isn't bringing any serious benefits.

Re: OOP Is Dead, Long Live OOP

#263
post #177

All my attempts to jump off OOP train break at exact same moment when I try to write a unit test. Closure: or, simply use this monstrous component pattern when 70% of your code is boilerplate or hack into namespaces and override functions in them in runtime. And don’t forget to do it in right order! JavaScript: yeah, simply re-define ‘require’ before importing dependencies in tests. Yeah, do it in right order. Recent…

I've done it well in C projects by tackling it at build time. Compile each test separately and use the dependencies of the test to decide what to link against, so if the test has "#include " then that gets translated to link against mock-thing.o which implements all the functions from thing.h (the interface) plus some ways to manipulate the state. Basically compile time dependency injection. I think this is a fairly language independent way to handle things.

By relying on make for the heavy lifting the tests are completely incremental, only tests that depends on modified files get run. It also doesn't pollute the run time code with layers of indirection.

Re: OOP Is Dead, Long Live OOP

#264

Does anyone know of a good reference for idiomatic OO(P)? Like the Codd paper for Relational Algebra.

Well, the best analogue to the Codd's relational algebra is Hewitt's actor model in my professional opinion. Both are based on mathematical formalism, though the Actor Model goes a bit further in that it's also informed by physics. But, just as SQL doesn't really implement Codd's relational algebra, so it is the case that most so-called OOP languages miss the mark vis-à-vis Alan Kay's original conception. The analogy…

Kay also mentioned the Internet is an OO system. At one point he was thinking every object would have it's own IP address.

He does have an account here on HN. https://news.ycombinator.com/threads?id=alankay1 I hope he doesn't get tired of explaining the same things over-and-over again. I have asked questions and he has answered, but I usually end up misinterpreting the ideas. :(

Re: OOP Is Dead, Long Live OOP

#265
post #233

Earlier quoted context omitted.

Bad code is bad code, no matter which language. Languages won't save you from poor design choices. OOP is popular in large enterprise systems because it (purports to) promote encapsulation and abstraction, which allows many teams/people to interact. Organizations may like OOP because it helps reinforce their drive for independence and fiefdom (see Conway's law https://en.m.wikipedia.org/wiki/Conway%27s_law ). Whether…

> Bad code is bad code, no matter which language. It’s easier to write bad code in some languages than others. > Languages won't save you from poor design choices. They do. They save you from entire classes of bugs, and make it less easy to shoot yourself in the foot. Do we need to have this conversation every time we talk about language design? Do you think the tool you use to achieve a task doesn’t matter?

> Do you think the tool you use to achieve a task doesn’t matter?

I think many people do think that, with a twist; specifically, when presented with a higher level language they'd argue "it's just a tool", while a lower level language would be "the wrong tool for the job".

I.e, for a hypothetical Ruby programmer, Haskell = "just a tool", C = "the wrong tool".

Re: OOP Is Dead, Long Live OOP

#267
post #9

If we just had made inheritance as something to be avoided unless absolutely needed then OOP would have probably never got such a bad reputation. All the other concepts make perfect sense.

Mutable internal state is problematic with or without inheritance.

Re: OOP Is Dead, Long Live OOP

#268
post #177

All my attempts to jump off OOP train break at exact same moment when I try to write a unit test. Closure: or, simply use this monstrous component pattern when 70% of your code is boilerplate or hack into namespaces and override functions in them in runtime. And don’t forget to do it in right order! JavaScript: yeah, simply re-define ‘require’ before importing dependencies in tests. Yeah, do it in right order. Recent…

Give it up. Mocks are mostly useless. If you want testable code, the first step is to separate computations from effects. Most of your program should be immutable. Ideally you'd have a mostly functional core, used by an imperative shell. Now to test a function, you just give it inputs, and check the outputs. Simple as that. Oh you're worried that your function might use some other function, and you still want to test…

This. I'll also add that in the world of things like Docker and [Insert]CI you don't need to mock most external dependencies like databases.

Re: OOP Is Dead, Long Live OOP

#269
post #183

Earlier quoted context omitted.

Really? I’d say the accidental distribution of state across objects due to cross cutting concerns is exactly where OO breaks down for me.

If cross-cutting concerns are making your architecture unwieldy, you likely haven't used composition enough / are doing OOP the bad way (tm).

No, some logic simply isn’t cleanly decomposable, plus the main problem here is that objects lets you get away with implicit state (e.g. if (this.x == 0) doA() else doB(); ) for long enough that when you start realizing you need explicit state, it’s usually distributed quite a bit.

Re: OOP Is Dead, Long Live OOP

#270

Becoming a professional Haskell and Erlang developer really shifted my view on OOP (let OOP denote class based OOP as found in Java or C++). In my view, OOP is prove a poor model for computation, and the result has been that OO code is almost always significantly more complex and error prone than an equivalent computation written in a concurrent, functional, or structured paradigm. Recent trends in language design (s…

I haven't done erlang or haskel, but this sums up what I've been thinking / trying to get around for years.
Post reply on HN