Live data from Hacker News

Goodbye, Object Oriented Programming

medium.com

181–190 of 355 posts

Re: Goodbye, Object Oriented Programming

#181

Let me try to list the objections: 1. Inheritance creates dependencies on their parent class 2. Multiple inheritance is hard 3. Inheritance makes you vulnerable to changes in self-use 4. Hierarchies are awkward for expressing certain relationships All true. But likewise, functions introduce dependencies on their arguments, and data structures introduces dependencies on their fields. You must consider your dependencie…

I think that inheritance and composition are not the interesting aspects of object oriented design, or of any language or paradigm. These are tools for code brevity / reuse / elegance. Advanced copying or ctrl-c.

I would also argue that too much elegance in any language or design paradigm faces the same problem, in that elegance is often (but not completely) in tension with modularity or granularity of control, which is an engineering subgoal, because a common engineering situation is to experience system change (feature growth or reorganization of code), and improvements in granularity or modularity makes system restructuring easier.

I think that object oriented design is more essentially about modelling distributed state, because you probably have multiple objects with their own internal state. I believe this means that object oriented design is highly concerned with protocolized communication and synchronization between distributed states, whether via messages or channels or something else.

I believe that in distributed situations, object oriented design can be very harmonious with functional reactive programming strategy. You can easily and usefully have a situation where an object functionally updates its internal state with a typed stream of inputs.

Re: Goodbye, Object Oriented Programming

#182

Programming paradigms are a lot like political parties -- they tend to lump a lot of disparate things together with a weakly uniting theme. You don't need inheritance for encapsulation to be useful, for instance. The problem is, sometimes you agree with only a small part of the platform. None of these things individually are terrible ideas if tastefully applied, but it all gets clumped together into one big blob of "…

I think that inheritance and composition are not the interesting aspects of object oriented design, or of any language or paradigm. These are tools for code brevity / reuse / elegance. Advanced copying or ctrl-c.

I would also argue that too much elegance in any language or design paradigm faces the same problem, in that elegance is often (but not completely) in tension with modularity or granularity of control, which is an engineering subgoal, because a common engineering situation is to experience system change (feature growth or reorganization of code), and improvements in granularity or modularity makes system restructuring easier.

I think that object oriented design is more essentially about modelling distributed state, because you probably have multiple objects with their own internal state. I believe this means that object oriented design is highly concerned with protocolized communication and synchronization between distributed states, whether via messages or channels or something else.

I believe that in distributed situations, object oriented design can be very harmonious with functional reactive programming strategy. You can easily and usefully have a situation where an object functionally updates its internal state with a typed stream of inputs.

Re: Goodbye, Object Oriented Programming

#183

God damn it I begin to hate Medium. Just another Bullshit article. When I read those dips ts description: "Software Engineer and Architect, Teacher, Writer, Filmmaker, Photographer, Artist…" Great. And you want to tell me that OO is dead and functional the only future? Fuck off.

