Поскольку комментарий большой, сначала краткий абстракт: 1. Мне нравится Хаскель (он прививает хорошие практики программирования). 2. Хаскель разгромно выигрывает в интернет-статьях и точно так же разгромно проигрывает в широте использования написанного на нём ПО. 3. Ваша реакция на неудобный комментарий "let tree = ..." в жизни тоже надо получать и тут Хаскель уже не будет так разгромно выигрывать: "я взял реальный АПИ, он что дофига математичный?".
Так вот проблема описанная в п.2 - во многом результат вот такой вот реакции (кто говорит о Хаскель недостаточно восторженно - тот враг и ату его).
Q: Мемоизация же нужна только в задаче из "ПС" (с графом) и в той задаче разрушает параллелизм? A: Да нет не разрушает. И вы приводите код для задачи с деревом.
У нас с вами какой-то misunderstanding, о причинах которого я могу только догадываться. Чтобы избежат недоразумений хочу вас заверить что у меня нет цели "атаковать" Хаскель - это хороший язык со своим балансом плюсов и минусов. Хаскель мне реально понравился, после знакомства с ним я прямо заметил места, в которых я стал делать лучшие инженерные решения. Но такие статьи не только воодушевляют на знакомство с Хаскелем, но и порождают нереализованные ожидания после первых десятков часов опробывания.
у меня собственно вопрос а в чем тут будет отличие?
Была 1 строка. Стало 5 строк которые я, (junior в Haskell) читаю не без труда. Я бы написал в 10-15 строк в более простом, менее семантически-насыщенном виде. И после этого вся магия "Хаскелю нужна 1 строка там, где Go 15" исчезла бы.
В качестве примера я взял васмделишное апи которое устроено по базовому рестовому принципу (пресловутый jsonplaceholder.typicode.com). Он дофига математичный? Можете показать пример где АПИ сделано так как вы предлагаете выше?
Задача показать дерево комментариев состоит из 2 частей: 1. Получить структуру дедева комментариев (предложен АПИ 1-к-1 соответствующий: SELECT * FROM xxx WHERE parent_id = *** ) 2. Подставить текст комментариев в структуру (взят API гугла для одноранговых комментов).
Вы упорно пытаетесь решить только задачу №2 (при этом если решить только её, то по-моему соотношение трудозатрат несколько приукрашивается в пользу Haskell).
Полагаю самым простым способом будет просто мемоизировать вызов getChil
Мемоизация же нужна только в задаче из "ПС"? Но мемоизация "в лоб" разрушает параллельность на такой задаче. Соответственно вам нужно будет делать какое-то инженерное решение: - параллельные запросы - последовательное добавление полученных данных в нашу структуру эдакий последовательно-параллельный BFS получается.
Но само такое апи кажется немного странным, кажется так не делают.
Ну в FS то ровно так. Тут более широкий вопрос в том, что есть: - "математичные" (термин не очень чёткий, но надеюсь понятный) задачи - они прям чудо как удобно решаются на Haskell - "нематематичные" задачи - кажется, что для их решения на Haskell из-за ограничений надо потратить больше времени, чем на императивном ЯП. Так вот в туториалах и статьях на Haskell любят решать задачи "математичные", а в реальном Software Engineering мы встречаемся с нематематичными.
После небольшой практики в Haskell эта задача мне видится не совсем честной. Она как раз показывает чуть ли не best case для Haskell.
Вот другая задача (готов поспорить, что она более "честная"): Есть: - корневой комментарий - API для получения всех непосредственных потомков комментария (да это латентное IO -- соответственно хотим распараллелить) Требуется: - нарисовать дерево комментариев начиная с заданного коммента.
Здесь баланс сложности резко сместится Haskell будет всё ещё проще но не настолько.
ПС. А вот в следующей задаче вообще Haskell похоже даст худшее решение: - исходная структура данных представляет собой граф (например File System со ссылками на директории).
Я бы вас малость поправил - автор поста не просто закончил ПТУ, а закончил и имел здесь свой бизнес. Что явно плюс не только в скилах, но и в умении пробиваться, искать варианты, приспосабливаться (во всех смыслах). Примеры с Амазоном и КикСтартером - явно намекают на "не сидение на попе ровно".
По поводу истории "мигранта из средней азии" - ремонт в Мск выходит сейчас около 250к/месяц/человека (прикидки очень примерные, конечно, работает то 1 человек то 4, но очень примерно так).
Хотелось бы почитать. Потому как лет 7 назад видел интересное исследование по США, вывод которого такой: ни наличие уроков, ни успеваемость по предмету финансовая грамотность не коррелирует с более разумным финансовым поведением во взрослом возрасте. Хорошие оценки по математике - коррелируют очень хорошо. Общий вывод, что я для себя сделал: "пичьканье" специализированным знанием детей слабо влияет на поведение во взрослом возрасте.
Опять же у программ сделанных условным Сбером или Мосбиржей (или finam \ aton \ .... тысячи их) есть проблема - волк учит поросят строить домики. А у программ сделанных МинОбр - другая проблема.
У вас есть 2 мысли: 1. Вот мы собираемся делать так (я только за - вполне разумные мысли) 2. Государству тоже неплохо бы двигаться в этом направлении. А вот тут есть очень большие и принципиальные проблемы.
Акцент на профилактику действительно возможен в ценовом диапазоне "выше среднего" (вот у меня семейный депозит в одной из клиник доказательной медицины, после других клиник крайне доволен). Но он практически невозможен в среднем диапазоне, т.к. идёт во благо пациента, но не во благо больницы (это вообще проблема агента и принципала).
И вообще похоже, что две необходимые сегодня задачи: - реализовать "голосование ногами" за лучшие клиники - сместить акцент на профилактику Не могут быть выполнены одновременно (в условиях, когда обычный пациент не обладает знаниями как оценить качество предоставленных ему услуг - и скорее не может обладать, как вы не можете сказать хорошо "под капотом" сделано приложение №3 на вашем телефоне).
Покупаете и готовите куриную грудку. Куда девать (или хранить 2 недели) целофан от неё?
ПС По раздельный сбор вообще интересно: диспоузер занимает весьма много места в угловом шкафу под раковиной, из-за того, что конструктивно его подвинуть поудобнее не получится. В итоге места хватает на диспоузер, фильтр для воды и по мелочи по углам что влезет, так что раздельное ведро без диспоузера вместилось бы , с ним - уже никак.
сначала подгузники. Сейчас упаковка (полиэтилен) от мясных продуктов. Не важно куриная грудка или котлеты: в диспоузер нельзя, даже 12 часов они в квартире не пролежат.
Upd: Если представить (вспомнить) жизнь с супругой до детей - то да штука бы пригодилась. Мусор можно реально было бы выносить раз в 3 дня, а то и реже.
Основная причина - всё равно в ведро набирается пахнущий мусор: - без измельчителя выносишь полное ведро раз\день - с измельчителем выносишь пол-ведра раз\день смысла особого (для семьи с детьми) не нашёл.
Ну тут цимес в том, что мы ищем не по всем возможным задачам (там большинство функций бессмысленные всюду разрывные), а лишь по некоторому подмножеству "разумных" задач (с +/- аналитически выглящящими функциями)
А вот на рузмных задачах эвристики уже имеют смысл
Одно из двух открытий в универе для меня было понятие "модульности" (проговоренное в явном виде) - как вообще основа всех сложных систем.
Поэтому это возможно то место, в котором не стоит гнаться за упрощениями и аналогиями, и описать всё как есть?
Сугубо ИМХО, конечно.
ПС Да большое спасибо за ваш труд. Когда вышло оглавление (предыдущий пост) - я подумал, что оно настолько монументально, что реализации ожидать не стоит. Уже вижу что ошибся. Буду рад продолжению.
ОМГ это надо видеть. Вот так бывает почитаешь Фридмана с Соуэлом и думаешь: сделать у нас договоры найма "at will", упразднив ТК, из-за которого экономика страдает.
А потом такие вот посты возвращают тебя в реальность: как будет на самом деле, учитывая большой дисбаланс ресурсов времени и информации между работником и работодателем.
Обсуждались уже на Хабре подобные договоры. Как я понимаю они составляются примерно так: 1. вы добровольно согласны пройти обучение стоимостью 100500 рублей 2. Оплата обучения в рассрочку, до тех пор пока вы работаете. 3. За каждый отработанный месяц компания (по своей доброй воле) оплачивает за вас 100 рублей обучения.
Итого на момент увольнения вам осталось выплатитиь всего 99400 рублей.
Так вот почему вымерли VLIW-процессоры - потому что нет смысла заставлять работать одновременно все вычислительные цепи, иначе процессор просто сгорит!
Ваш аргумент - думаю он никогда не был основным и сейон где-то во втором десятке причин вымирания VLIW как General Purpose GPU (*). А МЦСТ носится с Эльбрусом потому, что: а) если они покажут реальную ситуацию к ним возникнут очень серьёзные вопросы, вида: "а по чему вы по-существу обманывали раньше, пуская пыль в глаза" (и я бы не назвал их необоснованными). б) Подозреваю, что в текущем виде ядро Эльбруса - это то, что мы как программисты назвали бы legacy. Какие-то поверхностные улучшения они делают, но давно назревшие принципиальные улучшения в системе команд - насколько я помню даже не обсуждаются.
*) Основная причина в том, что VLIW просто хуже - т.к. вы обязаны статически, на этапе компиляции сгенерировать код и выдержать все задержки для любых данных (регистры состояния процессора - будем тоже считать данными). В OoO процессорах - вы просто смотрите готовность аргументов (память \ кэши) и зависимости (например одинаковость \ разность 2х указателей) "здесь и сейчас". Получается НАМНОГО продуктивнее.
Во сколько раз реально больше транзисторов на кв.мм влезает при 3нм по сравнению с 28 например?
Проблема в том, что это число (28^2 / 3^2) вам ничего не даст. Уже сейчас плотность компоновки транзисторов выше, чем возможности теплоотведения. Поэтому растёт не производительность вычислительных цепей, а количество вычислительных цепей для каких-то corner-case (на одной и той же площади IP-блока расположены несколько вычислительных цепей, одновременно из которых работает только одна).
Немного утрируя: ни обращаться к памяти, ни вычислять что-то быстрее вы не сможете, зато сможете добавить наборы инструкций: AVX-1024 и AVX-2048
Поскольку комментарий большой, сначала краткий абстракт:
1. Мне нравится Хаскель (он прививает хорошие практики программирования).
2. Хаскель разгромно выигрывает в интернет-статьях и точно так же разгромно проигрывает в широте использования написанного на нём ПО.
3. Ваша реакция на неудобный комментарий "let tree = ..." в жизни тоже надо получать и тут Хаскель уже не будет так разгромно выигрывать: "я взял реальный АПИ, он что дофига математичный?".
Так вот проблема описанная в п.2 - во многом результат вот такой вот реакции (кто говорит о Хаскель недостаточно восторженно - тот враг и ату его).
==================================================
У нас с вами какой-то misunderstanding, о причинах которого я могу только догадываться. Чтобы избежат недоразумений хочу вас заверить что у меня нет цели "атаковать" Хаскель - это хороший язык со своим балансом плюсов и минусов.
Хаскель мне реально понравился, после знакомства с ним я прямо заметил места, в которых я стал делать лучшие инженерные решения.
Но такие статьи не только воодушевляют на знакомство с Хаскелем, но и порождают нереализованные ожидания после первых десятков часов опробывания.
Была 1 строка.
Стало 5 строк которые я, (junior в Haskell) читаю не без труда.
Я бы написал в 10-15 строк в более простом, менее семантически-насыщенном виде.
И после этого вся магия "Хаскелю нужна 1 строка там, где Go 15" исчезла бы.
Задача показать дерево комментариев состоит из 2 частей:
1. Получить структуру дедева комментариев (предложен АПИ 1-к-1 соответствующий: SELECT * FROM xxx WHERE parent_id = *** )
2. Подставить текст комментариев в структуру (взят API гугла для одноранговых комментов).
Вы упорно пытаетесь решить только задачу №2 (при этом если решить только её, то по-моему соотношение трудозатрат несколько приукрашивается в пользу Haskell).
to del
Мемоизация же нужна только в задаче из "ПС"?
Но мемоизация "в лоб" разрушает параллельность на такой задаче.
Соответственно вам нужно будет делать какое-то инженерное решение:
- параллельные запросы
- последовательное добавление полученных данных в нашу структуру
эдакий последовательно-параллельный BFS получается.
Ну в FS то ровно так.
Тут более широкий вопрос в том, что есть:
- "математичные" (термин не очень чёткий, но надеюсь понятный) задачи - они прям чудо как удобно решаются на Haskell
- "нематематичные" задачи - кажется, что для их решения на Haskell из-за ограничений надо потратить больше времени, чем на императивном ЯП.
Так вот в туториалах и статьях на Haskell любят решать задачи "математичные", а в реальном Software Engineering мы встречаемся с нематематичными.
Извините, а топик всё ещё жив?
После небольшой практики в Haskell эта задача мне видится не совсем честной. Она как раз показывает чуть ли не best case для Haskell.
Вот другая задача (готов поспорить, что она более "честная"):
Есть:
- корневой комментарий
- API для получения всех непосредственных потомков комментария (да это латентное IO -- соответственно хотим распараллелить)
Требуется:
- нарисовать дерево комментариев начиная с заданного коммента.
Здесь баланс сложности резко сместится Haskell будет всё ещё проще но не настолько.
ПС.
А вот в следующей задаче вообще Haskell похоже даст худшее решение:
- исходная структура данных представляет собой граф (например File System со ссылками на директории).
Совершенно верно. Появление гималаев (индифский субконтинент врезался в евразию) привело к появлению пустынь такаламакан и гоби.
До того климат "Монголии" и "западного Китая" был похож на климат Индии, с поправкой на чуть более северные широты.
Вроде "холестериновую еду" оправдали, т.к. холестерин из пищи отвечает за примерно 15% холестерина в крови.
Не нашёл в минусах медикаментозного лечения риск уменьшения собсвенной выработки соответствующих нейромедиаторов организмом.
Неужели тагоко риска нет?
Я бы вас малость поправил - автор поста не просто закончил ПТУ, а закончил и имел здесь свой бизнес. Что явно плюс не только в скилах, но и в умении пробиваться, искать варианты, приспосабливаться (во всех смыслах).
Примеры с Амазоном и КикСтартером - явно намекают на "не сидение на попе ровно".
По поводу истории "мигранта из средней азии" - ремонт в Мск выходит сейчас около 250к/месяц/человека (прикидки очень примерные, конечно, работает то 1 человек то 4, но очень примерно так).
Хотелось бы почитать. Потому как лет 7 назад видел интересное исследование по США, вывод которого такой: ни наличие уроков, ни успеваемость по предмету финансовая грамотность не коррелирует с более разумным финансовым поведением во взрослом возрасте. Хорошие оценки по математике - коррелируют очень хорошо.
Общий вывод, что я для себя сделал: "пичьканье" специализированным знанием детей слабо влияет на поведение во взрослом возрасте.
Опять же у программ сделанных условным Сбером или Мосбиржей (или finam \ aton \ .... тысячи их) есть проблема - волк учит поросят строить домики.
А у программ сделанных МинОбр - другая проблема.
У вас есть 2 мысли:
1. Вот мы собираемся делать так (я только за - вполне разумные мысли)
2. Государству тоже неплохо бы двигаться в этом направлении. А вот тут есть очень большие и принципиальные проблемы.
Акцент на профилактику действительно возможен в ценовом диапазоне "выше среднего" (вот у меня семейный депозит в одной из клиник доказательной медицины, после других клиник крайне доволен).
Но он практически невозможен в среднем диапазоне, т.к. идёт во благо пациента, но не во благо больницы (это вообще проблема агента и принципала).
И вообще похоже, что две необходимые сегодня задачи:
- реализовать "голосование ногами" за лучшие клиники
- сместить акцент на профилактику
Не могут быть выполнены одновременно (в условиях, когда обычный пациент не обладает знаниями как оценить качество предоставленных ему услуг - и скорее не может обладать, как вы не можете сказать хорошо "под капотом" сделано приложение №3 на вашем телефоне).
Покупаете и готовите куриную грудку.
Куда девать (или хранить 2 недели) целофан от неё?
ПС
По раздельный сбор вообще интересно: диспоузер занимает весьма много места в угловом шкафу под раковиной, из-за того, что конструктивно его подвинуть поудобнее не получится.
В итоге места хватает на диспоузер, фильтр для воды и по мелочи по углам что влезет, так что раздельное ведро без диспоузера вместилось бы , с ним - уже никак.
сначала подгузники.
Сейчас упаковка (полиэтилен) от мясных продуктов. Не важно куриная грудка или котлеты: в диспоузер нельзя, даже 12 часов они в квартире не пролежат.
Upd:
Если представить (вспомнить) жизнь с супругой до детей - то да штука бы пригодилась. Мусор можно реально было бы выносить раз в 3 дня, а то и реже.
Мне, если честно, не понравилось.
Основная причина - всё равно в ведро набирается пахнущий мусор:
- без измельчителя выносишь полное ведро раз\день
- с измельчителем выносишь пол-ведра раз\день
смысла особого (для семьи с детьми) не нашёл.
Ну тут цимес в том, что мы ищем не по всем возможным задачам (там большинство функций бессмысленные всюду разрывные), а лишь по некоторому подмножеству "разумных" задач (с +/- аналитически выглящящими функциями)
А вот на рузмных задачах эвристики уже имеют смысл
Одно из двух открытий в универе для меня было понятие "модульности" (проговоренное в явном виде) - как вообще основа всех сложных систем.
Поэтому это возможно то место, в котором не стоит гнаться за упрощениями и аналогиями, и описать всё как есть?
Сугубо ИМХО, конечно.
ПС
Да большое спасибо за ваш труд.
Когда вышло оглавление (предыдущий пост) - я подумал, что оно настолько монументально, что реализации ожидать не стоит. Уже вижу что ошибся.
Буду рад продолжению.
ОМГ это надо видеть.
Вот так бывает почитаешь Фридмана с Соуэлом и думаешь: сделать у нас договоры найма "at will", упразднив ТК, из-за которого экономика страдает.
А потом такие вот посты возвращают тебя в реальность: как будет на самом деле, учитывая большой дисбаланс ресурсов времени и информации между работником и работодателем.
Вот видите вы уже поменяли тезис с "наказывать за увольнение нельзя" на "возможно вторая сторона подошла к оформлению таого договора некорректно".
Более того при таком раскладе уже вам требуется доказывать ничтожность или незаконность договора. В состоянии поиска новой работы.
В общем в реальности всё не так замечательно, как в комменте на хабре.
Обсуждались уже на Хабре подобные договоры.
Как я понимаю они составляются примерно так:
1. вы добровольно согласны пройти обучение стоимостью 100500 рублей
2. Оплата обучения в рассрочку, до тех пор пока вы работаете.
3. За каждый отработанный месяц компания (по своей доброй воле) оплачивает за вас 100 рублей обучения.
Итого на момент увольнения вам осталось выплатитиь всего 99400 рублей.
Честно говоря мне видится сильно по-другому.
Ваш аргумент - думаю он никогда не был основным и сейон где-то во втором десятке причин вымирания VLIW как General Purpose GPU (*).
А МЦСТ носится с Эльбрусом потому, что:
а) если они покажут реальную ситуацию к ним возникнут очень серьёзные вопросы, вида: "а по чему вы по-существу обманывали раньше, пуская пыль в глаза" (и я бы не назвал их необоснованными).
б) Подозреваю, что в текущем виде ядро Эльбруса - это то, что мы как программисты назвали бы legacy. Какие-то поверхностные улучшения они делают, но давно назревшие принципиальные улучшения в системе команд - насколько я помню даже не обсуждаются.
*) Основная причина в том, что VLIW просто хуже - т.к. вы обязаны статически, на этапе компиляции сгенерировать код и выдержать все задержки для любых данных (регистры состояния процессора - будем тоже считать данными).
В OoO процессорах - вы просто смотрите готовность аргументов (память \ кэши) и зависимости (например одинаковость \ разность 2х указателей) "здесь и сейчас". Получается НАМНОГО продуктивнее.
Проблема в том, что это число (28^2 / 3^2) вам ничего не даст.
Уже сейчас плотность компоновки транзисторов выше, чем возможности теплоотведения.
Поэтому растёт не производительность вычислительных цепей, а количество вычислительных цепей для каких-то corner-case (на одной и той же площади IP-блока расположены несколько вычислительных цепей, одновременно из которых работает только одна).
Немного утрируя: ни обращаться к памяти, ни вычислять что-то быстрее вы не сможете, зато сможете добавить наборы инструкций: AVX-1024 и AVX-2048