Does Google's go-language address the problems in Paul's Graham's post 'Why Arc isn't Especially Object Oriented'?

Question

Does Google's Golang address the problems with languages addressed in Paul's Graham's post 'Why Arc isn't Especially Object Oriented'?

Answer 1

My initial feeling towards this is "It is too soon to tell"

1) Object-oriented programming is exciting if you have a statically-typed language without lexical closures or macros. To some degree, it offers a way around these limitations. (See Greenspun's Tenth Rule.)

Go supports Function literals (see docs) which if I am reading this correctly allow you to pass functions as params, whether defined elsewhere or created ad-hoc.

2) Object-oriented programming is popular in big companies, because it suits the way they write software. At big companies, software tends to be written by large (and frequently changing) teams of mediocre programmers. Object-oriented programming imposes a discipline on these programmers that prevents any one of them from doing too much damage. The price is that the resulting code is bloated with protocols and full of duplication. This is not too high a price for big companies, because their software is probably going to be bloated and full of duplication anyway.

This point is far to subjective to answer.

3) Object-oriented programming generates a lot of what looks like work. Back in the days of fanfold, there was a type of programmer who would only put five or ten lines of code on a page, preceded by twenty lines of elaborately formatted comments. Object-oriented programming is like crack for these people: it lets you incorporate all this scaffolding right into your source code. Something that a Lisp hacker might handle by pushing a symbol onto a list becomes a whole file of classes and methods. So it is a good tool if you want to convince yourself, or someone else, that you are doing a lot of work.

Since go isn't a truly object oriented language, you can probably solve the problem in whatever fashon you are comfortable with.

4) If a language is itself an object-oriented program, it can be extended by users. Well, maybe. Or maybe you can do even better by offering the sub-concepts of object-oriented programming a la carte. Overloading, for example, is not intrinsically tied to classes. We'll see.

Go seems to have an interesting approach to objects, where you are not required to worry / develop large object trees. It looks like the tools are present in the language to structure your data in an object oriented fashion without locking you in to a pure object oriented environment.

5) Object-oriented abstractions map neatly onto the domains of certain specific kinds of programs, like simulations and CAD systems.

...

Answer 2

Paul has some interesting points, in general, I've read a lot of his musings. In this matter, we disagree. He's a lisp nut, and a crappy program nut. He seems to pawn off hard to understand programs as the work of great programmers. Yes, I realise it's more nuanced than that, but it really boils down to just that. At the end of the day, either your code is easy work with, or it's not. And some programmers, programmers that Paul would deem great, will be able to put up with more crap than others and still be able to make heads or tails of what the code intends. It's a skill, but most assuredly not the only one a good programmer needs.

Speaking of Arc, it sucks, and unless I'm mistaken even people in the Lisp community think so -- my point here being that even smart people make mistakes.

Again, Paul is a smart guy, but his entire approach in this particular piece is off the mark it seems.