Lambda the Ultimate

In which case it sounds like you're talking about what the functional community would call modules, in the sense of the SML or O'Caml module systems. More recently, research in type theory has blurred the distinction between module systems and object systems in exactly the way it sounds like you want to; see the various papers around Scala to see what I mean, especially "A Nominal Theory of Objects With Dependent Types" and Odersky's "Types for Objects and Modules" talk.

I would argue, that at a slight loss of elegance, OO does *everything* that a good software engineer wants to do.

There are three sliders in this sentence: one marked "loss of elegance", one marked "does *everything*" and one marked "good software engineer". It might be helpful to know just where those sliders are set.

In Smalltalk or Ruby or Python you don't have to choose, of course. Functions / blocks are objects. Function composition is object composition, of a kind.

I can't think offhand of a "combination" that is easier in OO than in HO. I had thought that rather the reverse was true. Composability is not what I would consider a strong point of most mainstream OO languages. Do you have any examples of the kind of thing you mean?

Without wishing to cause a flame war

HaHaVeryFunny

While robust, HO does not deal with OO programming all that well.

I had thought that the point of programming was to write programs, and not to do OO.

On the other hand, OO does nearly everything that HO can do... BTW, as far as I am concerned, OO is *not* equivalent to inheritance+subtypes+methods+classes+instances. Those are techniques useful in some situations. For me, OO is fundamentally about encapsulation and interfaces.

The great thing about OO is that you can define it to be whatever you want it to be, and everyone has a different definition. This way OO can survive even when criticisms are leveled against any of its putative incarnations.

I would argue, that at a slight loss of elegance, OO does *everything* that a good software engineer wants to do.

Yes, you are absolutely right! So, what is the most effective way to reeducate all those poor, misguided software engineers? :)

there's only one definining feature that is unique to OO (or at least originated with it), and that is inclusion polymorphism. Anything else is available in many different forms elsewhere.

And there's an argument to be made that inclusion polymorphism causes more problems than it solves.

an object can act as a kind of closure but a closure cannot capture the multiple uses of an object

For me, OO is fundamentally about encapsulation and interfaces.

Scheme:

(define (mk-point x y)
  (lambda (op . args)
    (let
        (
         (get-x (lambda () x))
         (get-y (lambda () y))
         (add (lambda (pt) (mk-point (+ x (pt 'x))
                                     (+ y (pt 'y))
                                     )
                      )
              )
         (sub (lambda (pt) (mk-point (- x (pt 'x))
                                     (- y (pt 'y))
                                     )
                      )
              )
         (wr (lambda ()  (display "(")
                     (display x)
                     (display " ")
                     (display y)
                     (display ")")
                     )
             )
         )
      (apply (cond
              ((equal? op 'x) get-x)
              ((equal? op 'y) get-y)
              ((equal? op '+) add)
              ((equal? op '-) sub)
              ((equal? op 'display) wr)
              )
             args
             )
      )
    )
  )

(define pt1 (mk-point 1 2))
(define pt2 (mk-point 3 4))

((pt1 '- pt2) 'display)