Здравствуйте, VladD2, Вы писали:
VD>Меня смущает высосанная из пальца необходимость использовать сущности (в данном случае монады) для элементарных вещей вроде последовательного исполнения. Я хочу чтобы была гарантия, что написав A(); B(); я получил бы последовательное их выполнение. И не хочу иметь геморрой.
А кстати, вот, насколько я помню, в C++ нет гарантии последовательного исполнения в конструкции f(A(),B()). Имеется в виду порядок вычисления аргументов. Дотнет и/или Немерле дают здесь какую-либо гарантию?
Здравствуйте, VladD2, Вы писали:
L>>Обрати внимание, VladD2 писал про неленивые map/fold/filter. Ещё обрати внимание — я писал про итераторы.
VD>Вообще-то я их не делил. И говорил тебе, что как раз таки есть линивые формы этих функций которые точно так же можно объеденять в комбинаторы.
VD>Так что для реальной жизни важно чтобы map, fold, filter, forall и т.п. не проигрывали по скорости аналогичным циклам в компилируемых языках. А ленивы он или нет дело десятое.
На что я тебе ответил
В цепочке map/filter/fold важно ленивы они или нет. Неленивые — неэффективны (или вообще невозможны для бесконечных списков). Поэтому так популярны итераторы.
Здравствуйте, VladD2, Вы писали:
VD>>>Я и так прекрасно знаю где и как рулит ленивость. Вот только, то что она иногда рулит не является доказательством того, что она рулит всегда и везде, и того, что она должна быть по умолчанию.
L>>Я не говорил о том, что она должна быть по умолчанию. Я говорил о том, что у ленивости по умолчанию есть свои преимущества.
VD>А недостатков нет?
Есть.
VD>В этот спор я в основном ввязался только потому, что утверждение о преимуществах ленивости в общем и Хаскеля в частности начинают выглядит на этом форуме как истина в последней инстанции. Меж тем это далеко не так.
Даже не знаю, что сказать.
VD>Решение Хаскеля — это предпочтение чего-то и потери чего-то другого.
Согласен.
VD>Несомненно, что есть люди которые считаю, что преимущества перевешивают недостатки. Но есть и другие.
При чём тут люди? Есть ситуации (задача, сроки, знание языка и т.д.), когда перевешивают. Есть другие.
VD>Тормоза (притом не предсказуемые), необходимость использования монад на ровном месте, необходимость думать о коде как о ленивом для меня превышают преимущества которые можно из этого извлечь. Ибо извлекаются они изредка, а проблемы создают постоянно.
То, что для тебя таких ситуаций (когда ленивость по умолчанию перевешивает) нет, не означает, что их нет вообще.
VD>Собственно на этом я данную дискуссию закончил. Просьба не отвечать на мое сообщение если у вас не будет аргументов которые смогут зародить во мне сомнение в моей правоте, потому как повтор догм изрекаемых сторонниками Хаскеля уже порядком утомил.
К сожалению, я не знаю, что способно зародить в тебе сомнение. Мало того, неприятия твоей точки зрения у меня не было. Я всего лишь отставивал своё мнение. У ленивости по умолчанию есть бенефиты — например, лаконичность. Наверное, стоило добавить — не везде, не всегда, не для всех, может быть и спора не было бы.
Здравствуйте, http://migmit.vox.com/, Вы писали:
L>>Кто-то пользуется Hugs98??
HMV>Да. Я, регулярно. Потому что на моём айподе ghc не завёлся, а геморроиться с портированием мне лень.
M>>А что, Nemerle уже порвал? VD>В некоторых случаях — да. В среднем, позволяет писать код близкий по скорости к С++-ному.
Я не про некоторые случаи
Хочу узнать когда Хаскель порвет (ну или хотя бы приблизится) по скорости MS С++ (об Intel я вообще молчу) скажем на тесте альфа-блэнда пробегавшем у нас в Философии?
Здравствуйте, thesz, Вы писали:
T>Я чуть выше выделил жирным мой вопрос.
Свои тезисы формулируй пожалуйста сам. Я тебе уже сказал, что единственное, что ты сформулировал четко — это то, что я ничего не понимаю в ФП. Догадываться, что ты еще хочешь сказать, не вижу смысла — скажи это прямо. Пока ты этого не сделаешь — спорить не буду. Времени жалко.
T>Я сейчас читаю твой ответ и ничего не понимаю.
Мне кажется, я простым русским языком пишу. Извини, лучше не смогу. Формулировка "ничего не понимаю" практически исключает возможность общения.
T>Ладно, зайду с другой стороны.
"Я не понял ваш вопрос, но попробую ответить". Вместо того, чтобы понять, что я хочу сказать, ты втягиваешь меня в непонятный, бессмысленный спор, вынуждая зачем-то отвечать на твои "выстрелы в молоко". Времени не жалко? Впрочем, свое время и мыслительные усилия ты таким подходом минимизируешь.
T>В общем и целом, конкретно сейчас конкретно мой опыт говорит, что первый вариант практически любой программы, которую ты ещё не писал, быстрее всего получится написать на Хаскеле. В этом я поддерживаю awson (http://rsdn.ru/forum/message/3214147.1.aspx
Первый вариант практически любой программы, которую ты еще не писал, быстрее всего получится написать на том языке, который ты знаешь лучше всего. Учитывая, что ты умеешь хорошо писать всего на трех языках — С, Хаскеле, и tcl (всякие Эпиграммы не считаем), меня не сильно удивляет, что именно говорит твой опыт.
Удивляет другое — что ты при этом претендуешь на вселенскую истину, думая, что твой субъективный опыт перечеркивает опыт всех остальных людей. Более того, я не совсем понимаю, почему я это от тебя выслушиваю — к теме ленивости и строгости по умолчанию это относится слабо.
T>Даже первый вариант высоконагруженного сервера.
На Хаскеле при этом ты писал не "практически любые программы", а консольные приложения, без активного ввода-вывода, без персистентных данных, без сетевого ввода вывода, без GUI, то есть — неинтерактивные, неограниченные по ресурсам, работающие в batch mode утилиты.
Предметные области которые ты знаешь — ты достаточно хорошо представляешь себе разработку игр, моделирование аппаратуры, да и, собственно, все. Если я что-то пропустил — добавь.
T>Что получается?
Получается, что у тебя недостаточно опыта, чтобы делать такие выводы, так как ты просто не знаком с нюансами. К сожалению, ты просто понятия не имеешь, о чем говоришь. Простой такой контрпример — складскую программу я сделаю на 1С примерно в 10 раз быстрее, чем ты на Хаскеле. Дальнейшее опускаю — у меня нет ни малейшего желания рассуждать на тему, насколько ленивые вычисления лучше чем строгие. Не интересно.
T>Что подумалось.
T>Из моего опыта следует, что аннотации строгости в общем не нарушают общего ленивого порядка вычислений.
Не понимаю, что такое "общий ленивый порядок вычислений".
T>Всего одна аннотация поможет убрать ленивость из значительного числа вычислений.
Так же, как всего одна аннотация поможет добавить ленивость в значительное число вычислений.
T>А вот обратное не совсем верно.
Совсем верно. Нет никакой фундаментальной разницы между аннотациями строгости и ленивости.
T>Грубо говоря, если у тебя строгий map, то ты не можешь сделать его ленивым, просто пометив, если у тебя под рукой нет его текста.
Строгий или ленивый map — это не совсем корректно сказать. Смотри.
map( [ H | T ], F ) -> [ F( H ) | map( T, F ) ];
map( [], _ ) -> [].
Здесь у тебя два момента. Первое — ленивый или не ленивый у тебя конструктор списка. Это — одно. Второе — ленивое или энергичное у тебя вычисление функции F. Допустим, я хочу сделать применение F энергичным (сама F внутри может быть при этом ленивой) — это я пишу в коде map, а тип конструктора списка — таким же как конструктор списка-аргумента. Второе я могу сделать, сохранив общее полиморфное описание алгоритма. Так сделано в Clean, например.
T> Форсировав чанк с отложенным map, ты обязательно вычислишь и голову, и хвост. Не уверен, что это хорошо. Точнее, уверен, что это плохо.
Если я напишу (назовем ленивое присваивание ?=) вот так
Res ?= map( Source, Fun )
И дам ему строгий список — то да. Если я дам ему аргументом ленивый список — то нет, даже если я выполню энергичное присваивание. Ты просто не задумываешься сейчас, в каких местах ленивость тебе действительно важна.
T>Whole program analysis, получается, нужен. T>Получается, что аннотации ленивости дороги в сравнении.
Не вижу, как это получается. Ты пример приводить будешь в качестве иллюстрации? Спрашиваю уже раз в пятый.
Здравствуйте, VladD2, Вы писали:
VD>Меня смущает высосанная из пальца необходимость использовать сущности (в данном случае монады) для элементарных вещей вроде последовательного исполнения. Я хочу чтобы была гарантия, что написав A(); B(); я получил бы последовательное их выполнение. И не хочу иметь геморрой.
Так и пишут. Вот прямо так do { A; B }, ну или A >> B. Тут, конечно, не точка с запятой, но неужто принципиально.
Всё-таки тебя пугает факт наличия страшной монады. Было бы ключевое слово "action of", наверняка бы не волновался. Типа как mutable для обозначения изменяемой переменной, так и action для обозначения нечистого блока кода.
Здравствуйте, Mamut, Вы писали:
M>Я не про некоторые случаи
M>
M>Хочу узнать когда Хаскель порвет (ну или хотя бы приблизится) по скорости MS С++ (об Intel я вообще молчу) скажем на тесте альфа-блэнда пробегавшем у нас в Философии?
M>)
Предполагаю, что Немерле достаточно (для некоторых) приблизился, иначе бы этой фразы в скобках не было бы
Здравствуйте, lomeo, Вы писали:
L>На что я тебе ответил
L>
L>В цепочке map/filter/fold важно ленивы они или нет. Неленивые — неэффективны (или вообще невозможны для бесконечных списков). Поэтому так популярны итераторы.
L>И понеслась!..
И как из этих слов ты вывел, что я говорил о не ленивых версиях этих функций? Как раз очевидно видно, что я говорил обо всех вариантах.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
M>Хочу узнать когда Хаскель порвет (ну или хотя бы приблизится) по скорости MS С++ (об Intel я вообще молчу) скажем на тесте альфа-блэнда пробегавшем у нас в Философии?
M>)
Ну, и? Где тест Хаскеля на этом примере?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, deniok, Вы писали:
D>А кстати, вот, насколько я помню, в C++ нет гарантии последовательного исполнения в конструкции f(A(),B()). Имеется в виду порядок вычисления аргументов. Дотнет и/или Немерле дают здесь какую-либо гарантию?
Я не знаток стандартов. Посему не уверен, что твое первое утверждение верно. Но это чистой воды офтоп. Достаточно, что все перечисленные языки гарантируют выполнение A(); B().
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>И как из этих слов ты вывел, что я говорил о не ленивых версиях этих функций? Как раз очевидно видно, что я говорил обо всех вариантах.
Вот именно.
P.S. Мы уже какую то фигню обсуждаем — вряд ли что то путное из этого выйдет.
Здравствуйте, deniok, Вы писали:
D>А кстати, вот, насколько я помню, в C++ нет гарантии последовательного исполнения в конструкции f(A(),B()). Имеется в виду порядок вычисления аргументов. Дотнет и/или Немерле дают здесь какую-либо гарантию?
Спецификация C# гарантирует выполнение аргументов слева направо, и я никогда не встречал отклонений от этого правила. У немерле, к сожалению, нет спецификации, но насколько мне известно, там это правило тоже соблюдается.
M>>Хочу узнать когда Хаскель порвет (ну или хотя бы приблизится) по скорости MS С++ (об Intel я вообще молчу) скажем на тесте альфа-блэнда пробегавшем у нас в Философии?
M>>)
VD>Ну, и? Где тест Хаскеля на этом примере?
Ээээ.
L>Насчёт оптимизаций — давай без риторических вопросов, что ты хочешь узнать? В GHC есть оптимизации, могу показать много. Всё соптимизировать разумеется нельзя. Хотя бы в силу того, что уже соптимизированное соптимизировать трудно.
Хочу узнать когда Хаскель порвет (ну или хотя бы приблизится) по скорости MS С++ (об Intel я вообще молчу) скажем на тесте альфа-блэнда пробегавшем у нас в Философии?
Мне то же самое интересно про Немерле. Хаскелистам, наверное, тоже
Просто ответ хаскелистов вполне ожидаем — не преназначен для числодробения. Что докажет....Да ничего оно не докажет Как и аналогичный вопрос, примененный к Немерле.
Какие-нибудь Эрлангисты тоже могут встать в позу и попросить наваять на Немерле сервер, держащий пару десятков тысяч запросов в секунду
Здравствуйте, VoidEx, Вы писали:
VE>Так и пишут. Вот прямо так do { A; B }, ну или A >> B. Тут, конечно, не точка с запятой, но неужто принципиально.
Это слишком примитивный пример. Рельно пишут куда заковырестей.
VE>Всё-таки тебя пугает факт наличия страшной монады. Было бы ключевое слово "action of", наверняка бы не волновался. Типа как mutable для обозначения изменяемой переменной, так и action для обозначения нечистого блока кода.
Ага. Мене вообще не понятно, зачем заниматься связыванием вычислений через кучу косвенных ссылок и хип когда их можно просто выполнить последовательно.
Если бы все было просто и можно было просто сказать компилятору, вот этот блок пожалуйста выполни последовательно, а вот этот как захочешь, то и вопросов бы не было. Но в борьбе за чистоту возможность выполнить что-то последовательно просто отняли. И предлагают вместо этого связывать вычисления сентетическими кострукциями. А синтаксчис — это как раз мелочи...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, VoidEx, Вы писали:
VE>>Всё-таки тебя пугает факт наличия страшной монады. Было бы ключевое слово "action of", наверняка бы не волновался. Типа как mutable для обозначения изменяемой переменной, так и action для обозначения нечистого блока кода.
VD>Ага. Мене вообще не понятно, зачем заниматься связыванием вычислений через кучу косвенных ссылок и хип когда их можно просто выполнить последовательно.
Потому что если у тебя есть влияние одного вычисления на другое, то синтаксис гражданских языков не требует уточнения этого влияния. А в Хаскелле ты указываешь, какое влияние A на B. Если нет влияния, то связывание >>, если есть (через результат), то связывание >>=. Плюс ещё конкретная монада задает стратегию связывания: в пресловутой IO, которую ты, похоже, имеешь в виду, произнося "монада", это действительно "одно, затем другое, потому что ввод-вывод". А в монаде Maybe "одно, и если удачно, то другое". А в монаде списка — "одно, и все другие, которые прицепились":
(на этом, кстати, основан сахар лист компрехеншэн)
VD>Если бы все было просто и можно было просто сказать компилятору, вот этот блок пожалуйста выполни последовательно, а вот этот как захочешь, то и вопросов бы не было. Но в борьбе за чистоту возможность выполнить что-то последовательно просто отняли.
Отняли возможность последовательно чудить с побочными эффектами любого рода втайне от компилятора. Хочешь чтобы B зависело от A — будь добр, опиши компилятору каким образом. Если B нужен просто результат A, то никаких монад для последовательного исполнения не требуется: B( A() ).
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Mamut, Вы писали:
M>>
M>>Хочу узнать когда Хаскель порвет (ну или хотя бы приблизится) по скорости MS С++ (об Intel я вообще молчу) скажем на тесте альфа-блэнда пробегавшем у нас в Философии?
Насколько я помню по своим замерам, этот вариант на Хаскелле был в два раза медленнее, чем у Visual C++ (на Celeron-D 2.8).
Ещё я помню, что где-то в обсуждениях альфа-бленда вариант на C# тоже уступил С++ в два раза.
Так что тут Хаскелл по крайней мере не уступил C#, а значит и Немерле, который, по признанию авторов Немерле, компилируется хуже (код медленнее), чем С#...
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, VoidEx, Вы писали:
VE>>Всё-таки тебя пугает факт наличия страшной монады. Было бы ключевое слово "action of", наверняка бы не волновался. Типа как mutable для обозначения изменяемой переменной, так и action для обозначения нечистого блока кода.
VD>Ага. Мене вообще не понятно, зачем заниматься связыванием вычислений через кучу косвенных ссылок и хип когда их можно просто выполнить последовательно.
Это детали реализации. И не забывай про оптимизации — сейчас, думаю, 99% процентов компиляторов занимаются этим. И делают это они довольно успешно. Тем более, что сейчас обсуждаются не детали реализации ленивых вычислений (или уже они?), а сами ленивые вычисления.
VD>Если бы все было просто и можно было просто сказать компилятору, вот этот блок пожалуйста выполни последовательно, а вот этот как захочешь, то и вопросов бы не было.
Так, приехали.
Во-первых, всё очень просто (хотя, конечно же, для некоторых людей это не очень просто, а просто просто).
Во-вторых, всё так и есть. Т.е. компилятору можно говорить, что вот этот блок кода нужно выполнять последовательно, а вот этот — когда понадобится (если вообще его нужно вычислять). Значит ли это, что у тебя уже нет вопросов?
VD>Но в борьбе за чистоту возможность выполнить что-то последовательно просто отняли.
Хватит говорить ерунду о невозможности "выполнить что-то последовательно". Это не правда.
Пример 1:
e = f . g
Ах да, это "слишком простой пример", и кому-то может быть не понятно, о чем собственно речь. Вот пример использования примера 1:
Пример 2:
sincos = sin . cos
Только не нужно пытаться мне доказать, что тут синус может быть посчитан до косинуса. Всё прекрасно вычислятеся последовательно. И никаких монад. Опять же, монада — это всего лишь интерфейс, обязующий предоставлять часть функций, удовлетворяющих некоторым условиям. Всё просто. На детали реализации ограничений никаких нет, так что не стоит судить об этих самых деталях.
Тем более, что свет клином на монадах не сошёлся — можете посмотреть на Clean. Там мы просто "помечаем" функции как "нечистые", т.е. такие, результаты которых зависят не только от входных аргументов, но ещё и от какого-то неявного стейта.
Так что вы либо неверно сформулировали вашу мысль, и тем самым лишили собеседников возможности понять вас и что-то обьяснить, либо имеете не совсем верное представление о хаскелле и ФП вообще.
Очень часто порядок соблюдать порядок вычислений не обязательно. Пример:
fact n = product [1..n]
Тут не важно, в каком порядке производить умножение. Тут важен результат — получить произведение. Так что получившуюся свободу можно отдать на откуп компилятору для оптимизации. Лично я не против.
Если вам нужен "полный контроль" — пишите на асме для RTOS и руками распределяйте регистры и просчитавайте кэш-миссы.
Видимо, так как хаскелл это не язык для написания RTOS и приложений для них, то ленивость по умолчанию в нём никому ничего плохого не делает и не мешает. Ну, а если мешает — то ленивость можно и убрать.
А теперь, если посмотреть на исходники на хаскеле и на количетсво использований bang patterns и seq — то получается, что этих самых приседаний очень мало. И делать всё наоборот смысла особого нет (т.е. зачем загромождать код не несущими смысла конструкциями?)
VD>И предлагают вместо этого связывать вычисления сентетическими кострукциями. А синтаксчис — это как раз мелочи...
Ммм, кажется, именно это тот случай, когда граманаци оказался бы прав, придравшись к ошибкам. Я так и не понял, о чём вы хотели написать. Ну да ладно, попробую угадать.
1. Если вы имели ввиду "связывать синтаксическими конструкциями", так тогда я не могу понять, чем же вы недовольны. По-моему, так везде. Т.е. в языках всё связывается синтаксическими конструкциями.
2. А если "связывать синтетическими конструкциями", то опять не ясно, чем же они отличаются от "синтаксических". Окей, попробую угадать ещё раз. Вы столкнулись с "чуждой" функциональной парадигмой, и, более того, тут вспыли "warm fuzzy things", и вам не понятно, какого чёрта они нужны. Ведь у вас уже есть свой любимый язык и там так всё просто и понятно.
3. А дальше я теряюсь в догадках и прошу помощи.
P.S. Читая эту тему я поразился бурному обсуждению и количеству шума. Самое печальное — это отрыв от реальности, т.е. я нигде так и не увидел, что же именно хочется закодировать/какая область/и т.п. Несколько мыслей:
1. В треде как-то смешались ленивость, порядок вычислений, монады и ещё фиг знает что. Каждый что-то пытается доказать другим, и я так не смог понять, кто что доказывает. Одни говорят, что ленивость губит на корню порядок вычислений, и что использование монад для "форсирования" порядка вычислений это слишком. Смешно, можно подумать, что монады используются только для IO.
И тут и там как-то неявно подразумевается, что в других языках (немерле, ява, си-шарп, Си, Си++) с этим всё отлично и там всегда всё выполняется "последовательно". Хотя порядок вычислений операндов и аргументов функций в Си, например, неопределен (вспомним i = ++i + ++i). И ведь ничего, никто не плачется о вреде неопределённости и небходимости помнить про сиквенс-поинты.
А вот стоило людям убрать неявные "фичи" языка и сделать их явными — так начинается ворчание. Может, стоит забыть про свой возраст, "открыть мозг" и выучить что-то новое, может эти "warm fuzzy things" не такие уж и страшные?
2. Всем понятно, что если есть MCU c 32kib флэшем и 10kib ram, то ни о каких nemerle,C#,F#,Haskell,java говорить не стоит. Как и не стоит говорить про окамль с питоном.
Если есть Embedded device с 2mib RAM и 4mib flash и от него нужен гарантированный отклик при обслуживании энного количества клиентов, то erlang сюда не вписывается, каким хорошим бы он не был. Тут остается выбор между ASM, C и, возможно С++, хотя использование последнего требует более высокой квалификации разработчика.
Когда есть устройство с 128mib RAM и 32mib flash и всё ещё нужен realtime, то никто в здравом уме не станет сюда тянуть nemerle/java. Они плохо подходят, хотя не всё так плохо и есть возможность заставить их работать (как можно написать ОС на паскале, сделать можно, особенно если хочется что-то кому-то доказать, но смысл?).
Для каждой задачи есть свои инструменты. Так почему же в этом треде так не сформулированна задача и исходные условия/окружение? Вот и получается, что каждый что-то "подразумевает" и надеется, что все остальные "адекватны" и "подразумевают" то же самое, что и они.
3. Никто не хочет читать рекомендумые статейки, а только продавливает своё "авторитетное" мнение. Нехорошо получается. Ну да ладно.
4. Несколько мыслей, что пришли мне в голову:
http://www.haskell.org/haskellwiki/DDC -- Disciple is an explicitly lazy dialect of Haskell which supports destructive update, computational effects, type directed field projections and allied functional goodness.
Было бы замечательно посмотреть на сравнение производительности и на реализацию уже существующих ленивых структур на этом чудном диалекте. Вряд-ли будет разница в разы.
Неужели тут никто не может пользоваться поисковиками, либо на худой конец почитать википедию и найти там описание хаскеля и ленивых вычислений? Люди уже привели pros and cons, почему бы не посмотреть? Да, всё в итоге можно свести к программе для тьюринг машины, но вопрос стоит в удобстве написания! Да, ленивые вычисления помогают строить и оперировать с бесконечными структурами данных. Да, то же самое можно сделать с помощью итераторов, ну и что? Только ленивость по умолчанию позволяет избежать оперирования ненужными сущностями и избежать обдумывания деталей реализации. Разве плохо?
Сделать быструю реализацию какого-нибудь факториала/умножения матриц на Си элементарно. Хаскель на этой задаче будет медленным (опять же, если не использовать специально предназначенные для этого библиотеки с ручной оптимизацией кода). Да, при сравнении хаскелла и других языков первый часто "выезжает" только за счёт использования более "продвинутых" алгоритмов. А при одном и том же алгоритме работает медленее. Но почему никто не думает о том, что реализации более сложного алгоритма на хаскелле может оказаться быстрее кодирования простого алгоритма на Си? Разве скорость написания и прототипирования ничего не значит?
Здравствуйте, geniepro, Вы писали:
T>>Хорошо стартовали многие строгие языки, и один ленивый — Хаскель.
G>До Хаскелла был весьма популярен Clean, а до него -- коммерческая Миранда... G>Хаскел-то и разработали, что бы избавиться от гнёта Миранды... :о)
Клин никогда не был особенно популярен, в основном — благодаря дурацкой политике его авторов, которые вдруг почувствовали в нем коммерческий потенциал. Компилятор у них был платный, плюс ко всему — они так и не смогли дописать книгу про свой язык. В контексте данного разговора совершенно не важно, как языки стартовали. Вон, Ява офигенно стартовала, гораздо лучше Хаскеля.
Отличия clean — он задуман, чтобы быть практичным ленивым языком. Uniqueness typing и быстрые "чистые" массивы. Кроме того, clean дает программисту контроль над unboxing. Данные фичи позволяют чистому ленивому языку clean иметь производительность, сравнимую с С++, в том числе и на массивах. То есть, при желании можно проиграть С++ (в меру туповатому gcc) не боле чем процентов 15-30. Если нашпиговать программу под завязку аннотациями строгости и unboxing-ом (анализаторы строгости никогда не смогут найти всю строгость — эта задача NP-полная).
Несколько лет назад мы на RSDN делали несколько микротестов для определения, насколько функциональная парадигма сосет. Ее тогда представляли Clean, OCaml, и Haskell. В качестве задач были взяты довольно неприятные для ФЯ — alpha blending и решето Эратосфена. Программы на Clean писал я. Так вот, решето работало примерно с такой же скоростью, как программа на С++, если пользоваться не vector<bool> а vector<char>, — задача упирается в память, и упаковка 8 значений в байт сильно помогала С++ реализации, что компилятор Clean делать не умел.
Стоит заметить, пока я не подавил всю ленивость в программе, оставив ее только там, где она была реально нужна — а это ленивые хвосты списков, программа вылетала по переполнению памяти, и просто не могла выполнить Эратосфена на мало-мальски вменяемом массиве данных, проблемы начинались с 10 тысяч. Смех один.
Разговоры про "высоконагруженный сервер" тоже довольно забавны. Это был микротест, на большой программе, которая должна предсказуемо себя вести в условиях ограниченных ресурсов, можно будет стреляться. А если у программы нетривиальные use cases — то вешаться, или убиваться об стену, потому что поведение будет разным при разных тестовых воздействиях — ленивость по умолчанию есть отличный источник багов с высоким severity, которые трудно найти.
В клине еще хорошо, что есть memory profiler — можно найти цепочку, отжирающую память. Теоретически. Меня это быстро задолбало, и я везде расставил строгость руками, так проще. Этим и закончится трахотня с расходом памяти на программе, которая работает на ограниченных ресурсах на Хаскеле — другого внятного способа контроля над проблемой нет (теоретически, наверное, возможно заставить сборщик мусора форсировать вычисления для того, чтобы подобрать отложенные цепочки, но это судя по всему не очень хороший подход). Не забивать же голову алгоритмом работы анализатора строгости, в самом деле.
Насчет alpha-blend — было примерно то же самое. Я в результате оставил ленивость только там, где она хорошо смотрелась (и, кстати, не давала penalty по производительности) — это бесконечный список случайных чисел. Так как расставлять везде строгость мягко говоря задалбывает, как решение само собой напрашивается расстановка аннотаций ленивости. Сугубо для экономии количества знаков.
Такую нотацию сложно придумать за пять минут, чтобы она была лишена косяков, но на первый взгляд, вполне достаточно знака ?. С семантикой "все что справа на том же уровне- лениво". Как-то так:
вызов функции fun — ленивый, аргументы вычисляются энергично.
x = ? fun a1 ... an
Вызов функции строгий, все аргументы ленивы.
x = fun ? a1 ... an
Ленивый только первый аргумент.
x = fun ( ? a1 ) ... an
Для справки, реализация на Haskell работала втрое медленнее, чем С++-реализация. И выглядела хуже, чем реализация на Clean — никакой хваленой красоты и выразительности не наблюдалось.
