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?

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?

  • 1
    Did OOP make procedural programming obsolete? I hate to sound pedantic or that I'm talking down to you, but that was the first sentence that came to mind. Go provides a new(ish) paradigm. With experimentation, users will find out what it's good at and what it's not good at (as with all paradigms and languages), and we'll end up with hundreds of great products (along with it's fair share of bad products) written in Go. At least, that's my opinion Commented Jun 19, 2012 at 8:48
  • 1
    There are some interesting reads when you Google for OOP is dead. I recommend The Web Will Die When OOP Dies
    – Andomar
    Commented Jun 19, 2012 at 8:54
  • There is such a little value in OOP that it does not worth wasting your time at all.
    – SK-logic
    Commented Jun 19, 2012 at 13:42
  • 1
    I agree with previous comment do not focus on OOP too much. Besides OOP doesn't mean C++ or Java. Try to read abit on ltu.org Commented Jun 19, 2012 at 14:35
  • C++, Java, and C# are not "classic" OOP languages. If there is a classic OOP language, I think it is Smalltalk. Commented Jun 19, 2012 at 15:13

5 Answers 5


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.

  • 11
    +1 for "not necessarily the best one". Citing Alan Kay: "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind." (nor did he have C# and/or Java, I would humbly guess)
    – herby
    Commented Jun 19, 2012 at 9:16
  • 1
    @herby I've seen it suggested that agent-systems (similar to how Erlang works) are closer to Alan Kay's eventual intent for OOP. Commented Jun 19, 2012 at 14:33
  • 2
    Er, Common Lisp definitely have classes. But, typically, a CL class contains data and methods are defined on "generic functions". As a side-effect, that gives you a convenient way of doing multiple dispatch, since methods are no longer tightly coupled to "a single implementation class".
    – Vatine
    Commented Jun 19, 2012 at 15:26
  • Yes, what I meant is that it does not have classes in the Java sense
    – Andrea
    Commented Jun 19, 2012 at 15:49

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.

  • In fact, Go makes all those OOP things easier and adds a few extra possibilities like extending a type to provide new interface applying to existing instances (as long as you don't need new data members, of course).
    – Jan Hudec
    Commented Jun 19, 2012 at 15:16

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.

  • 2
    The question pertains to the concepts, not necessary the term. If you can come up with a better name than "OOP" to refer to the concept of class hierarchies and all the trimming that come with it, then we can use that instead.
    – tylerl
    Commented Jun 19, 2012 at 21:29
  • @tylerl: You're confusing at least two questions into one. One is, whether structural subtyping is better than nominative subtyping. The other one is basically, whether composition is better than inheritance. These questions are mutually orthogonal. I think ultimately the "best" language doesn't make this choice for you. I would speculate that Go simply has a different set of issues, but we'll see whether Google adds those features "back" or not.
    – back2dos
    Commented Jun 20, 2012 at 13:19
  • I would like just one language that has most of the capabilities of C++ but was smaller and simpler. C++ is the only language except C realistic for kernels, and it gives you extremely useful tools like destructors and the STL. And the important principle 'if you do not use it, you do not pay for it'. OO, used correctly, is extremely powerful. But generics and other non-OO concepts are also vitally necessary. C give you almost nothing, and Go throws away real OO for some strange new-fangled ideas. Commented Sep 3, 2016 at 6:12

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.

  • 1
    I think : thaught in many places. Is not an advantage , actually. Commented Jun 19, 2012 at 14:36
  • @AndreasScheinert why wouldn't it be an advantage? Commented Jun 19, 2012 at 15:53
  • Because to make a judgement you should know at lest 1 alternative equally good. It is a a habit issue, people like to stay in their comfort zone and that leads to stagnation. Commented Jun 20, 2012 at 11:57
  • @AndreasScheinert use the right tool for the job. Oop doesn't work for all scenarios....has nothing to do with their comfort zone
    – pqsk
    Commented Dec 8, 2013 at 5:35

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.