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

Joe Is Wrong (2009)

goran.krampe.se

Post reply on HN
Print view View original

41–50 of 86 posts

Re: Joe Is Wrong (2009)

#41

Post by bitexploder »

m_mueller wrote: post #27
mtzet wrote: post #12

These discussions tend to boil down to OOP vs FP. That's a false dichotomy. The alternative to OOP is not FP, it's pre-OOP imperative programming with various techniques a la carte. Should data and functions be together? That's a choice you can make on a case-by-case basis. It makes total sense that a HashMap has an insert() method. On the other hand, maybe your Player object is just some data which is interpreted by…

I love this take. Programming techniques are that, tools on our belt. One should neither fall in love with a particular one, nor try to use it exclusively. Either it fits, meaning it provides advantages that outweigh the added complexity, or it doesn't.

Python balances this well. You are never forced into an OO hierarchy for your own code.

Re: Joe Is Wrong (2009)

#42

Post by throwaway744678 »

pansa2 wrote: post #17

One issue I have with (pure) OOP is the way that methods are associated with a single type (and its subtypes). What about operations that don’t naturally belong to any one type? For example, binary operator overloading. With unrelated classes `C` and `D`, should the implementation of `+` to handle `C.new() + D.new()` be added to `C` or `D`? Conversely, if both `C` and `D` define an implementation of `+`, which one sh…

In C++, quoting cppreference.com: "Binary operators are typically implemented as non-members to maintain symmetry (for example, when adding a complex number and an integer, if operator+ is a member function of the complex type, then only complex+integer would compile, and not integer+complex)". This makes perfect sense.

In other languages, I'd say: perhaps implement the operator in the return type of the operation?

Re: Joe Is Wrong (2009)

#43

Post by iomodo »

It’s all about your thinking process - the way you want to think when you solve a problem. It’s not about the programming language. You could use OOP even in C. And clearly there is no right or wrong here. As always, it depends, in some cases your problem is solved easily with OOP or FP or with imperative paradigm or any other.

Re: Joe Is Wrong (2009)

#44

Post by michaelcampbell »

nesarkvechnep wrote: post #32
yellowapple wrote: post #22

Imagine being a Smalltalker and still missing the underlying context of Joe's article - specifically, around the actor model (as used extensively in Erlang) being substantially closer to OOP as intended by e.g. Smalltalk than to the popularized inheritance-heavy brand of "OOP". You can see this in the objections: > Objection 1 - Data structure and functions should not be bound together ...and yet the usual way to sto…

A small nitpick, Erlang doesn't implement the Actor model. The similarity of Erlang's processes and the actors, defined by Carl Hewitt, is accidental as stated by Joe Armstrong multiple times. Edit: Actors doesn't run concurrently.

This feels a bit like a distinction without a difference. If 2 people come up on the same idea without knowledge of the other, that doesn't necessarily make them different ideas.

Re: Joe Is Wrong (2009)

#45

Post by yellowapple »

nesarkvechnep wrote: post #32
yellowapple wrote: post #22

Imagine being a Smalltalker and still missing the underlying context of Joe's article - specifically, around the actor model (as used extensively in Erlang) being substantially closer to OOP as intended by e.g. Smalltalk than to the popularized inheritance-heavy brand of "OOP". You can see this in the objections: > Objection 1 - Data structure and functions should not be bound together ...and yet the usual way to sto…

A small nitpick, Erlang doesn't implement the Actor model. The similarity of Erlang's processes and the actors, defined by Carl Hewitt, is accidental as stated by Joe Armstrong multiple times. Edit: Actors doesn't run concurrently.

> Edit: Actors doesn't run concurrently.

Why not? That's literally the whole point of the actor model; actors are definitionally units of concurrent computation. That's exactly why Hewitt based the actor model on how e.g. particles interact in physics - those interactions necessarily being concurrent.

That is:

> The similarity of Erlang's processes and the actors, defined by Carl Hewitt, is accidental as stated by Joe Armstrong multiple times.

Just because processes accidentally behave like actors doesn't mean they ain't actors.

Re: Joe Is Wrong (2009)

