With GO - Can I say Procedural is better than OO?

[nvcnvn]

I just read here: http://golang.org/doc/go_faq.html#Is_Go_an_object-oriented_language
And all of the GO example we have is not writen in OOP way.
So can I say that GO see the benefit of Procedural over OO!?

For myself, I fell ok with Procedural programming! Just need to stay
come, do some document for your code and that will help me avoid
duplicate of code, or easy to maintain and modify my code.

[Rodrigo Moraes]

On Sep 24, 1:14 pm, nvcnvn wrote:
> I just read here:http://golang.org/doc/go_faq.html#Is_Go_an_object-oriented_language
> And all of the GO example we have is not writen in OOP way.
> So can I say that GO see the benefit of  Procedural  over OO!?

I don't think it is that simple. Most Go packages use a OO flavor; but
that's Go's OO flavor. Let's call it GOO (!).

Go doesn't have some constructions from traditional OO, like
inheritance; the language seems to beg you to use clearer designs and
composition, and that's good because composition > inheritance anyway,
we've learned from years of traditional OO. And Go has has interfaces
and typed methods, so I'd say that GOO has some good parts of
traditional OO, and leaves others some that traditionally promotes bad
design (multiple inheritance).

My first Go attempts tried to replicate traditional OO with lots of
embedded fields and fake-inheritance, but later I realized that that
was a bad idea that just complicated stuff. You can use a mix of
procedural code with factories and helpers functions, and use
composition of typed methods and interfaces to achieve clearer
designs; that's GO's OO flavor. It's OO, just not in a orthodox sense.
You need to exercise it through coding and find the Go way.

-- rodrigo

[nvcnvn]

Thanks you! Can you share me some of your exp!?

[Rodrigo Moraes]

On Sep 25, 8:18 am, nvcnvn wrote:
> Thanks you! Can you share me some of your exp!?

Read code. From the standard packages, for example. Pay attention to
how they are written and designed. Copy from them.

I don't know what else to say. This blog helped me to start, mainly
because I arrived looking for the OO stuff and the blog used the words
I was looking for (:P):

http://golangtutorials.blogspot.com/2011/05/table-of-contents.html

But people learn differently and for me that helped. After I was more
familiar with the language, the official blog posts, the language
specification and Effective Go became my best friends.

-- rodrigo

[Andrew Gerrand]

I highly recommend you read the past articles from the Go blog: http://blog.golang.org/

Andrew

[Tony Worm]

+1 for GOO

[jeremy...@gmail.com]

It is procedural programming with OO seasoning and there's nothing wrong with that for small projects and utilities. Would like to see some case studies on using Go on projects with exceptional large code bases. I really think the all tenants of OOP (encapsulation, inheritance and polymorphism) come into play and are essentially when building large systems that have to be maintained by a team of programmers, but I'm open to see how others are structuring things.

[Simon Ritchie]

> Can I say Procedural is better than OO?

Better at what?  It depends what you are trying to do.

The novelist and aeronautical engineer Neville Shute wrote "It has been said an engineer is a man who can do for five shillings what any fool can do for a pound".

These days we accept that some engineers are women, but the point still holds.  You should use whatever technique gets you the result you need and does it for the least cost.  That could be an object-oriented Go solution, a procedural Go solution, a shell script, a spreadsheet, an abacus or one of many other choices. 

My only caveat is that when you consider cost, you need to think about the whole life of the project.  if you are going to use a solution for years, there's no point producing a quick and dirty version that doesn't work properly.

As for the discussions in this thread about Go's object oriented model compared with those offered by other languages, I'm reminded of Bjarne Stroustrup's paper "What is Object-Oriented Programming?", published around the time he was creating C++.  I don't have my copy to hand, but he pointed out that you can write an object-oriented program using any programmable system, from a Turing machine upwards.  The important issue is, does the system support Object-Oriented Programming rather than merely allowing it.

As fa I'm concerned, Go supports Object-Oriented Programming at least as well as any other language that I know, and a lot better than most of them.

[Henry]

Go also support first-class function which is an idea brought from functional programming. Anyhow, in my opinion, you shouldn't be too dogmatic about a particular paradigm. There are cases that can be solved elegantly using a particular paradigm and there are cases that will lead to further unnecessary complexity if you insist on using that particular paradigm. The key is to be practical and use what works best to elegantly solve your particular problem. To borrow a phrase from the Pirate of the Caribbean with a little modification, programming paradigm is more what you'd call "guidelines" than actual rules.

[Eric Johnson]

On Saturday, September 24, 2011 at 9:14:22 AM UTC-7, nvcnvn wrote:

I just read here: http://golang.org/doc/go_faq.html#Is_Go_an_object-oriented_language
And all of the GO example we have is not writen in OOP way.
So can I say that GO see the benefit of  Procedural  over OO!?

Object oriented programming means different things to different languages.

Depends on the examples you're looking at. For most example code in the standard docs, you're looking at a demonstration of an API. You instantiate a structure, and call a method or two on that structure. It doesn't "feel" object oriented, because you're talking about methods on a type (usually a structure) instead of a class. Once you start adding in interfaces when you need them, your perspective on the language may change considerably.

 

For myself, I fell ok with Procedural programming! Just need to stay
come, do some document for your code and that will help me avoid
duplicate of code, or easy to maintain and modify my code.

As with all things programming, best to learn a number of different paradigms, so you can apply the right one in the right context.

Eric.