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

211–220 of 355 posts

Re: Goodbye, Object Oriented Programming

#211

Post by stevesun21 »

a programming paradiam can be accepted massively not because people hate the predecessor, it's because the new one is more intuitive and useful. If you hate oop so much, then approve how it is counter-intuitive compare to fp. Keep complaining make you sounds too emotional, as a SE you should know how to objectively analysis.

FYI, in OOP paradiam all inherent, encapsulate and so concepts are for one goal – design a better interface, that also follow how the real world be designed, for example, power outlet at you home.

Re: Goodbye, Object Oriented Programming

#212

Post by jccalhoun »

aibottle wrote: post #31

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.

begin? I've always hated it. I think it is called "medium" because it isn't well-done...

However, I don't think the style of this article is Medium's fault. I find it more and more common that I see a headline and have to skim through the whole article to find out what the point is. I don't know if it is from watching too many TED talks or just poor writing (not mutually exclusive, of course). But then I go read the comments and see tons of people commenting about how they loved the article and how well written it was so maybe it is me that is wrong.

On second though, no. It's the children who are wrong.

Re: Goodbye, Object Oriented Programming

#213

Post by seanmcdirmid »

l_dopa wrote: post #201
seanmcdirmid wrote: post #185

Earlier quoted context omitted.

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.

You're still, at some point, simulating the steps of some abstract machine in your head to understand what the debugger is telling you. The simplest case is replacing an expression with its value, given an environment of lexical bindings that are apprent from the source program. Not much investigation necessary. That's FP. For OO code, you just need to keep track of a lot more context: the state of the receiver of th…

OO context is internalized linguistically, via lots of metaphors. Those metaphors can lie, of course, but your brain can apply abstractions to the state of the machine to deal with its complexity, for better or worse. Ideal FP debugging, which I don't think exists in practice, relies on ultimate truth with equational reasoning realized through techniques like referential transparency. In the ideal case, you just reason about the equation and there are no hidden surprises, fuzzy metaphorical reasoning is minimized. In practice, there is still plenty of metaphorical reasoning going on for any non-trivial program as even explicit state necessarily becomes implicit as it increases in quantity (our brains can't handle seeing everything even if it is technically all in front of us).

OO thinking optimizes for the less ideal cases that are far more common. Ideal FP has this ideal mathematical view of the world that rarely pans out in practice, while less ideal FP just resorts to OO-style metaphors and abstraction in practice. For the kinds of experiences I work on (heavily reactive, lots of state, complex interactions), this works well for me, and we are developing techniques to make it less painful (live programming). "Worse is better", as RPG would say.

Re: Goodbye, Object Oriented Programming

#214

Post by goalieca »

twic wrote: post #135
ebbv wrote: post #26

Earlier quoted context omitted.

That is a good analysis. While I was reading this article all I could think is "You wanted to do things in a bad way and then you learned how to do it the right way and you don't like the right way?" His entire problem seems to be he thought OO was a magic bullet he could do whatever he wanted with and then he learned there was more to using OO than the three concepts he cites at the beginning. And this guy has suppo…

> And this guy has supposedly been writing in OO languages for decades? What? This is the bit i don't get. It's like he learned OOP in the '90s, when everyone thought inheritance was rad and nobody had realised how terrible mutating shared state was, and then fell asleep for twenty years. None of this article, none of it , has any relevance to how OOP is practiced by informed people today.

People use that crap today. Ever take a shake at wpf for windows? It's a fucking mess.

Re: Goodbye, Object Oriented Programming

#215

Post by fbonetti »

matsemann wrote: post #73
fbonetti wrote: post #58

Earlier quoted context omitted.

> For instance I have yet to see an easy and simple to use (and as such maintainable) functional widget and gui library. I will continue to shill for Elm[1], like I always do. [1] http://elm-lang.org/

But that's not a library. It forces your whole project into a box in which it may not fit. Elm is not without problems as well, although they (him?) are working on the biggest pain-points.

> It forces your whole project into a box

Isn't that the point? Since Elm is a pure, strongly typed language, it introduces a lot of constraints. You can't mutate anything, there are no side effects (only declared effects captured by the type system), and the only architecture you can use is "The Elm Architecture". However, those restrictions will keep your code sane and the compiler almost guarantees that your code will work. It's a pretty fair trade-off if you ask me.

Re: Goodbye, Object Oriented Programming

#216

Post by MaulingMonkey »

overgard wrote: post #150
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…

There are things that are painful to express in a pure functional language. I'll give you an example: rasterize a triangle to a mutable buffer. (An inherently mutable and stateful algorithm). You can certainly do this in a purely functional language, but I doubt it will be any clearer or more performant than its procedural C counterpart. I think pure functional programming is super useful in other contexts, for insta…

While I agree, within the same context, I want to point out that right next to rasterization you have shaders, which are a poster child for functional programming.

A vertex shader just transforms an input vertex (and some other inputs) into an output vertex, and a fragment shader just transforms an input fragment (and some other inputs) into an output fragment. This is done at a scale so massively parallel that we have dedicated hardware for it, because your CPU doesn't have enough parallelism.

Sure, HLSL and GLSL are locally procedural. The most recent fancy versions ofo them even allow for some shared state mutation within a thread wave, useful for certain niche uses. But in in their traditional contexts? I find even local mutation for most use cases to merely be a source of bugs and obfuscation via poor naming. And most of the built-in functions are pure.

Re: Goodbye, Object Oriented Programming

#217

Post by davidad_ »

The specific problem described in the "encapsulation" section is solved in modern C++ (11/14) by std::unique_ptr. While this may seem like a trivial quibble, I think it's part of why I find modern C++ quite tolerable despite disliking almost every other "object-oriented" language.

Re: Goodbye, Object Oriented Programming

#218

Post by jdeisenberg »

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…

Erlang is a good choice for doing massive parallel computing, and it is a functional language.

Re: Goodbye, Object Oriented Programming

#220

Post by jonnybgood »

eutectic wrote: post #108
overgard wrote: post #59

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…

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

Post reply on HN