Хаскель и среднее арифметическое

[metaclass]

Вот я хаскель использовал только пару раз и практически его не знаю, но в чем проблема с неэнергичным foldl - помню. Про то, что нужны банг-паттерны внутри тупла - краем уха слышал, но не вникал.
Стеб же на эту тему людей, которые слышали звон, да не знают, где он, меня очень сильно огорчает.
Ладно, айсед критикует - он хотя бы писал на этом и понимает, о чем речь идет. А так - это выглядит как "разработчики на клиппере критикуют SQL за то, что теория множеств".

Comments

[plumqqz.livejournal.com]

Вообще если прямой вопрос "это они что, всерьез?" воспринимать как стеб, то я даже не знаю...
Кроме того, если народ не видит того, что если такие простые задачи не очень решаются, требуя при этом специфических знаний (там двадцать человек прособеседовали; где они их брали, интересно?), то это... как-то нехорошо.

[metaclass.livejournal.com]

Хинты для SQL-оптимизатора или умение правильно спроектировать БД, чтобы снизить нагрузку на i/o - тоже видимо нехорошо.

[develop7]

Это Совершенно Другое Дело

[http://users.livejournal.com/_slw/]

ну вот если БД надо проектировать специально, что бы тривиальный последовательный fullscan не тормозил -- то это плохая БД

[os80.livejournal.com]

Ой да ладно... Есть такой замечательный язык PL/SQL. Я уже года четыре людям объясняю, почему у них if не всегда работает (null!), но сам регулярно же наступаю на эти грабли.

[aamonster.livejournal.com]

Учитывая "Avoid Success at All Costs" - огорчаться не следует.

Интереснее другое: пока в обсуждениях я видел всего то ли 1, то ли 2-х человек, для которых правильное решение - очевидно и иначе не написать: "Если хоть чуть-чуть писал на хаскелле, такое делается на автомате, даже на бумаже. Безусловный рефлекс -- аккумулятор (что-то делаем, а результат используется только в конце) -- ставим bang pattern." (c) vshabanov

[dr-cha0s.livejournal.com]

Можешь третьего записать. BTW, Johan Tibbel в своих code covnventions писал, что аккумутяторы должны быть строгими по умолчанию. https://github.com/tibbe/haskell-style-guide/blob/master/haskell-style.md

[aamonster.livejournal.com]

Хорошо. Значит, правильно учить можно, но пока сложно (иначе процент был бы повыше).
Подождём.

Просто если есть стиль, позволяющий избегать таких ошибок, то учить без него - всё равно что учить людей на императивных языках считать факториал рекурсивно. А книжек, которые учат писать сразу в нужном стиле, я пока вроде не видел (UPD: надо снова взяться за Real World Haskell) - видел лишь статьи типа "а давайте посмотрим профайлером и решим, где добавить строгости".

UPD: Хотя, конечно, не так красиво получается. Академический язык, в котором всё лениво и (благодаря этому) единообразно, if и иже с ним - обычные функции, а не специальные формы - это прелесть. Но реальный мир вносит свои коррективы...

[dr-cha0s.livejournal.com]

Ленивость - это особенность. Всё. Как и отсутствие GC в C++.
Я за 2 года написания кода в продакшн на прикол с ленивостью напоролся ли тогда когда передал санк с эксепшеном в другой тред, где не предусматривалась обработка эксепшена. Мой пример конечно не показатель.

[lomeo.livejournal.com]

К сожалению, не всё так просто. vshabanov, конечно, понимал о чём говорил, но фраза звучит так, как будто мы ставим bang над аккумулятором. Это не так — в этом случае у нас просто WHNF, а надо, чтобы энергично считались потроха. Например, в предлагаемой задаче надо ставить bang и над той частью аккумулятора, что собирает сумму, и над той, что считает кол-во элементов.

Да, это действительно "безусловный рефлекс". К сожалению, я не видел этих советов в явном виде в учебниках.

[aamonster.livejournal.com]

Я таки нашёл. В Real World Haskell. Вот только это 20-я, что ли, глава - тогда как такие вещи должны относиться к основам (если, конечно, использовать язык как инструмент, а не как красивую математическую игрушку).

[thesz.livejournal.com]

Хаскель приколен тем, что можно сделать очень много до того, как такие проблемы станут насущными.

Мой опыт (с 1998 года) говорит именно об этом.

[lomeo.livejournal.com]

Интересно, спасибо! К сожалению, я RWH не читал внимательно (пролистал).

[cross-join.livejournal.com]

Как я понимаю, вопрос не в противопоставлении декларативного подхода императивному (сиквел-клиппер), а в состоятельности и вменяемости конкретных реализаций декларативных языков программирования.

[metaclass.livejournal.com]

В таком варианте - возможно. Но проблемы хаскеля, по-моему, не в этом месте.
Просто, когда у людей эбола со всякими node.js, jvm, .net и крестами - на это закрываются глаза. Если же похожие проблемы у хаскеля или скалы - сразу начинается массовая истерика. "Как так можно, язык, оказывается, знать надо, прежде чем писать на нем".

[cross-join.livejournal.com]

Проблемы и неинтуитивные (неарифметические) подходы при подсчете среднего - это гораздо хуже эболы, это какой-то инопланетный вирус, от которого надо срочно избавляться :)
При это SELECT AVG() как бы намекает авторам, что и в деларативном подходе можно делать по-человечески.

