Функциональное программирование *

Functional FizzBuzz

public class FizzBuzz
{
    public static void Main(string[] args)
    {
        Console.WriteLine(FizzBuzzProgram(350));
    }
    public static string FizzBuzzProgram(int n) =>
        String.Join("\r\n", 
            Enumerable.Range(1, n).Select(FizzBuzzPipeline));

    static readonly Func<int, string?>[] handlers = [(n) => n % 3 == 0 ? "Три" : null, (n) => n % 5 == 0 ? "Пять" : null];
    
    public static string FizzBuzzPipeline(int i) => Counter(i, String.Join("", handlers.Select(f => f(i))));

    public static string FizzBuzzPipelinePar(int i)
    {
        var results = handlers.AsParallel().Select(handler => handler(i)).Where(r => r != null);
        return results.Any() ? string.Concat(results) : i.ToString();
    }
}

Насмотрелся тут Скотта Влашина https://youtu.be/ipceTuJlw-M?si=ndSDvv-RWj8L1Ejt

и сделал свой функциональный FizzBuzz с массивом делегатов преобразований числа в Fizz & Buzz.

Этот массив расширяемый - пишите хоть 100 проверок, множество других решений на такое не способно.

Можно делать любое вычисление вычислять. А из-за независимости мы можем запускать их параллельно (если бы вычисление хендлера занимало большое время).

Хотите попроще ценой потери части универсальности?

    static string FizzBuzzPipelineWOHandlers(int n)
    {
        string result = $"{(n % 3 == 0 ? "Fizz" : "")}{(n % 5 == 0 ? "Buzz" : "")}{(n % 7 == 0 ? "Qux" : "")}";
        return String.IsNullOrEmpty(result) ? n.ToString() : result;
    }

Ката закончил, поклон.

Я зашел в Google Trends чтобы посмотреть популярность запроса "Mathematica". Меня, как большого фаната технологии, график очень расстроил.

В Wolfram Language остается все меньше и меньше программистов среднего класса, т.е. тех, кто способен самостоятельно писать нормальный код на этом языке, но им не обязательно знать все его тонкости и особенности. Я считаю, что это серьезная проблема для популяризации этого языка, кроме всех тех проблем, которые его уже преследуют многие годы.

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

А этих минусов достаточно много. Сложности с лицензией отсеивают огромное число потенциальных пользователей. Высокая цена и необходимость постоянного продления являются серьезным барьером для среднего гражданина. Абсолютная невозможность использования в коммерческих целях.

Я надеялся на то, что с появление бесплатного Wolfram Engine ситуация изменится, но эффект был очень слабым. Слишком поздно это произошло. В итоге все равно оказалось, что лицензия запрещает коммерческое использование бесплатного ядра. А значит компании не заинтересованы внедрять этот язык и нанимать инженеров, которые им владеют. Значит нет вакансий и нет интереса со стороны разработчиков и инженеров и нет смысла его изучать и оставаться в нем.

Утечки памяти преследовали программы на языке С с тех пор, как существует этот язык. Было предложено множество решений, вплоть до идеи переписать программы на языке C на других языках. Но есть лучший способ.

Здесь представлено простое решение, которое устранит утечки памяти в каждой программе на языке C. Используйте этот модуль с вашей программой, и утечки памяти останутся в прошлом.

#include <dlfcn.h>
#include <stdio.h>

struct leaksaver {
        struct leaksaver *next;
        void *pointer;
} *bigbucket;

void *
malloc(size_t len)
{
        static void *(*nextmalloc)(size_t);
        nextmalloc = dlsym(RTLD_NEXT, "malloc");
        void *ptr = nextmalloc(len);
        if (ptr) {
                struct leaksaver *saver = nextmalloc(sizeof(*saver));
                saver->pointer = ptr;
                saver->next = bigbucket;
                bigbucket = saver;
        }
        return ptr;

Пояснение автора кода в оригинале:

Every allocated pointer is saved in the big bucket, where it remains accessible. Even if no other references to the pointer exist in the program, the pointer has not leaked.

It is now entirely optional to call free. If you don’t call free, memory usage will increase over time, but technically, it’s not a leak. As an optimization, you may choose to call free to reduce memory, but again, strictly optional.

Problem sovled!

​​?️️️️️️ Каррирование и частичное применение

Каррирование и частичное применение — две концепции из функционального программирования, которые очень часто путают из-за их схожести (а я пишу этот пост, чтобы наконец-то запомнить). 

И частичное применение, и каррирование, реализуются как функции, принимающие в качестве параметра другую функцию.

Частичное применение — функция partialApply, принимающая первым параметром функцию — fn, а остальные параметры — часть параметров функции fn. Функция partialApply возвращает функцию, которая в качестве параметров принимает недостающие аргументы функции fn.

Каррирование — функция curry, которая принимает единственный параметр — функцию fn, и возвращает каррированную функцию fn.  Можно сказать, что каррированная функция fn — функция аккумулятор, которая будет накапливать переданные аргументы до тех пор, пока не будет передано достаточно параметров для вызова исходной функции. Параметры можно передавать в любом количестве.

Подробнее

• Карринг vs Частичное применение функции — C#

• Каррирование функций в JavaScript

• Реализация функции каррирования

• Function: length

https://t.me/cherkashindev/132

3 июля 2023 г., спустя полтора года вышла новая версия языка функционального программирования Koka. Несмотря на минорность версии в новом компиляторе внедрено изобретённое его авторами Full In-Place Calculus. Если коротко, то суть FIP в следующем: у нас есть чистая функция, производящая деконструирование объекта данных, а затем вновь конструирующая объект данных. Например, это функция трансформации списка или дерева. Так вот при таких манипуляция в памяти происходит создание новых объектов данных, которые затем и используются, а старые остаются там до тех пор, пока их не удалит за ненадобностью сборщик мусора (кстати говоря, язык Koka не использует сборщик мусора). FIP же позволяет производить проверку безопасности переиспользования памяти. Что и было реализовано в новой версии Koka. Теперь вы можете помечать функцию ключевым словом fip или fbit (FBIP техника, предложенная другими авторами), использовать разрушающий match! и получать описанный выше эффект. Так же, по-видимому, в связи со внедрением FIP появился borrowing (владение), которое также участвует в анализе кода на безопасность. Из приводимого в статье результата benchmarks видно, что новый подход увеличивает производительность программ на Koka и приближает её к таковой на C или C++.

Почитать о Koka можно в этом посте.