Hacker News new | ask | show | jobs
by rsj_hn 1915 days ago
Strangely a lot of the functional programming advocates are fine with closures, which are guilty of all the same issues -- private state, hidden state, combining data with functions. Closures are basically lightweight objects. Really the debate should be about whether you are dealing with pure objects or not, rather than whether you are binding code and data into a single variable that is passed around.

I once saw a python function that returned two other functions, a, b, such that depending on what was passed to a, the return value of b would change. Sounds terrible, right? Well, A was set_test_parameters(params) and B was get_test_results(test_run).

In OO parlance, they were two methods of the same test_ object but because they were returned as closures the underlying object was hidden as an internal variable in the function that returned a and b. In OO parlance that would be a factory. Wonder what Joe Armstrong would think about that -- it was both cringeworthy and also quite efficient, as the code that consumed A didn't need to know about B and vice versa. One could even think of A and B as two ends of a pipe, or as pointers to inputs and outputs of an unspecified function.

Being able to cleanly design a complex program so accurately that only immutable types are used is difficult. Then throw in large numbers of junior engineers working in tight time windows, subject to constantly changing requirements, and the odds of that codebase being pure a few years out is basically zero. In the end, we have to ship.

3 comments

"Obligatory c2.com reference": https://wiki.c2.com/?ClosuresAndObjectsAreEquivalent

""" 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. """

> Strangely a lot of the functional programming advocates are fine with closures, which are guilty of all the same issues -- private state, hidden state, combining data with functions.

In functional programming closures (like other functions) only hold immutable data and cannot have side effects, so there is no private/hidden state involved. Code which can mutate state or produce side effects is procedural, not functional.

this is misguided to such an extent
As bizarre as the stated API sounds, it's actually a good choice for a lock-free triple buffer where set() and get() are called on separate threads and shouldn't block each other: https://lib.rs/crates/triple_buffer

I think it's also useful for SPSC channels.

Such an extent mere words can't even comprehend your reasoning.