Там определение чистой функции а не чистой программы.
У нас есть ваше определение
Функциональная программа — программа, состоящая из чистых функций.
По которому не понятно, что значит "состоящей из" и вот например из википедии
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
маловероятно, что такой автор сразу заметит и исправит все ошибки
Если ошибки следствие какого-то подхода, про который уже был комментарий, что что он не самый подходящий и замена на более подходящий его исправят это просто аргумент в дальнейшей дискуссии но человек продолжает настаивать на своем подходе. Речь идет именно про этот случай.
До такого очень редко доходит.
Для смежных компонент это нормальная ситуация, что спрашивают и других людей
Я имел ввиду не приходят на исправление. Конечно некоторое время тратится на то, чтобы выяснить в каком компоненте ошибка, да.
Тут мне не очень понятно, как одновременно вы не ответственны за проект и вам приходят багрепорты на него.
Очень просто: в проект, за который я отвечаю пытались продавить дерьмо — как обычно через «толерантность» и «нетоксичность». Дерьмо я принял, но сказал, что этот вот компонент — он, теперь, не мой.
То есть получается, что на самом деле вы изначально вы отвечали за этот код, и определение -1 изначально не подходило, просто вы сделали так, чтобы, во-первых, неподходящий подход туда попал, во-вторых в дальнейшем не отвечать за него.
От меня такого комментария вряд ли можно услышать
Я так и не понял, что вы подразумеваете под "называть дерьмо дерьмом". Вы так и пишете или говорите слово "дерьмо" или формулируете в других терминах. Или вы указание на конкретную ошибку называете "называть дерьмо дерьмом".
Потому что кончается всё вот этим
Тут мне непонятно, какая причинно следственная связь, почему, если порекомендовать какой-то способ исправления вы будете исправлять косяки а если не порекомендовать, то не будете. С моей точки зрения, во втором случае меньше шанс получения косяков.
Я обычно в таком случае подробно объясняю почему именно я хочу другой подход, желательно со ссылками на какие-то авторитетные источники, потом переключаюсь в режим когда последущий апдейт код ревью должен стоить больше автору чем мне. Например, находить один косяк за апдейт и репортить его и прекращать дальнейшее ревью на этом. После какого-то количества итераций или я говорю с начальником или автор код ревью и мы аргументируем свою позицию.
Если указана возможность переделки, то начальство обычно на моей стороне, а если говорить "Тут все плохо, но я не знаю, как хорошо", то тут сложнее потому, что непонятно, что делать.
Это если речь идет про что-то чем владеет команда, в которую я вхожу. Если этим владеет другая команда, то мой голос совещательный, но и баги ко мне не приходят.
don’t like the change, but also aren’t responsible for the project long-term
Тут мне не очень понятно, как одновременно вы не ответственны за проект и вам приходят багрепорты на него.
Этот вопрос задаёт мне человек, который считает, что называть дерьмо дерьмом — это токсичо и нужно делать намёки? Ну я наделал намёков…
Тут мне непонятно, каким образом из не называния дерьма дерьмом следует что намеки надо делать вообще всегда. Вроде, можно не называя дерьмо дерьмом явно указать способы разрешения проблемы нет?
Хотелось бы, также, уточнить что именно вы подразумеваете под "называть дерьмо дерьмом".
Какие фразы подходят под это:
"Этот код — дерьмо"
"Этот код ненадлежащего качества"
"Вот тут вот такая ошибка. Я думаю, использование X в целом приводит к появлению ошибок такого типа. Рассмотрите, пожалуйста, возможность применить подход Y по такой-то и такой-то причине."
Вариант 3 я считаю приемлемым.
Если я правильно понял, на практике вы намерено сформулировали все так, что человек не понял, что повлекло добавление в продукт большого количества ошибок. При этом вы сами устали от большого колочиства апдейтов код ревью.
А какое было конструктивное замечание при ревью? Если вы давали специально непонятные подсказки как автор мог не залить этот код? Как он мог понять, что ему делать ?
А в каком-нибудь понимании есть?
Это иллюстрация того, что можно сделать с чистой функцией. А что можно сделать с чистой программой, что нельзя сделать с нечистой?
Есть ли у вас какой-то термин для программы, которая состоит только из вызовов чистых функций?
Там определение чистой функции а не чистой программы.
У нас есть ваше определение
По которому не понятно, что значит "состоящей из" и вот например из википедии
Если под "состоящей из" понимать что там должны быть только определения чистых функций, то непонятно, как им пользоваться. Программа может состоять из одной гигантской чистой функции реализация которой написана императивно и с ее логикой нельзя будет обращаться как композицией чистых функций — распараллеливать автоматически и так далее.
Неважно для того, кто вызывает эту функцию, или для программиста который пишет/меняет ее тело?
Там про то, почему функция чистая, а не почему программа чисто функциональна. С первым пунктом у меня та же точка зрения, а со вторым нет.
В программе нет никого, кто использует функцию (т.е. принимает за черный ящик), а, наоборот, есть определение и реализация. Реализация определена не только через чистые функции, => программа не является чисто функциональной, хотя функция является.
Возможно, какая-то другая программа, которая бы вызывала эту функцию была бы чисто функциональной.
Итого у нас есть чистая функция с нечистым телом. Ни одного вызова чистой функции в программе нет. Считается ли вся программа чистой в данном случае?
В данном случае оно не мешает постольку поскольку тело маленькое. Так же как и чистота функции никому не помогает, поскольку ее вызовов нет. Но формально программу нельзя назвать чистой, поскольку она определена не только через чистые функции.
что такое "локальный мутируемый стейт"? До какой степени локальный?
*= совершенно аналогичен функции
acumulator не является локальным состоянием для функции MultuiplyBy но может являться локальным для какого-то скопа сверху.
Мы не можем мемоизировать, авторматически пареллелить и т.д — т.е. не соблюдаются свойства которыми мы сможем воспользоваться для чисто функциональной программы.
Нам не важно пишем ли мы чистые функции или нет, важно пользуемся ли мы только ими или нет.
С моей точки зрения функция, которую вы написали, является чистой, а программа — нет.
А что такое ХКТ — я по быстренькому не нашел?
Как это? Там есть *= которая не является ссылочно-прозрачной. Функционально чистой была бы программа, которая только бы вызывала эту функцию, но не состояла из ее определения. Например, если бы это была чистая программа эксплуатирующая грязный рантайм с чистым интерфейсом.
У того, кто пишет и ревьюэра разный критерий дерьма?
Нарпимер, как я понял, для вас приемлем код похожий на результат обфускации но который работает. А для кого-то, может, наборот — небольшая ошибка — недочет, но если переменные названы непонятно, то дерьмо.
Плохо стучать или хорошо зависит от того, кому стучишь. Если власти в целом плохие, то плохо, если власти хорошие, то хорошо. Соответственно в разных обществах разное отношение.
Даже если учеcть это, зачем специально сообщать путь разрешения проблемы специально непонятно для автора? Почему он не был понятно описан в предыдущих коммуникациях?
Теперь уточнил
С моей точки зрения "как можно раньше" это во время код ревью. Я бы постарался помочь на code review — т.е. дал бы пояснение как исправить как можно понятнее, а не специально так, чтобы он не понял.
Если бы не получилось, то все равно бы исправлял баги, если бы они пришли ко мне, но на ретроспективе бы указал, что неправильный подход был принят, это породило такие-то и такие-то баги, что стоило времени таким-то людям.
Т.е. капал бы на мозги начальству и команде.
khim "Пытался человеку «помочь» (давая ему ровно достаточно подсказок, чтобы они ничерта не понял, но чтобы знающий человек мог это сделать)"
То есть как я понял цель была, чтобы конкретный человек не понял соответственно не исправил косяк, косяк попал к клиенту, потом бы компания тратила время на его исправление, но не сам khim
Если ошибки следствие какого-то подхода, про который уже был комментарий, что что он не самый подходящий и замена на более подходящий его исправят это просто аргумент в дальнейшей дискуссии но человек продолжает настаивать на своем подходе. Речь идет именно про этот случай.
До такого очень редко доходит.
Я имел ввиду не приходят на исправление. Конечно некоторое время тратится на то, чтобы выяснить в каком компоненте ошибка, да.
Всякое, конечно, бывает. Но, с моей точки зрения, попытаться хотя бы стоит.
А как тогда баги к нему потом приходят?
То есть получается, что на самом деле вы изначально вы отвечали за этот код, и определение -1 изначально не подходило, просто вы сделали так, чтобы, во-первых, неподходящий подход туда попал, во-вторых в дальнейшем не отвечать за него.
Я так и не понял, что вы подразумеваете под "называть дерьмо дерьмом". Вы так и пишете или говорите слово "дерьмо" или формулируете в других терминах. Или вы указание на конкретную ошибку называете "называть дерьмо дерьмом".
Тут мне непонятно, какая причинно следственная связь, почему, если порекомендовать какой-то способ исправления вы будете исправлять косяки а если не порекомендовать, то не будете. С моей точки зрения, во втором случае меньше шанс получения косяков.
Я обычно в таком случае подробно объясняю почему именно я хочу другой подход, желательно со ссылками на какие-то авторитетные источники, потом переключаюсь в режим когда последущий апдейт код ревью должен стоить больше автору чем мне. Например, находить один косяк за апдейт и репортить его и прекращать дальнейшее ревью на этом. После какого-то количества итераций или я говорю с начальником или автор код ревью и мы аргументируем свою позицию.
Если указана возможность переделки, то начальство обычно на моей стороне, а если говорить "Тут все плохо, но я не знаю, как хорошо", то тут сложнее потому, что непонятно, что делать.
Это если речь идет про что-то чем владеет команда, в которую я вхожу. Если этим владеет другая команда, то мой голос совещательный, но и баги ко мне не приходят.
Разница между вашим подходом и подходом khim то, что вы предложили как исправить, а он специально сделал так чтобы его не поняли.
Спасибо за ссылку.
Тут мне не очень понятно, как одновременно вы не ответственны за проект и вам приходят багрепорты на него.
Тут мне непонятно, каким образом из не называния дерьма дерьмом следует что намеки надо делать вообще всегда. Вроде, можно не называя дерьмо дерьмом явно указать способы разрешения проблемы нет?
Хотелось бы, также, уточнить что именно вы подразумеваете под "называть дерьмо дерьмом".
Какие фразы подходят под это:
Вариант 3 я считаю приемлемым.
Если я правильно понял, на практике вы намерено сформулировали все так, что человек не понял, что повлекло добавление в продукт большого количества ошибок. При этом вы сами устали от большого колочиства апдейтов код ревью.
А какая у этого была цель?
А какое было конструктивное замечание при ревью? Если вы давали специально непонятные подсказки как автор мог не залить этот код? Как он мог понять, что ему делать ?
Что такое неполно реагирует — перестает быть сложные задачи? Если менеджер уже видит почему он не назначении нему задачи полегче?