В комментах к статье "Синглтон - корень всех зол", который вообще-то про паттерн проектирования, я высказал мысль, что в функциональном программировании "все функции - синглтоны" (это уже в смысле lifestyle - больше одной функции на приложение не нужно). Тут же мне более опытные коллеги насовали в панамку, что "функции не синглтоны, потому что существуют замыкания". Я, конечно, "сварщик не настоящий" - в ФП серьёзно никогда не игрался, но основные идеи вроде как у всех на слуху: неизменяемость данных, чистота функций, функция как аргумент / результат другой функции.

На мой субъективный взгляд, при таких вводных, нет никаких доводов за то, чтобы в приложении иметь более одного экземпляра чистой функции. Какой смысл иметь два экземпляра функции, если она не имеет побочных эффектов - для одних и тех же входных данных всегда возвращает один и тот же результат, вне зависимости от внешних условий? Ну? Вот и я думаю, что никакого.

Тем не менее, мысль про замыкания надо было как-то подумать - не, ну а вдруг?! Под катом я привожу результаты своих изысканий на примере очень простого функционала на JS, написанного в трёх разных стилях.

ФП -> ООП -> Процедуры

Для демонстрации результатов я реализовал очень простую задачу:

Создать функционал для расчёта НДС (20%) и налога с продаж (7%).

сначала в виде ФП-кода, затем в виде ООП, а затем в процедурном стиле. В ретроспективе видно, каким образом шло развитие подходов к созданию ПО.

ФП

В функциональном стиле эта задача может быть решена таким образом

const calculateTax = (taxRate) => (amount) => amount * taxRate;
const vat = calculateTax(0.2);       // 20% НДС
const salesTax = calculateTax(0.07); // 7% налог с продаж

console.log(vat(100));      // Вывод: 20
console.log(salesTax(100)); // Вывод: 7.000000000000001

Лично я вижу тут три функции: calculateTax, vat, salesTax . Первая функция является фабрикой для двух других. В результате своей работы она создаёт замыкание, помещает данные в это замыкание, затем создаёт функцию и помещает её туда же. Для двух запусков фабрики имеем на выходе две функции - vat или salesTax .

Можно было бы сказать, что внутри vat и salesTax у нас есть два экземпляра одной и той же функции (amount) => amount * taxRate , но нет - при ближайшем рассмотрении видно, что это две разные функции: (amount) => amount * 0.2 и (amount) => amount * 0.07

ООП

В объектно-ориентированном стиле получается несколько более многословно, но зато явно видно место, где хранятся данные (значение ставки налога - this.taxRate):

class TaxCalculator {
    constructor(taxRate) {
        this.taxRate = taxRate;
    }

    calculate(amount) {
        return amount * this.taxRate;
    }
}

const vat = new TaxCalculator(0.2);    // 20% НДС
const sales = new TaxCalculator(0.07); // 7% налог с продаж

console.log(vat.calculate(100));  
console.log(salesTax.calculate(100)); 

Совершенно ясно, что метод calculate (аналог функции (amount) => amount * taxRate) существует в единственном экземпляре у прототипа класса TaxCalculator. Где-то там, "под капотом", движок вызывает один и тот же код для разного окружения, передавая в него необходимые параметры.

Но это же JavaScript, мы можем переписать этот же код таким образом:

class TaxCalculator {
    constructor(taxRate) {
        this.taxRate = taxRate;
        return (amount) => amount * this.taxRate;
    }
}

const vat = new TaxCalculator(0.2); 
const sales = new TaxCalculator(0.07); 

console.log(vat(100));       
console.log(salesTax(100));  

или даже таким:

class TaxCalculator {
    constructor(taxRate) {
        return (amount) => amount * taxRate;
    }
}

А теперь сравните с:

 (taxRate) => (amount) => amount * taxRate;

Можно сказать, что замыкание - это анонимный класс со своими приватными свойствами, который используется для создания экземпляров объектов.

Процедуры

Этот же функционал можно реализовать и в процедурном стиле: разделение кода на части, линейное выполнение. Если не злоупотреблять глобальными данными, то получается по сути очень похоже на ФП (чистые функции, неизменяемые данные, отсутствие сторонних эффектов):

function calculateTax(taxRate, amount) {
    return taxRate * amount;
}

function vat(amount) {
    return calculateTax(0.2, amount); // 20% НДС
}

function salesTax(amount) {
    return calculateTax(0.07, amount); // 7% налог с продаж
}

