Короче, я сторонник контроля над оружием, тьфу, явного управления ленивостью, посредством фьючерсов и стримов (ленивых списков), и строгости по умолчанию.
G>Короче, я сторонник контроля над оружием, тьфу, явного управления ленивостью, посредством фьючерсов и стримов (ленивых списков), и строгости по умолчанию.
Короче, ты сторонник преждевременной оптимизации.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
G>>Короче, я сторонник контроля над оружием, тьфу, явного управления ленивостью, посредством фьючерсов и стримов (ленивых списков), и строгости по умолчанию.
T>Короче, ты сторонник преждевременной оптимизации.
Так можно было бы сказать, если бы проблемы памяти и отклика являлись вопросом оптимизации.
Однако, они ведут себя как самые настоящие баги, подчас делая систему неработоспособной. Помнишь у тебя на симуляторе лик был из-за накапливающейся невычисленной цепочки? Это баг, с хорошим таким почти фатальным severity — симулятор не может работать больше нескольких дней. Баг поганый, неожиданный и непредсказуемый, и трудноуловимый.
Здравствуйте, thesz, Вы писали:
G>>Короче, я сторонник контроля над оружием, тьфу, явного управления ленивостью, посредством фьючерсов и стримов (ленивых списков), и строгости по умолчанию.
T>Короче, ты сторонник преждевременной оптимизации.
И вообще. "Оптимизация" — это расстановка strictness annotaation. При этом, ты полагаешься на исскуственный интеллект в виде анализатора строгости.
Я не сторонник оптимизаций, а противник исскуственного интеллекта, в особенности если ему доверяют принятие важных решений, относящихся по сути к дизайну системы. Строгость по умолчанию, и явная аннотация ленивости — это по всем понятиям не "оптимизация", а упрощение проектирования.
Тезис: никакого значимого выигрыша от ленивости везде по умолчанию нет. Обоснование: ты все равно при проектировании и детальном дизайне (что в случае хаскеля почти кодирование) прикидываешь сложность алгоритмов с учетом ленивости, с рассчетом на нее. Таким образом, все места, где ленивость для тебя действительно существенна, ты отмечаешь в голове, и тебя не затруднит их пометить в коде явно аннотацией. Что, кстати, существенно облегчит _чтение_ твоего кода другим программистом, так как он видит, на что ты заложился в коде явно, и не должен это реконструировать. В тех же местах, где ленивость для тебя не важна — от нее в основном вред, а не польза — она дает замедление, неконтроллируемые задержки, и неконтроллируемый расход памяти.
Опровергать тезис по существу будешь? Я бы хотел наглядный и убедительный контрпример, лишенный эмоций и шелухи.
G>>>Короче, я сторонник контроля над оружием, тьфу, явного управления ленивостью, посредством фьючерсов и стримов (ленивых списков), и строгости по умолчанию.
T>>Короче, ты сторонник преждевременной оптимизации.
G>И вообще. "Оптимизация" — это расстановка strictness annotaation. При этом, ты полагаешься на исскуственный интеллект в виде анализатора строгости.
Не вижу в этом ничего плохого.
Компилируют же плюсовики свои проекты с -O3.
G>Я не сторонник оптимизаций, а противник исскуственного интеллекта, в особенности если ему доверяют принятие важных решений, относящихся по сути к дизайну системы. Строгость по умолчанию, и явная аннотация ленивости — это по всем понятиям не "оптимизация", а упрощение проектирования.
Так говорят все сторонники преждевременной оптимизации.
Все они оптимизацию закладывают ещё при проектировании.
Как раньше распределяли регистры, а позже следили за владением динамической памятью.
G>Тезис: никакого значимого выигрыша от ленивости везде по умолчанию нет. Обоснование: ты все равно при проектировании и детальном дизайне (что в случае хаскеля почти кодирование) прикидываешь сложность алгоритмов с учетом ленивости, с рассчетом на нее. Таким образом, все места, где ленивость для тебя действительно существенна, ты отмечаешь в голове, и тебя не затруднит их пометить в коде явно аннотацией. Что, кстати, существенно облегчит _чтение_ твоего кода другим программистом, так как он видит, на что ты заложился в коде явно, и не должен это реконструировать. В тех же местах, где ленивость для тебя не важна — от нее в основном вред, а не польза — она дает замедление, неконтроллируемые задержки, и неконтроллируемый расход памяти.
G>Опровергать тезис по существу будешь? Я бы хотел наглядный и убедительный контрпример, лишенный эмоций и шелухи.
Что значит "лишённый эмоций и шелухи"? Я могу говорить только по личному опыту и только чуть по чужому. Поэтому здесь будут и эмоции, и шелуха.
При кодировании на Хаскеле я вообще не беру в расчёт сложность алгоритмов до получения первых результатов. Looking at algorithm complexity is soooo 1980. Сейчас, максимум, что надо учитывать, это класс задачи, P она, или NP.
Ленивость важна при описании функциональных преобразований. Я могу не придерживаться определённого порядка, я могу производить опасные действия (в блоге у меня есть на эту тему: http://thesz.livejournal.com/488747.html).
The design patterns of Brian Hurt circa 2008 are radically different than the design patterns of Brian Hurt circa 2003. For example, were I to redo extlib now, it's be purely applicative, heavily functorized, lots of monads, and a fair bit of lazy evaluation, as opposed to the code I wrote in 2003.
Ленивые вычисления повышают модульность программы. Они выгодны в качестве порядка вычислений по умолчанию. Как только ты набираешься опыта в программировании на (более-менее нормальном) функциональном языке, то они начинают вылезать всюду. Просто потому, что они удобны и полезны.
Full throttle emotions
Ты говоришь с высоты своего не очень большого опыта. Ну сколько ты написал на ленивом ФЯ? Сотни три строчек, наверное. А сколько на строгом? Да примерно столько же. А писал ли ты на любом из них скорость получения первого результата? Нет, не писал.
Да ты даже Вадлера не читал толком. У него про пользу ленивых вычислений отдельная статья.
Emotions throttle off
Как контролируются задержки в ленивом ФЯ, я уже рассказывал. Как и всё в таких ФЯ, они контролируются высокомодульно — есть генератор, есть потребитель. Потребитель потребляет создаваемое, пока не сочтёт, что упёрся или не завершится время на решение.
Неконтролируемый расход памяти — это да, проблема. Но она менее серьёзна, чем её пытаются представить. Let it crash никто не отменял.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Gaperton, Вы писали:
G>Тезис: никакого значимого выигрыша от ленивости везде по умолчанию нет. G>Опровергать тезис по существу будешь? Я бы хотел наглядный и убедительный контрпример, лишенный эмоций и шелухи.
Например, при ленивости по умолчанию код более лаконичен. Это считается выигрышем?
Здравствуйте, thesz, Вы писали:
G>>И вообще. "Оптимизация" — это расстановка strictness annotaation. При этом, ты полагаешься на исскуственный интеллект в виде анализатора строгости.
T>Не вижу в этом ничего плохого.
T>Компилируют же плюсовики свои проекты с -O3.
Использование или не использование о3 не приводит к таким результатам, как мемори лик в программе из-за невычисленной цепочки. Эффект от о3 в целом презсказуем. В этом разница.
G>>Я не сторонник оптимизаций, а противник исскуственного интеллекта, в особенности если ему доверяют принятие важных решений, относящихся по сути к дизайну системы. Строгость по умолчанию, и явная аннотация ленивости — это по всем понятиям не "оптимизация", а упрощение проектирования.
T>Так говорят все сторонники преждевременной оптимизации.
Не думаю, что так говорят все сторонники преждевременной оптимизации.
T>Все они оптимизацию закладывают ещё при проектировании.
Так как я к ним не отношусь, то комментировать не буду. Хотя, я в самом деле сторонник подхода поменьше прыгать, побольше думать. Однако, одновременно я сторонник подхода сделать проще, проще настолько, насколько это возможно, но не слишком. Что подразумевает откладывание усложнений на потом.
В целом, я сторонник предсказуемых результатов, только и всего.
T>Как раньше распределяли регистры, а позже следили за владением динамической памятью.
Для встраиваемой железки или высоконагруженного сервера такие свойства, как расход памяти, должны быть доказуемы. Так дешевле. В этом смысле — да, до сих пор следим за динамической памятью.
G>>Опровергать тезис по существу будешь? Я бы хотел наглядный и убедительный контрпример, лишенный эмоций и шелухи.
T>Что значит "лишённый эмоций и шелухи"? Я могу говорить только по личному опыту и только чуть по чужому. Поэтому здесь будут и эмоции, и шелуха.
Это означает привести содержательный контрпример, а не выражать свое мнение касательно моего опыта, как ты делаешь ниже.
T>При кодировании на Хаскеле я вообще не беру в расчёт сложность алгоритмов до получения первых результатов. Looking at algorithm complexity is soooo 1980. Сейчас, максимум, что надо учитывать, это класс задачи, P она, или NP.
Любопытно. Обоснуй. Впрочем, я догадываюсь, почему ты так делаешь. Тебе сложно в голове предсказать сложность даже относительно простых алгоритмов в условиях тотальной ленивости, поэтому ты предпочитаешь мерять. А потом — ломать (или не ломать) голову, почему результаты именно такие. Это не мой метод.
T>Ленивость важна при описании функциональных преобразований. Я могу не придерживаться определённого порядка, я могу производить опасные действия (в блоге у меня есть на эту тему: http://thesz.livejournal.com/488747.html).
Прочитаю, отвечу по существу.
T>А вот не моё, но от опытного функционального программиста: http://enfranchisedmind.com/blog/2008/05/07/why-ocaml-sucks/
T>The design patterns of Brian Hurt circa 2008 are radically different than the design patterns of Brian Hurt circa 2003. For example, were I to redo extlib now, it's be purely applicative, heavily functorized, lots of monads, and a fair bit of lazy evaluation, as opposed to the code I wrote in 2003.
Это мнение напрямую не относится к нашей теме — ленивость по умолчанию. Ну стало у чувака больше монад, и fair bit ленивости. О чем он и говорит. Стал опытнее, стал умнее. И все.
T>Ленивые вычисления повышают модульность программы. Они выгодны в качестве порядка вычислений по умолчанию. Как только ты набираешься опыта в программировании на (более-менее нормальном) функциональном языке, то они начинают вылезать всюду. Просто потому, что они удобны и полезны.
Это твое _мнение_, которое я тебя просил подтвердить содержательным контрпримером. А не "авторитетами". Раз они "вылезают повсюду" — то в чем сложность привести пример? Неужто на авторитеты ссылаться проще (разновидность замера пиписьками)?
T>Full throttle emotions
А вот это ты зря. Сам понимаешь, если ты не прав, то зачем волноваться? Это как то по детски. Ну а теперь, допустим, что ты прав. Ну, тогда тем более непонятно, что ты волнуешься.
T>Ты говоришь с высоты своего не очень большого опыта. Ну сколько ты написал на ленивом ФЯ? Сотни три строчек, наверное. А сколько на строгом? Да примерно столько же. А писал ли ты на любом из них скорость получения первого результата? Нет, не писал.
Если бы мой "не очень большой опыт" исчерпывался строками кода на ФЯ, то я бы немедленно посыпал голову пеплом. Однако, мой опыт коммерческой разработки не меньше твоего. А если говорить о высоконагруженных надежных серверных приложениях — то он существенно превышает твой опыт, Сергей. Ты ведь на поддержке софтины, написанной не тобой, вообще никогда не сидел, не так ли? Предлагаю замять для ясности, и тему не развивать.
T>Да ты даже Вадлера не читал толком. У него про пользу ленивых вычислений отдельная статья.
Ты читал Вадлера толком — так почему тебе проще обсуждать мою личность, а не объяснить мне Вадлера? Тем более, что я с тобой разговариваю, и тебя об этом прошу. В чем проблема? Вот ты Вадлера толком понял — и что, ты не в состоянии это просто и доходчиво объяснить другим?
T>Emotions throttle off
Ну слава богу.
T>Как контролируются задержки в ленивом ФЯ, я уже рассказывал. Как и всё в таких ФЯ, они контролируются высокомодульно — есть генератор, есть потребитель. Потребитель потребляет создаваемое, пока не сочтёт, что упёрся или не завершится время на решение.
Я тебя просил привести пример. Пример будет?
T>Неконтролируемый расход памяти — это да, проблема. Но она менее серьёзна, чем её пытаются представить. Let it crash никто не отменял.
Let is crash тут не причем. Твое мнение о серьезности или не серьезности данной пробемы я приму во внимание, когда ты напишешь на Хаскеле хотя бы один нетривиальный высоконагруженный сервер. А пока ты этого не сделал, извини — я хочу доказательств, или хотя бы обоснований.
Здравствуйте, lomeo, Вы писали:
G>>Тезис: никакого значимого выигрыша от ленивости везде по умолчанию нет. G>>Опровергать тезис по существу будешь? Я бы хотел наглядный и убедительный контрпример, лишенный эмоций и шелухи.
L>Например, при ленивости по умолчанию код более лаконичен. Это считается выигрышем?
Возможно, если это оправдывает приведенные недостатки. Пример, пожалуйста, для иллюстрации вашей мысли.
Здравствуйте, Gaperton, Вы писали:
G>Использование или не использование о3 не приводит к таким результатам, как мемори лик в программе из-за невычисленной цепочки. Эффект от о3 в целом презсказуем. В этом разница. G>Для встраиваемой железки или высоконагруженного сервера такие свойства, как расход памяти, должны быть доказуемы. Так дешевле. В этом смысле — да, до сих пор следим за динамической памятью. G>Let is crash тут не причем. Твое мнение о серьезности или не серьезности данной пробемы я приму во внимание, когда ты напишешь на Хаскеле хотя бы один нетривиальный высоконагруженный сервер. А пока ты этого не сделал, извини — я хочу доказательств, или хотя бы обоснований.
Все так. Проблемы с ленивыми вычислениями есть и они объективны. НО. Как показывает опыт, люди научаются с ними работать и справляться. Т.о., речь не идет об абстрактных вопросах — что лучше — ленивые или энергичные вычисления, а о вполне прагматичных, типа — какие инструменты у нас под рукой? Любая из рапространенных платформ имеет свои недостатки и преимущества. Когда я обсуждал с заказчиком одного небольшого проекта стоит ли (и почему я собираюсь) в нем использовать Хаскелл — я честно написал, что с ним проблем — вагон и маленькая тележка, но в нашем конкретном случае его выразительность и мощь — перевешивают. Основные проблемы здесь — недостаток опыта использования в *реальных* приложениях.
И да, для меня, например, появление rvalue references в С++ означает *реальную* возможность работать на C++ в *чистом* функциональном стиле, хотя, например, мне никто не мешает выкинуть mutable state в С++ безо всяких rvalue references и с т. зр. thesz, это — "преждевременная оптимизация". Равно как и идиома left-fold enumerator — почти тривиальная — доставляет возможность возможность реализации разннобразных traversing стратегий (и IO в том числе) в Хаскелле безо всяких утечек ресурсов.
Иными словами, я агитирую за Хаскелл не потому, что он во всех отношениях безупречен, а потому, что для очень очень широкого круга задач (высоконагруженных серверов тож) это — оптимальный выбор.
Здравствуйте, awson, Вы писали:
A>Иными словами, я агитирую за Хаскелл не потому, что он во всех отношениях безупречен, а потому, что для очень очень широкого круга задач (высоконагруженных серверов тож) это — оптимальный выбор.
А есть опыт создания высоконагруженных серверов на Haskell?
Здравствуйте, EvilChild, Вы писали: EC>А есть опыт создания высоконагруженных серверов на Haskell?
У меня до этого дела пока так и не дошло, хотя я сделал довольно серьезную оценку и пришел к выводу, что проканает. Заказчик закрыл проект по коммерческим соображениям.
Здравствуйте, Gaperton, Вы писали:
G>>>Тезис: никакого значимого выигрыша от ленивости везде по умолчанию нет. G>>>Опровергать тезис по существу будешь? Я бы хотел наглядный и убедительный контрпример, лишенный эмоций и шелухи.
L>>Например, при ленивости по умолчанию код более лаконичен. Это считается выигрышем?
G>Возможно, если это оправдывает приведенные недостатки. Пример, пожалуйста, для иллюстрации вашей мысли.
Ну! Ты говорил, что вообще "никакого значимого выигрыша от ленивости везде по умолчанию нет." Я показал то, что считаю выигрышем (для ясности — мы же под этим словом понимаем преимущество?). А оправдывает он или нет приведенные недостатки зависит от задачи, полагаю. Может в некоторых задачах вообще этих недостатков нет или они неважны.
Здравствуйте, lomeo, Вы писали:
L>Например, при ленивости по умолчанию код более лаконичен. Это считается выигрышем?
Это утверждение требует доказательства. Пока что такие доказательства дальше разных фибоначей не пошли.
Мое мнение — ленивость нужна только при обработке списков, да и то не все время. В большинстве случаев совершенно все равно лениво обрабатывается список или нет. А вот быстро это делается или медленно зачастую важно. Так что для реальной жизни важно чтобы map, fold, filter, forall и т.п. не проигрывали по скорости аналогичным циклам в компилируемых языках. А ленивы он или нет дело десятое.
Ленивость же в обработке списков вполне легко достигается во многих не ленивых языках. Даже в Яве это возможно. А уже в C# это как два пальца об асфальт.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
T>>Все они оптимизацию закладывают ещё при проектировании.
G>Так как я к ним не отношусь, то комментировать не буду. Хотя, я в самом деле сторонник подхода поменьше прыгать, побольше думать. Однако, одновременно я сторонник подхода сделать проще, проще настолько, насколько это возможно, но не слишком. Что подразумевает откладывание усложнений на потом.
Считать ли этот комментарий признанием?
G>В целом, я сторонник предсказуемых результатов, только и всего.
При этом ты не указываешь точно, какие результаты тебе нужны. Это должен вычислить твой собеседник.
Вот, смотри, я же тоже сторонник предсказуемых результатов.
О чем же мы тогда спорим?
G>>>Опровергать тезис по существу будешь? Я бы хотел наглядный и убедительный контрпример, лишенный эмоций и шелухи. T>>Что значит "лишённый эмоций и шелухи"? Я могу говорить только по личному опыту и только чуть по чужому. Поэтому здесь будут и эмоции, и шелуха. G>Это означает привести содержательный контрпример, а не выражать свое мнение касательно моего опыта, как ты делаешь ниже.
Мне можно. Я всё воспринимаю очень лично.
T>>При кодировании на Хаскеле я вообще не беру в расчёт сложность алгоритмов до получения первых результатов. Looking at algorithm complexity is soooo 1980. Сейчас, максимум, что надо учитывать, это класс задачи, P она, или NP. G>Любопытно. Обоснуй. Впрочем, я догадываюсь, почему ты так делаешь. Тебе сложно в голове предсказать сложность даже относительно простых алгоритмов в условиях тотальной ленивости, поэтому ты предпочитаешь мерять. А потом — ломать (или не ломать) голову, почему результаты именно такие. Это не мой метод.
Как там в Крепком Орешке? "Bzz, Hans, wrong answer"?
Например, я использую сортированные списки вместо множеств или отображений. По ним проще производить сравнения с образцом.
Было. До pattern guards. Сейчас я на них переползаю.
T>>А вот не моё, но от опытного функционального программиста: http://enfranchisedmind.com/blog/2008/05/07/why-ocaml-sucks/ T>>The design patterns of Brian Hurt circa 2008 are radically different than the design patterns of Brian Hurt circa 2003. For example, were I to redo extlib now, it's be purely applicative, heavily functorized, lots of monads, and a fair bit of lazy evaluation, as opposed to the code I wrote in 2003. G>Это мнение напрямую не относится к нашей теме — ленивость по умолчанию. Ну стало у чувака больше монад, и fair bit ленивости. О чем он и говорит. Стал опытнее, стал умнее. И все.
И стало больше ленивости.
Нешто это не доказательство, что выбор умного человека — ленивость?
T>>Ленивые вычисления повышают модульность программы. Они выгодны в качестве порядка вычислений по умолчанию. Как только ты набираешься опыта в программировании на (более-менее нормальном) функциональном языке, то они начинают вылезать всюду. Просто потому, что они удобны и полезны. G>Это твое _мнение_, которое я тебя просил подтвердить содержательным контрпримером. А не "авторитетами". Раз они "вылезают повсюду" — то в чем сложность привести пример? Неужто на авторитеты ссылаться проще (разновидность замера пиписьками)?
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.30.5644
Laziness is an advantage precisely when it is difficult to predict the required order of evaluation in advance, while strictness is an advantage precisely because it allows such prediction.
Для получения решения большинства встречавшихся мне задач совершенно нет необходимости заботиться о последовательности вычислений.
T>>Full throttle emotions G>А вот это ты зря. Сам понимаешь, если ты не прав, то зачем волноваться? Это как то по детски. Ну а теперь, допустим, что ты прав. Ну, тогда тем более непонятно, что ты волнуешься.
Как ты сам понимаешь, мне может просто нравится волноваться в таких ситуациях.
Грех не воспользоваться возможностью.
T>>Ты говоришь с высоты своего не очень большого опыта. Ну сколько ты написал на ленивом ФЯ? Сотни три строчек, наверное. А сколько на строгом? Да примерно столько же. А писал ли ты на любом из них скорость получения первого результата? Нет, не писал. G>Если бы мой "не очень большой опыт" исчерпывался строками кода на ФЯ, то я бы немедленно посыпал голову пеплом. Однако, мой опыт коммерческой разработки не меньше твоего. А если говорить о высоконагруженных надежных серверных приложениях — то он существенно превышает твой опыт, Сергей. Ты ведь на поддержке софтины, написанной не тобой, вообще никогда не сидел, не так ли? Предлагаю замять для ясности, и тему не развивать.
Как так? Я же неоднократно тебе рассказывал про программу с глобальным int i.
В ПСиТ я вообще исправлял ошибки за всей командой, без малого. В высоконадёжной системе, тоже связанной с финансами.
Так что я не вижу причин, по которым надо это заминать.
Да и носки у меня стоят лучше. Просто потому, что я старше.
T>>Да ты даже Вадлера не читал толком. У него про пользу ленивых вычислений отдельная статья. G>Ты читал Вадлера толком — так почему тебе проще обсуждать мою личность, а не объяснить мне Вадлера? Тем более, что я с тобой разговариваю, и тебя об этом прошу. В чем проблема? Вот ты Вадлера толком понял — и что, ты не в состоянии это просто и доходчиво объяснить другим?
Ты как-то странно об этом просишь.
Буквально, год назад объяснил тебе всё, что сейчас пытаюсь объяснить. Вроде, ты сказал, что понял. И вот снова вынужден это делать.
Видимо, то было лично, вне просторов RSDN, а это "не считается".
И как ты просто обязан знать, "знать и применять" не означает "способен просто и доходчиво объяснить другим".
Да и место для объяснений здесь так себе. Некая нехорошая аура.
T>>Emotions throttle off
G>Ну слава богу.
T>>Как контролируются задержки в ленивом ФЯ, я уже рассказывал. Как и всё в таких ФЯ, они контролируются высокомодульно — есть генератор, есть потребитель. Потребитель потребляет создаваемое, пока не сочтёт, что упёрся или не завершится время на решение. G>Я тебя просил привести пример. Пример будет?
Я не смогу написать что-то, отличное от абзаца выше.
Поэтому — почему это не контрпример?
T>>Неконтролируемый расход памяти — это да, проблема. Но она менее серьёзна, чем её пытаются представить. Let it crash никто не отменял. G>Let is crash тут не причем. Твое мнение о серьезности или не серьезности данной пробемы я приму во внимание, когда ты напишешь на Хаскеле хотя бы один нетривиальный высоконагруженный сервер. А пока ты этого не сделал, извини — я хочу доказательств, или хотя бы обоснований.
Я повторю свой вопрос: О чем же мы тогда спорим?
Какой тезис я доказываю, с твоей точки зрения?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
L>>Например, при ленивости по умолчанию код более лаконичен. Это считается выигрышем? VD>Это утверждение требует доказательства. Пока что такие доказательства дальше разных фибоначей не пошли. VD>Мое мнение — ленивость нужна только при обработке списков, да и то не все время. В большинстве случаев совершенно все равно лениво обрабатывается список или нет. А вот быстро это делается или медленно зачастую важно. Так что для реальной жизни важно чтобы map, fold, filter, forall и т.п. не проигрывали по скорости аналогичным циклам в компилируемых языках. А ленивы он или нет дело десятое.
Ленивость позволяет класть код так, как этого требует мысль, а не последовательность вычислений.
Например, я часто применяю операции наподобие (head:tail) = someListThatMayBeEmpty и потом беру результаты этого опасного сравнения с образцом исходя из других критериев, когда, например, этот список точно не может быть пуст.
В результате мой код полон ленивых сравнений с образцом и, соответственно, он сильно завязан на ленивые вычисления.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, VladD2, Вы писали:
L>>Например, при ленивости по умолчанию код более лаконичен. Это считается выигрышем?
VD>Это утверждение требует доказательства. Пока что такие доказательства дальше разных фибоначей не пошли.
1. Бесконечные и потенциально бесконечные структуры данных. Сильно сокращают код. Ну, может и не сильно, но заметно. Однако, для того, чтобы понять это, надо для начала пописать что-то отличное от потоков. К сожалению, для этого надо немного поменять мышление — научиться смотреть на задачу по другому.
2. Лёгкое отделение генерации от выборки. В коде просто видно — вот тут мы создаём структуру данных, а тут обрабатываем её. При ленивости по умолчанию не нужно смешивать эти два отдельных по сути этапа, чтобы создать только то, что будет обработано. Учитывая, что каждый из этих этапов сам может разбиваться на подэтапы, порождающие структуры (map f . map g . map h) — ленивость играет большую роль.
3. Соответственно подобное разделение позволяет выписывать комбинаторы и использовать их отдельно. Повторное использование, что тоже показатель лаконичности.
4. eDSL без макросов — следствие ленивости (одна из причин)!
5. Можно ещё много чего дописать — всё это связано с тем, что бета-редукция при ленивости не ограничивается никаким порядком.
VD>Мое мнение — ленивость нужна только при обработке списков, да и то не все время. В большинстве случаев совершенно все равно лениво обрабатывается список или нет. А вот быстро это делается или медленно зачастую важно. Так что для реальной жизни важно чтобы map, fold, filter, forall и т.п. не проигрывали по скорости аналогичным циклам в компилируемых языках. А ленивы он или нет дело десятое.
1. В цепочке map/filter/fold важно ленивы они или нет. Неленивые — неэффективны (или вообще невозможны для бесконечных списков). Поэтому так популярны итераторы.
2. Про медленную ленивую обработку списков — это утверждение тоже требует доказательства
3. Ленивость нужна не только при обработке списков. Предполагаю, что тебе так кажется, потому что ты не пробовал писать лениво, а ленивость у тебя прочно ассоциируется с потоками. Тут уж, как ты выражаешься, эффект Блаба — надо получить опыт.
VD>Ленивость же в обработке списков вполне легко достигается во многих не ленивых языках. Даже в Яве это возможно. А уже в C# это как два пальца об асфальт.
Никто не спорит. Strictness тоже легко достигается в ленивых языках.
Здравствуйте, thesz, Вы писали:
L>>>Например, при ленивости по умолчанию код более лаконичен. Это считается выигрышем? VD>>Это утверждение требует доказательства. Пока что такие доказательства дальше разных фибоначей не пошли. VD>>Мое мнение — ленивость нужна только при обработке списков, да и то не все время. В большинстве случаев совершенно все равно лениво обрабатывается список или нет. А вот быстро это делается или медленно зачастую важно. Так что для реальной жизни важно чтобы map, fold, filter, forall и т.п. не проигрывали по скорости аналогичным циклам в компилируемых языках. А ленивы он или нет дело десятое.
T>Ленивость позволяет класть код так, как этого требует мысль, а не последовательность вычислений.
Ну, главное чтобы класть код, а не класть на код.
Ну, а по делу скажу только то, что не так много на свете людей у которых мыслительный процесс расходится с ходом вычислений. Скорее у большинства возникают проблемы когда вычислительный процесс вдруг начинает жить своей жизнью.
Потом если бы ленивость была бесплатной (в данном случае речь не о производительности), а так за отложенность вычислений прихдится платить тем, что приходится повсеместно возиться с головоломными монадами. А ведь голова не компьютер. Она уровень косвенности больше 2 переваривает с трудом.
T>Например, я часто применяю операции наподобие (head:tail) = someListThatMayBeEmpty и потом беру результаты этого опасного сравнения с образцом исходя из других критериев, когда, например, этот список точно не может быть пуст.
На мой взгляд опасный код вообще не нужно допускать (если это не крайне необходимо).
Ну, да речь не о том. Ты пытаешся обосновать глобальное утверждение тем, что ты используешь тот или иной трюк. Но где доказательство, что этот трюк действительно радикально упрощает код, и что нет других подходов которые не давали бы лучший результат без создания проблем?
T>В результате мой код полон ленивых сравнений с образцом и, соответственно, он сильно завязан на ленивые вычисления.
И в результате главным достоинством твоего кода становится, то что тебя прёт он него. А то что другим его не понять только потешит твое самолюбие...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
L>Для начала классика: Why FP matters. Must read.
Спасибо, религиозным чтивом не увлекаюсь. В свое время не осилил даже Майн Камф.
L>Теперь обоснования
L>1. Бесконечные и потенциально бесконечные структуры данных. Сильно сокращают код. Ну, может и не сильно, но заметно. Однако, для того, чтобы понять это, надо для начала пописать что-то отличное от потоков. К сожалению, для этого надо немного поменять мышление — научиться смотреть на задачу по другому.
Это мы отвергаем сразу по двум причинам:
1. Ленивые структуры данных доступны и не ленивых по умолчанию языках.
2. Ни фига они ни не дает грандиозного выигрыша в общем случае. Большую часть времени программист возится со списками или массивами.
L>2. Лёгкое отделение генерации от выборки. В коде просто видно — вот тут мы создаём структуру данных, а тут обрабатываем её. При ленивости по умолчанию не нужно смешивать эти два отдельных по сути этапа, чтобы создать только то, что будет обработано. Учитывая, что каждый из этих этапов сам может разбиваться на подэтапы, порождающие структуры (map f . map g . map h) — ленивость играет большую роль.
ОК, принимается. С оговоркой. Ленивые списки (или их аналоги) сейчас есть практически везде. И функции склеивать можно даже в C#. А уж для разных ОКамлов и Немерлов это самая, что ни на есть банальщина.
L>3. Соответственно подобное разделение позволяет выписывать комбинаторы и использовать их отдельно. Повторное использование, что тоже показатель лаконичности.
Не видел подобных проблем в не ленивых языках.
L>4. eDSL без макросов — следствие ленивости (одна из причин)!
Ой. Только не на до про ДСЛ-и. Ладно? Есть разные пути их создания.
Вообще, надо бы стравить Лиспаря и Хаскелиста... и поглядеть на получившийся флэйм.
L>5. Можно ещё много чего дописать — всё это связано с тем, что бета-редукция при ленивости не ограничивается никаким порядком.
Можно. Но все это треп и понты. А по жизни код есть код. Ленивость при обработке списков иногда полезно. Но ее не трудно достичь и в не ленивом языке. А ленивость в обычном коде скорее создает проблемы, чем их решает.
А вот, то что код нельзя тупо превратить в машинные команды, а надо заниматься разными бета-редукциями — это проблема. Сколько слов сказано о том, что в Хаскеле все можно соптимизировать? И где эти оптимизации?
VD>>Мое мнение — ленивость нужна только при обработке списков, да и то не все время. В большинстве случаев совершенно все равно лениво обрабатывается список или нет. А вот быстро это делается или медленно зачастую важно. Так что для реальной жизни важно чтобы map, fold, filter, forall и т.п. не проигрывали по скорости аналогичным циклам в компилируемых языках. А ленивы он или нет дело десятое.
L>1. В цепочке map/filter/fold важно ленивы они или нет. Неленивые — неэффективны (или вообще невозможны для бесконечных списков). Поэтому так популярны итераторы.
Чушь полнейшая. Во-первых, только у теоретиков везде возникают бесконечные списки. У всех остальных есть списко и его надо обработать. 99% программистов их до сих пор for-ами на Cxx обрабатывают. Ну, и если вдруг появляется нужда в ленивых map/filter/fold, то нет проблем их использовать. Как, по-твоему, работают Select, Where, Aggregate в LINQ?
L>2. Про медленную ленивую обработку списков — это утверждение тоже требует доказательства
Скорее обратное доказательства. Если обработка не переписана в код аналогичный for, то ее скорость по любому оставляет желать лучшего. А добиться отложенности вычислений на современных процессорах без доп.затрат нельзя в принципе.
L>3. Ленивость нужна не только при обработке списков. Предполагаю, что тебе так кажется, потому что ты не пробовал писать лениво, а ленивость у тебя прочно ассоциируется с потоками. Тут уж, как ты выражаешься, эффект Блаба — надо получить опыт.
Не сомневайся, пробовал. Только оргазма от этого не получил. Есть задачи в которых это удобно. Но не так, чтобы они ломились в дверь.
VD>>Ленивость же в обработке списков вполне легко достигается во многих не ленивых языках. Даже в Яве это возможно. А уже в C# это как два пальца об асфальт.
L>Никто не спорит. Strictness тоже легко достигается в ленивых языках.
Может быть. Только я таких не знаю. Идею применять монады для того чтобы сделать код последовательным нельзя не только назвать простой, но и здоровой. Это же надо так извращаться чтобы достичь то, что и так есть?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
L>>Для начала классика: Why FP matters. Must read.
VD>Спасибо, религиозным чтивом не увлекаюсь. В свое время не осилил даже Майн Камф.
Это не религиозное чтиво. В этой статье показывается на примерах где и как рулит ленивость. Мне бы не пришлось писать предыдущий, да и этот пост, если бы ты просто прочитал эту статью.
VD>Это мы отвергаем сразу по двум причинам: VD>1. Ленивые структуры данных доступны и не ленивых по умолчанию языках. VD>2. Ни фига они ни не дает грандиозного выигрыша в общем случае. Большую часть времени программист возится со списками или массивами.
1. Да, но записываются они не так лаконично, как в ленивых. А мы же о лаконичности, как преимуществе ленивости, не так ли?
2. Про грандиозный я не говорил. Я говорил про заметный. Большую часть времени программист возится со списками и массивами — это что? Опровержение того, что ленивый код лаконичен? Если да — разверни. Если нет — поясни, зачем ты это написал.
VD>ОК, принимается. С оговоркой. Ленивые списки (или их аналоги) сейчас есть практически везде. И функции склеивать можно даже в C#. А уж для разных ОКамлов и Немерлов это самая, что ни на есть банальщина.
а) А если не списки?
б) А что на Камлах и Немерлях пишут — map f . map g . map h? Или всё таки map (f . g . h)?
L>>3. Соответственно подобное разделение позволяет выписывать комбинаторы и использовать их отдельно. Повторное использование, что тоже показатель лаконичности.
VD>Не видел подобных проблем в не ленивых языках.
Я же написал почему. В ленивом языке мы можем объединять их, потому что промежуточные структуры будут удаляться.
Давай вернёмся к нашему map f . map g . map h. Представь, что всё это осмысленные операции: foo = map f, goo = map g, hoo = map h.
И теперь нам надо foo.goo.hoo. В неленивом языке придётся выписывать map (f.g.h). Ну и где переиспользование в неленивом языке?
L>>4. eDSL без макросов — следствие ленивости (одна из причин)!
VD>Ой. Только не на до про ДСЛ-и. Ладно? Есть разные пути их создания.
Ладно. Я только к тому, что eDSL-и они же тоже для лаконичности, выразительности и всего-всего. И их можно не только на макросах делать. Но, если не хочешь, не будем это связывать.
VD>Вообще, надо бы стравить Лиспаря и Хаскелиста... и поглядеть на получившийся флэйм.
А что тут смотреть! Лисп мощнее (можно больше), Хаскель мягче (пользуем только уровень функций, никаких макр)
L>>5. Можно ещё много чего дописать — всё это связано с тем, что бета-редукция при ленивости не ограничивается никаким порядком.
VD>Можно. Но все это треп и понты. А по жизни код есть код. Ленивость при обработке списков иногда полезно. Но ее не трудно достичь и в не ленивом языке. А ленивость в обычном коде скорее создает проблемы, чем их решает.
Почему трёп? Почему понты?
Что же касается проблем — я сейчас не об этом спорю. Я говорю о ленивости, как о средстве писать лаконичный код.
VD>А вот, то что код нельзя тупо превратить в машинные команды, а надо заниматься разными бета-редукциями — это проблема. Сколько слов сказано о том, что в Хаскеле все можно соптимизировать? И где эти оптимизации?
А что в С# код прямо так превращается в машинные команды, безо всяких разных преобразований?
Насчёт оптимизаций — давай без риторических вопросов, что ты хочешь узнать? В GHC есть оптимизации, могу показать много. Всё соптимизировать разумеется нельзя. Хотя бы в силу того, что уже соптимизированное соптимизировать трудно.
VD>>>Мое мнение — ленивость нужна только при обработке списков, да и то не все время. В большинстве случаев совершенно все равно лениво обрабатывается список или нет. А вот быстро это делается или медленно зачастую важно. Так что для реальной жизни важно чтобы map, fold, filter, forall и т.п. не проигрывали по скорости аналогичным циклам в компилируемых языках. А ленивы он или нет дело десятое.
L>>1. В цепочке map/filter/fold важно ленивы они или нет. Неленивые — неэффективны (или вообще невозможны для бесконечных списков). Поэтому так популярны итераторы.
VD>Чушь полнейшая. Во-первых, только у теоретиков везде возникают бесконечные списки. У всех остальных есть списко и его надо обработать. 99% программистов их до сих пор for-ами на Cxx обрабатывают. Ну, и если вдруг появляется нужда в ленивых map/filter/fold, то нет проблем их использовать. Как, по-твоему, работают Select, Where, Aggregate в LINQ?
Где чушь? Конкретно какие из моих слов являются чушью? Я тебе пишу одно, ты мне отвечаешь совсем другое. Ты вообще читал, что я тебе написал?
Повторю свою мысль — цепочка неленивых map/filter/fold неэффективна. Обосную — в силу создания промежуточных структур.
И зачем ты мне про LINK написал я не понимаю. Я же тебе написал про итераторы, как ты хочешь моими же аргументами эти же аргументы опровергнуть?
L>>2. Про медленную ленивую обработку списков — это утверждение тоже требует доказательства
VD>Скорее обратное доказательства. Если обработка не переписана в код аналогичный for, то ее скорость по любому оставляет желать лучшего. А добиться отложенности вычислений на современных процессорах без доп.затрат нельзя в принципе.
Нет, не скорее. Заявление сделал ты, тебе и доказывать. Насчёт обработки в аналогичный for — смотри на оптимизацию под названием stream fusion.
L>>3. Ленивость нужна не только при обработке списков. Предполагаю, что тебе так кажется, потому что ты не пробовал писать лениво, а ленивость у тебя прочно ассоциируется с потоками. Тут уж, как ты выражаешься, эффект Блаба — надо получить опыт.
VD>Не сомневайся, пробовал. Только оргазма от этого не получил. Есть задачи в которых это удобно. Но не так, чтобы они ломились в дверь.
Сомневаюсь. Я имею в виду, что ты дизайнил задачу в ленивых структурах и функциях, реализовывал это на ленивом языке? И тем не менее не увидел преимущества лени? Это очень странно.
Для ясности — я не говорю о преимуществе, как о доминантной черте, которая перевешивает всё и вся и давайте теперь дружно писать лениво. Лаконичность — один из бенефитов ленивости, и я доказываю только это.
VD>>>Ленивость же в обработке списков вполне легко достигается во многих не ленивых языках. Даже в Яве это возможно. А уже в C# это как два пальца об асфальт.
L>>Никто не спорит. Strictness тоже легко достигается в ленивых языках.
VD>Может быть. Только я таких не знаю. Идею применять монады для того чтобы сделать код последовательным нельзя не только назвать простой, но и здоровой. Это же надо так извращаться чтобы достичь то, что и так есть?
При чём здесь монады? А стриктнесс в Хаскеле достигается совсем другими механизмами. Подавляющее большинство монад — ленивы. Я же говорю — не разобрался.
Здравствуйте, VladD2, Вы писали:
VD>Может быть. Только я таких не знаю. Идею применять монады для того чтобы сделать код последовательным нельзя не только назвать простой, но и здоровой. Это же надо так извращаться чтобы достичь то, что и так есть?
А в чём ты углядел извращение? Там сложного ничего нет.
Применение итераторов для достижения ленивости — это просто и здраво?
