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

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

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

Flat | Top-Level Comments Only

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таким образом, те, кому нужна именно хаскелеподобная ленивость, могут себя ею обеспечить. Не беспокоя остальных лишней когнитивной нагрузкой ("думать санками") и дополнительными расходами на отладку "недовычисленности".

(no subject)

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

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

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

Уже отвечал thesz. Для любых вычислений приходится писать свои библиотеки. Усложнять жизнь всем ради поклонников ленивости нет смысла.

Edited 2015-07-14 12:27 (UTC)

(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