Ну справедливости ради конекретно этот аргумент «выкидывание целых модулей и компонент» — так себе.
Т.к. функционально это близкий аналог DCE (dead code elimination) в gcc. Что является достаточно быстрой фазой, т.к. требует однократного прохода по коду программы (разумеется в специальном представлении: IR).
Ну вот у меня было (когда в качестве начального этапа освоения языка решил олимпиадные задачки пописать), что построение обычного бинарного дерева на Haskell работало раз в 50 медленнее, чем на С.
Ну и я по времени не укладывался.
ПС
Отдельно хочу заметить, что даже не представляю как в этом случае профилировать программу на Haskell.
А как вообще будет выглядеть 2 монадических поведения?
Из самого очевидного (я не настоящий Хаскелист, просто действительно не очень понимаю насколько Хаскелл даже для небольших утилит подходит): логирование (чтобы можно было разобраться что случилось) и maybe (чтобы не писать всю логику «не получилось»).
Позвольте один насущный вопрос: а как сделать, логирование в функциональном ЯП (прогидывать IO(...) в сигнатуру всех ф-ий — я бы не назвал нормальным решением задачи)?
Это зависит от реализации:
— (L1 хранит вирт.адрес + тэг(и) не устарела ли адресация
— L2 хранит физ-адрес (а значит нужна поддержка разадресации, вложенных каталогов адресов, TLB — вот это всё).
Т.е. это моменты хоть и очень важные — но технические.
И можно сказать, что более детальные, по сравнению с общей направленностью статьи.
1. У вас на картинке есть L0_instruction_cache. Это что?
2. ЕМНИП в статье What any programmer should know about memory было утверждение, что время поиска данных в кэше пропорционально размеру кэша (в кэш-лайнах или в бакэтах, не помню).
Собственно есть два варианта:
— вычислить и обосновать какую-то «справедливую функцию» (тут вот прям выше чуть не нейросетки и ген.алгоритмы советуют).
— устроить аукцион (разумеется правила, гарантирующие «честность» аукциона также следует прописать).
Мне видится, что вариант с аукционом более предпочтительным по двум причинам:
— априорная формула — это «демократия сверху», что вообще не очень хороший вариант
— аукцион более устойчив (т.к. имеет отрицательные обратные связи) к попыткам его «взломать / проабузить KPI» и т.д.
Меня, если честно, очень удивило, что люди критикуют пункт о нестандартной внешности.
В частной жизни розовые волосы естественно не означают, я очень на это надеюсь, какое-то предвзятое отношение к человеку (хотя есть другие «стоп-моменты», поверьте они всегда есть, например неприятный запах, мешающая на рабочем месте музыка и т.д.)
Но традиции делового оборота, они пока другие. И не предполагают на менеджерском уровне «розовых волос».
И как эти «розовые волосы» считываются людьми (естественно не всеми, но значительной частью)?
«Он нарушает неписанные неписанные правила ради розовых волос (разумеется это не важный пункт), что ещё он завтра нарушит? Наверное к нему стоит повнимательнее присмотреться, прежде чем давать ему бОльшую, менеджерскую, ответственность».
В обязанности PM входит преодоление всех видов трудностей связанных с проектом (входит ли проедоление искусственно создаваемых трудностей — неизвестно).
Да и для карьеры, в некоторых сценариях, может быть не очень хорошо.
Но это совершенно не аргумент: зачем оставаться программистам.
В обязанности прогрраммиста (QA, DevOp, вообще любого технического спеца) не входит устранение искусственно созданных управленцами трудностей.
А нервы, при такой работе, тратятся.
Если прочитать эксперимент с воронкой, то становится ясно, что пользователю предоставляются инструменты для компенсации направленных искажений (при этом инструменты весьма кривые, как мне кажется), и применяются к случайному процессу.
Как-то не очень впечатляют такие «доказательства».
Я не очень основной посыл (я бы даже сказал пафос) статьи.
В первой же строчке нам обещают разобраться в скорости работы смартфона исходя из скорости работы «жёсткого диска»?
Но в типовом сценарии (сёрфинг в интернете или прохождение одного уровня игрушки) — это явно не первый фактор.
аджайл плох не сам по себе (более того он хорош), плохо когда методологией и процедурой подменяют то, разумное что в основу методологии положено.
аджайл же утверждает (по существу, а не по форме), то, что разработчики сложных систем и так знают: в достаточно сложном проекте нереально предсказать как сложности внедрения (и раскорячивания архитектуры), так и результаты после внедрения (думали ускоримся в 2 раза, а оказалось bottleneck в другом месте) практически никакой сложной фичи.
Поэтому фичи надо внедрять настолько маленькие, насколько это вообще возможно, и по результатам внедрения микро-фичи каждый раз принимать обоснованное решение куда двигаться дальше.
Как достаточно пытливый читатель уже догадался, а для остальных наша фирма предлагает методиста всего по 1000$ \ день.
Так вот, когда сосредотачиваются на формальном соблюдении «неформальных процедур аджайла», а не на сути «не нужно больших фич, занимайтесь continious integration» и возникают проблемы.
Для принятия управленчиских решений (decision, часто в условиях принципиальной неполноты информации) наиболее полезные инструменты:
— личная встреча
— созвон
— issue в PM-application.
Для техничесого решения какого-то вопроса полезность инструментов
— issue в PM-application
— личная встреча (с объяснением) / созвон.
*) есть пара исключений:
— во-первых нужен минимум неопределённости.
— во-вторых обсуждение не должно быть «лекцией» или «семинаром» — тут наверное полезнее (по затраченному времени) личная встреча.
Плохо, когда инструменты полезные для принятия управленчиских решения используют для решения технических вопросов.
Т.к. функционально это близкий аналог DCE (dead code elimination) в gcc. Что является достаточно быстрой фазой, т.к. требует однократного прохода по коду программы (разумеется в специальном представлении: IR).
Как вы его переведёте?
Ну и я по времени не укладывался.
ПС
Отдельно хочу заметить, что даже не представляю как в этом случае профилировать программу на Haskell.
А как вообще будет выглядеть 2 монадических поведения?
Из самого очевидного (я не настоящий Хаскелист, просто действительно не очень понимаю насколько Хаскелл даже для небольших утилит подходит): логирование (чтобы можно было разобраться что случилось) и maybe (чтобы не писать всю логику «не получилось»).
— (L1 хранит вирт.адрес + тэг(и) не устарела ли адресация
— L2 хранит физ-адрес (а значит нужна поддержка разадресации, вложенных каталогов адресов, TLB — вот это всё).
Т.е. это моменты хоть и очень важные — но технические.
И можно сказать, что более детальные, по сравнению с общей направленностью статьи.
Но есть ряд вопросов:
1. У вас на картинке есть L0_instruction_cache. Это что?
2. ЕМНИП в статье What any programmer should know about memory было утверждение, что время поиска данных в кэше пропорционально размеру кэша (в кэш-лайнах или в бакэтах, не помню).
Как современные L1 кэши делают поиск быстрее?
— вычислить и обосновать какую-то «справедливую функцию» (тут вот прям выше чуть не нейросетки и ген.алгоритмы советуют).
— устроить аукцион (разумеется правила, гарантирующие «честность» аукциона также следует прописать).
Мне видится, что вариант с аукционом более предпочтительным по двум причинам:
— априорная формула — это «демократия сверху», что вообще не очень хороший вариант
— аукцион более устойчив (т.к. имеет отрицательные обратные связи) к попыткам его «взломать / проабузить KPI» и т.д.
А при работе из дома этой вот широкой ниши «обо всём около-рабочем и около-технологическом» сильно не хватает.
В частной жизни розовые волосы естественно не означают, я очень на это надеюсь, какое-то предвзятое отношение к человеку (хотя есть другие «стоп-моменты», поверьте они всегда есть, например неприятный запах, мешающая на рабочем месте музыка и т.д.)
Но традиции делового оборота, они пока другие. И не предполагают на менеджерском уровне «розовых волос».
И как эти «розовые волосы» считываются людьми (естественно не всеми, но значительной частью)?
«Он нарушает неписанные неписанные правила ради розовых волос (разумеется это не важный пункт), что ещё он завтра нарушит? Наверное к нему стоит повнимательнее присмотреться, прежде чем давать ему бОльшую, менеджерскую, ответственность».
В обязанности PM входит преодоление всех видов трудностей связанных с проектом (входит ли проедоление искусственно создаваемых трудностей — неизвестно).
Да и для карьеры, в некоторых сценариях, может быть не очень хорошо.
Но это совершенно не аргумент: зачем оставаться программистам.
В обязанности прогрраммиста (QA, DevOp, вообще любого технического спеца) не входит устранение искусственно созданных управленцами трудностей.
А нервы, при такой работе, тратятся.
Если прочитать эксперимент с воронкой, то становится ясно, что пользователю предоставляются инструменты для компенсации направленных искажений (при этом инструменты весьма кривые, как мне кажется), и применяются к случайному процессу.
Как-то не очень впечатляют такие «доказательства».
В первой же строчке нам обещают разобраться в скорости работы смартфона исходя из скорости работы «жёсткого диска»?
Но в типовом сценарии (сёрфинг в интернете или прохождение одного уровня игрушки) — это явно не первый фактор.
аджайл же утверждает (по существу, а не по форме), то, что разработчики сложных систем и так знают: в достаточно сложном проекте нереально предсказать как сложности внедрения (и раскорячивания архитектуры), так и результаты после внедрения (думали ускоримся в 2 раза, а оказалось bottleneck в другом месте) практически никакой сложной фичи.
Поэтому фичи надо внедрять настолько маленькие, насколько это вообще возможно, и по результатам внедрения микро-фичи каждый раз принимать обоснованное решение куда двигаться дальше.
Как достаточно пытливый читатель уже догадался, а для остальных наша фирма предлагает методиста всего по 1000$ \ день.
Так вот, когда сосредотачиваются на формальном соблюдении «неформальных процедур аджайла», а не на сути «не нужно больших фич, занимайтесь continious integration» и возникают проблемы.
Почитать первоисточник.
— личная встреча
— созвон
— issue в PM-application.
Для техничесого решения какого-то вопроса полезность инструментов
— issue в PM-application
— личная встреча (с объяснением) / созвон.
*) есть пара исключений:
— во-первых нужен минимум неопределённости.
— во-вторых обсуждение не должно быть «лекцией» или «семинаром» — тут наверное полезнее (по затраченному времени) личная встреча.
Плохо, когда инструменты полезные для принятия управленчиских решения используют для решения технических вопросов.
А как она у вас организована?
Переносимые ссылки или указатели? Stop the World есть?