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

51–60 of 86 posts

Re: Joe Is Wrong (2009)

#51

Post by HeckFeck »

michaelcampbell wrote: post #44
nesarkvechnep wrote: post #32

Earlier quoted context omitted.

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.

Exactly, if anything it lends validity to the idea. See how Leibniz and Newton thrashed it out over calculus.

Re: Joe Is Wrong (2009)

#52

Post by youerbt »

majkinetor wrote: post #46
youerbt wrote: post #39

Earlier quoted context omitted.

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.

Yes. Records in Java are another example. But that only fuels my suspicion, that oriented part is the problem.

Re: Joe Is Wrong (2009)

#53

Post by BeefWellington »

meheleventyone wrote: post #3

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…

IMO this is an example where both parties can be right and wrong at the same time. "Correctness superposition" if you will. I have come to think of programming languages themselves a bit like art. Take fiction for example; Arguing about the "provably best way" the thing the programmer is typing should look is a bit like arguing which writer is the greatest. Everyone's going to have an opinion and the only thing the majority will agree about is when an author is really terrible.

When I started out programming it was all straightforward procedural languages, working up to C eventually. It took me a bit to figure out why OO was this big new shiny thing everyone loved when I first started to learn C++ and Java. Eventually I understood that the strength was around having functions that manipulate the state tied directly to the struct carrying that state was handy and saved a lot of type checks and variable passing for the programmer.

Java and C# are good examples of languages where there's a straightforward admission that everything can't be OO. Static methods are pretty non-OO in their conception but even if you wanted to argue they fit, how many projects eventually wind up with a `public static class Utils` or end up shoveling in extension methods in C# to accomplish some common task that in C would just be an include and then calling the function directly.

Re: Joe Is Wrong (2009)

#54

Post by necovek »

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…

I think binary operator overloading is a bit of a stretch here and it usually has clear rules in whatever language you choose.

But the more general question of where to put `combine_with()` in `A.combine_with(B)` is on neither (and not necessarily on another object either).

Unfortunately, this is prevalent in OOP programming but it is simply bad architecture. Of course, with it being so common, it's natural to blame OOP programming, because—in a way—it lets people get away with it easily.

As others have pointed out, the most pragmatic approach is the most reasonable one: use functional paradigms where they make more sense, OO-ones where they do. When things stop making sense (as in your example), don't do it!

To best understand what things make sense, start doing TDD and you'll quickly learn to de-couple things that don't need to be coupled (even if you don't end up doing TDD all the time).

Re: Joe Is Wrong (2009)

#55

Post by zozbot234 »

Kototama wrote: post #47

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

The point of encapsulation is (1) to protect meaningful invariants of the internal state - you care about external modifications because those might break your invariants; (2) to abstract away an object's interface from how the internal state happens to be implemented. Sometimes there are meaningful choices to be had in implementation, and any allowance for "external" modifications basically adds to your object's interface and breaks that abstraction. Both of these can be useful. Concurrent access is yet another issue, of course, and newer languages make it easier to control it.

Re: Joe Is Wrong (2009)

#56

Post by indymike »

OOP, FP or procedural, or even good old fashioned, start the top, run to the bottom imperative scripting all suffer from human beings choosing the wrong paradigm, or implementing that paradigm poorly. OOP has been largely a force for good, and the modern FP movement has been great, too. Same goes for dynamic typing and strong, static typing. It's all good if applied to the right problem.

Re: Joe Is Wrong (2009)

#57

Post by michaelcampbell »

balefrost wrote: post #49
nesarkvechnep wrote: post #32

Earlier quoted context omitted.

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.

Erlang allows BEAMs on multiple machines, and of course multiple schedulers on multiple cores.

I think it'd be harder to make them run serially than concurrently, and of negative benefit.

Unless OP is saying this is some "rule" of being an Hewitt "Actor" in which case I'd call that somewhat arbitrary and unnecessary.

Re: Joe Is Wrong (2009)

#58

Post by necovek »

xupybd wrote: post #13

I find OO can wind up in a complex mess. If I have to look into 4 levels of inheritance I'm very lost. Encapsulation is great if your encapsulated black boxes function as they should. However that is often not the case, or at least you need to dig into that black box to understand the system. Mixing data structures and models is something I find difficult. It can be hard to follow the logic of a simple function if it…

That's a pretty good insight: FP encourages working with simpler data types, whereas OO encourages encapsulating everything into these complex types which become unbearable as they get deeply nested.

Re: Joe Is Wrong (2009)

#59

Post by teekert »

I only like this and the opposite post because now I know that even experts don't agree and I can feel good about using OOP when I feel like it is appropriate.

As a rookie it can be a tad jarring to read that OOP is an invention from the devil just to lure us into some hell later on. Now I know I can safely take such arguments with a grain of salt.

Re: Joe Is Wrong (2009)

#60

Post by fendy3002 »

majkinetor wrote: post #46
youerbt wrote: post #39

Earlier quoted context omitted.

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.

Not op, but I think you missed his / her point.

Let's take static void main as example. It's a series of operation called at the beginning (at least during my era), does not need to be in a class. The very reason we put it on class (let's say) Start, feels like language limitation.

The same with class Math, such as Math.floor and Math.ceil. Is Math a class or is it more suitable as a namespace? Since no object instantiated from Math is required (and maybe the same with static class).

However I don't think OOP is bad or limited language, beside the static void main part.

Post reply on HN