Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
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 –  Jamie Taylor Jun 19 '12 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 Jun 19 '12 at 8:54
    
There is such a little value in OOP that it does not worth wasting your time at all. –  SK-logic Jun 19 '12 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 –  AndreasScheinert Jun 19 '12 at 14:35
    
C++, Java, and C# are not "classic" OOP languages. If there is a classic OOP language, I think it is Smalltalk. –  kevin cline Jun 19 '12 at 15:13

5 Answers 5

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.

share|improve this answer
    
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 Jun 19 '12 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.

share|improve this answer
1  
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 Jun 19 '12 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 Jun 20 '12 at 13:19

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.

share|improve this answer

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.

share|improve this answer
    
I think : thaught in many places. Is not an advantage , actually. –  AndreasScheinert Jun 19 '12 at 14:36
    
@AndreasScheinert why wouldn't it be an advantage? –  Simon Jun 19 '12 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. –  AndreasScheinert Jun 20 '12 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 Dec 8 '13 at 5:35

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.

share|improve this answer
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 Jun 19 '12 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. –  CodexArcanum Jun 19 '12 at 14:33
1  
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 Jun 19 '12 at 15:26
    
Yes, what I meant is that it does not have classes in the Java sense –  Andrea Jun 19 '12 at 15:49

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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