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

[metaclass]

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

Comments

[dr-cha0s.livejournal.com]

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

[justy-tylor.livejournal.com]

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

[dr-cha0s.livejournal.com]

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

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

[justy-tylor.livejournal.com]

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

[dr-cha0s.livejournal.com]

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

[justy-tylor.livejournal.com]

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

[dr-cha0s.livejournal.com]

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

[justy-tylor.livejournal.com]

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

[lomeo.livejournal.com]

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

[justy-tylor.livejournal.com]

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

[thesz.livejournal.com]

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

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

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

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

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

[justy-tylor.livejournal.com]

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

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

[thesz.livejournal.com]

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

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

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

[lomeo.livejournal.com]

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

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

[justy-tylor.livejournal.com]

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

[lomeo.livejournal.com]

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