
"I'd just use an n-by-k array of closures to represent this." - henning
Paul Graham has claimed quite a few times that OOP isn't very significant. From http://www.paulgraham.com/pfaq.html: "A lot of what seem to be OO problems turn out not to be if you have random access to the concepts that together comprise object-orientedness. If I were writing a CAD program or a simulation, for example, I'd probably use OO abstractions (though I'd probably end up creating my own OO model with macros instead of using whatever came with the language)."<p>I wonder, if you had 5 different Paul Grahams working on different subsystems of the same project, if they'd each create 5 different mutually incompatible object models, with no code reuse between them. How about performance? The CLR and the JVM use a lot of techniques to make method dispatch efficient; why reinvent the wheel if you need performance?<p>In the particular case of a serial port protocol, I could easily see how the protocol could involve keeping track of state, in which case an object would be extremely convenient. Stuffing all that into a single closure could easily become awkward; what you want is a way to manage state and behavior <i>together</i>, which is exactly what an object does.<p>Yes, objects matter more if you don't closures, because then you can simulate them using the so-called strategy pattern. But nevertheless both closures and objects are something I use frequently based on what reads easier and is easier to express.<p>I say this as someone who <i>has</i> used Lisp, who programs with map, filter, and fold all day long, and so on. I like Lisp, and also I think objects are a good idea. If you actually are working with real-world things, the ability to create a domain-model is a wonderful resource. Having a language as powerful as CLOS to work with is a blessing and I think that should be recognized, that's all.
======
gruseom
You make an extremely significant qualification here:

 _If you actually are working with real-world things_

A lot of computation involves abstractions that _don't_ correspond to real
world things. Modeling techniques aren't nearly as applicable in cases when
there's nothing objective (like a chemical system) or semi-objective (like a
business process) to model.

Freud said sometimes a cigar is only a cigar. Well, sometimes a function is
only a function.

I worked for years on OO projects and slowly came to realize that many complex
object models act like a straitjacket. They're highly coupled and thus
difficult to change. This of course is the exact opposite of the benefit most
often claimed for OO. It's one of the oddities of the software world that
people repeat for a very long time assumptions that their own experience is
contradicting. Once you've accepted a language or a paradigm as a way of
thinking, you frame all problems in terms of it and you just don't see its
weaknesses even when they're directly affecting you. OO was oversold way
beyond its roots in simulation, partly because of the irrational economics of
the software industry, and a lot of people were trained not to think about
programming from any other point of view.

When a partner and I began working in Common Lisp we made a conscious effort
_not_ to take the approach we were accustomed to. For example, we didn't begin
by asking "What are our objects?" We simply let ourselves follow the path of
least resistance, programming incrementally in a functional style. I fully
expected to end up with an object model but that never happened: we just had a
lot of orthogonal functions that were easily organized in a modular fashion.
Subsequent experience has borne this out, and in fact most times I have
defined object models in CLOS, I've regretted it. (Generic functions are a
different story.)

I'm not claiming OO isn't useful, which would be absurd as people mean
different things by OO anyway. But I am sympathetic to Paul Graham's
statements about objects (and also about design patterns being human
compilers) because I was becoming aware of these aspects of my own experience
by the time I encountered them.

~~~
henning
Yes, I only think you can even talk about a domain model if there actually is
some kind of world (real or imaginary) or some collection of entities to
model.

~~~
gruseom
By the way, do you know the book _Domain-Driven Design_? I think it is the
most sophisticated book on OO and domain modeling. But I also think that it's
straining beyond OO toward a design style that is not really about object
models, but rather about how to create a good language for talking about one's
problem. (The application then reduces to a series of statements in that
language.) Lisp programmers would be comfortable with this distinction. In the
book it's obscured by the fact that the examples are in Java.

------
asolove
Just to review, this stream of comments leads us to the invention of a new
unit, the "Hypothetical Paul Graham" or HPG, which represents the amount of BS
required to defend poor coding practice.

Absolute reliance on OO even in non-real systems is a 5 HPG proposition, as it
would apparently require five hypothetical Paul Grahams before the use of
closures to simulate objects became too complex.

A language that does not include functional abstraction is at least a 10 HPG
proposition. We would need to posit at least ten hypothetical Paul Grahams
before the dangerous ability to simply define one's own functions (even
redefine system functions, oh my!) and pass them around would become
dangerously confusing.

This raises the question: is there a theoretical limit of HPGs? How many would
be required before we could justify just writing machine instructions?

------
Hexstream
"I wonder, if you had 5 different Paul Grahams working on different subsystems
of the same project"

In fact, I think having one Paul Graham working on the project would be better
than having 5. Especially "if they'd each create 5 different mutually
incompatible object models, with no code reuse between them".

Overhead and incoherence kill.

~~~
henning
One person can't do all the work on many modern software projects.

Needlessly reinventing the wheel in an incompatible, inefficient way is
pointless.

Suppose you're working on a 3D game. There'll be plenty of work for one person
each for AI, sound, networking, graphics, networking, and game logic. The game
logic code will probably touch all those different parts. If each person is
like Paul Graham and thinks he'll roll his own fucking object system it's
going to be a nightmare.

~~~
gruseom
_If each person is like Paul Graham and thinks he'll roll his own fucking
object system_

This is a total non-issue. Graham's original comment was that even in
situations where an object model was appropriate, he wouldn't necessarily use
the OO constructs of an OO language to build one. It had nothing to do with
working on a team or not. Conversely, five intelligent programmers would
quickly recognize areas of potential conflict and agree on a common approach.
This has nothing to do with using OO or not.

------
johnrob
Classes require a LOT of thinking ahead of time. I will admit that a well
designed class model can produce a quality long term solution to a problem.
However, a poorly designed class model is the WORST thing you can possibly
write. I'd take functions/closures/whatever over a bad class model.

I don't use classes because I'm never willing to pay the design forward. I
want to get the product working without spending a long time designing. If you
have any freedom as to what you're building, your time is better spent
thinking about which features to add.

------
rkts
The word "OOP" is so ill-defined that we can't begin to have a meaningful
discussion unless you tell us precisely what you mean by it. In particular,
what is an "object" and how is it different from a collection of closures?

