Benefits of classic OOP over Go-like language

Question

I've been thinking a lot about language design and what elements would be necessary for an "ideal" programming language, and studying Google's Go has led me to question a lot of otherwise common knowledge.

Specifically, Go seems to have all of the interesting benefits from object oriented programming without actually having any of the structure of an object oriented language. There are no classes, only structures; there is no class/structure inheritance -- only structure embedding. There aren't any hierarchies, no parent classes, no explicit interface implementations. Instead, type casting rules are based on a loose system similar to duck-typing, such that if a struct implements the necessary elements of a "Reader" or a "Request" or an "Encoding", then you can cast it and use it as one.

Is there something about OOP as implemented in C++ and Java and C# that is inherently more capable, more maintainable, somehow more powerful that you have to give up when moving to a language like Go? What benefit do you have to give up to gain the simplicity that this new paradigm represents?

EDIT
Removed the "obsolete" question that readers seemed to get excessively hung up on and infuriated by.

The question is, what does the traditional object oriented paradigm (with hierarchies and such) as frequently seen in common language implementations have to offer that can't be done as easily in this simpler model? Or, in other words, if you were to design a language today, is there a reason you would want to include the concept of class hierarchies?

Answer 1

There is no new paradigm. Object orientation is a pattern you use to write programs, which is not even clearly defined. Various languages provide various traits typical of object orientation (definition of new types, encapsulation, type hierarchies, polymorphism, message passing and more) but may fail to provide others. In those cases it is up to programmers to emulate them if the need arises.

Many of the languages that provide these features do not have an analogue of the class concept - for instance Javascript and Common Lisp. The implementation provided by Java-like languages (class-based, with single inheritance, interfaces, type-based dispatch) is just one of the possibilities, and not necessarily the best one.

Answer 2

What benefit do you have to give up to gain the simplicity that this new paradigm represents?

The type checking for a structural type system is a lot more complex than simply checking if the baseclass is in your inheritance list. Virtual dispatch becomes a bit trickier, and likely less performant.

Does such a system obsolete the concept of OOP?

No. As long as you can make the program in terms of 'objects that do things' rather than a list of instructions, or a declared set of rules, or a cascading series of functions... the implementation doesn't matter. Likewise, changing the type system doesn't invalidate any of the common OO principles.

You can still work on a base type and not care about its actual type. You can still extend types without modifying them. You can still make a type do only one thing. You can still supply fine grained interfaces. You can still supply abstractions to your types.

How a language allows that doesn't really matter.

Answer 3

I think your idea about OOP is quite a bit off:

I invented the term 'Object Oriented Programming' and this {Java and C++} is not what I had in mind.
- Alan Kay.

The choice of typing (nominative subtyping, structural subtyping or duck typing - or a combination of those) is largely orthogonal to OOP. Inheritance and classes are entirely orthogonal to OOP. If you take some time to play with io you will come to see that.

Now you can ask which kind of type systems are "better", and which means of code reuse and combination are. And try to determine the advantages and drawbacks between the choices made in Simula (and later carried on in C++, Java and C#) and those made in Go. But these are all different and distinct questions.

Ultimately, OOP is a very vague concept and all attempts to implement it come in a huge variety of flavors. But to really simplify things, I'd say the core idea of OOP is to compose systems of SOLID subsystems. Now this absolutely blurs the line to other paradigms, but I'd speculate that that's the reason why multi-paradigm languages have risen in popularity recently and why Google has taken it's own shot at that with Go.

Answer 4

OOP is not obsolete.

As Andrea said there have been many concepts proposed as an alternative to classes (for ex: haskell typeclass). OOP has one big benefit: it is taught in many places, and the culture of OOP is largely shared among developpers.

This enables richer communication inside a team. One can talk about factories more easily than about Zygohistomorphic prepromorphisms. OOP structures the way you will organize and communicate about your programm with commonly used diagrams. This is a powerful asset.

Answer 5

No, there's nothing new here, nor is OOP obsolete. C++ has implicit interfaces too in the form of templates, but people still use virtual functions. You need explicit interfaces to cope with, e.g., binary interfaces, or interfaces where the other code simply isn't known at compile-time.

You could argue that this is simply a case of inference vs stating it explicitly, which is nothing like a "new paradigm" and really just more convenient.