I get your desire to deflate something you dislike. I know this calling-out of OOP, as in TFA, has become routine (e.g., Steve Yegge's posts were quite celebrated here, and that was years ago). Maybe you're tired of the banana quote, and thought this post brought nothing new. But your comment is purely ad hominem -- to the point of calling the author a dipshit with absolutely no basis -- and does not engage TFA (brea…

You gotta admit it was quite funny. There needs to be balance. Let it be.

Re: Goodbye, Object Oriented Programming

#184

Earlier quoted context omitted.

I work in a group of teams that is mostly new college grads and nobody has trouble writing pure FP business logic in Scala. We don't go as far as doing pure FP for all effects though (although we are starting to do that more as well) If we can do it, so can everyone else ;)

They come Berkeley and MIT, colleges that are renowned for teaching functional languages in their intro to programming courses, don't they.

I went to a state College (Mizzou) and everybody I knew that was in a CS degree took a Haskell course.

Re: Goodbye, Object Oriented Programming

#185

Earlier quoted context omitted.

> Except that there is a real advantage to using pure functional programming; being able to easily prove theorems about your code and understand different components in isolation. And how often does that occur in practice for most of the programs people write? Even the most hardcore Haskell programmer isn't going around proving theorems about their modules beyond what the type system can provide for free (and that is…

Any sort of thinking about what the code does or does not do is essentially proving theorems about it, is it not? It seems to me one does that all the time when debugging.

I don't think about coding that way. To me debugging is more like a Sherlock Holmes investigation rather than a formal theorem proving process. I guess we maybe work on different kinds of programs.

Re: Goodbye, Object Oriented Programming

#186

Programming paradigms are a lot like political parties -- they tend to lump a lot of disparate things together with a weakly uniting theme. You don't need inheritance for encapsulation to be useful, for instance. The problem is, sometimes you agree with only a small part of the platform. None of these things individually are terrible ideas if tastefully applied, but it all gets clumped together into one big blob of "…

>everything is an object, no you can't write a function outside of a class

This is all really semantics, when you consider static methods and classes as nothing more than namespace or extended function names.

Re: Goodbye, Object Oriented Programming

#187
I love using object oriented design and find it quite odd when I meet seasoned programmers who still don't 'get it'. It feels a bit like meeting someone who says Obama was born in Kenya.

Here's a concrete example of object oriented design:

To understand the problem domain, go to https://whiteboardfox.com and click Start Drawing > Create Whiteboard, then draw something. Play around with different colours, erase some lines, try undo and redo, etc.

Now here is my class diagram for implementing it: https://s1.whiteboardfox.com/s/7762255cabe34643.png

I honestly don't see how you could implement it without object oriented design. Surely it makes sense to have a Diagram class that encapsulates a list of strokes and pictures? Isn't it easier if the Diagram class exposes addStroke() and removeStroke() but does not reveal how it's implemented? And shouldn't I have a separate view class which encapsulates how much zoom and pan the user has applied to the diagram?

Could you implement Undo and Redo actions so neatly without a command pattern?

And isn't it lovely that the ViewController can switch between different modes (Pencil Mode, Eraser Mode, etc) without needing to know anything except a small interface that is common to all modes?

I actually get a little thrill when I think about how cleanly this design addresses the requirements. Could I get that feeling if this were implemented in a functional programming style?

Re: Goodbye, Object Oriented Programming

#188

Earlier quoted context omitted.

> Except that there is a real advantage to using pure functional programming; being able to easily prove theorems about your code and understand different components in isolation. And how often does that occur in practice for most of the programs people write? Even the most hardcore Haskell programmer isn't going around proving theorems about their modules beyond what the type system can provide for free (and that is…

Any sort of thinking about what the code does or does not do is essentially proving theorems about it, is it not? It seems to me one does that all the time when debugging.

Debugging is a time to stop thinking and start looking.

Thinking is probably what got you the bug in the first place, so to kill it a different angle is usually preferable.

In practice, this means sending in test data to see what happens and/or stepping through the code to see where it diverges from what we think it does.

Re: Goodbye, Object Oriented Programming

#189

God damn it I begin to hate Medium. Just another Bullshit article. When I read those dips ts description: "Software Engineer and Architect, Teacher, Writer, Filmmaker, Photographer, Artist…" Great. And you want to tell me that OO is dead and functional the only future? Fuck off.

So basically, you've given zero actual counterarguments other than an ad hominem. Or let's go at it this way- How exactly did you expect someone to introduce themselves who felt they had something to say about OO in a negative light?

Re: Goodbye, Object Oriented Programming

#190

God damn it I begin to hate Medium. Just another Bullshit article. When I read those dips ts description: "Software Engineer and Architect, Teacher, Writer, Filmmaker, Photographer, Artist…" Great. And you want to tell me that OO is dead and functional the only future? Fuck off.

It's missing "web artisan". So much self-entitlement.

> Bespoke website designer
Post reply on HN