Just to make it explicit; I'm not suggesting Javascript for communicating this type of posts. Without strong typing, this kind of refactoring will immediately become a spaghetti of screaming ducks.

Defunctionalisation is a not-so-rare pattern to encounter and I humbly think choosing a non C-like language to explain it is a waste of opportunity to introduce it to people who can benefit it most (i.e network programmers, game scripting tools programmers, distributed systems programmers etc).

https://docs.microsoft.com/en-us/dotnet/api/system.linq.expr...

https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...

Something like:

"For this section and the next, let us imagine the guts of a very basic calculator application, expressed in the initial algebra style, using [your language and environment]."

It can be done. There are plenty of C codebases that end up having something defunctionalized eventually. It's arguably one of the main pressures that causes Greenspun's 10th Rule [1] to be so accurate; as your codebase grows the odds that you'll be forced to defunctionalize something significant in your code goes to 100%.

It isn't any fun, though.

[1]: "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."

The very origin of defunctionalization is to emulate higher-order functions in a language without them.

https://en.wikipedia.org/wiki/Defunctionalization

> defunctionalization refers to a compile-time transformation which eliminates higher-order functions, replacing them by a single first-order apply function.

    static void Main()
    {
        var expr = TwoArg.New(Add.New(), Constant.New(1), Constant.New(1));
        var res = ExprModule.Interpret(expr);
    }

    [Union]
    public interface OneArgFunction
    {
        OneArgFunction Negate();
        OneArgFunction Custom1(Func<int, int> x);
    }

    [Union]
    public interface TwoArgFunction
    {
        TwoArgFunction Add();
        TwoArgFunction Subtract();
        TwoArgFunction Custom2(Func<int, int, int> x);
    }

    [Union]
    public interface Expr
    {
        Expr Constant(int x);
        Expr OneArg(OneArgFunction f, Expr x);
        Expr TwoArg(TwoArgFunction f, Expr x, Expr y);
    }
        
    public static class OneArgFunctionModule
    {
        public static Func<int, int> Interpret(OneArgFunction f) => f switch
        {
            Negate _         => x => -x,
            Custom1 (var fn) => fn
        };
    }
        
    public static class TwoArgFunctionModule
    {
        public static Func<int, int, int> Interpret(TwoArgFunction f) => f switch
        {
            Add _            => (x, y) => x + y,
            Subtract _       => (x, y) => x - y,
            Custom2 (var fn) => fn
        };
    }

    public static class ExprModule
    {
        public static int Interpret(Expr e) => e switch
        {
            Constant (var x)             => x,
            OneArg (var f, var x)        => OneArgFunctionModule.Interpret(f)(Interpret(x)),
            TwoArg (var f, var x, var y) => TwoArgFunctionModule.Interpret(f)(Interpret(x), Interpret(y)),
        };
    }

[2] https://github.com/louthy/language-ext/

Your example in the "Testability" section doesn't involve HOFs. I thought it was interesting to view that example as an instance of defunctionalisation.

Over the past two years we've been slowly moving our code base in this direction general, eliminating Exceptions, for example, in favor of more detailed Result<ValueT, ErrorT> return types.

With lamdas, writing this kind of code does require more boilerplate in Java, but it's getting better.

Nonetheless, ADTs and pattern matching are sorely missed. The Visitor pattern is an alternative and is well worth it for key data structures, but is too verbose for one off usage.

The metaidea is to stay at a richer abstraction level for longer, and then drop down in the last moment for execution? One doesn't always have a chance to do this, being able to detect when to apply the technique would be a good lesson.

Rather than reworking the post to meet the imperative programmers in their safe space, it could entice them into your crystal palace.

Many programmers have used these techniques even outside FP and would be able to understand it one concept at a time - they aren't advanced concepts to me. It's more that it isn't "easy reading"; but it seems its for an internal audience with assumed background knowledge.

The example you gave is similar to a discriminated union in ML but it is not as robust because the language will not check that every match expression (probably an if-instanceof-ladder in Java) handles every case.

I don't think this is really the same thing. You're discussing the object level; I'm discussing the meta-level.

Haskell is based around "define the concepts as you would naturally define them and I'll use that definition to create a program". However, this is entirely implicit in the language. Defunctionalisation explicitly reifies this, allowing the language to discuss how it does it.

I see your point as basically "what's the use of continuations? I already have `goto`".

Parenthetical aside: I could have been rescued from this by a sufficiently advanced Markdown renderer, and in fact the HTML source is annotated with `lang-fsharp`, but that metadata did not make its way up to the reader.

[0]: https://en.wikipedia.org/wiki/Interpreter_pattern

On one hand, it feels similar, especially if the Command class is "sealed".

On the other hand, it feels like completely the opposite since the command classes contain the code they execute and act like lambdas.

