В обязанности PM входит преодоление всех видов трудностей связанных с проектом (входит ли проедоление искусственно создаваемых трудностей — неизвестно).
Да и для карьеры, в некоторых сценариях, может быть не очень хорошо.
Но это совершенно не аргумент: зачем оставаться программистам.
В обязанности прогрраммиста (QA, DevOp, вообще любого технического спеца) не входит устранение искусственно созданных управленцами трудностей.
А нервы, при такой работе, тратятся.
Если прочитать эксперимент с воронкой, то становится ясно, что пользователю предоставляются инструменты для компенсации направленных искажений (при этом инструменты весьма кривые, как мне кажется), и применяются к случайному процессу.
Как-то не очень впечатляют такие «доказательства».
Я не очень основной посыл (я бы даже сказал пафос) статьи.
В первой же строчке нам обещают разобраться в скорости работы смартфона исходя из скорости работы «жёсткого диска»?
Но в типовом сценарии (сёрфинг в интернете или прохождение одного уровня игрушки) — это явно не первый фактор.
аджайл плох не сам по себе (более того он хорош), плохо когда методологией и процедурой подменяют то, разумное что в основу методологии положено.
аджайл же утверждает (по существу, а не по форме), то, что разработчики сложных систем и так знают: в достаточно сложном проекте нереально предсказать как сложности внедрения (и раскорячивания архитектуры), так и результаты после внедрения (думали ускоримся в 2 раза, а оказалось bottleneck в другом месте) практически никакой сложной фичи.
Поэтому фичи надо внедрять настолько маленькие, насколько это вообще возможно, и по результатам внедрения микро-фичи каждый раз принимать обоснованное решение куда двигаться дальше.
Как достаточно пытливый читатель уже догадался, а для остальных наша фирма предлагает методиста всего по 1000$ \ день.
Так вот, когда сосредотачиваются на формальном соблюдении «неформальных процедур аджайла», а не на сути «не нужно больших фич, занимайтесь continious integration» и возникают проблемы.
Для принятия управленчиских решений (decision, часто в условиях принципиальной неполноты информации) наиболее полезные инструменты:
— личная встреча
— созвон
— issue в PM-application.
Для техничесого решения какого-то вопроса полезность инструментов
— issue в PM-application
— личная встреча (с объяснением) / созвон.
*) есть пара исключений:
— во-первых нужен минимум неопределённости.
— во-вторых обсуждение не должно быть «лекцией» или «семинаром» — тут наверное полезнее (по затраченному времени) личная встреча.
Плохо, когда инструменты полезные для принятия управленчиских решения используют для решения технических вопросов.
Вообще примеры типа приведённого в статье «варения борща» ужасны для программирования.
Приведённый вами пример (для удалённого доступа) просто очень неудачен для FP, кмк (для Haskell в частности). Потому, как само по себе ФП очень тяжело ложиться на низкоуровневые вещи (хотя бы потому, что любое обращение к аппаратуре — IO, т.е. завёрнуто в свой слой монадок).
Я бы, на самом деле предпочёл цепочку вычислений из «открыть файл» -> прочитать строки -> преобразовать каждую строку -> вывести.
Всё это завёрнуто в Maybe. Тогда и «бойлерплейта» обслуживающего плохие случаи не будет.
>> Если бы вы сказали, «монады — это абстракция над вычислениями в контексте, независимая от вычислителя», а потом добавили, что мол «на практике сама абстракция не нужна…
Извините мне вот стало „легко и понятно“, когда я для себя понял что зачем монада — это просто такой способ разделить вычисления над значениями и `контекст` доставшийся от предыдущих вычислений.
При этом: „монада это просто такой способ“ — тут слово просто обманчиво, поскольку в него запихали много чего, позволяющие получать интуитивно понятный результат при цепочках вычислений, и использовать IO как `контекст`(и наверняка вы добавите много чего ещё в это „просто“).
Так вот вопрос: интуитивно-удобное для меня понимание довольно близко к тому, с чем вы могли бы поспорить. Есть какая-то конкретная проблема в этом (удобном для меня) понимании?
Не первый раз вижу попытки «просто объяснить ФП».
И место с монадами — во многих таких статьях описывается похоже и откровенно вводит в заблуждение (я читал похожее, когда ещё не знал ФП, меня обманули тогда и обманули бы вы сейчас).
Я бы хотел, чтобы 6 месяцев назад мне объяснили как-то так (если бы мог объяснить сам — написал бы статью):
1. Есть функциональная парадигма (с чистыми ф-иями и иммутабельными данными. Даст она вам то-то и то-то). В промышленных языках давно поддерживается её имитация (map, reduce, lampda....)
2. Сама по себе функциональная парадигма «вычислительно слабее». Для удобства, краткости кода (и для того, чтобы хоть частично компенсировать «отставание вычислительных возможностей» ФП) прямо-таки напрашиваются вот такие улучшения: ВФП, lambda, Curring. А также вот такие: Functor, Applicative, Monad.
3. Функтор, это просто контейнер (функтор уже контейнер, умеющий помещать в себя значения, да!)
Монада — это тоже контейнер. Зачем нам «ещё контейнер» — у монады можно реализовать достаточно сильную логику, отдельно для обработки элементов, а отдельно для контейнера.
Пример? Пожалуйста? Цепочка вычислений на Maybe (когда нам не нужен «бойлерплейт» код для плохих случаев). Хорошо переписывается с поддержкой логов в виде монады Writer.
>> Если будет интересно, скажите, я внизу добавлю список ресурсов, которые местные преподаватели активно используют для обучения. Некоторые из них очень неплохие.
Да пожалуйста добавьте.
Как раз хочу подтянуть английский до уровня выше, чем «читать мануалы по своему профилю».
Мне видится, что в таком случае наиболее востребованной частью математики будет «составление приближённых моделей».
Поскольку хоть вальфрам альфа и лучше получает решения сформулированных выражений (хотя иногда численно), но вот проконтролировать, что «решение уравнений» и «решение исходной задачи» это одно и то же должен именно человек.
И тут уже должен быть навык понять «туда ли мы идём вместе с компьютером».
>> Я бы послушал интервью с каким-нибудь политиканом. В идеале — с Яровой, Луговым и прочими клишасами.
Ну было же интервью Яровой Познеру. Посмотрите.
ПС
Хотя если резюмировать личные впечатления, то одно из самых слабых (я бы даже сказал провальное) интервью Познера. Как говорится «к такому его жизнь не готовила».
Ох как тяжело, с этими статьями на Хабре (хотел расширить кругозор, а теперь ничего не понимаю).
Вот пол-месяца назад я думал, что почти разобрался с Haskell.
Потом прочитал 4 «лонгрида», с обсуждениями call\cc и продолжениями и связей с монадами и перестал что-либо понимать (окончательно?).
Объясните пожалуйста если кто-то найдёт в себе силы и время.
Попробую по-порядку: I. Вот моё представление о Haskell (до прочтения заумных комментариев на хабре):
0. Expressions (в смысле ссылочно-прозрачные функции) это хорошо при прочих равных.
Но:
1. «statement» часто обладает более насыщенной семантикой, чем «expressions» (сравните изменение элемента дерева в Haskell с императивом. А изменение 1го узла графа!?).
2. Чтобы FP-программы не оказались многословнее потребовались способы «более сильной» комбинации выражений, в сравнении с промышленными языками
3. Вот «из-за 1 и 2» и ввели такие понятия, как аппликативные функторы и монады (монады, также, оказались удобны для сокрытия внутри IO, почему так — надо разобраться (*)).
Это было очень удобно, хотя и оставались «мелкие» вопросы, с которыми оставалось разобраться:
I.a. Правда ли, что "<-" из do-нотации «невыразима без do-нотации сама по себе» (хотя любые законченные функции в do-нотации могут быть альтернативно выражены через комбинирование).
I.b В какой именно момент происходят вычисления монадических функций (как сами значения, так и эффекты)?
I.b.ii Для монады IO применяется общее правило про время вычисления функций (с учётом зависимости по данным через «переменную RealWorld») или нет?
Это примерно моё представление о Хаскель 2 недели назад оно «не бесповоротно неправильное»?
Можно же чуть-чуть доразобраться и идти дальше?
II. Вот пришло время разобраться почему: «монады, а не аппликативные функторы?», «IO как монады, а не отдельный механизм», а также «I.a, I.b, I.b.ii»,
Прочитал 4 больших статьи на хабре с обсуждением и зарубами специалистов по ФП на 200+ комментариев, несколько статей со ссылками на новые понятия…
Итак я узнал (spoiler: и офигел понял что ничего не понял):
II.a do-нотация зачастую многословнее, чем комбинирование через >>=. Но писать надо всё равно через do (а не вырабатывать интуицию «функционального подхода» на >>=), — я думал ровно наоборот
II.b монады это «просто» реализация паттерна call/cc, — это вообще как? Ну т.е. что такое паттерн call/cc я прочитал (передаём функцию «досрочного» возврата в лямбду).
II.c монады реализуют ту же семантику, что и async\await, — тут я опять ничего не понял. Какое это имеет отношение, к ФП или Хаскелю (кроме исторически-дизайнерского legacy)? Чистые же функции с ленивыми вычислениями и так распараллелены по данным? Зачем нам мыслить категориями async\await?
II.d IO через монады это сознательный дизайн хаскеля, — но зачем!? Это же IO надо связать в последовательность, для этого надо между IO-вызовами передавать «скрытую переменную RealWorld». Неужели такое дизайнерское решение чем-то хорошо, я вот СОВЕРШЕННО не понимаю чем (эти «кишки элементов реализации наружу» мне какие-то лабораторные опытные образцы напоминают).
Резюмируя: знающие товарищи (если у вас найдётся на это время):
— поправьте меня, если я совсем не прав в своих предварительных представлениях (I.1 — I.4).
— если же мои предварительные представления о ФП «не совсем неправильные»:
— объясните как сделано — I.a — I.c
— а также какое отношение «II.a — II.d» имеет к действительности и зачем сделано именно так.
ПС
Извините за сумбур, если я недоразобрался.
Спасибо за внимание, если прочитали, и за внимание и потраченное время, если найдёте время и силы ответить!
У вас тут такой интересный разговор, а можно ссылочку (для базового уровня, лучше на русском, чем нет), что такое cps.
Ну и сразу что есть «эффекты», что «продолжения».
В обязанности PM входит преодоление всех видов трудностей связанных с проектом (входит ли проедоление искусственно создаваемых трудностей — неизвестно).
Да и для карьеры, в некоторых сценариях, может быть не очень хорошо.
Но это совершенно не аргумент: зачем оставаться программистам.
В обязанности прогрраммиста (QA, DevOp, вообще любого технического спеца) не входит устранение искусственно созданных управленцами трудностей.
А нервы, при такой работе, тратятся.
Если прочитать эксперимент с воронкой, то становится ясно, что пользователю предоставляются инструменты для компенсации направленных искажений (при этом инструменты весьма кривые, как мне кажется), и применяются к случайному процессу.
Как-то не очень впечатляют такие «доказательства».
В первой же строчке нам обещают разобраться в скорости работы смартфона исходя из скорости работы «жёсткого диска»?
Но в типовом сценарии (сёрфинг в интернете или прохождение одного уровня игрушки) — это явно не первый фактор.
аджайл же утверждает (по существу, а не по форме), то, что разработчики сложных систем и так знают: в достаточно сложном проекте нереально предсказать как сложности внедрения (и раскорячивания архитектуры), так и результаты после внедрения (думали ускоримся в 2 раза, а оказалось bottleneck в другом месте) практически никакой сложной фичи.
Поэтому фичи надо внедрять настолько маленькие, насколько это вообще возможно, и по результатам внедрения микро-фичи каждый раз принимать обоснованное решение куда двигаться дальше.
Как достаточно пытливый читатель уже догадался, а для остальных наша фирма предлагает методиста всего по 1000$ \ день.
Так вот, когда сосредотачиваются на формальном соблюдении «неформальных процедур аджайла», а не на сути «не нужно больших фич, занимайтесь continious integration» и возникают проблемы.
Почитать первоисточник.
— личная встреча
— созвон
— issue в PM-application.
Для техничесого решения какого-то вопроса полезность инструментов
— issue в PM-application
— личная встреча (с объяснением) / созвон.
*) есть пара исключений:
— во-первых нужен минимум неопределённости.
— во-вторых обсуждение не должно быть «лекцией» или «семинаром» — тут наверное полезнее (по затраченному времени) личная встреча.
Плохо, когда инструменты полезные для принятия управленчиских решения используют для решения технических вопросов.
А как она у вас организована?
Переносимые ссылки или указатели? Stop the World есть?
Вообще примеры типа приведённого в статье «варения борща» ужасны для программирования.
Приведённый вами пример (для удалённого доступа) просто очень неудачен для FP, кмк (для Haskell в частности). Потому, как само по себе ФП очень тяжело ложиться на низкоуровневые вещи (хотя бы потому, что любое обращение к аппаратуре — IO, т.е. завёрнуто в свой слой монадок).
Я бы, на самом деле предпочёл цепочку вычислений из «открыть файл» -> прочитать строки -> преобразовать каждую строку -> вывести.
Всё это завёрнуто в Maybe. Тогда и «бойлерплейта» обслуживающего плохие случаи не будет.
Извините мне вот стало „легко и понятно“, когда я для себя понял
чтозачем монада — это просто такой способ разделить вычисления над значениями и `контекст` доставшийся от предыдущих вычислений.При этом: „монада это просто такой способ“ — тут слово просто обманчиво, поскольку в него запихали много чего, позволяющие получать интуитивно понятный результат при цепочках вычислений, и использовать IO как `контекст`(и наверняка вы добавите много чего ещё в это „просто“).
Так вот вопрос: интуитивно-удобное для меня понимание довольно близко к тому, с чем вы могли бы поспорить. Есть какая-то конкретная проблема в этом (удобном для меня) понимании?
И место с монадами — во многих таких статьях описывается похоже и откровенно вводит в заблуждение (я читал похожее, когда ещё не знал ФП, меня обманули тогда и обманули бы вы сейчас).
Я бы хотел, чтобы 6 месяцев назад мне объяснили как-то так (если бы мог объяснить сам — написал бы статью):
1. Есть функциональная парадигма (с чистыми ф-иями и иммутабельными данными. Даст она вам то-то и то-то). В промышленных языках давно поддерживается её имитация (map, reduce, lampda....)
2. Сама по себе функциональная парадигма «вычислительно слабее». Для удобства, краткости кода (и для того, чтобы хоть частично компенсировать «отставание вычислительных возможностей» ФП) прямо-таки напрашиваются вот такие улучшения: ВФП, lambda, Curring. А также вот такие: Functor, Applicative, Monad.
3. Функтор, это просто контейнер (функтор уже контейнер, умеющий помещать в себя значения, да!)
Монада — это тоже контейнер. Зачем нам «ещё контейнер» — у монады можно реализовать достаточно сильную логику, отдельно для обработки элементов, а отдельно для контейнера.
Пример? Пожалуйста? Цепочка вычислений на Maybe (когда нам не нужен «бойлерплейт» код для плохих случаев). Хорошо переписывается с поддержкой логов в виде монады Writer.
Да пожалуйста добавьте.
Как раз хочу подтянуть английский до уровня выше, чем «читать мануалы по своему профилю».
Поскольку хоть вальфрам альфа и лучше получает решения сформулированных выражений (хотя иногда численно), но вот проконтролировать, что «решение уравнений» и «решение исходной задачи» это одно и то же должен именно человек.
И тут уже должен быть навык понять «туда ли мы идём вместе с компьютером».
Ну было же интервью Яровой Познеру. Посмотрите.
ПС
Хотя если резюмировать личные впечатления, то одно из самых слабых (я бы даже сказал провальное) интервью Познера. Как говорится «к такому его жизнь не готовила».
Вот пол-месяца назад я думал, что почти разобрался с Haskell.
Потом прочитал 4 «лонгрида», с обсуждениями call\cc и продолжениями и связей с монадами и перестал что-либо понимать (окончательно?).
Объясните пожалуйста если кто-то найдёт в себе силы и время.
Попробую по-порядку:
I. Вот моё представление о Haskell (до прочтения заумных комментариев на хабре):
0. Expressions (в смысле ссылочно-прозрачные функции) это хорошо при прочих равных.
Но:
1. «statement» часто обладает более насыщенной семантикой, чем «expressions» (сравните изменение элемента дерева в Haskell с императивом. А изменение 1го узла графа!?).
2. Чтобы FP-программы не оказались многословнее потребовались способы «более сильной» комбинации выражений, в сравнении с промышленными языками
3. Вот «из-за 1 и 2» и ввели такие понятия, как аппликативные функторы и монады (монады, также, оказались удобны для сокрытия внутри IO, почему так — надо разобраться (*)).
Это было очень удобно, хотя и оставались «мелкие» вопросы, с которыми оставалось разобраться:
I.a. Правда ли, что "<-" из do-нотации «невыразима без do-нотации сама по себе» (хотя любые законченные функции в do-нотации могут быть альтернативно выражены через комбинирование).
I.b В какой именно момент происходят вычисления монадических функций (как сами значения, так и эффекты)?
I.b.ii Для монады IO применяется общее правило про время вычисления функций (с учётом зависимости по данным через «переменную RealWorld») или нет?
Это примерно моё представление о Хаскель 2 недели назад оно «не бесповоротно неправильное»?
Можно же чуть-чуть доразобраться и идти дальше?
II.
Вот пришло время разобраться почему: «монады, а не аппликативные функторы?», «IO как монады, а не отдельный механизм», а также «I.a, I.b, I.b.ii»,
Прочитал 4 больших статьи на хабре с обсуждением и зарубами специалистов по ФП на 200+ комментариев, несколько статей со ссылками на новые понятия…
Итак я узнал (spoiler:
и офигелпонял что ничего не понял):II.a do-нотация зачастую многословнее, чем комбинирование через >>=. Но писать надо всё равно через do (а не вырабатывать интуицию «функционального подхода» на >>=), — я думал ровно наоборот
II.b монады это «просто» реализация паттерна call/cc, — это вообще как? Ну т.е. что такое паттерн call/cc я прочитал (передаём функцию «досрочного» возврата в лямбду).
II.c монады реализуют ту же семантику, что и async\await, — тут я опять ничего не понял. Какое это имеет отношение, к ФП или Хаскелю (кроме исторически-дизайнерского legacy)? Чистые же функции с ленивыми вычислениями и так распараллелены по данным? Зачем нам мыслить категориями async\await?
II.d IO через монады это сознательный дизайн хаскеля, — но зачем!? Это же IO надо связать в последовательность, для этого надо между IO-вызовами передавать «скрытую переменную RealWorld». Неужели такое дизайнерское решение чем-то хорошо, я вот СОВЕРШЕННО не понимаю чем (эти «кишки элементов реализации наружу» мне какие-то лабораторные опытные образцы напоминают).
Резюмируя: знающие товарищи (если у вас найдётся на это время):
— поправьте меня, если я совсем не прав в своих предварительных представлениях (I.1 — I.4).
— если же мои предварительные представления о ФП «не совсем неправильные»:
— объясните как сделано — I.a — I.c
— а также какое отношение «II.a — II.d» имеет к действительности и зачем сделано именно так.
ПС
Извините за сумбур, если я недоразобрался.
Спасибо за внимание, если прочитали, и за внимание и потраченное время, если найдёте время и силы ответить!
Со всего что выше — платится 10%. И это, как бы лучше выразиться, благотворительность.
Про продолжения и call/cc нашёл статью достаточно начального для меня уровня на русском (перевод):
fprog.ru/lib/ferguson-dwight-call-cc-patterns
Про cps-преобразование, эффекты (и почему монады это упрощённое call/cc) вопросы однако остались.
Ну и сразу что есть «эффекты», что «продолжения».