Выразительный код без программазма на вашем любимом ЯП

Можно. Причем разными способами. И в сях. И в плюсах. И думаю в любом ООП языке через объект. (и это правильно)

Но, в общем случае, это не корректный подход т.к. условный f(x) должен для одинаковых x давать одинаковый результат.

Но, в общем случае, это не корректный подход т.к. условный f(x) должен для одинаковых x давать одинаковый результат.

Кому должен?

Кроме того:

Желательно с минимумом программазма в виде новых типов, классов-хренассов

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

Кому должен?

Как минимум здравому смыслу.

Я вот не хочу гадать, почему у меня функция выдает разный результат при одинаковых аргументах.

И я знаю только одно исключение из этого правила - рандомизатор.

Готов выслушать ваши примеры, когда такое допустимо.

p.s.

Я, если что, считаю что дефолтный strtok это не очень хорошо (в отличии от strtok_r)

не корректный подход т.к. условный f(x) должен для одинаковых x давать одинаковый результат

«Не корректный» с какой т.з.? С т.з. Джулии все корректно. А с объектами, по крайней мере в С и С++ будет то же самое: object.method(agrs) не обязан быть инвариантом в любых местах программы.

ИМХО: Если это собственное поведение объекта - можно (если это не синглтон). Если говорить о функции самой по себе, которая работает не свой объект, а действует во вне - так нельзя.

p.s.

Зачему что это мое личное мнение. Я готов выслушать аргументы против.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&am...

fn make_sequencer<F, T>(next: F) -> impl FnMut() -> Option<T>
where
    F: Fn(Option<T>) -> Option<T>,
    T: Clone,
{
    let mut value = None;
    move || {
        value = next(value.clone());
        value.clone()
    }
}

fn main() {
    let mut seq = make_sequencer(|x: Option<i32>| match x {
        Some(x) => Some(x + 1),
        None => Some(0),
    });
    for _ in 0..5 {
        println!("{:?}", seq());
    }
}

Вторая версия. Я заметил что там инициализация еще нужна. Но у тебя кривоватая какая-то.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&am...

fn make_sequencer<F, T>(init: T, next: F) -> impl FnMut() -> T
where
    F: Fn(T) -> T,
    T: Clone,
{
    let mut value = init;
    move || {
        value = next(value.clone());
        value.clone()
    }
}

fn main() {
    let mut seq = make_sequencer(0, |x| x + 1);
    for _ in 0..5 {
        println!("{:?}", seq());
    }
}

Вот из этого кода столько ассемблера

https://pastebin.com/ms7iafxk

;)

В моем примере вообще нет упоминания никаких типов данных.

Ну это просто одна из фич языка - generic by default, пока не укажешь ограничения. В принципе удобно, но есть свои недостатки.

Это не математическая функция, а некий объект, сочетающий в себе состояние и внутреннюю динамику, возможно, неизвестную его пользователю, а ля черный ящик. Я просто показал пример, в котором для подобной абстракции не нужно создавать новых типов данных, и вообще даже знать ничего о ООП не надо.

Допустим, мне интересно только анализировать выходную последовательность при изменении входных данных и/или внутренней логики функции изменения состояния, а парадигмы программирования меня не интересуют, но в тоже время я не хочу каждый раз при изменении логигки переписывать все или наращивать простыню лапшеобразноко кода.

Это если есть привычка, что если функция - то чистая, а если обьект - то с состоянием, которое меняется. Но это лишь конвенция в большинстве ЯП. В некоторых - нет, фича языка. Но уж в С++ точно никого не удивишь сайд-эффектами, их ожидают везде

Я вот не хочу гадать, почему у меня функция выдает разный результат при одинаковых аргументах.

Не надо гадать, все написано в документации

На Джулии это довольно прямолинейно

И довольно убого. Решать что-либо за счёт подобных грязных функций — плохая идея. Здесь ведь даже текущее состояние (X) нельзя узнать.

Xnew = next_f(X, Y) X = Xnew

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

Фу, короче, во всех норманых языках это можно написать гораздо лучше, либо так же, но читаемо.

        end
    end
end

Ужас какой.

Пфффф static int counter; Си, всё ясно и лаконично

Тебя не удивило что оно возвращает генератор, в который каждый раз нужно передавать переменную инициализации? Та которая Y

o_O

Ого, и этот капец называли убийцей питона!

def gen(next_f, x):
    while True:
        yield x := next_f(x)

рассосано на 13 строк? Чума.

создание расширяемых (настраиваемых) функций, умеющих хранить свое состояние.

Зачем изобретать кульхацкерский «велосипед», если есть Supplier?

package test;

import java.util.function.Supplier;

public class Test {
    
    static private Supplier<Integer> raccoon() {
        final int[] cnt = new int[1];
        return (() -> ++cnt[0]);
    }
    
    public static void main(String[] args) {
        Supplier<Integer> lotor = raccoon();
        System.out.println(lotor.get());
        System.out.println(lotor.get());
        System.out.println(lotor.get());
    }
}

Идею я подал - дальше самостоятельно.

На собеседовании, естественно.

В большинство дистров ешё только 3.6 завезли.

Там же next_f принимает X и Y.

Хорошо, на тебе 3.6 да с игреком:

def gen(next_f, x, y):
    while True:
        x = next_f(x, y)
        y = yield x

Там Y можно разный давать на каждую итерацию.

