golang OO removal, benefits. over python?

F

flebber

I was wondering if a better programmer than I could explain if the removal of OO features in golang really does offer an great benefit over python.

An article I was reading ran through a brief overview of golang in respect of OO features http://areyoufuckingcoding.me/2012/07/25/object-desoriented-language/
..

maybe removing OO features would be a benefit to c++ users or Java users but python?

As I have seen an interesting reddit or two of people trying to figure out go today it was a ruby user, totally lost with structs.

So anecdotally is actually python and ruby users changing to Go, here is a blog and reddit from Rob Pike. http://www.reddit.com/comments/1mue70

Why would a Python user change to go except for new and interesting?

Sayth
 
R

Rustom Mody

I was wondering if a better programmer than I could explain if the removal of OO features in golang really does offer an great benefit over python.

That's a strange locution: You are suggesting that go had OOP and it was removed
 
I

Ian Kelly

I was wondering if a better programmer than I could explain if the removal of OO features in golang really does offer an great benefit over python.

An article I was reading ran through a brief overview of golang in respect of OO features http://areyoufuckingcoding.me/2012/07/25/object-desoriented-language/

The description of how Go structs work is accurate from what I know of
it, but I think the author goes astray in claiming that this is not
OOP.

If you look at how C++ compiles inherited classes, it works in
basically the same way. The SmallBox class in C++ is essentially a
struct with its fields laid out in a specific order and some methods
that operate on it. A BigBox class that inherits from SmallBox will
first lay out the SmallBox fields in the same way that SmallBox does,
and then add the fields specific to BigBox after. Draw an imaginary
line around the SmallBox fields, and you have the same setup as the Go
example: a SmallBox nested within a BigBox. SmallBox methods will
only operate on the portion of BigBox that is within the imaginary
line (i.e. the SmallBox) and don't need to have any knowledge that the
SmallBox is part of a larger data structure. BigBox methods can
operate on the entire BigBox and can call SmallBox methods when
desired.

The author points out that nested structures can be made optional by
including a pointer to the structure instead of the structure itself.
Again you can do the exact same thing in C++; in OOP this is usually
described as a "has-a" relationship. Most languages don't support the
syntactic sugar that makes this look almost identical to inheritance
in Go, but that's all it is.

The biggest difference between the two is that Go doesn't have any
concept of virtual methods. A call of a SmallBox method on a SmallBox
object, whether part of a larger object or not, will always call that
SmallBox method. Whereas a call to a C++ method that is compiled as a
virtual method will actually call the method associated with the
superstructure, regardless of the static type the method was called
on. Go gets around this by using interfaces. An interface that is
satisfied by SmallBox will usually automatically be satisfied by
BigBox also, and calls to interface methods are dispatched
dynamically. As a result, object-oriented Go code will typically work
with interfaces rather than specifying actual classes, which is not
too different from how Java code is typically written.

Incidentally, I rather like the design of Go interfaces. They are
essentially Python's duck typing made explicit, divorcing interface
implementation from formal inheritance. On the whole though I think
that the language is not yet mature enough to be able to seriously
compete with more established languages like Python or Java.
 
M

Marko Rauhamaa

Ian Kelly said:
The description of how Go structs work is accurate from what I know of
it, but I think the author goes astray in claiming that this is not
OOP.

Call it "no-nonsense OOP." No wonder the color of the box was gray in
the example.
On the whole though I think that the language is not yet mature enough
to be able to seriously compete with more established languages like
Python or Java.

Also, is there anything seriously lacking in Python, Java and C?

I was very interested in Go when it came out, but was turned off by the
fact that you had so have a Google account to effectively participate in
the community.


Marko
 
F

flebber

Also, is there anything seriously lacking in Python, Java and C?


Marko

From their FAQ:

Go was born out of frustration with existing languages and environments forsystems programming. Programming had become too difficult and the choice of languages was partly to blame. One had to choose either efficient compilation, efficient execution, or ease of programming; all three were not available in the same mainstream language. Programmers who could were choosing ease over safety and efficiency by moving to dynamically typed languages such as Python and JavaScript rather than C++ or, to a lesser extent, Java.

Go is an attempt to combine the ease of programming of an interpreted, dynamically typed language with the efficiency and safety of a statically typed, compiled language. It also aims to be modern, with support for networked and multicore computing.
Although Go doesn't have exception handling either which is odd. http://blog.golang.org/error-handling-and-go
http://uberpython.wordpress.com/2012/09/23/why-im-not-leaving-python-for-go/
Or you can use defer http://blog.golang.org/defer-panic-and-recover
func CopyFile(dstName, srcName string) (written int64, err error) {
src, err := os.Open(srcName)
if err != nil {
return
}
defer src.Close()

dst, err := os.Create(dstName)
if err != nil {
return
}
defer dst.Close()

return io.Copy(dst, src)
}
That's a strange locution: You are suggesting that go had OOP and it was > > removed
Although Go has types and methods and allows an object-oriented style of programming, there is no type hierarchy. The concept of "interface" in Go provides a different approach that we believe is easy to use and in some ways more general. There are also ways to embed types in other types to provide something analogous--but not identical--to subclassing. http://golang.org/doc/faq#Is_Go_an_object-oriented_language

