Hacker News Reader

Comment by agumonkey | Hacker News Reader

I never found a way to sense the differences between OOP flavours (NPI). Are you thinking of ST/Ruby where it's object and method all the way down ?

View on HN

There are many models:

- OO like in Smalltalk

- OO like in SELF

- OO like in BETA

- OO like in CLOS

- OO like in COM

- OO like in Haskell

- OO like in C++

- OO like in Eiffel

- OO like in Ada

- OO like in Sather

A few more models might exist.

HyperCard and AppleScript. And JavaScript is pretty unique at this point. Scala's OO is also pretty unique with traits and type members.

How unique is JavaScript from SELF?

In regards to Scala, I would say OCaml has similar capabilities.

Scala's capabilities are not really comparable to OCaml, which doesn't even have traits. JavaScript has many influences beyond Self, and is enough of a mishmash even in its original form to have its own point in the list (at best, a not very similar descendant of self).

> Scala's capabilities are not really comparable to OCaml, which doesn't even have traits.

Yes, it has a bit of everything anyone thought about in FP in it.

However you can make use of traits like feature by mixing in modules and objects, while taking advantage of first class modules in OCaml.

> JavaScript has many influences beyond Self

Sure, but I am unaware of any that make it such a great language.

Scala's OO features are more like Java's done better. OCaml is this weird object system that is structural most of the time sometimes nominative, and then there is that weird ML module system. Ah...I totally forgot about Moby. [1]

JavaScript has been very successful, and got a whole generation of programmers playing around with prototypes without knowing it.

[1] http://moby.cs.uchicago.edu

Thanks for pointing out to Moby.

JavaScript's success has less to do with how good the language is, rather sharing the same fate as successful systems programming languages, by being the only gate to the kingdom.

I think the biggest difference between Scala and OCaml is that Scala users don't (have to) tell beginners to avoid the OO part at all costs.

OO in OCaml feels as if the designers thought "we think OO sucks, so let's implement terrible support for OO to get our point across".

OCaml's object/class system is actually pretty good. It isn't used very often in OCaml because most of what OO gives you can be more naturally expressed in other parts of the language, but that doesn't mean that it's bad. In particular, classes are still the best mechanism for open recursion in OCaml, and should be used when that is what is required.

> OO like in Haskell

Please explain. Are you referring to type classes?

Yes. Type classes is a way of doing polymorphism in Haskell, the central point of OO.

I thought the central point of OOP was to encapsulate functions ("methods") and the data ("objects") they operate on, thereby providing a way to structure code? That's why it's called "Object Oriented Programming" and not "Polymorphism X Y".

Wikipedia at least seems to agree with me.

That is only in the case of OOP as introduced by Smalltalk.

For example, OOP with multi-methods, does not imply such encapsulation.

I think one problem that people have when they are talking about object oriented (or FP for that matter), is that there isn't a clear definition around what it means. Most developers agree that it is some mix of encapsulation, polymorphism and inheritance.

There is a lot of disagreement about which of those is more important. For me polymorphism is the most important, encapsulation is useful sometimes, and inheritance might be a negative attribute. For you encapsulation.

I had that revelation at my college Lab, teacher discussing why OOP was such a beautiful thing, none of them could agree on definition of OOP nor the qualities.

FP is smaller and stricter, it's almost formally defined (you have denotational semantics for FP VM for what it's worth).

OO is more general than that, it's just a general paradigm for code reuse. Polymorphism is one of many forms of code reuse (allowing functions to accept multiple type signatures). I wouldn't call it the "central point" because polymorphism can be done without OOP, and OOP can be done without polymorphism.

What you're saying is that traditional OO conflates polymorphism with encapsulation and inheritance, creating one big complexity murder-death-ball; whereas Haskell lets you have these things a-la carte, so you can deploy them as needed.

It is central. Without polymorphism you don't have a way to abstract algorithms over types.

So you just get ADTs as introduced by Mesa/Modula-2.

You can do OOP with only ad-hoc polymorphism, which is just method overloading, which is what Java and C++ do. Actual parametric polymorphism isn't necessary for OOP, and there are non-OOP languages that have it (e.g. SML has polymorphism but does not have objects).

So, polymorphism and object-orientation are orthogonal concerns. OOP is about encapsulation, inheritance, and modules that couple mutable state (attributes) and behavior (methods).

For the curious, Ocaml mixes both, its object model is parametric (see: http://caml.inria.fr/pub/docs/u3-ocaml/ocaml-objects.html)

> You can do OOP with only ad-hoc polymorphism...

Which is still polymorphism. I purposely did not enumerate all CS forms of polymorphism, but can get more detailed if you will.

Reply on news.ycombinator.com