Live data from Hacker News

Goodbye, Object Oriented Programming

medium.com

281–290 of 355 posts

Re: Goodbye, Object Oriented Programming

#281
post #240
post #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 l…

> 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? Dat…

PS I feel your joy on finding a nice way to abstract your domain and represent it just right.

Re: Goodbye, Object Oriented Programming

#282
post #233

Earlier quoted context omitted.

Actually, from what I've seen, pure FP forces people with less experience into design and structures of their code that they'd only do in imperative settings with considerably more experience. Eg when I asks students to do some simple exercise like "write a function that finds the shortest path through a given graph", in impure languages their solutions tend to return a path if they find one, but just give up with eg…

Funny choice of exmple, the algorithms I am aware of for finding shortest paths require mutable vertices that store the scores and pointers (edges) for the best part found so far . No doubt there ways to do it in a pure functional language -- but that requires a bit of thought. Compared to that difficulty, this business of return values seems trivial. Worse, a language that forces people to Do The Right thing, might…

>Worse, a language that forces people to Do The Right thing ... just encourages closed minded rule-following.

I think experience shows that freedom to do the wrong thing frequently leads to the wrong thing happening. There are many case studies to be found in security and concurrency.

Re: Goodbye, Object Oriented Programming

#283
post #221

Earlier quoted context omitted.

Do you have anecdotes you can share? :D

Quite a few, but the worst would be the custom logger. I got lost trying to trace the inheritance graph. which spans projects, and the dependency graph, loggers within loggers within loggers. I gave up when I ran out of space trying to sketch the relationships in my notepad. Being encapsulated means you don't actually have any control over the logger, or the threads it spins up. Creating a logger for a new app requir…

> If only there was some free and stable alternative...

There's no shortage of good-enough loggers out there for major languages.

Re: Goodbye, Object Oriented Programming

#284
post #221

Earlier quoted context omitted.

Quite a few, but the worst would be the custom logger. I got lost trying to trace the inheritance graph. which spans projects, and the dependency graph, loggers within loggers within loggers. I gave up when I ran out of space trying to sketch the relationships in my notepad. Being encapsulated means you don't actually have any control over the logger, or the threads it spins up. Creating a logger for a new app requir…

> If only there was some free and stable alternative... There's no shortage of good-enough loggers out there for major languages.

The ellipsis in this case appears to me to be a sarcasm indicator, not a real wish.

Re: Goodbye, Object Oriented Programming

#285

How about we just say this: OO solves a set of problems albeit with tradeoffs Functional solves a set of problems albeit with tradeoffs There. We can all go back to our tea.

yep... I was just dunking a hobnob while writing some good old imperative C. Did anybody notice that Vulkan, "the future" of graphics APIs, doesn't f*ck around with OO or Functional?

GLSL does have things in common with functional programming. Immutable inputs, restricted rules for mutating data, no side effects.

Re: Goodbye, Object Oriented Programming

#286
post #241
post #81

When I read such titles I feel sad. In 2016 we are still talking about Cobol, which is spread in a relatively niche market and considered as a pillar in fields like banking, how can the object oriented paradigm be considered " past or even bad? It is the present and will be the future for at least the next 20 years, considering the number of billions lines of code. From a management perspective, such statements are n…

Cobol is certainly considered bad.