sayth
 
C

Chris Angelico

The author points out that nested structures can be made optional by
including a pointer to the structure instead of the structure itself.
Again you can do the exact same thing in C++; in OOP this is usually
described as a "has-a" relationship. Most languages don't support the
syntactic sugar that makes this look almost identical to inheritance
in Go, but that's all it is.

Composition versus single inheritance versus multiple inheritance.
Where's the line drawn? In Python, it's easy to tell one from another.
Composition hides everything behind another dot level; single and
multiple inheritance use the MRO (with MI handled by "super" sometimes
pointing you to a peer). But compare this:

class command
{
void create(string name) {.......}
void process(...) {...}
}

class hook
{
void create(string name) {.......}
void inputhook(...) {...}
}

class timer
{
inherit command;
inherit hook;
void create(string name) {::create(name); .....}
}

This is part of the class hierarchy of Gypsum, implemented in Pike. It
looks like multiple inheritance, and it mostly works that way. Given
an instance of timer, you can call process() on it as a command, or
inputhook() as a hook. The create() function (which is like Python's
__init__) defers to its parents using a C++ syntax form with the
leading double colon - but without C++'s ambiguity error. (The
specific case of the constructor is different in C++, but any other
duplicate method name would be a compile-time error. In Pike, the
expression "::create" actually returns an array of functions, in the
order of the inherits; and calling an array of functions calls each
function in turn with the same args.) So this definitely acts like MI.
And the syntax is almost the same as SI, in that removing the "inherit
hook;" statement will have this function beautifully as
straight-forward single inheritance. But consider this:

class foo
{
inherit Stdio.File : file1;
inherit Stdio.File : file2;

void readwrite()
{
//Assumes both files were opened by other methods
file1::write(file2::read());
}
}

So multiple inheritance is really just composition in disguise.
(Actually, this last form is stylistically discouraged. It's normally
much clearer to use a more classic form of composition, which works
the same way Python's does. But it does work, and there are uses for
it.)

I think it's only the theory purists who really care strongly about
the differences between all the various terms. There's an implication
to inheritance (Liskov Substitution Principle) that composition
doesn't have, but *every* (bar none!) implementation of Multiple
Inheritance I've ever seen is either horribly horribly sucky, or ends
up creating some edge cases that make LSP a little odd. (Or both.) So
don't sweat the details. Practicality beats purity. I think C++'s MI
implementation is more on the pure side and less on the practical...
and I've never used it in production code. Python's MI is fairly
practical, but requires that every class in the hierarchy be able to
cope with MI, and has odd edge cases with "might be the last in the
tree". Pike's MI has oddities with external "reaching in" to
something, so sometimes I need to write explicit dummy methods, or
carefully avoid name collisions; definitely practical, and quite
useful. Java's MI simply doesn't exist (that's perfectly pure!),
although implementing interfaces can do a lot of it; but then you end
up duplicating piles of code (on the other hand, that's nothing new in
Java code). I don't remember what other languages I've tried MI in,
but most of them tended toward the "pure" and were impractical enough
to avoid using.

ChrisA
 
M

Marko Rauhamaa

Chris Angelico said:
Java's MI simply doesn't exist (that's perfectly pure!), although
implementing interfaces can do a lot of it; but then you end up
duplicating piles of code (on the other hand, that's nothing new in
Java code).

Java 8 has default methods for interfaces. That covers one principal use
case of multiple inheritance.

That said, I find I'm using stray duck-typed classes in Python all the
time. For some reason, inheritance doesn't crop up all that much.


Marko
 
C

Chris Angelico

Java 8 has default methods for interfaces. That covers one principal use
case of multiple inheritance.

Okay, wasn't aware of that. Been a few years since I did anything with
Java. Still, the Java philosophy seems to be "start with maximum
purity, then add as little practicality as we can get away with",
rather than "let's make something useful, and let the language
theorists figure out what it's called".

ChrisA
 
N

Neil Cerutti

I was wondering if a better programmer than I could explain if
the removal of OO features in golang really does offer an great
benefit over python.

An article I was reading ran through a brief overview of golang
in respect of OO features
http://areyoufuckingcoding.me/2012/07/25/object-desoriented-language/
.

maybe removing OO features would be a benefit to c++ users or
Java users but python?

As I have seen an interesting reddit or two of people trying to
figure out go today it was a ruby user, totally lost with
structs.

So anecdotally is actually python and ruby users changing to
Go, here is a blog and reddit from Rob Pike.
http://www.reddit.com/comments/1mue70

Why would a Python user change to go except for new and
interesting?

Static typing combined with duck typing and simple distribution
of applications is a draw. Go's tools are pretty awesome, and are
scheduled for improvements.

If you can get by with its built in types (or simple aggregates
of them) it feels quite expressive.
 
I

Ian Kelly

Also, is there anything seriously lacking in Python, Java and C?

I was very interested in Go when it came out, but was turned off by the
fact that you had so have a Google account to effectively participate in
the community.

Concurrency is one area where Go beats Python hands down. The newish
multiprocessing module helps with that, but it is still rather heavy
compared to the light-weight processes used by Go's goroutines.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,780
Messages
2,569,611
Members
45,276
Latest member
Sawatmakal

Latest Threads

Top