[metaclass.livejournal.com]

Да хаскелю надо оптимизатор встроить, по типу SQL в СУБД.
RAM считаем внешней памятью, с дорогим и долгим доступом, кэши проца - дешевыми и на основе этого считаем :)

[vit-r.livejournal.com]

Хаскель не создан для таких примитивных задач. Он - птица высокого полёта.

[justy-tylor.livejournal.com]

Какая разница, если "ленивость по умолчанию" при любом раскладе мощнейшие грабли. Одни это знают из практики, другие просто "жопой чуют", всё ок.

[binf.livejournal.com]

какие грабли? В 99% случаев всё прекрасно работает без fold' и bang patterns. А если обсчитывать гигобайты и не думать о том, как именно fold их сворачивает - так это распиздяйство а не грабли.

[justy-tylor.livejournal.com]

Вот эти проценты "когда всё грохнется" могут зависеть от любых сочетаний версии GHC с фазой луны.

И у разработчика два варианта продолжать. Либо "думать значениями", надеясь на авось пронесёт и фаза сойдётся, либо "думать санками", но при этом когнитивная нагрузка взлетает в небеса, что, в свою очередь, снижает доступные ресурсы на сам процесс программирования и увеличивает вероятность ошибок.

Но есть и третий вариант - никогда не использовать языки с "ленивостью по умолчанию" вне учебного контекста. Самый выгодный.

[dr-cha0s.livejournal.com]

Когда нужно обрабатывать гигабайты, редко берутся ленивые списки. Есть conduits и десяток альтернатив с константной памятью и финализацией.

[binf.livejournal.com]

Вы хотите сказать, что гипотетическая ситуация, когда коллекция тестировалась на мегабайты, а в продакшене стала гигобайтами и обвалила всю систему - это большая редкость для java, c++ или (здесь вписать ваш любимый не ленивый ЯП)? Не соглашусь. Из моей практики: в разы проще отыскать и исправить узкое место профилированием в GHC, чем в C# например. Просто потому что меньше бойлерплейта

[zeit-raffer.livejournal.com]

Во времена, когда про теорию категорий знали только алгебраисты, в профильных журналах печатали рекламу "Клиппер - СУБД для профессионалов!"
Пройдет еще двадцать лет, и критики функционального программирования рассосутся сами собой.

[ww9cb.livejournal.com]

дурачок метакласс, когда напишешь новый бред?