[racket] Why functional?

From: Greg Hendershott (greghendershott at gmail.com)
Date: Thu May 23 14:48:37 EDT 2013

> Pure functional languages do not allow (re)assignment. You can assign a
> variable/identifier once,
> then it is immutable.  If you need a new value, it is a different identifier
> (different memory location
> under the covers).  It removes a number of shared-memory bugs caused by
> updating a location
> incorrectly, whether your application is single-threaded or multi-threaded
> or distributed.

To me, that's the crux. The problem isn't assignment, it's REassignment.

Saying that "X is 1" is fine. The problem is later saying, yeah
actually, X isn't 1 anymore. What, you didn't get the memo?

Even a pure functional program is constantly writing to memory, or it
wouldn't be accomplishing anything. The "state" of interest here isn't
RAM, it's your names for things in RAM.

Also, any practical system will be non-functional at its "edges": At
some point, it has to earn its living by doing I/O of some sort.

My word cloud also includes:

WORM: Write Once, Read Many.

CR_D: CRUD with Create, Read, and Delete, but without the Update.

POST, GET, DELETE: HTTP without the P verbs. No PUT. _Definitely_ no PATCH. ;)

Finally I think it's important to walk the talk. My understanding of
functional programming, however poor, is itself purely functional.
Nothing anyone says will change it. :p

Posted on the users mailing list.