
The Humpty-Dumpty Guide to OOP - ingve
http://www.sicpers.info/2014/10/the-humpty-dumpty-guide-to-oop/
======
munificent
As an OOP afficionado, I am embarrassed by how mushy our discipline is
compared to the crystal clarity of our functional bretheren. How I wish I
lived in a world of such well-defined boundaries.

After all, everyone knows that FP was started with Lisp with the insight that
the heart of FP is homoiconicty. Except where it isn't, as in ML and others.

Likewise, functional programming introduced a higher level way of expressing
our intention without being bound to the low level machine representation of
values. Unlike Fortran and Cobol, all functional languages use dynamically
typed variables (except for ML and its derivatives) and operate at a level of
abstraction above the primitive underlying machine (except for nil punning,
car, cdr, etc.).

While OOP languages endlessly fiddle with syntax, functional languages all
agree that only way to represent code is with s-exprs. Or not, as in ML. And
that function arguments should be lists. Or is it tuples? Or curried?

Either way, syntax is just window dressing. What really matters is semantics,
and here functional programming has always stood for a very firmly defined set
of behaviors. Functions should be pure, as in Haskell. Except when they are
not as in Scheme, Lisp, and ML. Evaluation should be by name. Or by need. Or
eager.

There must be macros. Or not. They should not require hygiene since that is an
artificial limitation, except that they should require hygiene because
unhygienic macros are evil.

Let's not forget one of the key contributions that functional languages have
given us: lexical scope. All functional languages use it strictly. Except for
Emacs Lisp which does not, and Common Lisp and Clojure which have options to
not use it.

OK, fine, I'm side-stepping the most important facet that all functional
languages agree on: first class functions. This is the defining feature of FP
languages: all functional languages have them, and all other languages do not.
Except for Lua, C#, Java, C++, JavaScript, Self, SmallTalk, and others. But,
functional languages certainly have first-class functions more thoroughly
integrated into the rest of the language than non-FP languages do. Except for
Common Lisp, which relegates them to a separate namespace.

In conclusion, I think we can all agree that object-oriented languages could
learn a lot from FP about how to keep your terminology precise.

~~~
Dewie
The article is silly, and so is your response. Functional programming most
usually, the _vast_ amount of time, refers to a declarative style of
programming which involves using functions in the more mathematical sense,
which means that one tries to avoid state and side effects. Not necessarily as
a compiler-mandated thing, but as a convention. Does one still make
"functions" from time to time which are really about mutating state and/or
side effects? Yes, but then you would say that they are doing a more
procedural/imperative style at that point in time. Like java can be
procedural, if you try hard enough.

"[...], and all other languages do not." \- Demanding that other languages -
which might not self-identify as 'functional' \- _not_ have something seems
like a futile demand. Are those languages just gonna be banned by the almighty
FP wizards? :)

I've never seen things like the syntax of lisp, the homoiconicity of lisp, the
lazy evaluation of Haskell, be equated with functional programming as a whole.

~~~
munificent
> The article is silly, and so is your response.

Guilty as charged, though I fear the original article doesn't realize it's
silly too.

> Functional programming most usually, the vast amount of time, refers to a
> declarative style of programming which involves using functions in the more
> mathematical sense, which means that one tries to avoid state and side
> effects.

Maybe it's just me, but I've never found most functional code I've seen to be
particularly declarative. I certainly like purity and immutability, but much
of it still reads imperatively to me, just in a slightly more abstract style.

But, then, that's true of OOP code that I like too. I find method calls (in
good APIs) just as declarative because there I'm describing what I want the
object to do and not how to do it.

> Are those languages just gonna be banned by the almighty FP wizards? :)

I think they prefer the term "smug Lisp weenies", but they probably wouldn't
turn down that title either. :)

I think arguments like this are silly because I don't really like any single-
paradigm languages. I think functional, object-oriented, imperative,
declarative, etc. are all _styles_ and each of those styles has its place,
often all within the same program.

People (like the author of this post I suspect) like FP because it _rejects_
OOP, but I like OOP because it _doesn 't_ reject other styles. Mainstream OOP
languages have no qualms about adopting higher-order functions, closures,
immutability, and all sorts of different concurrency models. I like
simplicity, of course, but I also like having a lot of tools at my disposal
and not rejecting some for religious reasons.

~~~
eru
> Maybe it's just me, but I've never found most functional code I've seen to
> be particularly declarative. I certainly like purity and immutability, but
> much of it still reads imperatively to me, just in a slightly more abstract
> style.

How much have you seen? If you can understand Haskell, the ideas in
[http://gergo.erdi.hu/blog/2012-12-01-static_analysis_with_ap...](http://gergo.erdi.hu/blog/2012-12-01-static_analysis_with_applicatives/)
are pretty neat and directly exploit declarations.

------
djur
I don't see where the gotcha is in 1 and 2. The meaning is pretty clear if
you're familiar with the two languages. Simula is a procedural Algol-style
language that includes a class-based OO system, analogous to Java or C++
today. Smalltalk is completely based on message-passing. The distinction
between the two approaches is reminiscent of the ML/Haskell divide
(strict+impure vs. lazy+pure).

3 and 4 is a statement of principle _preceded_ by an acknowledgement that the
definition the book uses is not universal. 5 seems uncontroversial to me; the
need for automatic memory management is a secondary outcome of other aspects
of object-oriented systems, not a primary quality. And 7 doesn't seem to
follow from the quoted excerpt.

All the quotes are from a single 33-year-old copy of Byte magazine. They don't
conflict nearly as much as the commentary implies. Together they suggest that
an idealized OO system consists strictly of objects passing messages, but that
other languages blend OO and procedural features. The same is true today.

EDIT: retracted an unnecessary implication.

------
nbevans
OOP... where originally specified as a queued serializable messaging-based
topology of reusable components, i.e. what we now know as a actor/agent based
programming.

... But where CPU stack-based function calls (cutely named "method calls") was
what was actually delivered. Presumably because in the 80's, what was
specified, was too costly on the CPU and memory to deliver. Oops, indeed.

A lot of bad decisions were made in the 80s in the name of CPU and memory.
Just look at RDBMS still in the 21st century being the default persistence
layer for 99% of applications.

OOP is a pattern that became popular for GUI programming because everything is
inherently messaging-based already, and because Xerox and Apple adopted it and
for some reason people thought it could be reasonably applied across all types
of programming.

~~~
retox
The problem with RDBMS being? No sarcastic, just curious.

~~~
nbevans
The problem being that to use RDBMS well with object-oriented software you
need an ORM (object-relation mapping) layer, which adds complexity and cost
and maintenance burden. RDBMS are a central point of failure and don't scale
well. Relational data is typically overkill for the vast majority of
applications which would be better suited to a document-based dataset at the
expense of a little more memory cost. Etc etc... :)