I guess you could apply a visitor pattern on top of the command pattern to make it truly like defunctionalization. I hope nobody actually does this.

In a proper functional language, you do not need objects for the latter, as you can directly compose functions.

That being said, the ability to add more operations than just "execute" to your commands allows you to emulate the features of deep embedding (e.g., serialization). But you have to extend every command for a single new operation (read up on the expression problem). That style is known as tagless in the FPL community, btw.

1. Serializable, scriptable configuration parsing (i.e used widely in video games such as visual novels)

2. RPC over network where request/response paradigm isn't applicable (i.e a distributed state machine, language server etc)

Both of these can be worked around with existing techniques but they can also benefit from defunctionalization for much better debug-ability.

In my comment, I stated that even non-junior programmers have hard time reading these kind of articles and I believe they already deal with problems like 1 and 2 in their career.

Well, it depends. My experience is that being aware of how lambda lifting/defunctionalization works actually makes first-class functions/HOFs a lot easier to understand as a language feature, even to a novice programmer. It's precisely the "missing link" between that language feature and the usual case of first-order functions/subroutines. Same for other "high-level" features known from FP and other programming paradigms - there are way too many of those to list them, really.

There are a lot of "senior programmers/developers/engineers/whatever other term you want to use" that don't know about these techniques. More broadly they don't know about a lot of the features and functionalities of functional programming and more generally higher order (as in function) programming paradigms.

If we don't write introductory articles in a way that those outside the subfield can grasp them, we are alienating large groups of new-guard and old-guard programmers who could benefit greatly from understanding the techniques that not only help them improve their code and productivity, but also the techniques that allow them to use high level features without paying for the cost of them.

Anecdote: I've worked with a senior engineer on a C++ project. We used C++11 but effectively we wrote C++98 style code because they had largely unfounded fears of not only the performance impacts of utilising new features and FP paradigms in their codebase, but also the debugging and readability impacts of using them. I found that many of the articles and videos I would send them to try to ease those fears ended up falling flat due to them not targetting his audience. It took me slowly writing up internal memos and presentations on these various features, and showing how they came at little to no cost while providing their benefits for our team to actually start using them. Now they like to joke about how "In 2019 I did the impossible and helped drag them kicking and screaming into 2011".

On your last comment: You claim that we shouldn't need to "Cobalize everything to make it superficially acceptable to people who refused to learn basic language" but the issue is a matter of priorities. For a new engineer learning the language is important however for senior engineers and leadership, these are not the most important concerns. The important stuff is the following in order:

- Actually delivering a product.

- Making the product stable, easy to maintain, easy to debug/validate/test, and easy to modify/improve without introducing issues.

- Making sure that the product ages well, handles staff churn without losing design intent, and doesn't unnecessarily accrue technical debt.

- Ensuring that new staff can be easily on-boarded and become productive.

It should come to no surprise that senior staff are hesitant to waste time on what could potentially be fads or misinformed design choices. They won't waste time on learning something they don't think will be useful or pay off and as a result, unless introductory content includes them in the intended audience, they never will get a chance to find value in these concepts.

One last note: Sorry if I rambled a bit, I'm typing this up real quick while I take a break and I've been a bit all over the place recently. If I don't seem clear about anything, ask me to clarify and I will.

Citadel, for instance sued a former employee for steeling a model (he emailed the source for a model to his personal email. He was sued in federal at 8am on a Monday, fired at noon. Criminal charges came months later. Tried dispose g of the evidence by tossing hard drives in the Chicago River. Dive teams were involved to recover the drives. But, Citadel already had all they needed because they monitored all outgoing and internal communication, including MITMing SSL email services.

Is there something in particular that you'd like to see "a bit more"? Are you imagining e.g. a more extended walkthrough of how to realise the benefits of defunctionalisation on a real-life program, or some more theoretical background, or some of how it's used in compilers, or anything in particular?

However, if you were to use "free monads", you get closer to what the author is talking about. Free monads are a special implementation of monad that don't actually _run_ any effects - they just build up a data benign structure that can be interpreted later (possibly as an effect).

To do defunctionalization, you don't need monads though - you just need to define data that represents operations. Monads can just provide convenient syntax to do this while looking like a sequential program.

In fact you don't need to use monads at all here. I've used this pattern on merely applicative non-monadic initial algebras before; in fact, the article's "arithmetic expressions" example isn't what I would call "monadic", because it doesn't readily admit Bind as currently phrased.

Worse, the "writeSmallOddToFile" example isn't even generic at all, so I don't think there's a reasonable sense in which it could even be said to be functorial.

Is it just me or does this sound a bit like Common Lisp's compiler macros (http://www.lispworks.com/documentation/HyperSpec/Body/03_bba...)?