Разница в том, что автор считает чисто функциональной программу в которой есть одно гигантское определение чистой функции внутри которого грязный код
Нет содержательного способа отличить чистую функцию от грязной, об этом речь.
Я не очень понимаю, что такое "содержательный способ" в данном случае. В моем представлении речь идет о том из кусков какого типа мы составляем программу — то есть о форме записи алгоритма.
Если является — то грязных функций не существует, т.к. любую грязную ф-ю в любом языке можно рассматривать как функцию, возвращающую ИО.
Речь идет о способе выражения программы. В тот момент как мы представляем функцию, возвращающую IO мы мысленно делаем эквивалентную функциональную программу. Мы можем мысленно перевести практически все с русского на английский, это не означает что английский и русский, это одинаковые языки. Или что запись длины в дюймах то же самое, что запись длины в сантиметрах. Или что полярные координаты это то же самое что и декартовы.
Мы можем, конечно, себя ограничить и написать формально чисто функциональную программу написанную в императивном стиле, как допустим, мы можем написать объектно ориентированный эмулятор оборудования на C# и писать все на нем (типа processor.Registers.Ax.Move(processor.Registers.Bx)). Но тогда у нас, по крайней мере, будет способ заводить новые чистые функции и они будут отделены от IO/RealWorld.
Что вы подразумеваете под "чистой ф-ей" в данном случае?
"В языках программирования, чистая функция, это функция, которая:
С моей точки зрения чистая функциональная программа это то, что состоит из вызовов чистых функций, а не их определений.
Это определение относится не к тому, что делает программа, а из чего она собрана — т.е. это некоторый способ соединения частей программы.
Это полезно, например, для того, чтобы понимать какие преобразования мы можем делать с программой без нарушения ее работы.
Побочный эффект, это, что-то не являющееся возвращаемым результатом функции, трансформировать функцию с побочным эффектом в чистую функцию просто, достаточно передать состояние вселенной в качестве аргумента, и вернуть в качестве результата (правда, для этого нужен особый тип с особыми ограничениями)
Я думаю, это больше зависит от атмосферы в конкретном коллективе. Если люди поверят, что начальству не все равно, то большая часть будет работать на результат, а от остальных можно избавиться.
Только основателю надо готовиться к тому, чтобы раз за разом объяснять и показывать одно и то же. Ему должно быть принципиально и он должен понимать, что для людей доходит не с первого раза и что они будут периодически пытаться испортить атмосферу и надо будет постоянно следить, чтобы все работали как ему надо.
Там определение чистой функции а не чистой программы.
У нас есть ваше определение
Функциональная программа — программа, состоящая из чистых функций.
По которому не понятно, что значит "состоящей из" и вот например из википедии
In computer science, purely functional programming usually designates a programming paradigm—a style of building the structure and elements of computer programs—that treats all computation as the evaluation of mathematical functions. Purely functional programming may also be defined by forbidding changing-state and mutable data.
Purely functional programming consists in ensuring that functions, inside the functional paradigm, will only depend on their arguments, regardless of any global or local state.
Если под "состоящей из" понимать что там должны быть только определения чистых функций, то непонятно, как им пользоваться. Программа может состоять из одной гигантской чистой функции реализация которой написана императивно и с ее логикой нельзя будет обращаться как композицией чистых функций — распараллеливать автоматически и так далее.
Что внутри тела, неважно, до тех пор, пока она ссылочно прозрачна.
Неважно для того, кто вызывает эту функцию, или для программиста который пишет/меняет ее тело?
Там про то, почему функция чистая, а не почему программа чисто функциональна. С первым пунктом у меня та же точка зрения, а со вторым нет.
Если принять ее за черный ящик
В программе нет никого, кто использует функцию (т.е. принимает за черный ящик), а, наоборот, есть определение и реализация. Реализация определена не только через чистые функции, => программа не является чисто функциональной, хотя функция является.
Возможно, какая-то другая программа, которая бы вызывала эту функцию была бы чисто функциональной.
Итого у нас есть чистая функция с нечистым телом. Ни одного вызова чистой функции в программе нет. Считается ли вся программа чистой в данном случае?
на практике в данном случае не особо мешает
В данном случае оно не мешает постольку поскольку тело маленькое. Так же как и чистота функции никому не помогает, поскольку ее вызовов нет. Но формально программу нельзя назвать чистой, поскольку она определена не только через чистые функции.
что такое "локальный мутируемый стейт"? До какой степени локальный?
*= совершенно аналогичен функции
void MultuiplyBy(ref int accumulator, int multiplier)
{
accumulator *= multiplier
}
acumulator не является локальным состоянием для функции MultuiplyBy но может являться локальным для какого-то скопа сверху.
Мы не можем мемоизировать, авторматически пареллелить и т.д — т.е. не соблюдаются свойства которыми мы сможем воспользоваться для чисто функциональной программы.
Нам не важно пишем ли мы чистые функции или нет, важно пользуемся ли мы только ими или нет.
С моей точки зрения функция, которую вы написали, является чистой, а программа — нет.
Так ведь? С одной стороны да. А с другой именно вторая программа в отличие от первой является функциональной.
Как это? Там есть *= которая не является ссылочно-прозрачной. Функционально чистой была бы программа, которая только бы вызывала эту функцию, но не состояла из ее определения. Например, если бы это была чистая программа эксплуатирующая грязный рантайм с чистым интерфейсом.
откуда вообще взяться комментариям «этот код — дерьмо»?
У того, кто пишет и ревьюэра разный критерий дерьма?
Нарпимер, как я понял, для вас приемлем код похожий на результат обфускации но который работает. А для кого-то, может, наборот — небольшая ошибка — недочет, но если переменные названы непонятно, то дерьмо.
Плохо стучать или хорошо зависит от того, кому стучишь. Если власти в целом плохие, то плохо, если власти хорошие, то хорошо. Соответственно в разных обществах разное отношение.
но у нас сейчас нет данных, сколько попыток внятного корректного объяснения с необходимыми подсказками было сделано до того.
Даже если учеcть это, зачем специально сообщать путь разрешения проблемы специально непонятно для автора? Почему он не был понятно описан в предыдущих коммуникациях?
Я это поддерживаю, такие проблемы должны вскрываться как можно раньше.
С моей точки зрения "как можно раньше" это во время код ревью. Я бы постарался помочь на code review — т.е. дал бы пояснение как исправить как можно понятнее, а не специально так, чтобы он не понял.
Если бы не получилось, то все равно бы исправлял баги, если бы они пришли ко мне, но на ретроспективе бы указал, что неправильный подход был принят, это породило такие-то и такие-то баги, что стоило времени таким-то людям.
Откуда это «вы сделали так, чтобы неподходящий код туда попал»?
Кто сделал «так, чтобы неподходящий код туда попал»?
khim "Пытался человеку «помочь» (давая ему ровно достаточно подсказок, чтобы они ничерта не понял, но чтобы знающий человек мог это сделать)"
То есть как я понял цель была, чтобы конкретный человек не понял соответственно не исправил косяк, косяк попал к клиенту, потом бы компания тратила время на его исправление, но не сам khim
маловероятно, что такой автор сразу заметит и исправит все ошибки
Если ошибки следствие какого-то подхода, про который уже был комментарий, что что он не самый подходящий и замена на более подходящий его исправят это просто аргумент в дальнейшей дискуссии но человек продолжает настаивать на своем подходе. Речь идет именно про этот случай.
До такого очень редко доходит.
Для смежных компонент это нормальная ситуация, что спрашивают и других людей
Я имел ввиду не приходят на исправление. Конечно некоторое время тратится на то, чтобы выяснить в каком компоненте ошибка, да.
Разница в том, что автор считает чисто функциональной программу в которой есть одно гигантское определение чистой функции внутри которого грязный код
Я не очень понимаю, что такое "содержательный способ" в данном случае. В моем представлении речь идет о том из кусков какого типа мы составляем программу — то есть о форме записи алгоритма.
Речь идет о способе выражения программы. В тот момент как мы представляем функцию, возвращающую IO мы мысленно делаем эквивалентную функциональную программу. Мы можем мысленно перевести практически все с русского на английский, это не означает что английский и русский, это одинаковые языки. Или что запись длины в дюймах то же самое, что запись длины в сантиметрах. Или что полярные координаты это то же самое что и декартовы.
Мы можем, конечно, себя ограничить и написать формально чисто функциональную программу написанную в императивном стиле, как допустим, мы можем написать объектно ориентированный эмулятор оборудования на C# и писать все на нем (типа processor.Registers.Ax.Move(processor.Registers.Bx)). Но тогда у нас, по крайней мере, будет способ заводить новые чистые функции и они будут отделены от IO/RealWorld.
"В языках программирования, чистая функция, это функция, которая:
С моей точки зрения чистая функциональная программа это то, что состоит из вызовов чистых функций, а не их определений.
Это определение относится не к тому, что делает программа, а из чего она собрана — т.е. это некоторый способ соединения частей программы.
Это полезно, например, для того, чтобы понимать какие преобразования мы можем делать с программой без нарушения ее работы.
Побочный эффект, это, что-то не являющееся возвращаемым результатом функции, трансформировать функцию с побочным эффектом в чистую функцию просто, достаточно передать состояние вселенной в качестве аргумента, и вернуть в качестве результата (правда, для этого нужен особый тип с особыми ограничениями)
"Квадро" означает "четыре". Это трикоптер.
Я думаю, это больше зависит от атмосферы в конкретном коллективе. Если люди поверят, что начальству не все равно, то большая часть будет работать на результат, а от остальных можно избавиться.
Только основателю надо готовиться к тому, чтобы раз за разом объяснять и показывать одно и то же. Ему должно быть принципиально и он должен понимать, что для людей доходит не с первого раза и что они будут периодически пытаться испортить атмосферу и надо будет постоянно следить, чтобы все работали как ему надо.
На codereview могут указать на неправильную терминологию. А переименовать ее достаточно легко — ide помогут.
А в каком-нибудь понимании есть?
Это иллюстрация того, что можно сделать с чистой функцией. А что можно сделать с чистой программой, что нельзя сделать с нечистой?
Есть ли у вас какой-то термин для программы, которая состоит только из вызовов чистых функций?
Там определение чистой функции а не чистой программы.
У нас есть ваше определение
По которому не понятно, что значит "состоящей из" и вот например из википедии
Если под "состоящей из" понимать что там должны быть только определения чистых функций, то непонятно, как им пользоваться. Программа может состоять из одной гигантской чистой функции реализация которой написана императивно и с ее логикой нельзя будет обращаться как композицией чистых функций — распараллеливать автоматически и так далее.
Неважно для того, кто вызывает эту функцию, или для программиста который пишет/меняет ее тело?
Там про то, почему функция чистая, а не почему программа чисто функциональна. С первым пунктом у меня та же точка зрения, а со вторым нет.
В программе нет никого, кто использует функцию (т.е. принимает за черный ящик), а, наоборот, есть определение и реализация. Реализация определена не только через чистые функции, => программа не является чисто функциональной, хотя функция является.
Возможно, какая-то другая программа, которая бы вызывала эту функцию была бы чисто функциональной.
Итого у нас есть чистая функция с нечистым телом. Ни одного вызова чистой функции в программе нет. Считается ли вся программа чистой в данном случае?
В данном случае оно не мешает постольку поскольку тело маленькое. Так же как и чистота функции никому не помогает, поскольку ее вызовов нет. Но формально программу нельзя назвать чистой, поскольку она определена не только через чистые функции.
что такое "локальный мутируемый стейт"? До какой степени локальный?
*= совершенно аналогичен функции
acumulator не является локальным состоянием для функции MultuiplyBy но может являться локальным для какого-то скопа сверху.
Мы не можем мемоизировать, авторматически пареллелить и т.д — т.е. не соблюдаются свойства которыми мы сможем воспользоваться для чисто функциональной программы.
Нам не важно пишем ли мы чистые функции или нет, важно пользуемся ли мы только ими или нет.
С моей точки зрения функция, которую вы написали, является чистой, а программа — нет.
А что такое ХКТ — я по быстренькому не нашел?
Как это? Там есть *= которая не является ссылочно-прозрачной. Функционально чистой была бы программа, которая только бы вызывала эту функцию, но не состояла из ее определения. Например, если бы это была чистая программа эксплуатирующая грязный рантайм с чистым интерфейсом.
У того, кто пишет и ревьюэра разный критерий дерьма?
Нарпимер, как я понял, для вас приемлем код похожий на результат обфускации но который работает. А для кого-то, может, наборот — небольшая ошибка — недочет, но если переменные названы непонятно, то дерьмо.
Плохо стучать или хорошо зависит от того, кому стучишь. Если власти в целом плохие, то плохо, если власти хорошие, то хорошо. Соответственно в разных обществах разное отношение.
Даже если учеcть это, зачем специально сообщать путь разрешения проблемы специально непонятно для автора? Почему он не был понятно описан в предыдущих коммуникациях?
Теперь уточнил
С моей точки зрения "как можно раньше" это во время код ревью. Я бы постарался помочь на code review — т.е. дал бы пояснение как исправить как можно понятнее, а не специально так, чтобы он не понял.
Если бы не получилось, то все равно бы исправлял баги, если бы они пришли ко мне, но на ретроспективе бы указал, что неправильный подход был принят, это породило такие-то и такие-то баги, что стоило времени таким-то людям.
Т.е. капал бы на мозги начальству и команде.
khim "Пытался человеку «помочь» (давая ему ровно достаточно подсказок, чтобы они ничерта не понял, но чтобы знающий человек мог это сделать)"
То есть как я понял цель была, чтобы конкретный человек не понял соответственно не исправил косяк, косяк попал к клиенту, потом бы компания тратила время на его исправление, но не сам khim
Если ошибки следствие какого-то подхода, про который уже был комментарий, что что он не самый подходящий и замена на более подходящий его исправят это просто аргумент в дальнейшей дискуссии но человек продолжает настаивать на своем подходе. Речь идет именно про этот случай.
До такого очень редко доходит.
Я имел ввиду не приходят на исправление. Конечно некоторое время тратится на то, чтобы выяснить в каком компоненте ошибка, да.
Всякое, конечно, бывает. Но, с моей точки зрения, попытаться хотя бы стоит.
А как тогда баги к нему потом приходят?