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

[metaclass]

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

Comments

[justy-tylor.livejournal.com]

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

[dr-cha0s.livejournal.com]

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

[justy-tylor.livejournal.com]

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

[ww9cb.livejournal.com]

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

[ww9cb.livejournal.com]

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

[belezbar.livejournal.com]

Вот да. Нужна оптимизация по скорости/памяти - транслируй хаскельную программу в С, а то и в ассемблер и оптимизируй критичные места до победы. На Хаскеле надо решать более глобальные, "общечеловеческие" задачи.

P.S. Jigsaw puzzle в капче - это да (:

[antilamer.livejournal.com]

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

[worm-ii.livejournal.com]

Там, вроде как, объяснялось, что в этом случае нельзя даже теоретически оптимизатор присобачить, halting problem, всё такое...

[binf.livejournal.com]

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

[lomeo.livejournal.com]

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

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

[lomeo.livejournal.com]

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

[justy-tylor.livejournal.com]

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

[aamonster.livejournal.com]

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

[thesz.livejournal.com]

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

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

[thesz.livejournal.com]

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

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

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

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

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

[justy-tylor.livejournal.com]

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

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

[os80.livejournal.com]

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

[thesz.livejournal.com]

Мой основной аргумент остаётся в силе: хера там!

Я тут пописал для всякого разного, включая GPU. Включая сюда мой недавний опыт C# программиста, могу сказать, что ваши позиция не вяжется с моим опытом.

Перейдя с Хаскеля на C# мне приходится "думать в классах и объектах". Какая пакость!

[thesz.livejournal.com]

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

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

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

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

[metaclass.livejournal.com]

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

[antilamer.livejournal.com]

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

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

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

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

[lomeo.livejournal.com]

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

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

[lomeo.livejournal.com]

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

[justy-tylor.livejournal.com]

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

[lomeo.livejournal.com]

Ну, конечно, это неправда. Вот только в этом треде привели пример форсирования свёртки снаружи без влезания в потроха. Так что как минимум не "для любых". Из моего опыта — в подавляющем большинстве случаев этого достаточно.