
Professor Frisby's Mostly Adequate Guide to Functional Programming - rbanffy
https://drboolean.gitbooks.io
======
brudgers
Direct link to book: [https://drboolean.gitbooks.io/mostly-adequate-
guide/content/](https://drboolean.gitbooks.io/mostly-adequate-guide/content/)

------
chriswarbo
Whilst I'm not a particular fan of OOP or Javascript, statements like this
feel intellectually dishonest to me:

> Object-oriented programming currently dominates the industry, but it's
> clearly awkward in JavaScript. It's akin to camping off of a highway or tap
> dancing in galoshes. We have to bind all over the place lest this change out
> from under us, we don't have classes (yet), we have various work arounds for
> the quirky behavior when the new keyword is forgotten, private members are
> only available via closures.

OOP does not equal class-based programming; prototypes are a perfectly
cromulent way to implement inheritance (although, of course, inheritance
should be avoided; but I think OOP should be avoided, so...).

OOP is actually _very easy_ in Javascript, since everything is an object, e.g.

    
    
        > (123).toString().length
        3
    

That's certainly more OO than many other languages which claim to be OO. For
example, the Java equivalent to Javascript's "123" would be "new Double(123)",
which I would consider to be more awkward.

Whilst prototypical inheritance is the go-to example for Javascript's Self
influence (and, in turn, Self's Smalltalk influence), I would say a more
pervasive influence is the _use of objects to define the object system_. In
other words, the object system isn't a language-provided template of keywords
and special syntax, where the programmer fills in the boxes. Instead, the
language provides a bunch of objects which, when combined together, produce
the behaviour of an object system. This not only makes the language simpler
(fewer keywords, less context-specific semantics, etc.) but is much more
flexible: by combining them in other ways, you get a different object system;
you can _extend_ the object system using the object system; you're also free
to _completely ignore_ the object system (but it's still there; "123" is still
an object, even if you don't treat it like one).

For this reason, I dislike criticism like "private members are only available
via closures"; it's true, but that's a positive! Closures are one of the
components of the the object system, lexically-scoped variables are another,
"constructor functions"/"factories" are another (which, I believe, is what the
new "class" keyword reifies), etc. "bind" and "this" are others. In other
words, class-based programming is a design pattern in JS; if you think it's
appropriate in some situation, go for it; if not, you're not stuck with it.

I think it's much more damning to say, of other languages, that "private
members are only available via special-purpose syntax", since this translates
to "if you want to tweak it, go hack the compiler".

I find myself having this rant so often I even wrote it up once
[http://chriswarbo.net/blog/2014-03-12-trolled.html](http://chriswarbo.net/blog/2014-03-12-trolled.html)

~~~
junke
I read your rant and while I agree, you said that classes are not objects in
Java. But last time I checked, there was a java.lang.Class object (and objects
have a getClass() method which return a Class).

