Arc Forumnew | comments | leaders | submitlogin
4 points by absz 6111 days ago | link | parent

I do think you leave out an important class (no pun intended) of problems for which OOP is helpful. Simulation, windowing systems... these are modeled elegantly by using classes and objects. In other words, OOP seems to me to be a good fit when the problem you are trying to solve deals with objects. The problem lies in trying to coerce other problems into noun-land.


4 points by bayareaguy 6111 days ago | link

I think pg agrees with you in http://paulgraham.com/noop.html when he writes:

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

Also for things like instance creation and method dispatch, OO languages can easily be both faster and more concise than functional languages. In a performance-sensitive setting like a desktop gui or a window system this can easily decide the issue.

But while simulation and OOP do have an important historic relationship, I don't believe you actually gain any special modeling expressiveness by making your objects adhere to a "class" framework. What's worse, the hardcoded assumptions OO languages make about classes and methods can confuse the assumptions in a simulation (e.g. because you can implement an "IS-A" relationship with inheritance doesn't mean you should).

If you want objects in a functional setting, you can just create the appropriate "factory" functions and have those functions return "objects" (i.e. functions with state in closures) which dispatch "methods" however you want them to, just like Jim Rankin did in the article at the top of the thread.

Personally I prefer the approach in SICP ( http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-19.html... ).

-----

2 points by absz 6110 days ago | link

I've skimmed the SICP link, and that does look like a good method. But I don't think they're mutually exclusive. As Jonathan Rees points out (http://paulgraham.com/reesoo.html), the definition of OOP varies; having just inheritance (coughjavacough) does make that problematic. Ruby's mixins and duck typing allow "is-a" without inheritance, thus alleviating some of the complaints.

I think that describing certain things, e.g. a windowing system, in terms of classes and objects does result in a useful description. "My window contains a button and a text field" maps nicely to an OO model. The implementation can (perhaps should) be user-level and/or functional with closures, but that modeling system can be powerful.

And of course, some of this is "taste;" I can't think very well in a visual paradigm, but I love a symbolic one. OOP may be orthogonal to your mental processes, in which case don't use it.

-----

2 points by jimbokun 6110 days ago | link

"Personally I prefer the approach in SICP ( http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-19.html.... )."

I was negligent in citing prior work. I had SICP in mind when I wrote my code.

The main differences are I wrapped it all up in a macro, I supported inheritance, and "method invocations" require one less set of parentheses:

    (define acc (make-account 100))
    ((acc 'withdraw) 50)
    50
    ((acc 'withdraw) 60)
    "Insufficient funds"
    ((acc 'deposit) 40)
    90
    ((acc 'withdraw) 60)
    30
I also didn't allow for initial arguments (yet). And you need to say "(vars 'varname)" to get values in method bodies instead of just "varname." I could probably fix both those things together.

But, generally speaking, the goal was to provide a macro for creating SICP style "objects."

-----

1 point by NickSmith 6110 days ago | link

Be interested to read your code Jim with your 'fixes'.

-----