IMHO this is a pretty poor rant. Let me argue each point:
* Data structure and functions should not be bound together
In some cases encapsulation works really well. For example GUI elements. It is less true for "process-oriented" components. But the arguments he makes don't seem very well thought out.
* Everything has to be an object
I actually agree here. To my mind, the biggest problem with OOPS is that is slowly devours all other concepts until we are left trying to force-fit all problems into the OOPS mould.
* In an OOPL data type definitions are spread out all over the place
This just ignorance.
* Objects have private state
This is also a good point. Having state actually tends to being a "bad" thing to do. Of course, the entire purpose of the object is to capture some invariant, but an object doesn't make that clear. Many objects contain instance variables that should actually be parameters.
* Why is OOPS popular?
Because it makes it easier and safer to get programmers working together as a group. The vocabulary of available objects is a simple and somewhat elegant way of communicating.
He is actually correct that in an OOPL data type definitions are spread out all over the place
In a typical OO language all the code belongs in classes, and there is no way of telling which classes define the essential data types and which are mostly placeholders for code. There is no way to tell at a glance what are the important data structures. Just look at any open source Java project.
I use python and I find myself using more functions and fewer and thinner classes recently. In particular, if some state is transient, I find it is much better to keep it in local variables of the more abstract functions than obscure it as object state.
Most people treat packages just like bigger-than-classes chunks of related functionality and state. Typically there is a 'common' package for supporting stuff that is used all over the place, but these are not the data types most important for the project, these are just that project's particular incarnation of datetime utilities.
The 'basic' package is certainly not common practice.
You can assign them to a variable, and you can write out a function literal. What more does it take to be a "first-class citizen"?
...for a given function you can't request / modify it's syntax tree
And what language does let you do that? Macro systems like let you do it at compile-time, but when you use the phrase "request an AST", it sounds like you're doing it at runtime...
Not at runtime... This occurs at compile time by assigning to a variable of type Expression.
F#, like OCaml, supports proper quotation and allows you to create executable code, or ASTs, or both using metadata attributes that the compiler is aware of.
Because it makes it easier and safer to get programmers working together as a group.
Making OO the ultimate dogfood.
Whenever I encounter any kind of new "thinking", the first question I ask is, "Who is it good for?"
Ultimately, OO was made for us, not our customers. True, anything that helps us helps our customers, but I'd prefer to ask a more basic question...
If we have so many programmers that we need new technologies to work better together, are we doing something fundamentally too complex to begin with? Most of us aren't working on the space shuttle. We're doing relatively simple bread and butter apps moving data through logic. Before we surrender to OO, maybe we should take a closer look at why we need "easier and safer" ways to work together. For most of us, a simpler approach than OO often makes more sense. I suspect that's OP's biggest point.
Back in the '80s I was the first person in my CS dept to champion the idea of OOP. It wasn't some conspiracy to make money (not a bad thing) selling a fresh set of buzzwords (that would be a bad thing). My views were strongly influenced by the views of writer Michael Jackson, who pointed out that every program contains a model -- at varying levels of explicitness -- of its domain. OOP just seemed to make the model clearer by creating a more explicit mapping between the objects in the world and those in the program. Grady Booch and Bertrand Meyer later made similar arguments specifically about OOP.
What happened next was that an idea that worked well in a few contexts (discrete simulation and graphics/GUIs) was expanded to almost all kinds of programming where it didn't work as well. That's because a lot of the world-to-be-modeled is more verb than noun. That in turn means that functions will make better models than objects.
I now think that Lisp-class functional languages (using, say, Clojure) are better for most programs. The reason, as pg has pointed out, is succinctness. The problem with OOP is that it's hard for it to be succinct because new data types are constantly being created and new methods added to them, all of which requires extra code.
All programs are programs about a particular domain. Programs become succinct when the language being used can be sculpted to the domain at hand. That's best done in languages with macros and a simple (e.g., s-expression) syntax.
One last point. I've looked for many years for the One True Programming Paradigm. I no longer believe that any such thing exists. Different classes of problems simply require different approaches. What I've come home to is using a language that allows easy creation of DSLs and controls side-effects, while still allowing them. A wet clay language that allows experimentation and sculpting to the domain at hand. Lisp-class languages do this best, with Clojure at the top of the heap in my opinion.
I still think that OOP is best for GUIs, where state is inherent in the domain and inheritance can pay off big.
I think it's more that OO was created because lots of programmers couldn't be bothered to exert discipline in observing APIs, so discipline was forced upon them.
I'm not sure what you mean here. How does OO force APIs on a user more than any other programming style? If you don't follow an API, your code won't work whether it's OO or not.
He probably has a point in some ways, but some of the points seem so bad they are almost impossible to rebuff - e.g. functions are functions, data is data, therefore they must be separate?
Additionally, he's run up against the pitfall with OO - it actually lacks a definition. It's got lots of dimensions and facets, and each implementation interprets these in it's own way... e.g You could argue that SmallTalk's message passing metaphor was the precursor to Erlang's model.
The problem is when people mix them up, I think. Rants are usually written to appeal to the emotions (whether intentionally, e.g. to rally support, or just venting), and sometimes people get so caught up in them that they miss major gaps in the author's argument...and people busy cheering aren't usually in the mood to coolly debate.
> Additionally, he's run up against the pitfall with OO - it actually lacks a definition
I think OO is well-defined.
I would define it thus: an object is something with state and behaviour. An OOPL is a PL with facilities for handling objects. These facilities must include (i) specialisation -- either through subclasses or prototypes -- and (ii) method invocation determined at run time, so that for example:
someShape.drawOn(aCanvas);
their are several drawOn() methods and the one that is executed is determined at run time by the class (or equivalent) of someShape and possibly also by the class of aCanvas.
There are plenty of OOPLs where this is not the case. For example C++ or Python.
> Why is OOPS popular? Because it makes it easier and safer to get programmers working together as a group.
That's true. But the main reason why OOPL is popular is because it makes programming more productive, whether there's one programmer writing the code or lots of them.
Python is a pure OO language; everything is an object. Java is impure; primitives are not objects. Python is not an everything-must-be-in-a-class language, like Java. Python allows you to create a variable or function without having to put in a class. Much better, I think;
> Python is a pure OO language; everything is an object.
It is now, but it wasn't always. For example, you didn't used to be able to create a subclass of dict or int. And you can certainly code in Python just using built in data types and functions, not making use of any OO features.
Which is pretty much my point. Python has morphed into "everything is an object".
To see how C++ has moved towards objects-for-everything, I have just one word - boost!
RE your second point - I don't know of any studies that show OOPS makes programmers more productive. As a matter of fact, some anecdotal evidence (cough pg cough), points to the opposite!
I actually wanted to like this post but visitor4rmindia is right, it is, sadly, a fairly ill-thought-out rant. For example: 'Consider "time". In an OO language "time" has to be an object. But in a non OO language a "time" is a instance of a data type'. In an OO language like Ruby, A time value is an instance of a class "Time", in a non-OO language, a time, variable may be an instance of a built-in type "time" if you are really lucky (PL/SQL) but it is more likely to be an integer or a string or a structure or all of these at different times.
This is also a good point. Having state actually tends to being a "bad" thing to do. Of course, the entire purpose of the object is to capture some invariant, but an object doesn't make that clear. Many objects contain instance variables that should actually be parameters.
Yikes guilty as charge here as I currently have a unhealthy fascination for the use of instance variables if not all in most of my objects. Thanks for the heads up.
* Data structure and functions should not be bound together
In some cases encapsulation works really well. For example GUI elements. It is less true for "process-oriented" components. But the arguments he makes don't seem very well thought out.
* Everything has to be an object
I actually agree here. To my mind, the biggest problem with OOPS is that is slowly devours all other concepts until we are left trying to force-fit all problems into the OOPS mould.
* In an OOPL data type definitions are spread out all over the place
This just ignorance.
* Objects have private state
This is also a good point. Having state actually tends to being a "bad" thing to do. Of course, the entire purpose of the object is to capture some invariant, but an object doesn't make that clear. Many objects contain instance variables that should actually be parameters.
* Why is OOPS popular?
Because it makes it easier and safer to get programmers working together as a group. The vocabulary of available objects is a simple and somewhat elegant way of communicating.
(EDIT: Corrected layout.)