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

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

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

Flat | Top-Level Comments Only

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

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

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

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

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

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

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

Решение чего? Ленивости по умолчанию? Так это фича Хаскела.

А выедание памяти санками случается когда обрабатывается поток данных, собственно как с этим бороться всем давно известно.

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

Ок, доказывай на прмерах. И хочется услышать про правильный дизайн ленивости по умолчанию.

Такие вещи нельзя делать по умолчанию. Только явно. Пример более внятного дизайна: Scala.

Ну ахуеть, ты эксперт. Вот сказал - низя и неебёт. Муллы свинину есть запрещают, так що менi сало не їсти?

Edited 2015-07-10 18:36 (UTC)

Как говорится, ИМХО (имею мнение, хрен оспоришь).

В Scala задолбаешься делать лениво.

С хаскельными привычками - возможно. Но на порядок человечнее, чем в Хаскеле, где задолбаешься сделать энергично.

Я редко так выражаюсь, но тем не менее: хера там! Ибо задолбало читать одно и тоже, особенно от людей, которые должны были бы знать лучше.

Я как-то писал пост про внедрение ленивых и энергичных вычислений в, соответственно, энергичные и ленивые языки.

В ленивом языке всё остаётся как есть, только в некоторых местах надо поставить $! или !.

В энергичном языке надо заново переписать всю необходимую библиотеку, поскольку чуть упустив энергичность (оставив энергичный map, например, по любому параметру), мы теряем лень всюду.

Или, зайдя с теоретической стороны: если значение может быть вычислено в call-by-value, оно может быть вычислено и в call-by-need, обратное неверно.

(no subject)

justy-tylor.livejournal.com - 2015-07-12 11:38 (UTC) - Expand

(no subject)

thesz.livejournal.com - 2015-07-12 16:33 (UTC) - Expand

Человечнее это как?

В Haskell сделать энергично можно сверху, не влезая в потроха библиотеки. Сделать же ленивой работу с ленивой структурой в энергичной библиотеке практически невозможно.

(no subject)

justy-tylor.livejournal.com - 2015-07-14 12:27 (UTC) - Expand

(no subject)

lomeo.livejournal.com - 2015-07-15 07:25 (UTC) - Expand

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

"авгиевы конюшни на 5 строк".

сейчас ты снова как подросток говоришь. очень глупо выглядит.

Не соглашусь. Профайлера утечек памяти из-за ленивости у хаскеля, насколько я знаю, до сих пор приличного нету. Имеющиеся режимы профайлинга памяти почти совсем не помогают, а только слегка намекают. В C#, Java, даже C++, по крайней мере по моему опыту, такого не бывает: если у программы есть проблема, то прикладываешь профайлер (памяти ли, процессора ли) и проблема как на ладони, осталось только пофиксить. Профайлеры памяти у Java и C#, типа YourKit, вообще невероятно мощные, хаскелю до этого расти десятки лет.
Для меня это перекрывает бойлерплейт, и при всей моей любви к хаскелю в серьезном проекте я его использовать не хотел бы именно из-за того, что если что-то пойдет не так, то будет кирдык, особенно если программа напичкана какими-нибудь абстракциями высшего порядка. Профайлер скажет что-нибудь вроде "так у вас списки текут!" и приехали.
Когда сделают приличный профайлер или расширение системы типов, решающее такие проблемы, пересмотрю.

Я таки юзал YourKitd на F#-пе (охуенная вещь!) и могу это всё понять, но вы не совсем правы. Профайлер кучи, встроенный в Haskell Platform, на самом деле очень классный. Там есть все нужные группировки потребления - по центрам затрат, по типам, по модулям, по замыканием и плюс ещё пяток. Проблема с хаскель-профиоированием такая же как, и с почти любым софтом, разработанным изначально под линуксы - говёный front-end. Профайлер просто создаёт двоичный файл с расширением hp, который потом можно перевести в PostScript. Конечно такие костыли омерзительны и очень бесят. Для результатов профилирования надо интерактивные фильтры с удобной навигацией, графики и всё такое, а этого в хаскеле нет. У меня уже давно есть желание сделать на WPF утилиту вместо уёбищной hp2ps, но всё лень

Edited 2015-07-11 21:42 (UTC)

Вот вы это кому другому рассказывайте, пардоньте.

В отчёте профиля ghc RTS я нахожу проблемное место прямым глазением в подобие дерева в текстовом виде. Часто даже этого не надо, пяток самых тяжёлых функций наверху мне услужливо привели. В отчёте VS 2012 я, если специально не указал нужный модуль в качестве единственного, вообще ничего найти не могу. А если указал, то мне надо сделать десять раскрытий дерева и всё равно можно промахнуться. Например, две функции занимают, примерно, по 20%, но в одной десять вызово по 2%, а в другой, чуть ниже, есть горячий вызов в 18%. И вот ты сидишь, и пялишься на этот тупой список в 10 вызовов.

(не говоря уж о том, что оптимизиррованный код оставляет new промежуточных данных!!!)

В VS я вообще почти на ощупь работаю. Удивительно ущербная система, от тестирования (smallcheck? хаха!) до отладки (eventlog? хаха!).

Какой еще eventlog, log4net или NLog наверно надо :)

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

Я помню, что https://github.com/jkff/timeplot/commit/5eba586188e0767c1cf59bc43c45d71ea7e73752 или какой-то похожий коммит у меня занял несколько дней, т.к. профайлер показывал мне какую-то бесполезную бурду (я уже не помню - может, стеки cost centres тогда не умел показывать?), и мне пришлось написать https://hackage.haskell.org/package/htrace, чтобы найти утечку. Возможно, с тех пор ситуация улучшилась - надо будет попробовать откатиться до того коммита и посмотреть, что мне покажет сегодняшний профайлер памяти.

В идеале, я бы хотел видеть профайл количества живых санков и занимаемых ими байтов, разбитый по стекам cost centres, так же как для профайлинга производительности. Такое уже есть?

(Профайлером VS я не пользовался, но в YourKit у меня, кажется, описываемых проблем не было.)

У меня не настолько длинные строки, тем не менее, код структурирован примерно так же.

Я тут недавно баловался профилированием, проблем с поиском проблемных мест не было. Были трудности, как исправить.

Мой анекдот против вашего анекдота.

Насчёт "такое уже есть" это вам лучше самому проверить. Мне хватает отчёта +RTS -p. Дерево вызовов там точно есть, с суммарной и отдельными стоимостями.

На всякий случай - функционал +RTS -p не менялся вот уже лет восемь, думаю.

Flat | Top-Level Comments Only