G>>>Меня бесполезно агитировать. И я не считаю Хаскель оптимальным выбором для очень широкого круга задач. И в особенности — высоконагруженных серверов. Как я сказал — верования меня не интересуют, меня интересуют факты, и рассуждения. A>>Вы, боюсь, недостаточно знаете Хаскелл, чтобы такие обсуждения имели смысл.
VD>А ты уверен, что надо быть курицей, чтобы рассуждать о вкусе яичницы?
Поваром — да.
Курица здесь "Хаскель".
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
VD>Можно конечно возразить, что писать функции аналогичные Repeat проще на ленивом языке, но ёлы-палы, кто же будет их писать постоянно? Нам реально нужны Map и Fiter. Ну, на крайняк напишем еще пару более специализированных функций. А скажем функции вроде Fold вообще бессмысленно делать ленивыми. Нам же ведь нужен результат, а не процесс!
*Main> foldr (\x list -> x+1:1:list) [] [1,error "aaa!!!",2]
[2,1,*** Exception: aaa!!!
*Main> take 2 $ foldr (\x list -> x+1:1:list) [] [1,error "aaa!!!",2]
[2,1]
С ленивыми fold проще.
Меньше надо думать.
И результат нам может быть нужен разный.
Чаще всего — это просто работающая программа, пусть медленно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
VD>Хочу узнать когда Хаскель порвет (ну или хотя бы приблизится) по скорости MS С++ (об Intel я вообще молчу) скажем на тесте альфа-блэнда пробегавшем у нас в Философии?
Отличие: ленивость не по умолчанию, к сожалению, не будет лаконичной.
G>Пример ленивой программы, где преимущество от ленивости по умолчанию будет до такой степени значимым по сравнению со строгостью по умолчанию, что заставит меня забыть про неконтроллируемый расход памяти и задержки.
Здравствуйте, awson, Вы писали:
А> Разговоры, что лучше — в лоб или по лбу, с моей точки зрения, совершенно пустые. Содержательно, проблема именно в семантике вычислений, а не в том, куда двигать "умолчание".
По моему, пустые разговоры развели вы с thesz. Содержательно, проблема именно в семантике вычислений по умолчанию.
Есть, например, языки, где не ленивыми являются только конструкторы, а все остальное — строгое. Пример — Hoar, в котором нет озвученных проблем, не может там накопится невычисленная цепочка, при этом — можно вполне комфортно манипутировать бесконечными структурами данных.
Есть языки, полностью ленивые по умолчанию, но где абсолютно все можно сделать строгим, как например, в Clean.
Есть языки, где ленивые вычисления делаются явно — как например, в Схеме (delay-force, или что-то в этом роде), или Alice ML (посредством фьючерсов).
А> В том же Хаскелле strictness annotation можно расставить отнюдь не везде и отнюдь не всякое вычисление сделать строгим. Я не знаю, что конкретно Вы имеете в виду (если вообще) под "строгостью по умолчанию с lazy annotation", но предполагаю, что с этим будет еще хуже.
Вы думаете ваши предположения о свойствах того, чего вы не знаете, имеют какую-то ценность? Для примера, что такое Lazy Annotation и как она внедряется в срогий язык — почитайте книгу Криса Окасаки "Purely Functional Data Structures", где он описывает lazy annotation для SML. Слышали о таком парне и этой его работе? Вот и посмотрите, что он имеет под этим в виду, если вообще имеет.
Меня всегда удивляло — что именно заставляет людей, не понимающих о чем речь, лезть в дискуссию, и превращать ее в флейм. Ведь не могут никак смолчать, не могут!
A>Вы, боюсь, недостаточно знаете Хаскелл, чтобы такие обсуждения имели смысл.
Вы, боюсь, недостаточно разбираетесь в языках программирования, чтобы вести осмысленное обсуждение. Только и всего.
Здравствуйте, D. Mon, Вы писали:
L>>б) А что на Камлах и Немерлях пишут — map f . map g . map h?
DM>Пишут, пишут! Просто не List.map (который создает новый список), а, например, Enum.map (который ленивый).
Ну ты из контекста не выдирай
Обрати внимание, VladD2 писал про неленивые map/fold/filter. Ещё обрати внимание — я писал про итераторы.
G>Вы думаете ваши предположения о свойствах того, чего вы не знаете, имеют какую-то ценность? Для примера, что такое Lazy Annotation и как она внедряется в срогий язык — почитайте книгу Криса Окасаки "Purely Functional Data Structures", где он описывает lazy annotation для SML. Слышали о таком парне и этой его работе? Вот и посмотрите, что он имеет под этим в виду, если вообще имеет.
SML с указаниями ленивости так и не стартовал. Вне зависимости от того, насколько хороша идея Окасаки.
Хорошо стартовали многие строгие языки, и один ленивый — Хаскель.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
G>>2) Твой опыт исключается двумя темами, из которых одну вы с potan не доделали, а вторая — это архитектурные прототипы харда, который ты делал в одиночку на выброс.
T>Я совсем не понял этого предложения.
Ты ничего кроме прототипов не писал на Хаскеле. Это понятно?
T>Ээээ. И? T>Ээээ. И?
Я тебе все сказал в предыдущем посте.
Это не засчитывается за значимый опыт разработки. Это так называемое "экспериментальное программирование".
T>>>Видимо, то было лично, вне просторов RSDN, а это "не считается". G>>Видимо, сейчас ты просто придумываешь те события, которых не было.
T>Это было при свидетелях. При том же самом potan.
Я не понимаю, что "это".
T>Действительно, всё, что вне просторов RSDN, в зачёт не идёт.
В зачет не идут туманные намеки на то, не знаю что. Независимо от того, проходит то, неизвестно что, на просторах RSDN, или нет. Я не понимаю, как ты можешь говорить, что в реале ты меня в переубедил в "этом" споре, и одновременно не понимать, о чем мы спорим.
T>Запомню.
Запомни.
T>>>И как ты просто обязан знать, "знать и применять" не означает "способен просто и доходчиво объяснить другим". G>>Ну да, это на самом деле так. Способность научить — третий, высший уровень понимания предмета. Первый — повторение, второй — умение применять. G>>Удивительно, как же у тебя тогда-то получилось мне все объяснить, буквально год назад, а сейчас ты почему-то даже не пытаешься, все больше взываешь у духу святого Вадлера и грозишь гневом монад.
T>Личное общение и общение через форум полностью эквивалентны?
Раз не можешь объяснить — значит не понимаешь. Это раз. На форуме ты в более выгодных условиях, чем в очном разговоре, так как не должен отвечать немедленно, и можешь как следует подумать. Это два. И третье — общение через форум — это публичная дискуссия, и поэтому ты должен трижды подумать, прежде чем перейти на личности. Компрене ву?
T>>>Я повторю свой вопрос: О чем же мы тогда спорим? T>>>Какой тезис я доказываю, с твоей точки зрения? G>>Начал ты с того, что обвинил меня в преждевременной оптимизации.
T>Формально там обвинения нет.
Короче, ты сторонник преждевременной оптимизации.
Формально, я на это ответил не как на обвинение, а дал вежливое разъяснение своей позиции.
T>Добавлю, что формально ты прав, конечно. За исключением того, что это не ответ на вопрос о тезисе, это рассказ об исторических событиях.
У моего тезиса не выросли ножки, он никуда не убежал, и до сих пор находится по тому же адресу. Если тебе что-то в нем непонятно, он кажется тебе размытым и неоднозначно сформулированным — готов его уточнить по любому из твоих вопросов. http://rsdn.ru/forum/message/3215352.1.aspx
G>>Потом я сказал, что считаю lazy annotation более продуктивной, чем strictness annotation. Привел обоснование. И попросил тебя по правилам это опровергнуть.
T>Опять не о моём тезисе.
Единственный твой тезис, который ты сформулировал четко, состоял в том, что я ничего не понимаю в функциональном программировании, и не могу понимать, потому что написал на ФЯ несколько сотен строк кода. Я это даже комментировать не буду. Если ты ограничишься им, то я просто буду вынужден послать тебя в жопу — это будет наиболее адекватный ответ. Тезис, Сергей, формулируют спокойно, без эмоций.
T>То есть, ты не выдаешь критериев, которым должны соответствовать примеры или доказательства, а оставляешь решение за собой. T>То есть, никто никогда не сможет соответствовать твоим внутренним критериям, пока ты так не решишь. T>Подобрать аргументы в таком случае не представляется возможным по объективным причинам.
Для опровержения моего тезиса достаточно любого из трех способов:
1) Опровергнуть или доказать небольшую значимость (путем приведения workaround, например) для двух проблем (память + задержки), лежащих в его основе.
2) Показать неверность рассуждения в обосновании.
3) Привести контрпример.
L>Ты хочешь, чтобы я показал, что ленивый код лаконичен? Или что лаконичность — это преимущество, я не очень понимаю, что от меня требуется.
Пример ленивой программы, где преимущество от ленивости по умолчанию будет до такой степени значимым по сравнению со строгостью по умолчанию, что заставит меня забыть про неконтроллируемый расход памяти и задержки. Видишь ли, я для себя всегда сам решаю, что для меня перевешивает.
Для опровежения тезиса не канают:
1) Переходы на личности.
2) Обвинение меня в недостаточном профессионализме.
3) Разрывание тельжек на грудях.
4) Биение себя пятками в грудь.
5) Жим штанги на 120 кг, и прочие килограмм-амперы.
Здравствуйте, Gaperton, Вы писали:
G>Есть, например, языки, где не ленивыми являются только конструкторы, а все остальное — строгое. Пример — Hoar, в котором нет озвученных проблем, не может там накопится невычисленная цепочка, при этом — можно вполне комфортно манипутировать бесконечными структурами данных. G>Вы думаете ваши предположения о свойствах того, чего вы не знаете, имеют какую-то ценность? Для примера, что такое Lazy Annotation и как она внедряется в срогий язык — почитайте книгу Криса Окасаки "Purely Functional Data Structures", где он описывает lazy annotation для SML. Слышали о таком парне и этой его работе? Вот и посмотрите, что он имеет под этим в виду, если вообще имеет. G>Есть языки, где ленивые вычисления делаются явно — как например, в Схеме (delay-force, или что-то в этом роде), или Alice ML (посредством фьючерсов).
Вот вы заявляете что я "не умею читать, что мне пишут", на что я специально обращаю Ваше внимание, что веду речь о делах "вполне прагматичных" и о *выборе из существующих инструментов*. Должен ли я теперь понимать, что вы всерьез предлагаете Схему, Alice ML, Hoar и книгу Окасаки вместе или по-отдельности как лучший выбор по сравнению с GHC platform?
G>Вы, боюсь, недостаточно разбираетесь в языках программирования, чтобы вести осмысленное обсуждение. Только и всего. G>Есть языки, полностью ленивые по умолчанию, но где абсолютно все можно сделать строгим, как например, в Clean.
Как я понял, Вы достаточно разбираетесь в языках программирования, чтобы делать подобные утверждения. В связи с этим задам вопрос — делает ли Clean редукцию дальше WHNF?
Здравствуйте, VladD2, Вы писали:
VD>Что же до ленивости монад, то как я их понимаю — это средство заставить вычисления быть последовательными. Конечно можно углядеть ленивость и в монадах, но их суть как раз борьба с ленивостью в отдельных участках программы. VD>Ты по всей видимости перепутал термины "последовательные" и "с побочными эффектами".
Я с тобой во многом согласен про ленивость по умолчанию, но твои рассуждения про монады лучше опустить, серьёзно.
Gaperton,
T>Буквально, год назад объяснил тебе всё, что сейчас пытаюсь объяснить. Вроде, ты сказал, что понял. И вот снова вынужден это делать.
G>Для опровежения тезиса не канают: ... G>5) Жим штанги на 120 кг, и прочие килограмм-амперы.
Аааааа!!! Я понял, почему thesz тебя в реале убедил, а здесь ну никак убедить не может!
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, awson, Вы писали:
G>Короче, я сторонник контроля над оружием, тьфу, явного управления ленивостью, посредством фьючерсов и стримов (ленивых списков), и строгости по умолчанию.
Насчет строгости по-умолчанию. У меня, к примеру, есть небольшой DSL для описания конечных автоматов (типа FRP).
На Хаскеле типичный код будет выглядеть так:
-- | переключалка между несколькими сценами
scene = state1
where state1 = switch scene1 [event1 --> state2,
event2 --> state3]
state2 = switch scene2 [event3 --> ...]
...
stateN = ...
-- | тупой счетчик
counter n = switch (pure n) [tick --> counter (n+1)]
Здесь state1..N/counter и т.д. -- это обычные ленивые хаскельные выражения. Спокойно взаиморекурсивно ссылаются друг на друга.
В кемле (и в любом eager языке) так сделать не получится. Не даст он запросто выражениям ссылаться друг на друга
Тот же код на кемле
(** переключалка между несколькими сценами *)let scene =
let rec state1 _ = switch scene1 [event1 -=> state2,
event2 -=> state3]
and state2 _ = switch scene2 [event3 -=> ...]
...
and stateN _ = ...
in
state1 ()
(** тупой счетчик *)let rec counter n = switch (pure n) [tick -=> fun _ -> counter (n+1)]
Тут приходится вместо выражений делать ф-ии с фейковым параметром. Приходится добавлять еще один оператор (-=>), чтобы уметь переходить не сразу на следующее выражение, как (-->), а вызывать ф-ию, и только потом переходить на ее результат. И если первый пример (со взаиморекурсивными выражениями) без фейковых ф-ий даже компилиться не будет, то второй отлично скомпилится и упадет по stack overflow (что хоть лечится и быстро, но все равно неприятно).
В итоге, мало того, что код стал менее читаемым, так еще и дополнительные глюки появляются. Я уж не говорю о том, что, показывая вариант на кемле человеку неподготовленному, приходится объяснять заметно больше не имеющих отношения к делу сущностей, чем в варианте на хаскеле.
А главная проблема строгости по-умолчанию -- это то, что ты работаешь с вычислениями, где надо думать, что и в какой последовательности считается (особенно, если язык не чистый). В ленивом языке ты работаешь с выражениями, а это уже другой уровень. Даже какой-нить print foo в хаскеле -- это не вывод на экран, а выражение-действие, которое выведет что-то на экран только когда оно попадет в main. До того, как оно попало в main с ним можно делать что угодно. mapM/replicateM -- это не циклы, а всего-лишь ф-ии, работающие с выражениями, и возвращающие выражения. В неленивом языке пришлось бы делать процедуры и управляющие структуры, учить больше, работать уровнем ниже.
Может объяснил и несколько сумбурно (мне кажется этот момент надо почувствовать, так его не передать), но важно то, что ленивость позволяет подняться уровнем выше, и это ее главный плюс. А если по-умолчанию все строго, то возможность работать на более высоком уровне становится очень призрачной (надо везде ручками писать lazy). Это возврат в обычное структурное программирование, шаг назад.
Здравствуйте, VladD2, Вы писали:
VD>В том, что компьютер на котором выполняется программа и так может выполнить B после A. Так что не иметь возможности напрямую воспользоваться этой базовой возможностью просто глупо. А уж привлекать для решения этой "сверх задачи" функциональные абстракции просто юмористично. Это уже теория ради теории.
Ничего не понял. Пользуйся. Тебя смущает, что блок кода имеет тип "Вычисление-значения int" а не просто "int"? Или слово "монада"? Всё равно, что в Немерле блок кода имел бы тип "computation of int" вместо просто "int" (просто умолчание другое выбрано, вместо 'pure int' и 'int' сделано 'int' и 'compute int'). Это просто такой декларативный способ описать вычисление. Плохо, что с ним мало, что можно сделать, разве что прицепить к другому вычислению, но это уже другой вопрос.
VD>Они применяются чтобы написать 3-5 базовых функций
А в монаде 2 функции.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, thesz, Вы писали:
VD>>>>>А ты уверен, что надо быть курицей, чтобы рассуждать о вкусе яичницы? T>>>>Поваром — да.
Q>Ну да, ну да. Сперва добейся того же, что и Сергей Зефиров, а потом берись критиковать Хаскель.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, awson, Вы писали:
G>>>Меня бесполезно агитировать. И я не считаю Хаскель оптимальным выбором для очень широкого круга задач. И в особенности — высоконагруженных серверов. Как я сказал — верования меня не интересуют, меня интересуют факты, и рассуждения. A>>Вы, боюсь, недостаточно знаете Хаскелл, чтобы такие обсуждения имели смысл.
VD>А ты уверен, что надо быть курицей, чтобы рассуждать о вкусе яичницы?
Влад, ну только в фанатизм не впадай опять? Нет, курицей быть не нужно, как и не нужно быть создателем Хаскеля, но сожрать его хоть раз надо бы.
Я поражаюсь, как ты умудряешься пол сообщения говорить здраво, а в конце ляпнуть в полной уверенности какую-нибудь чушь в предмете, в котором ты не разобрался.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