console.log(vat(100));        // Вывод: 20
console.log(salesTax(100));   // Вывод: 7.000000000000001

Несмотря на свою похожесть на ФП, тем не менее в данном коде не создаются замыкания. Это старая добрая линейная передача параметров в подпрограммы по ходу выполнения.

program TaxCalculation;

{$APPTYPE CONSOLE}

uses
  SysUtils;

// Процедура для вычисления налога
procedure CalculateTax(taxRate: Real; amount: Real; var result: Real);
begin
  result := taxRate * amount; // Модифицируем выходной параметр
end;

// Главная программа
var
  amount: Real;
  pvnRate, salesTaxRate: Real;
  pvnResult, salesTaxResult: Real;
begin
  amount := 100.0;         // Сумма
  pvnRate := 0.2;          // Ставка НДС (20%)
  salesTaxRate := 0.07;    // Ставка налога с продаж (7%)

  CalculateTax(pvnRate, amount, pvnResult);
  CalculateTax(salesTaxRate, amount, salesTaxResult);

  WriteLn('PVN (20% от ', amount:0:2, '): ', pvnResult:0:2);
  WriteLn('Sales Tax (7% от ', amount:0:2, '): ', salesTaxResult:0:2);
end.

procedure CalculateTax(taxRate: Real; amount: Real; var result: Real);

var result: Real

Эволюция разработки

Если прокрутить эти три примера в обратном порядке, то можно проследить эволюцию подхода к разработке ПО.

Процедурный подход применял функции в лоб:

function fn(a, b, c, ..., x, y, z) {
    return a * b + c - ... - x * y + z;
}

ООП предложил часть данных "заморозить" в виде атрибутов объекта:

class Clazz {
    constructor(a, b, c) {
        this.a = a;
        this.b = b;
        this.c = c;
    }

    run(x, y, z) {
        return this.a * this.b + this.c - ... - x * y + z;
    }
}

Можно считать, что все параметры функции поделили на две группы:

• конфигурационные параметры: то, что отличает один объект класса от другого (например, ставка налога)

• оперативные параметры: данные для обработки (например, сумма для расчёта налога).

Ну и в настоящий момент наша процедура со своими "конфигурационными параметрами" сворачивается до такого состояния:

const fn = (a, b, c) => (x, y, z) => a * b + c - ... - x * y + z;

Каррирование функции - это просто превращение её в последовательность анонимных классов, где каждый конструктор конфигурируется одним параметром.

const fn = (a) => (b) => (c) => ... => (z) => a * b + c ... + z;

Так синглтоны ли функции?

И да, и нет.

Можно сказать, что в ФП "все функции - синглтоны", но это будет неправдой.

Вот, например, функция для расчёта количества вещества при его разведении водой:

const calculateDilution = ratio => substanceAmount => substanceAmount * ratio;
const dilutionWith20Percent = calculateDilution(0.2);

"Под капотом" у dilutionWith20Percent будет функция, аналогичная функции vat :

(x) => x * 0.2

С математической точки зрения это одна и та же функция, но с программной - два экземпляра в разных местах.

Тем не менее, утверждать, что в ФП "функции не синглтоны, потому что существуют замыкания" тоже не верно. Вот аналогичный пример без замыканий:

const vat = (amount) => amount * 0.2;
const dilution20 = (val) => val * 0.2;

И как я уже показал выше, фабрика по созданию замыканий с функцией внутри замыкания аналогична классу (часть входных параметров фиксирована в свойствах класса, часть - вариативна). Реализовать обработку данной ситуации можно и так, чтобы замкнутая функция была одиночкой для всех порождаемых замыканий, а можно и так, чтобы была экземпляром для каждого нового замыкания. Сам-то я больше склоняюсь к первому варианту - нет смысла плодить сущности без необходимости. Но может быть я просто не вижу этих смыслов. Разработчики V8-движка могли бы поточнее ответить на этот вопрос, но вряд ли им есть до этого дело.

Заключение

В этой версии Вселенной радикализм не в почёте. Всё как обычно: есть правила, из них есть исключения, из исключений есть свои исключения. Очень редко утверждения со словами "все", "всегда", "никто", "никогда" и т.п. подобными являются истинными.

Благодарю коллег за ценные замечания и отдельно @Tishka17.

Персональная благодарность Игорю Ивановичу за консультации по проблемным вопросам и примерам кода.

Ну а Maximiliano Contieri - порицание за кликбейтный заголовок. Хотя без него вряд бы появилась эта статья. Так что и от этого в конечном итоге польза.