The venerable master Qc Na was walking with his student, Anton.  Hoping to
prompt the master into a discussion, Anton said "Master, I have heard that
objects are a very good thing - is this true?"  Qc Na looked pityingly at
his student and replied, "Foolish pupil - objects are merely a poor man's
closures."

  Chastised, Anton took his leave from his master and returned to his cell,
intent on studying closures.  He carefully read the entire "Lambda: The
Ultimate..." series of papers and its cousins, and implemented a small
Scheme interpreter with a closure-based object system.  He learned much, and
looked forward to informing his master of his progress.

  On his next walk with Qc Na, Anton attempted to impress his master by
saying "Master, I have diligently studied the matter, and now understand
that objects are truly a poor man's closures."  Qc Na responded by hitting
Anton with his stick, saying "When will you learn? Closures are a poor man's
object."  At that moment, Anton became enlightened.

--- Anton van Straaten

You can go even further and remove the need for if statements and booleans:

function cons(a, b) {
    return fn => fn(a, b);
}

function getFirst(pair) {
    return pair((a, b) => a);
}

function getSecond(pair) {
    return pair((a, b) => b);
}

Is there a reason you’re doing SICP in javascript? Isn’t half the fun getting to use Scheme?

I got pretty deep into chapter 3 last year. The realization in the article really hit me when watching the corresponding lectures from 1986. Just as amazing as the book.

Also, SICP is a surprisingly great introduction to creating abstractions, which was not what I was expecting. Pairing it with A Philosophy of Software Design (which contrasts nicely to SICP’s practicality) I think would be great reading for any developer.

I think there’s an inadvertant misleading statement early on: cdr does not get the second item in a list, as the article plainly says.

It plays a role in so doing: cdr gets the “tail” of the list, i.e., what remains past the head.

I’m too young to have experienced it first-keyboard, but i think “car” and “cdr” were assembly language instructions for “contents, address register” and maybe “contents, data register”, IIRC, alluding to an early Lisp implementation’s underlying assembly language.

Back to the article: cadr would get the second item in a list, if it existed, or (car (cdr someList)) would be what the author was thinking, it seems.

You can encode pretty much whatever you want into functions. Here’s the natural numbers, for instance

function fromNat(n) {
  if (n == 0) { (s, z) => z} 
  else { (s, z) => s(fromNat(n-1)(s, z)) }
}

function toNat(n) {
  n( (x) => x + 1, 0 )
}

There’s even an automatic way to do this encoding to any algebraic data type.

Another strange beast I found somewhere is this

(define true (lambda (x y) x)))
(define false (lambda (x y) y)))

But how do you use it?

;; definitely not working but you get the idea
(define-syntax if
  (syntax-rules ()
    [(_ t l r)
     (t l r)]))

So with just function application you can do a lot! Abstraction for data and control flow!

In contrast you can get something also delightful from go boolean builtin

const (
    true  = 0 == 0 // Untyped bool.
    false = 0 != 0 // Untyped bool.
)```

That’s pretty cool, thanks for sharing :)

EDIT: Wow straight up I just used this trick for a test I’m writing for work. Python library uses *args and instead of fighting trying to fit an extra member into the object, I just closed over the thing I was trying to pass in.

can someone explain to me what is so mind blowing?

Would someone care to explain as to exactly why this blew his mind? I do not understand Scheme enough to see/understand what is happening here.