Live data from Hacker News

Joe Is Wrong (2009)

goran.krampe.se

31–40 of 86 posts

Re: Joe Is Wrong (2009)

#31

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…

There is a function/type duality that goes very deep into foundations of mathematics, but it's a conceptually different one than the one proposed in OOP. So I don't think interpreting all those similarities as being OOP is quite correct.

Re: Joe Is Wrong (2009)

#32

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.

Re: Joe Is Wrong (2009)

#33

The thing I find interesting about revisiting these old pieces is that the debate about the merits of OOP is effectively stymied. This post and the article it replied to posted yesterday ( https://news.ycombinator.com/item?id=26586829 ) could effectively have been written today. And the debate in the comments tends to be pretty formulaic as well. It's one of those perennial topics that generates a lot of heat from re…

Why would you want to revisit these debates, having progressed beyond them? :) Instead of rehashing "Is OOP good, actually?", we should explore the boundaries of the paradigm by making a popular language that's based on prototypes, or that privileges composition over inheritance, or pulls apart the various pieces of OOP into standalone concepts that can be mixed and matched. If we get inspired, maybe come up with som…

> we should explore the boundaries of the paradigm by making a popular language that's based on prototypes, or that privileges composition over inheritance, or pulls apart the various pieces of OOP into standalone concepts that can be mixed and matched.

JavaScript? ;-)

Re: Joe Is Wrong (2009)

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

A paricular point people don't get is that Java joined functional programming instead of beating it. The Hotspot compiler was based on a research runtime for a functional language. Type inference is basically the same as ML family languages. With heavy use of Lambdas and higher-order functions some of my Java looks like ML. If i want to have functions like maybe(x, f1, f2, ...) that works (emphasis) like the maybe mo…

This frustrates me though.

My POV ("Writing functional stuff in Java is a headache") gets lost between the much larger camps of "Functional bad, Java good" and "Java is functional and therefore good". Or worse "Java is better because it's both OO and FP".

I want to type inference to work as well as ML. I don't think it ever will.

I want to be free of nulls. I don't think I ever will be.

I want the language to just let me implement `interface Monad` and not need to generate code to arity 30.

Re: Joe Is Wrong (2009)

#35
post #33

Earlier quoted context omitted.

Why would you want to revisit these debates, having progressed beyond them? :) Instead of rehashing "Is OOP good, actually?", we should explore the boundaries of the paradigm by making a popular language that's based on prototypes, or that privileges composition over inheritance, or pulls apart the various pieces of OOP into standalone concepts that can be mixed and matched. If we get inspired, maybe come up with som…

> we should explore the boundaries of the paradigm by making a popular language that's based on prototypes, or that privileges composition over inheritance, or pulls apart the various pieces of OOP into standalone concepts that can be mixed and matched. JavaScript? ;-)

You joke but I think TypeScript's structural typing is really cool and has a lot of neat advantages of nominal typing.

Re: Joe Is Wrong (2009)

#37
post #33

Earlier quoted context omitted.

Why would you want to revisit these debates, having progressed beyond them? :) Instead of rehashing "Is OOP good, actually?", we should explore the boundaries of the paradigm by making a popular language that's based on prototypes, or that privileges composition over inheritance, or pulls apart the various pieces of OOP into standalone concepts that can be mixed and matched. If we get inspired, maybe come up with som…

> we should explore the boundaries of the paradigm by making a popular language that's based on prototypes, or that privileges composition over inheritance, or pulls apart the various pieces of OOP into standalone concepts that can be mixed and matched. JavaScript? ;-)

I can neither confirm nor deny that I had any particular languages in mind... but, yeah, having slightly or wildly different takes on various patterns can help us explore the practical consequences. I would suggest that the history of JS is good evidence that prototypes are harder to use and reason about than classes.

Re: Joe Is Wrong (2009)

#38
Yes I oslo agree : For me, the the OO programming gets me close to the design of the problem I try to solve. I mean before even programming. Then when I feel ready to program my solution, Actors become classes naturally.

I tend to believe OO langage simply gives us less work to design & program solutions.

Re: Joe Is Wrong (2009)

#39
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 the only way he could make it. So you have all those User/DateFormatter/Encoding objects for no reason, but language limitation. And then, on top of that, when you want an actual object, something that does its thing, have internal state and an interface to communicate (not a method call), you are on your own.

Re: Joe Is Wrong (2009)

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

The meaningful alternative to OOP is modular, object-based programming based on composition instead of inheritance. That encompasses both "pre-OOP" and "post-OOP", mainly functional-based idioms. Simple imperative programming does not really scale to larger software systems, modularity and compositional thinking are essential.
Post reply on HN