#46

Post by majkinetor »

youerbt wrote: post #39
mtzet wrote: post #12

These discussions tend to boil down to OOP vs FP. That's a false dichotomy. The alternative to OOP is not FP, it's pre-OOP imperative programming with various techniques a la carte. Should data and functions be together? That's a choice you can make on a case-by-case basis. It makes total sense that a HashMap has an insert() method. On the other hand, maybe your Player object is just some data which is interpreted by…

My problem with object oriented programming it's not the object part, it's the oriented part. In object oriented programming, there is, usually, no trade-off. It's objects all the way down. The problem is that not many things actually need to be an object. But when something needs to be one, there is no distinction. No way to tell whether somebody made a thing an object, because it makes sense or just because that's…

Not necessarily: C#, for example, has a lot of FP like moments. Its not particularly relevant how are those internally implemented.

Re: Joe Is Wrong (2009)

#47

Post by Kototama »

One problem with encapsulation is that it is used to protect modification of the internal state of an object against external modifications but with very little benefits. Languages which are more relaxed on this subject (Python in some extend, for example) have shown that programmers are, most of the time, just not stupid enough to mess with the internals of an objects and that all the ceremony of encapsulation brings little value.

In top of that, a much bigger problem is that encapsulation is fundamentally broken, it does not prevent against what a real source of bugs: concurrent accesses on the object.

Re: Joe Is Wrong (2009)

#48

Post by submeta »

When I started programming in Pascal in the early 90s, my procedures/functions and my data were decoupled, spread all over the place. Then I started learning (Turbo)Pascal with OOP. It was godsend. All of a sudden I could structure my code in a way I wasn’t able to do before.

Now thirty years later I know how to structure my (Python) code without OO: Via modules. I hardly use OO anymore. And I am drawn to FP more and more. But I see cases where OO is useful.

I don‘t think it‘s either/or. We should be glad we have all sorts of paradigms to go back to.

Re: Joe Is Wrong (2009)

#49

Post by balefrost »

nesarkvechnep wrote: post #32
yellowapple wrote: post #22

Imagine being a Smalltalker and still missing the underlying context of Joe's article - specifically, around the actor model (as used extensively in Erlang) being substantially closer to OOP as intended by e.g. Smalltalk than to the popularized inheritance-heavy brand of "OOP". You can see this in the objections: > Objection 1 - Data structure and functions should not be bound together ...and yet the usual way to sto…

A small nitpick, Erlang doesn't implement the Actor model. The similarity of Erlang's processes and the actors, defined by Carl Hewitt, is accidental as stated by Joe Armstrong multiple times. Edit: Actors doesn't run concurrently.

Actors doesn't run concurrently.

Is that an actual law, or is it just that some implementations of the pattern are deficient? My impression is that the actor model was originally envisioned as being applied to a machine with hundreds or thousands of processors.

Re: Joe Is Wrong (2009)

#50

Post by eternalban »

mtzet wrote: post #12

These discussions tend to boil down to OOP vs FP. That's a false dichotomy. The alternative to OOP is not FP, it's pre-OOP imperative programming with various techniques a la carte. Should data and functions be together? That's a choice you can make on a case-by-case basis. It makes total sense that a HashMap has an insert() method. On the other hand, maybe your Player object is just some data which is interpreted by…

> These discussions tend to boil down to OOP vs FP. That's a false dichotomy. The alternative to OOP is not FP, it's pre-OOP imperative.

Thank you for raising this oft ignored fact. I remember graduating from C to C++ in order to hack on SGI’s OpenGL in 1991. Possibly graphics and scene-graphs are a sweet spot for OOP, but I found the approach very elegant and quite effective.

OOP, as a paradigm (it is not a “tool”), is one of the handful of viable approaches for organizing and writing code. Given that these are paradigms, it is natural that there are those who have a natural mental affinity for one and abhorrence for another. In my view, the only merit in these comparative critiques is when contextualized within a specific, e.g. UI development, problem space.

(Also, Joe (RIP) is indeed wrong. OOP doesn’t suck, it bloows. /g)

Post reply on HN