Здравствуйте, VladD2, Вы писали:
VD>Я и так прекрасно знаю где и как рулит ленивость. Вот только, то что она иногда рулит не является доказательством того, что она рулит всегда и везде, и того, что она должна быть по умолчанию.
Я не говорил о том, что она должна быть по умолчанию. Я говорил о том, что у ленивости по умолчанию есть свои преимущества.
VD>Возьмем пример из этой статьи.
Вот видишь — вместо простого создания ленивого списка конструктором — ты делаешь yield.
Тебе каждый раз приходится явно указывать ленивость при описании ленивой функции, что не может не снижать лаконичность и загромождает код деталями реализации.
VD>Можно конечно возразить, что писать функции аналогичные Repeat проще на ленивом языке, но ёлы-палы, кто же будет их писать постоянно? Нам реально нужны Map и Fiter. Ну, на крайняк напишем еще пару более специализированных функций. А скажем функции вроде Fold вообще бессмысленно делать ленивыми. Нам же ведь нужен результат, а не процесс!
В этом у нас и отличие. При ленивом дизайне эти функции надо будет писать постоянно.
Насчёт ленивого фолда, кстати, ты ошибаешься — он может порождать ленивые структуры.
L>>1. Да, но записываются они не так лаконично, как в ленивых. А мы же о лаконичности, как преимуществе ленивости, не так ли?
VD>На фи не нужна экономия 2 символов раз в пол года. В тома же Немерле мне нужно дописать lazy в паре мест, чтобы получить ленивую структуру. Но на практике я, написав на том же Немерле пару мег кода, не создал ни одной (!) ленивой структуры данных. Ну, не нужны они мне.
Так не в символах надо мерить. Так то APL всех победит
У тебя детали реализации указываются — "этот код ленив".
VD>Может быть конечно, что мой мозг так устроен. Но мне кажется дело в другом (о чем я уже говорл). Дело в том, что: VD>1. Я могу получать ленивость и другими средствами. VD>2. Ленивость реально полезна только для списков (деревья приравниваем к ним). VD>3. Большинство реальных задач не требует ленивости и не страдает от того, что ее не использовали.
Все пункты верны. Но они никак не опровергают мой тезис о том, что ленивость по умолчанию лаконична
Кстати, насчёт второго пункта — я так легко с ним согласился потому, что все структуры данных это по сути деревья, если не углубляться в подробности (графы, то-сё). Ну а раз для всех структур данных ленивость реально полезна — то о чём тут говорить?
L>>Если да — разверни. Если нет — поясни, зачем ты это написал.
VD>Затем, что ленивость при вызове некоторой функции вообще не нужна. То есть полностью. VD>А раз это нужно только изредка, то и не проблемой будет пометить нужные места чем надо или написать их с использованием подходящих средств (вроде итераторов пример использования которых я привел выше).
Можно, но это не будет так лаконично, как с ленивостью по умолчанию.
VD>Ну, а для обработки списков в ленивой манере можно сделать библиотеку содержащую набор ленивых функций. Вот тот же LINQ отличный пример такого подхода. Столь удобной библиотеки я не видел ни в одном самом ленивом языке. Хотя казалось бы Шарпу (на котором написаны библиотеки LINQ-а) до ФЯ как до Пекина раком.
Э? Монада?
L>>а) А если не списки? VD>То и это редкость ради которой не стоит иметь тот геморрой и проблемы с производительностью которые появляются в ленивых языках.
Списки — фигня! Есть масса задач, где структуры данных удобно делать ленивыми. Не делают — потому что в неленивых языках это будет оверхед.
VD>Там пишут по разному. Есть к примеру оператор |> который теми же F#-щиками юзается на право и на лево. VD>Результат получается аналогичным твоему примеру.
Ладно, проехали. Этот кусок идёт от твоего замечания о неленивых map/fold/filter и от моего о неэффективности цепочки этих функций. Для ленивых спорить не о чем, само собой.
VD>То что Парсек повторен на том же Немерле и реализация получилась вполне компактная не сильно заденет твое самолюбие?
Да мы как бы не меня обсуждаем, так что вряд ли тут что нибудь способно задеть моё самолюбие.
Насчёт парсека на Немерле — мне так и не дали код самого парсека, только его использование. Может дать посмотреть?
Код там такой же лаконичный как и на Хаскеле?
VD>В не ленивых тоже можно, если функции композицию которых мы делаем тоже ленивы. VD>Ну, ёлы-палы, пойми — это тоже самое но вместо map нам надо будет взять map_lazy.
С этим не спорю.
L>>И теперь нам надо foo.goo.hoo. В неленивом языке придётся выписывать map (f.g.h). Ну и где переиспользование в неленивом языке? VD>Да, пиши так же. Только используй foo_lazy.goo_lazy.hoo_lazy и вместо точки оператор >>.
ОК.
VD>Можно. А можно и на макросах. Причем то что скажем Лисп и Немерле имеют первоклассные макросы не отменяет возможности создавать и ДСЛ-и на базе комбинаторов. Пример с повторением Парсека на Немерле я тебе уже привел. Разве его существование не отрицается твоей теорией?
У меня нет теории Его существование будет опровергать мой тезис, если код так же лаконичен как и на ленивом языке, и парсек идентичен хаскелевскому, т.е. ленив.
VD>Да согласная я! Согласная!!! При условии, что ты добавишь слово "иногда". VD>Вот только я тебе устал повторять. Она (ленивость) есть в ленивых по умолчанию языках.
Только не такая лаконичная.
VD>Пойми, если бы ленивость действительно постоянно давала бы ощутимый выигрыш, то в Лиспе и Немерле давно бы сделали макрос: VD>Вот только овчинка выделки не стоит.
Это не доказательство. Так получается — всё то, чего нет в Немерле не стоит выделки.
А если я тебе тоже самое только про строгость со стороны Хаскеля скажу?
VD>Я бы поддержал твою теорию если бы за ленивость не приходилось бы платить. Но за нее нужно платить и платить дорого. Я не хочу связываться с монадами только из-за того, что мне нужно получить вывод на экран или просто выполнить две функции одну за другой. Я уж лучше буду просто делать что хочу, а когда понадобится, то и ленивостью воспользуюсь. Но контролируемой.
Да, кстати, немного оффтопик — думаю, что ленивость не по умолчанию медленнее, чем по умолчанию из-за оптимизаций компилятора.
L>>А что в С# код прямо так превращается в машинные команды, безо всяких разных преобразований? VD>С преобразованиями. Но преобразования эти просты и линейны, так как система одна и та же — Фоннэймоновская.
Так ЛИ ещё проще. И преобразования там тоже простые. Впрочем, это мы отвлеклись.
VD>Хочу узнать когда Хаскель порвет (ну или хотя бы приблизится) по скорости MS С++ (об Intel я вообще молчу) скажем на тесте альфа-блэнда пробегавшем у нас в Философии?
Не знаю. В чём там проблемы расскажи? Может это алгоритм строгий? Ну так, наверное, Хаскель для других задач. Ну или на Хаскеле надо писать строго, будет не так лаконично, конечно.
L>>Повторю свою мысль — цепочка неленивых map/filter/fold неэффективна. Обосную — в силу создания промежуточных структур.
VD>Вот это и есть чушь. Цепочка ЛЮБЫХ map/filter/fold неэффективна в сравнении с аналогичным императивным кодом в силу наличия лишних телодвижений и косвенности. Единственный верный путь оптимизации этих цепочек — это суровый инланинг и превращение их в банальные циклы. Тогда не будет не только промежуточных структур данных, но и вообще ничего лишнего. Будет только сам алгоритм приведенный к виду наиболее эффективно вычисляемому на современных процессорах.
VD>Произвести подобный инлайнинг можно и для ленивой версии и для не ленивой, но в общем случае заинлайнить не ленивую версию будет проще, так как вычисление не может быть передано черти куда.
Тогда вопрос. Заинлайнина ли неленивая версия сейчас? Или всё таки создаются промежуточные структуры. Ленивая — да, не будет порождать структуры + есть stream fusion для компиляции в аналогичный for (в ghc).
L>>И зачем ты мне про LINK написал я не понимаю. Я же тебе написал про итераторы, как ты хочешь моими же аргументами эти же аргументы опровергнуть? VD>Твои аргументы за ленивый язык. А это пример ленивой обработки списков (притом весьма выразительной) в на сквозь императивном не ленивом языке. Понятно?
Нет, так как я оспаривал не это.
VD>Я смотрю на результат. А он плачевный. Компилируемый язык временами сливает скриптам. А на теоритические рассуждения пускай смотрят юноши бледные с взорами горящими.
Тут можно много говорить
1. Инструмент надо использовать для того, для чего он предназначен.
2. Компилируемый сливает скриптам на том же алгоритме? Можно пример?
VD>Мне надоело отвечать на одни и те же вопросы по сто раз. Отвечаю в последний раз. Увидел. Но не везде и не увидел зачем для этого иметь ленивый язык.
О "везде" я речь не вёл. И как можно увидеть преимущества лени по умолчанию и не увидеть, зачем для этого иметь ленивый язык?
VD>Повторяюсь в сто первый раз. Локонично можно писать и без ленивости. Иногда ленивость упрощает решение задачи и делает его тем самым лаконичнее, а что важнее понятнее. Но это не происходит при любом вызове функции или использовании операторов, а стало быть это перебор. Платить же за это приходится с полна. И я предпочту не платить и иметь немного менее лаконичный код в некоторых случаях.
Ну то есть всё таки такой бенефит иногда есть?
VD>Если рассуждать о Хаскеле, то мне в нем намного больше нравится его система типов поддерживающая классы типов. Вот это действительно интересное решение которое способно повлиять на лаконичность в масштабах всего приложения. А ленивость по умолчанию... Ну, короче ты понял.
Понял
L>>При чём здесь монады?
VD>Притом, что их повсеместное применение в Хаскле как раз вызвано его ленивостью. В обычных языках монады могут понадобиться раз в год. Скажем в F# вот сделали интересное решение для поддержки параллельных вычислений на их базе. Такое их применение я расцениваю как красивое решение. А выводить с их помощью значения на консоль — это, извините за грубость — маразм!
Надо делать отдельную тему.
L>>А стриктнесс в Хаскеле достигается совсем другими механизмами. Подавляющее большинство монад — ленивы. Я же говорю — не разобрался.
VD>Да, ну? Другими средствами? Ой как я сер! Просвети, плиз. Что за другие механизмы такие?
Паттерн матчинг, seq, ($!)
VD>Что же до ленивости монад, то как я их понимаю — это средство заставить вычисления быть последовательными. Конечно можно углядеть ленивость и в монадах, но их суть как раз борьба с ленивостью в отдельных участках программы. VD>Ты по всей видимости перепутал термины "последовательные" и "с побочными эффектами".
Я ничего не перепутал. Ты неправильно понимаешь что такое монады. Монада IO — да, средство заставить вычисления быть последовательными. Другие — совсем необязательно. Монада — всего лишь интерфейс. Как это интерфейс может вычислять последовательно?
Здравствуйте, Gaperton, Вы писали:
G>И какое из этих обоснований говорит в пользу того, что все должно быть по умолчанию ленивым, а не строгим?
Нет слов. Я говорил, что всё должно быть ленивым по умолчанию?
Нет, я говорил, что у ленивости по умолчанию тоже есть преимущества.
Как ты думаешь, если у просто ленивости есть свои преимущества, чего же не пишут с её использованием на неленивых языках? Потому что неудобно и неэффективно.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
T>>Буквально, год назад объяснил тебе всё, что сейчас пытаюсь объяснить. Вроде, ты сказал, что понял. И вот снова вынужден это делать.
G>>Для опровежения тезиса не канают: ... G>>5) Жим штанги на 120 кг, и прочие килограмм-амперы.
LCR>Аааааа!!! Я понял, почему thesz тебя в реале убедил, а здесь ну никак убедить не может!
Однажды мне некий Игорь, менеджер из соседнего направления, рассказывал:
— Я боксер, и вообще мало кого боюсь. В нашей конторе, например, я боюсь только двоих.
— Кого же? — с любопытством спросил я.
— Ну первый — это замдиректора.
— Почему? — удивился я.
— Он больно здоровый. Такого сложно завалить.
— А второй кто?
— Но больше всего я боюсь этого твоего зверя, у тебя в отделе работает. Лысый, здоровый, — со смесью непоодельного страха и уважения говорит Игорь, — с этим ваще никаких шансов!
— А, я кажется понял, о ком ты говоришь. У него, кстати, — небрежно говорю я, — жим штанги 120, ты знаешь?
— Нет! — с ужасом и завистью говорит Игорь, — у меня только 90, но блин 120!!
— А еще, он каратэ в молодости занимался. Кекусинкай, силовой стиль.
— Блин!
— И кроме того, — с годостью перехожожу к финальной части я, — в прошлый новый год он выиграл конкурс "самый умный сотрудник", и ему выдали футболку с соответствующей надписью. Так что "этот зверь" — наш самый крупный специалист. Гордость отдела.
— Да ну?! Что, был такой конкурс? — вконец изумился Игорь. Он был полностью раздавлен.
— Конечно. Первый человек, которого ты боишься, кстати, тоже выиграл этот конкурс — только в номинации "самый красивый".
G>Раз не можешь объяснить — значит не понимаешь. Это раз. На форуме ты в более выгодных условиях, чем в очном разговоре, так как не должен отвечать немедленно, и можешь как следует подумать. Это два. И третье — общение через форум — это публичная дискуссия, и поэтому ты должен трижды подумать, прежде чем перейти на личности. Компрене ву?
T>>>>Я повторю свой вопрос: О чем же мы тогда спорим? T>>>>Какой тезис я доказываю, с твоей точки зрения? G>>>Начал ты с того, что обвинил меня в преждевременной оптимизации. T>>Формально там обвинения нет. G>
G>Короче, ты сторонник преждевременной оптимизации.
G>Формально, я на это ответил не как на обвинение, а дал вежливое разъяснение своей позиции. T>>Добавлю, что формально ты прав, конечно. За исключением того, что это не ответ на вопрос о тезисе, это рассказ об исторических событиях. G>У моего тезиса не выросли ножки, он никуда не убежал, и до сих пор находится по тому же адресу. Если тебе что-то в нем непонятно, он кажется тебе размытым и неоднозначно сформулированным — готов его уточнить по любому из твоих вопросов. G>http://rsdn.ru/forum/message/3215352.1.aspx
В общем и целом, конкретно сейчас конкретно мой опыт говорит, что первый вариант практически любой программы, которую ты ещё не писал, быстрее всего получится написать на Хаскеле. В этом я поддерживаю awson (http://rsdn.ru/forum/message/3214147.1.aspx
Это утверждение условно, то есть имеет условия — например, знание Хаскеля. Малый опыт в предметной области — тоже условие.
Это утверждение может быть поддержано теоретическими аргументами (экстремальная простота ЛИ и максимальная мощность вычислимых термов при ленивых вычислениях).
Это утверждение может быть поддержано практическими аргументами, базирующимися на теоретических — смешение инвариантов при написании программы вредно, это раз, поэтому надо выбрать максимально удобный, второй пункт состоит в том, что наиболее ценно сейчас даже не время программиста, а время выхода на рынок.
Грубо говоря, надо успеть провернуть пару-тройку итераций прежде, чем конкуренты успеют сообразить хотя бы одну. При этом минимизируя затраты по всем фронтам. Значит, нам надо будет пару раз поменять техзадание и гарантировано надёжно распространить изменения по всему коду.
Значит, нам надо иметь минимальный объём исходного кода, максимальную эффективность исполнения при минимуме вложений в неё и строгую типизацию. Плюс знание языка.
Что получается?
Если я примерно одинаково знаю энергичный и ленивый язык, то надо выбирать ленивый. Фора у ленивого, там меньше писать.
Если я примерно одинаково знаю статически типизированный и динамически типизированный, то надо выбирать статически типизированный. Фора у более статически типизированного, там меньше тестировать.
Если я примерно одинаково знаю компилируемый и интерпретируемый, то надо выбирать компилируемый. Фора у лучше компилируемого, там меньше оптимизировать.
В общем и целом, фора у Хаскеля по одному или более параметров в случае программы, которую ты ещё не писал.
Если правильно понимаю рынок труда, то на написание уже написанной программы людей не берут. Берут с опытом в близкой предметной области, возможно, но всё равно что-то будет отличаться.
Из моего опыта следует, что аннотации строгости в общем не нарушают общего ленивого порядка вычислений. Всего одна аннотация поможет убрать ленивость из значительного числа вычислений.
А вот обратное не совсем верно.
Грубо говоря, если у тебя строгий map, то ты не можешь сделать его ленивым, просто пометив, если у тебя под рукой нет его текста. Форсировав чанк с отложенным map, ты обязательно вычислишь и голову, и хвост. Не уверен, что это хорошо. Точнее, уверен, что это плохо.
Whole program analysis, получается, нужен.
Получается, что аннотации ленивости дороги в сравнении.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
VD>>>>>А ты уверен, что надо быть курицей, чтобы рассуждать о вкусе яичницы? T>>>>Поваром — да.
Q>Ну да, ну да. Сперва добейся того же, что и Сергей Зефиров, а потом берись критиковать Хаскель.
Что это означает?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Хорошо стартовали многие строгие языки, и один ленивый — Хаскель. G>До Хаскелла был весьма популярен Clean, а до него -- коммерческая Миранда... G>Хаскел-то и разработали, что бы избавиться от гнёта Миранды... :о)
Здравствуйте, thesz, Вы писали:
T>В общем и целом, конкретно сейчас конкретно мой опыт говорит, что первый вариант практически любой программы, которую ты ещё не писал, быстрее всего получится написать на Хаскеле. В этом я поддерживаю awson (http://rsdn.ru/forum/message/3214147.1.aspx
Здравствуйте, geniepro, Вы писали:
L>>Да вообще bang patterns достаточно, если мы везде их будем использовать.
G>Две проблемы: нестандартность (Hugs98 не понимает) и невозможность использования в лямбдах...
Кто-то пользуется Hugs98??
Ну, а в лямбдах вообще много проблем — больше одного паттерна не напишешь, например. Но не bang patterns:
{-# LANGUAGE BangPatterns #-}
main = print ((\ !x !y -> x+y) (2+2) (4-1))
после \ только пробел оставляй или первый параметр в скобки бери первый параметр, а то будет думать, что это оператор такой (\!)
Здравствуйте, geniepro, Вы писали:
G>Здравствуйте, thesz, Вы писали:
T>>Первый релиз Clean 1994.
G>Надо же, я думал Клин старше...
Это именно первый публичный релиз по ходу дела, перый "внутренний" был ещё в 1987-м вроде как (здесь).
SPJ вроде не раз упоминал, что Плазмейер активно участвовал в работе над Хаскелем и по первости были идеи "слить" 2 языка.
Re[14]: Ленивые языки - за и против
От:
Аноним
Дата:
18.12.08 22:26
Оценка:
Здравствуйте, lomeo, Вы писали:
L>Кто-то пользуется Hugs98??
Да. Я, регулярно. Потому что на моём айподе ghc не завёлся, а геморроиться с портированием мне лень.
Здравствуйте, lomeo, Вы писали:
VD>>Я и так прекрасно знаю где и как рулит ленивость. Вот только, то что она иногда рулит не является доказательством того, что она рулит всегда и везде, и того, что она должна быть по умолчанию.
L>Я не говорил о том, что она должна быть по умолчанию. Я говорил о том, что у ленивости по умолчанию есть свои преимущества.
А недостатков нет?
Мне надоело повторять одно и то же по сто раз.
В этот спор я в основном ввязался только потому, что утверждение о преимуществах ленивости в общем и Хаскеля в частности начинают выглядит на этом форуме как истина в последней инстанции. Меж тем это далеко не так.
Решение Хаскеля — это предпочтение чего-то и потери чего-то другого.
Несомненно, что есть люди которые считаю, что преимущества перевешивают недостатки. Но есть и другие.
Тормоза (притом не предсказуемые), необходимость использования монад на ровном месте, необходимость думать о коде как о ленивом для меня превышают преимущества которые можно из этого извлечь. Ибо извлекаются они изредка, а проблемы создают постоянно.
Собственно на этом я данную дискуссию закончил. Просьба не отвечать на мое сообщение если у вас не будет аргументов которые смогут зародить во мне сомнение в моей правоте, потому как повтор догм изрекаемых сторонниками Хаскеля уже порядком утомил.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VoidEx, Вы писали:
VE>Здравствуйте, VladD2, Вы писали:
VD>>В том, что компьютер на котором выполняется программа и так может выполнить B после A. Так что не иметь возможности напрямую воспользоваться этой базовой возможностью просто глупо. А уж привлекать для решения этой "сверх задачи" функциональные абстракции просто юмористично. Это уже теория ради теории.
VE>Ничего не понял. Пользуйся. Тебя смущает, что блок кода имеет тип "Вычисление-значения int" а не просто "int"? Или слово "монада"?
Меня смущает высосанная из пальца необходимость использовать сущности (в данном случае монады) для элементарных вещей вроде последовательного исполнения. Я хочу чтобы была гарантия, что написав A(); B(); я получил бы последовательное их выполнение. И не хочу иметь геморрой.
VE>Всё равно, что в Немерле блок кода имел бы тип "computation of int" вместо просто "int"
А зачем?
VE>(просто умолчание другое выбрано, вместо 'pure int' и 'int' сделано 'int' и 'compute int').
Нет. Не просто. Вот А после Б — это просто. А связывание А и Б по средством функций и каких-то там промежуточных структур данных — блин, маразм полнейший. Причем вызванный пуританскими рассуждениями о чистоте.
VE>Это просто такой декларативный способ описать вычисление. Плохо, что с ним мало, что можно сделать, разве что прицепить к другому вычислению, но это уже другой вопрос.
Это просто такой мазохизм. Смысла нет, но очень красиво (для некоторых).
VD>>Они применяются чтобы написать 3-5 базовых функций VE>А в монаде 2 функции.
И они лишние в 99% случаев.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