~~~
collyw
I disagree. Database code is generally a lot less buggy than application code,
probably due the declarative nature. Plus with a properly normalized schema,
you can answer most questions about your data. Document databases have
basically forced you to denormalise at step 1. I would say we should forget
about the OOP and stick with the RDBMS, as that part works well.

~~~
nbevans
RDBMS has its uses, I didn't say otherwise. However I did say adopting it as a
"default" persistence mechanism is wrong. RDBMS is something you adopt with
your eyes wide open as it is large architectural decision and ultimately a
burden to take on board. And even then you may only adopt it for one
particular subsystem of your product; for polyglot persistence is the best.

For application state, the big drawback of RDBMS is its lack of temporal and
immutable persistence. This is where the temporal nature of event sourcing is
a better fit for application state. Event sourcing can feasibly perform a
superset of operations that SQL can do, and it can do all this without the the
need for mutable state.

------
artsrc
ReST shows that a person can invent a technical term, write a long
dissertation on what it means, clarify any ongoing misconceptions on the web,
and have people use the word to mean whatever they like.

[http://roy.gbiv.com/untangled/2008/rest-apis-must-be-
hyperte...](http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-
driven)

> REST APIs must be hypertext-driven

[http://msdn.microsoft.com/en-
us/library/jj819168.aspx](http://msdn.microsoft.com/en-
us/library/jj819168.aspx)

> Using the REST Services with .NET > In order to make use of JSON
> serialization in .NET

This is not new. Codd spent ages talking about why every relational database
was not a relational database.

~~~
gracenotes
REST came to mind for me as well.

Let's assume there is a platonic ideal for REST, or for OOP. Just talking
about REST over _HTTP_ (methods, response codes, URIs) clouds that ideal,
making it hard to learn about and even harder to talk about with other
programmers. The same could be said about OOP with classes, structs,
prototypes, etc... or as some of this article's quotes do, about OOP in
Smalltalk. Over time you could look at this in terms of SCOT theory[1] and I
think it would be fascinating. You could look at all of the marketing,
conflict, and the effects of collective perspective shifts where things are
considered "solved" but they aren't really.

My own opinion about the platonic ideal of OOP is close to Chapter 18 of
Pierce's Types and Programming Languages, which suggests these attributes: 1\.
Multiple representation 2\. Encapsulation 3\. Subtyping 4\. Inheritance 5\.
Open recursion.

To me the kernel of OOP is mainly just #1 and #2. If you don't have #3, you
should have a damn good alternative. I don't attach #4 and #5 to the core
definition but certainly the former should imply the latter. Another favorite
is "On Understanding Data Abstraction, Revisited"[2], which contrasts objects
and ADTs in a different framework.

[1]
[http://en.wikipedia.org/wiki/Social_construction_of_technolo...](http://en.wikipedia.org/wiki/Social_construction_of_technology)
[2]
[http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf](http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf)

------
nbevans
OOP was a programming paradigm sponsored by big enterprise. Just search
YouTube for this string: "steve jobs object oriented"

Apple, NEXT were absolutely the biggest advocates of OOP. The word "object",
for a time, literally pervaded all across their product lineups and marketing.
Microsoft got on the bandwagon a little later, first with Visual Basic and
later with COM (component object model) that was baked into Windows. The
latter of which turned out to be an utter disaster.

Object oriented programming was being pushed in the same way that ORMs, RDBMS,
etc etc. It was a whole sales pitch to make money. Whether it was actually
"any good" is very much still up for debate.

------
ExpiredLink
There is no definition of OOP. It's a amalgam of features and best practices.
BTW, can we also get the 'The Humpty-Dumpty Guide to Functional Programming'
which is as vague as OOP.

------
pan69
Over the years I've come to realize the the 'P' in OOP is not important at
all. What you technically can or cannot do in a given programming language
isn't really that important. In my opinion it should be OOT where 'T' stands
for "thinking". To be able to "think" in objects is so much more important and
beneficial than to understand some technical language construct.

~~~
sklogic
How could it be "beneficial" to artificially limit your thinking into such a
narrow, mostly useless, alien framework? How can one see the world in all of
its endless variety as a boring and irrelevant set of hierarchical taxonomies
of message-passing entities?

~~~
TeMPOraL
Yes, that was something that always bugged me. I find it hard to model the
real world using OOP constructs - something OOP was advertised as well-suited
for.

------
V-2
Yeah, OOP is a fuzzy concept :) It reminds me of discussion under Eric
Lippert's answer -
[http://programmers.stackexchange.com/a/234563/29029](http://programmers.stackexchange.com/a/234563/29029)
\- about whether OOP requires classes.