While I think that you are definitely right and that nowadays Cobol would probably not be the first choice for 98% companies out there, I think we should also consider that according to TIOBE ( http://www.tiobe.com/tiobe_index ) Cobol is one of the 20 most used languages in the world - and it's also thanks to it that we can use banks efficiently. Can we all say goodbye to Cobol? Go and ask those ones who program in such language - who make a s* load of money with it.

I personally could say goodbye to Assembly, as I only used it for learning purposes, I could say goodbye to Perl, because I don't use it and I don't like it, or I could say goodbye to Visual Basic - for other reasons. All these languages are extremely powerful, they still do their job today, although some are too low-level for our everyday applications, some are just in a process of replacement (like Cobol, of course). However, I tend to keep these opinions for myself.

"Saying goodbye" in such cases is a strong statement, inherently sensationalist and biased, therefore my criticism toward the title. In a field like computer science, you can't and shouldn't use such titles. Such a title shows already how biased you (the author) are.

Re: Goodbye, Object Oriented Programming

#287

My experience with ReactJS has been the first time I felt I had the perfect balance of OOP and FP. The components are so well defined as objects since they have the luxury of being tangible. But using them in a pure manner with zero local state makes them so easy to reason about and reuse. More can be said about Redux but I'll leave it there.

What is OO about React though? You have data, and pure functions. Where does OO come into it?

You can create components from functions or as classes. I will create a button class, which has some methods for how it renders and updates itself and how a user interacts with it. I can then subclass it to make a toggle button or whatever else.

Say I have a form with 4 fields and a "Submit" button. The submit button's `onClick` tells its parent that it was clicked. The parent calls `getValue()` on all of its children (the form fields) and dispatches a `updateMyDatabase()` action.

My example may be controversial to some as my form fields have state. Some may say that on every keystroke, the form should have an action called that updates the `centralState.formValue`. But regardless of that, I think it's still evident how there's OOP involved?

Re: Goodbye, Object Oriented Programming

#288
post #60

Inheritance is overused in OOP. There are many ways to share object behaviors, inheritance only works well when you expect all objects of both classes to share all behavior except one or two things. Even then, you should investigate dependency injection before reaching for inheritance. For the example given for the Triangle Problem, the author isn't clear about exactly what behavior is being shared among the classes.…

From a purist view one could argue that inheritance doesn't belong in OO in the first place. Alan Kay's first descriptions of Smalltalk & OOP did not include inheritance concepts.

  class A {
      public int field1;
      public void method1() {
          System.out.println("A");
      }

      public void method2() {
          System.out.println("A");
      }
  }

  class B extends A {
      public int field2;
      public void method1() {
          System.out.println("B");
      }
  }
is basically equivalent to

  interface C {
      public void method1() {}
      public void method2() {}
  }
  
  class A implements C {
      public int field1;
      public void method1() {
          System.out.println("A");
      }
      public void method2() {
          System.out.println("A");
      }
  }

  class B implements C {
      public A a;
      public int field2;
      public void method1() {
          System.out.println("B");
      }
      public void method2() {
          a.method();
      }
  }
As you can see both are basically the same except one little detail. The benefit is that you don't have to write the redundant "method2" method in class B. So the only time inheritance is ever useful is when you don't want to override all methods. Now someone tells you to model everything in terms of class hierarchies even when they don't need it right now and you've negated the tiny little benefit it ever had which means not having it in the programming language actually has positive consequences.

Re: Goodbye, Object Oriented Programming

#289

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 "…

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. There is a reason why the majority of proof assistants are implemented as functional languages. Most functional languages even give you ways of modelling imperative code (e.g. monads) in a way which hardly sacrifices expressiveness. The real…

The problem I have with the functional paradigm is that it's couched in the idea that all problems can be reduced to same kind of algorithms. It's better to accept that all problems can be reduced to some king of algorithm whether or not it follows neatly along with the functional paradigm. That's why OOD sometimes works better for some problems over others and vice versa. Plus, I think not all functional programming languages are equal in this regard. I have a bias toward Ocaml since it's fairly easy to get into it without having to abandon previous knowledge. You can learn Ocaml even if most of your professional life you've written code in C. Whereas Haskell you have to unlearn lots of old idioms which worked well in C to get a basic comprehension of Haskell. So, just picking up Haskell because you think a specific problem is easier within the functional paradigm is a bad idea IMO. Unless you have plenty of time to learn then go for broke.

Re: Goodbye, Object Oriented Programming

#290
post #231
post #117

Earlier quoted context omitted.

The real disadvantage of pure functional programming is that it is notoriously difficult to use and thus only very few programs outside specialized domains are written in them. For example I would guess that in a typical enterprise (say, a manufacturing company), 0.0001% of the software is written in a pure functional language. Things OO languages 'force' us seem to be relatively easy to use: sending a message to a c…

The majority of software written ever has been written in the world's most popular functional programming language: Excel.

Oh God, if you saw the Excel workbook my previous boss created as the back end for the financial calculations used in all our applications you'd scream in horror. Like just about every contingency in the process was done within the excel workbook and not just as a wrapper around some simplified formulas.
Post reply on HN