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

Goodbye, Object Oriented Programming

medium.com

Post reply on HN
Print view View original

221–230 of 355 posts

Re: Goodbye, Object Oriented Programming

#221

Post by flukus »

vikiomega9 wrote: post #192
flukus wrote: post #166

Earlier quoted context omitted.

The keyword there is informed. There are still plenty of shops that practice OOP this way. I'm working at one right now and there are OOP horrors around every corner. Unfortunately, they seem intent on adding more mutable state rather then eliminating it.

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 requires inheriting from a application logger (which is already 3 or 4 layers deep in the inheritance hierarchy.

The distinction other loggers make between the log interface and the appenders are non-existent. If you want to log to a new source (say the event log) you have to add a new layer to the inheritance tree.

Then there's the fact that it's handling the application state, in an "on error resume next" kind of way. And this is a global state, so don't even think about multi threading.

Naturally, actually accessing the logger is done via a singleton.

It causes more problems than it helps resolve, and the ones it causes naturally don't have an diagnostic information available.

There are plenty of others, but it's hard to top this tour de force of OO anti patterns. If only there was some free and stable alternative...

Re: Goodbye, Object Oriented Programming

#222

Post by iainmerrick »

jonnybgood wrote: post #220
eutectic wrote: post #108

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

> pure functional programming; being able to easily prove theorems about your code I believe you're referring to a type system. That is different. There is little about functional programming that allows you to easily prove theorems about your code.

No, FP is great for analyzing your code! Internal state and side effects are the main things that make code hard to analyze, and it's exactly those things that FP avoids.

Re: Goodbye, Object Oriented Programming

#223

Post by RCortex »

Apocryphon wrote: post #137
whateveracct wrote: post #127

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.

Err, not exactly, Berkeley and Mit use python now and have been for a while.

Re: Goodbye, Object Oriented Programming

#224

Post by jonnybgood »

iainmerrick wrote: post #222
jonnybgood wrote: post #220

Earlier quoted context omitted.

> pure functional programming; being able to easily prove theorems about your code I believe you're referring to a type system. That is different. There is little about functional programming that allows you to easily prove theorems about your code.

No, FP is great for analyzing your code! Internal state and side effects are the main things that make code hard to analyze, and it's exactly those things that FP avoids.

How is that related to easily proving theorems about the code?

Re: Goodbye, Object Oriented Programming

#225

Post by iainmerrick »

seanmcdirmid wrote: post #155
eutectic wrote: post #108

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

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

The "proving theorems" stuff is definitely overstated. People always toss that term around, and it's true in principle, but in practice hardly anyone ever uses correctness proofs in real world code.

But to flip it around and make a less grandiose version of the same point: the majority of bugs are to do with state. (I don't actually know if that has been "proved" but it's definitely what I find in practice!) Pure FP gets rid of a whole swathe of potential bugs at one stroke. Of course it makes programming harder in some other respects, as often it can be hard to figure out a pure function that's as efficient as the obvious imperative algorithm, or even to figure out how do a state-y thing in FP in the first place.

Re: Goodbye, Object Oriented Programming

#226

Post by Illniyar »

pjmlp wrote: post #84
Illniyar wrote: post #5

I think the functional vs OO debate is being done with a very narrow point of view. Functional came before OO and there are reasons why it became much more popular- it had much better, easier and simpler solution to the most common problems of the 90's and early 2000's, namely handling GUI and keeping single process app state (usually for a desktop app). It fares much worse in today's world of SaaS and massive parall…

Lisp with LOOPS, followed by FLAVORS and finally settled on CLOS?

What are those?

Re: Goodbye, Object Oriented Programming

#228

Post by PhasmaFelis »

MawNicker wrote: post #202

Object Oriented Programming simulates the restrained reasoning capacity of the real world. This is done by weaving state into every conceivable unit of computation. The result is a universal and inescapable notion of identity. It's a state conspiracy! Sometimes you are actually interacting with the real world and this is an appropriate constraint. That is only because, in the real real world, these things are pervasi…

I don't want to be rude, but that is nearly impossible to read without paragraph breaks.

Re: Goodbye, Object Oriented Programming

#229

Post by seanmcdirmid »

iainmerrick wrote: post #225
seanmcdirmid wrote: post #155

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…

The "proving theorems" stuff is definitely overstated. People always toss that term around, and it's true in principle, but in practice hardly anyone ever uses correctness proofs in real world code. But to flip it around and make a less grandiose version of the same point: the majority of bugs are to do with state. (I don't actually know if that has been "proved" but it's definitely what I find in practice!) Pure FP…

I agree with this mostly. You can get rid of state in OO programs, and that often involves a bit of functional programming. Struct/values in C# help a lot in keeping the performance up (well, if GC is a problem, you can also inline your closures to prevent boxing...lots of crazy things like that). Essential (rather than accidental) state is impossible to eliminate in any case.

Re: Goodbye, Object Oriented Programming

#230

Post by Illniyar »

MindPenguin wrote: post #46
Illniyar wrote: post #23

Earlier quoted context omitted.

Is this same react where your components keep internal state (called state) and every component must be created by extending a base class?

Conceptually, components have state, but it's all managed by react, so you only ever write pure functions. Granted, depending on how you update state in event handlers and lifecycle methods, you will need to think about state a lot, but this is an unavoidable fact of UI programming. > every component must be created by extending a base class This is an implementation detail, instead of ES6 classes you can also use Re…

Conceptually is nice. All react code I've seen or wrote of even the most trivial systems have components (and more then a few) that override lifecycle methods - which is by almost definition OO's polymorphism.

Buy even if you could write every component with the stateless style it doesn't change the fact that your framework/GUI-library is using OO extensively and in it's fundamental concepts, I think that makes it OO, you seem to disagree.

Post reply on HN