Так и у меня y можно задавать разный на каждую итерацию.

А, ну у тебя next его должен возвращать, а это не то. Если next_f чистая, то в последовательность нельзя вмешаться. Видимо, это требуется.

Хунта, нет функций, есть дрочильня на конкретные методы, что первый next, а дальше send.

А, ну у тебя next его должен возвращать, а это не то.

Нет, ты что-то не так понял. У меня он должен быть отправлен генератору .send()ом и будет принят y = yield ...ом.

Это не то же самое, что в условии. Вот этот вариант ближе: Выразительный код без программазма на вашем любимом ЯП (комментарий)

Только там вся история не нужна (динамический массив не нужен).

Да дошло уже, затупил.

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

ТС спросил «А можно ли ту же идею реализовать на вашем любимом ЯП?», а не «изобретите паттерн генератор столь же криво, как и я».

Конечно ближе, но реализовывать генераторы не через генераторы откровенно непитонично.

Нет, ООПизма хотелось бы избежать. Все эти «public private static void», "..get()" - это ненужная инженерия для простого, но расширяемого примера. Придумали какой-то новый класс сапплаер, но код такой же громоздкий, как и всегда в этих Джавах.

В условии что-то такое (фиксированного количества предыдущих значений) и требуется. Вместо коллекции для этого конечно лучше взять collections.deque, но это вообще никак не изменит код.

идиоматичного подхода

Помнить, что первым всегда next, а дальше send? Нахер такие идиоматичные подходы.

Кому не нужна? А вообще.

def makesequencer(next_f):
    x = None
    def f(y):
        nonlocal x
        x = next_f(x, y) if x else y
        return x
    return f

ООПизма хотелось бы избежать.

Ну, что тут сказать... Каждый - ССЗБ.

Или адепт секты проФФеСора В.С.ЛугоФФского.

Это понятный код

import java.util.function.Supplier;

public class Test {
    
    static private Supplier<Integer> raccoon(int x, int y) {
        final int[] cnt = new int[1];
        cnt[0] = x;
        return (() -> cnt[0] += y);
    }
    
    public static void main(String[] args) {
        Supplier<Integer> lotor = raccoon(5, 5);
        for (int i = 0; i < 3; i++) {
            System.out.println(lotor.get());
        }
    }
}

10
15
20

А то, что в сообщении топика и на прочих недоязычках ниже - кулькакерское поделие.

Какой ужас, это страшное ООП!

class Sequencer:
    def __init__(self, next_f, x=None):
        self.next_f, self.x = next_f, x
    def __call__(self, y):
        self.x = y if self.x is None else self.next_f(self.x, y)
        return self.x

s = Sequencer(lambda x, y: x + ' ' + y)
print(s('О'))
print(s('боже'))
print(s('ООП'))
print(s('как'))
print(s('страшно'))

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

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

А потом сам генератор еще жрет Y постоянно. Причем использует только первый раз

Помнить, что первым всегда next, а дальше send? Нахер такие идиоматичные подходы.

Не нравится, как принято в языке? Не пиши. Рекомендую познакомиться с Goury.

В тред набежало читоров. Напомню - Julia компилируется LLVM в натив. Так что корректнее приносить примеры с С++ и кушать их с маслом.

Я попробовал на Rust, который в том же классе языков. И получилось вроде неплохо

В тред набежало обалдевших ребят, радостно рассказывающих, что надо было не то, что ТС просил в шапке, а вместо этого (то|это|пятое|десятое). Меня лично радует, что в их числе есть также я и сам ТС.

Ну мы то знаем что он набежал Julia понахваливать. А ему раз, и пехтон, на котором абсолютно что угодно короче

self.x = y if self.x is None else self.next_f(self.x, y)

наследие Фортрано-Матлаба живêт и развивается в форме новых ЯП типа Джулии, в т.ч и потому что позволяет с минимальными изменениями кодировать математические формулы на ЯП без шума ООПшных конструкций. В данном случае self убивает легкость чтения вычислительной логики. Также, математическое выражение вариантов предполагает записи условий и значений на отдельных строках.

Сколько времени прошло, а педонисты до сих пор доставляют:

[питон] А как записать многострочную лямбду?

____ЫЫЫ____ https://www.artima.com/weblogs/viewpost.jsp?thread=147358

Понятно, почему его из Гугля «выставили на мороз»(С).

Не нравится, как принято в языке?

Так и не принято, вовсе. Знаешь, сколько раз в коде всей стандартной библиотеки cpython используется send?

пехтон, на котором абсолютно что угодно короче

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

наследие Фортрано-Матлаба живêт и развивается в форме новых ЯП типа Джулии

а жаль

В данном случае self убивает легкость чтения вычислительной логики.

Кто бы спорил. Никто и не кинется так писать, когда в языке есть генераторы. А вот над тем, что ты путаешь ООП с джава-специфичным шумом от ООП не подтрунить было нельзя.

Так и не принято, вовсе.

Собирай ребят, скажи: отзываем нафиг PEP 342.

Знаешь, сколько раз в коде всей стандартной библиотеки cpython используется send?

Передай, что раз в реализации стандартной библиотеки фича не нужна, то не нужна и конечным пользователям. И, чтоб два раза не ходить, операторы @ и walrus, аннотации типов и async/await тоже пусть сразу вынесут за одним.

Если я правильно понял, то эта штука в Python называется итератор (или генератор, не помню уже).