OOP is currying

Thinks about it :inheritance, polymorphism, virtual functions, code+data.
The classes constructed are basically curried functions+data.

Currying is essentially a restricted, single-function object implementing:
https://en.wikipedia.org/wiki/Abstract_factory_pattern

>>2
That would be https://en.wikipedia.org/wiki/Command_pattern ?

Partial application is essentially a
https://en.wikipedia.org/wiki/Decorator_pattern
Call/cc is https://en.wikipedia.org/wiki/Memento_pattern
Eval is https://en.wikipedia.org/wiki/Interpreter_pattern

Lisp is partially implemented Clojure

breaking news: abstactions used in one programming paradigm can be used to achieve the same thing as abstractions used in the other programming paradigm. this is absolutely shocking.

>>6
Design Patterns are far more flexible.
You can construct 10 pages imperative pathworks in Command Pattern,
but currying anything recursively will be problematic to debug and read.
It seems as if designers of OOP Design Patterns were inspired by something functional, leveraged their core skillset in the problem domain using world-class team synergy to provide programmers worldwide with robust, scalable, modern turnkey implementations of flexible, personalized, cutting-edge Internet-enabled e-business API design pattern e-solution architectures that accelerate response to customer and real-world market demands and reliably adapt to evolving technology needs, seamlessly and efficiently integrating and synchronizing with existing legacy infrastructure, enhancing the e-readiness capabilities of e-commerce production environments across the enterprise while giving a critical competitive advantage and taking OOP to the next level.

>>7
cease your buzzwording

Absolutely correct. Lambdas are just shorthand for anonymous inner classes which implement an interface with only one method -- aka single abstract method (SAM) types.

For instance, you have two functions. One takes `Function<Type, Type>` and the other takes `UnaryOperator<Type>`. Giving the "same" lambda to both functions will result in two anonymous inner types, one implementing both interfaces.

OOP done properly:
(define (cat name)
(lambda (op)
(cond ((eq? op 'getName) name)
((eq? op 'meow) "meow"))))

(define my-kitty (cat "Hanekawa"))
(display (my-kitty 'getName))
(display (my-kitty 'meow))

>>10
too complex

>>11
How so? with a dispatch function one can easily just do:
(define (cat name)
(dispatch 'getName name
'meow "meow"))

(define my-kitty (cat "Hanekawa"))
(display (my-kitty 'getName))
(display (my-kitty 'meow))

And if you had a lisp where a.b was the same as (a 'b) then you could just do
(display my-kitty.getName)
(display my-kitty.meow)

And the above with a macro can easily become

(class (cat name) 'getName name
'meow "meow")

>>12

How so?

Because he's a mental midget.

OOP is curryniggering

>>15
The Lispers created Java as the thesis of their Hegelian dialectic, which was intended to destroy OOP and promote Lisp.

C++ - not memory safe, we need garbage collection
Java - static typing is bad, we need dynamic typing
JavaScript - new languages compile to it, we need macros
Lisp - Hegelian synthesis