Стандартной функции Even я не нашёл, так что пришлось определить самому:
Func<int, bool> Even = (x => 0 == x % 2);
VE>А то это, конечно, хорошо, когда на каждое упрощение находится какой-то язык, где это же самое сделано сравнимо просто, но я же на всех этих языках одновременно писать не буду, верно? Так что дайте мне тот, где всё либо так же, либо лучше.
Такого языка нет. Скажем, Хаскель — точно не такой язык.
Q>>
VE>Да и мне этот код потом читать, зачем мне обратный порядок слов?
В том-то и дело, что на F# порядок прямой: данные (randoms) попадают в функцию List.take 25 (т. е. результат каррирования функции List.take при фиксации аргумента), затем результат применения передаётся по конвейеру дальше в функцию List.filter even, её результат в свою очередь... и так далее. А что, если конвеер будет длинным, и придётся перенести на несколько строчек? В Хаскеле придётся читать снизу вверх?
VE>А про "глаза непривычного читателя" опустим, так как незнакомых с языком сажать за него никто не будет.
Почему нет? Вот, скажем, F# позиционируется как язык, за который можно сажать вообще непрограммистов. Смотри, например, книжку «F# for Scientists» by Jon Harrop.
VE>Что за упор на то, чтобы и баран смог прочитать и написать?
Не надо впадать в крайность. Речь не о баранах, а о людях. О «программистах-прагматиках» и «смиренных программистах».
Мы будем программировать гораздо лучше, если только подойдем к задаче, полностью оценивая ее потрясающую сложность, если только мы будем придерживаться скромных и элегантных языков программирования, если только мы примем во внимание свойственные человеческому разуму ограничения и подойдем к задаче как Очень Смиренные Программисты. (Эдсгер Дейкстра)
VE>Я, конечно, не буду говорить, что сам бы везде предпочёл Хаскель, но именно из-за отсутствия .NET или каких-либо библиотек, и в некоторой неуверенности, что если мне, например, придётся делать кастомный контрол, да руками его рисовать, что я вообще осилю это на каком-нибудь wxHaskell, а вот на C#/C++ — точно сделаю. Т.е. банально проверенные миллионами (уж тем более мной лично) технологии как-то надёжнее, вдруг какая библиотека на Haskell развалится в середине проекта, а спросить почти некого, а по .NET'у тому же пол интернета форумов, кто-нибудь да сталкивался, и проект по крайней мере не встанет.
Я об этом же. F# и Nemerle опираются на твёрдую почву .NET, при этом не проигрывая по большому счёту Хаскелю в выразительности. Так зачем платить больше?
VE>А чисто как язык он очень удобен, но в двух примерах этого не покажешь (тем более если убедиться хотят в обратном), это понимание само приходит.
Мало того, чтобы он был удобен. Нужно, чтобы он был удобнее других. Вот положа руку на сердце — Хаскель удобнее Nemerle или F#?
Здравствуйте, Qbit86, Вы писали:
Q>Мало того, чтобы он был удобен. Нужно, чтобы он был удобнее других. Вот положа руку на сердце — Хаскель удобнее Nemerle или F#?
Q>Стандартной функции Even я не нашёл, так что пришлось определить самому: Q>
Q>Func<int, bool> Even = (x => 0 == x % 2);
Q>
Я видел. Я хотел сначала было усложнить пример, но потом передумал.
Хотя вот приведу из реального кода:
result <- modifyMVar someMap $ return.(Map.delete value &&& Map.lookup value)
MVar — синхронизированная переменная, этот код возвращает старое значение по ключу value в map'е, и удаляет его.
Наверняка и на C# это можно как-нибудь в одну строку уместить, но боюсь, что так никто не пишет, и я не буду.
Q>Такого языка нет. Скажем, Хаскель — точно не такой язык.
В Хаскеле что-то сложнее, чем в Хаскеле что ли? Поясните мысль
Q>>>
VE>>Да и мне этот код потом читать, зачем мне обратный порядок слов?
Q>В том-то и дело, что на F# порядок прямой:
Я про порядок слов, а не действий. Мне код читать, а не интерпретировать в голове. Q> В Хаскеле придётся читать снизу вверх?
Слева направо же, как предложение.
Q>Почему нет? Вот, скажем, F# позиционируется как язык, за который можно сажать вообще непрограммистов. Смотри, например, книжку «F# for Scientists» by Jon Harrop.
А ссылка есть? Или она платная?
Q>Я об этом же. F# и Nemerle опираются на твёрдую почву .NET, при этом не проигрывая по большому счёту Хаскелю в выразительности. Так зачем платить больше?
Одинаково. Я вот пока серьёзного на Хаскеле не писал, так, не очень большие программки, но каждый раз замечаю, что тут получилось вместо 5 строк одна, и тут меньше, и там. Вот так понемногу код получается раза в 3 короче, а вносимые изменения влияют только на то место, где я их вношу. Это не объяснить словами.
Так что если у меня будет необходимость писать под .NET, разумеется, я не буду биндинги через одно место под Хаскель писать, я просто возьму F# или Nemerle. Но пока я не связан .NET'ом, я лично предпочту Haskell.
Q>Мало того, чтобы он был удобен. Нужно, чтобы он был удобнее других. Вот положа руку на сердце — Хаскель удобнее Nemerle или F#?
Я уже ответил. Положа руку на что угодно, удобнее. Другое дело, что лично я не вижу под него надёжных хороших библиотек, а те, что есть, не вызывают у меня должного доверия. Так что если мы о языке, то Хаскель удобнее.
Здравствуйте, thesz, Вы писали:
T>Итак, мы пишем систему на ФЯ. Как мы можем напортачить технически, чтобы внесение изменений стало приводить к неконтролируемому распространению ошибок?
Неужели ты в самом деле считаешь, что ФП настолько посеребрена, что с ним становится невозможен плохой дизайн?
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, thesz, Вы писали:
T>>>>>Кого не устраивает? LP>>>>Пока — меня. Потом будет не устраивать пользователей. T>>>Ladies and gentleman! T>>>Here we have an extremely revealing case of premature optimization!
LP>>В моем случае это не преждевременная оптимизация, не нужно мне тыкать в нее, я и сам прекрасно знаю, что это зло.
T>Да ты что!
T>Тебе о производительности ещё никто не сказал, а ты уж вовсю профайлером машешь!
А мне и говорить не нужно. Нужно просто на минуту почувствовать себя пользователем. В пользовательском интерфейсе согласно т з расчеты запускаются интерактивно, пользователь тыкает в точку на схеме и ждет, пока не отобразятся на схеме же, и в виде таблицы результаты расчетов. Очевидно, что если, после тычка на схему, программа уходит в раздумья на несколько минут (а в схеме тысячи элементов, а расчеты сложные), то приятного в работе с такой программой мало.
Почему это не совсем корректно называть преждевременной оптимизацией — работа идет не над вылизыванием и подбиванием костылей ради мифического прцентного увеличения производительности, а выявление алгоритмов, которые нужно заменить. Например, сейчас алгоритм, основанный на выявления связности графа, заменен менее универсальным, и работающим в 99 процентах случаев, но зато быстрым. Остальной 1 процент случаев будет обработан отдельно. В результате время выполнения расчетов сократилось более чем в два раза.
T>Что это, как не преждевременная оптимизация?
Это не преждевременная оптимизация.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Qbit86, Вы писали:
L>>4. Вывод типов или раздельное описание типа и определения. Q>Чем оно принципиально лучше других ML'ей (ну там OCaml и производный от него F#) или Nemerle?
У Nemerle локальный вывод вроде.
Предположим, что у ML-ей и Haskell абсолютно одинаковый вывод типов. Это как то отменяет тезис о том, что Хаскель помогает писать в ФП стиле?
L>>5. Ленивость — ура! L>>Ленивость by default в чистом языке очень сильно помогает писать в ФП стиле. Но это большая (больная) тема. Q>Возможно. (Не будем вспоминать тред с обсуждением утечек невычисленных цепочек К слову, работа с коллекциями в C# по сути тоже ленива по умолчанию.)
Я правильно понял, что единственная претензия к синтаксису Хаскеля, это наличие в библиотеках идентификаторов типа восклицательного знака?
Q>Во-вторых, не совсем понятно, что там с real world Haskell (выкопанные откуда-то сомнительные success stories как-то не очень убеждают). Большинству не нужно писать компиляторы или «моделировать какую-то там систему знаний с теоретико-множественным подходом»
. Часто приходится, например, делать клиент-серверные приложения. На сервере общение с БД, на клиенте rich GUI, коммуникация, O/RM, работа с сетью, безопасность, криптография, etc, etc, etc.
Э... Мы вроде говорим о том, помогает ли синтаксис конкретного языка в ФП.
Но если хочешь, можем поговорить о возможностях в real world. Всё перечисленное тобой есть, разве что кроме ОРМ, за отсутствием тех самых О. Только это скучно — БД, гуй... Есть библиотеки, значит их можно нарисовать или сгенерить — интереснее дизайн и алгоритмы. Тут уже плавно можно перейти к роли ФП в этом
Q>Итак, F# и Nemerle: 1) вменяемый синтаксис, 2) интероп с .NET, 3) мультипарадигменность. Пока не вижу никаких убийственных доводов, чтобы предпочесть им Хаскель.
4) грязные
5) энергичные
Да ну и пусть. Разве это отменяет тезис о том, что (надоело повторять)?
Здравствуйте, lomeo, Вы писали:
Q>>Итак, F# и Nemerle: 1) вменяемый синтаксис, 2) интероп с .NET, 3) мультипарадигменность. Пока не вижу никаких убийственных доводов, чтобы предпочесть им Хаскель.
L>4) грязные
Это хорошо, можно писать императивный код там где он уместен.
L>5) энергичные
Лучше энергичность по-умолчанию, чем ленивость.
Хотя остсутствие возможности задать ленивость декларативно — это плохо.
Здравствуйте, VoidEx, Вы писали:
Q>>Почему нет? Вот, скажем, F# позиционируется как язык, за который можно сажать вообще непрограммистов. Смотри, например, книжку «F# for Scientists» by Jon Harrop. VE>А ссылка есть? Или она платная?
Она платная, в сети есть версия довольно поганого качества, но для ознакомления сгодится.
T>>We all yet to see your article named "Обобщённые алгебраические типы, как шаг к зависимым типам данных", ага. VD>У тебя проблемы с общением на русском?
Мне так интересней выражаться.
VD>Что до обоебщенных АлгТД, то меня вполне устраивают не обобщенные в купе с ООП.
А ты знаешь, зачем нужны GADT?
T>>Поскольку пересесть с Nemerle на Хаскель не будет составлять труда, по-твоему. VD>Это значительно проще чем пересесть с Явы на Хаскель.
We all yet to see... и далее по тексту.
VD>>>В общем, сложность имеет тенденцию складываться (если не умножаться). И всегда проще освоить язык в котором минимум изменений нежели совершенно другой. T>>Но и дольше будет путь достижения того же уровня владения предметом, здесь — функциональным программированием. T>>Значительно дольше. VD>С чего бы это?
Владение инструментом — ФП, — достигается окольным путём, путём освоения череды промежуточных инструментов, всё более и более приближающих человека к цели. В процессе приходится осваивать идиосинкразии этих самых промежуточных инструментов.
Понять, где не хватает знания ФП, а где не хватает привычки к идиосинкразии очередного промежуточного инструмента, в принципе, невозможно.
За одним исключением — если можно сравнивать с наиболее чистым вариантом.
Но зачем мучиться и сравнивать, если можно использовать сразу?
VD>К тому же, как показывает практика, многие кто пытался освоить совершенно незнакомый ФЯ попросту бросали это занятие еще на первых шагах.
Вопросы мотивации шерифа волнуют весьма умеренно.
Второе. Такое отношение к людям, как у тебя — их, бедненьких, надо защищать от вьюг и морозов ФП, от палящего зноя систем типов, — унижает твоих же коллег.
На самом деле программисты весьма мужественны. Это одни из самых сильных людей на планете во всех смыслах этого слова — что в интеллектуальном (кто будет спорить?), что в психологическом (кто может каждый день обнаруживать свои ошибки и при этом не считать себя неудачником?), что в физическом (последнее со слов моего тренера, который потренировав ещё одного программиста, как-то сказал, что "Программисты довольно крепкие").
Поэтому надо бить в лоб. Вот тебе Хаскель. Ты программист. Справишься.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Итак, мы пишем систему на ФЯ. Как мы можем напортачить технически, чтобы внесение изменений стало приводить к неконтролируемому распространению ошибок? LP>Неужели ты в самом деле считаешь, что ФП настолько посеребрена, что с ним становится невозможен плохой дизайн?
Хороший доступней, плохой невозможней. Переход к лучшему проще.
Мне "невозможен плохой дизайн" не нужно. Фортрановскую программу можно написать на любом ЯП. Мне нужно, чтобы фортрановские программы становилось писать все сложнее и сложнее.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Возьмите другой пример. Там, где изменения в случае написания системы на ФЯ всё равно приведут к неконтролируемому распространению изменения инвариантов. Типа, "поменяли мы тут, а вылезло вон там". E>Был у меня когда-то такой случай. На web-форме запрашивался пароль пользователя, затем строился хеш пароля и хэш сохранялся в куках. Через какое-то время выяснилось, что используемая хэш-функция генерирует символы, которые не могут сохраняться в куках без специального экранирования.
E>Пусть будет такая ситуация: система на ФЯ, использует функцию хеширования A, результатом которой является набор символов из диапазона [0..255]. Результат ее работы начали сохранять в текстовом файле, забыв, что символы из диапазона [0..31] в текстовый файл записывать нельзя. На первом этапе тестирования и функционирования системы ошибок не было выявлено, т.к. не попадалось случаев, когда A генерировала бы символ из [0..31]. Затем A заменили на B. Через какое-то время сломалась функция загрузки данных из файла. Или даже так: сначала использовали A и запись в двоичный файл (в котором ограничений не было), потом двоичный файл заменили текстовым, затем A заменили на B.
И вот опять он — внешний интерфейс. У вас все примеры, за исключением одного, связаны с внешним интерфейсом. А в единственном примере, где интерфейс внутренний, вы не дали сделать его функциональным.
В императивном программировании даже внутренний интерфейс представляет проблему. Объём кода, который надо изучить при внесении изменений, не имеет верхней границы, в общем случае. Который встречается чаще, чем хотелось бы.
Сделать проблематичный внутренний интерфейс на ФЯ достаточно тяжёлая задача.
Собственно, все ваши попытки изобрести пример это и доказывают.
Если вам мало, то я умываю руки.
E>Дополнение: если бы все программы писали идеальные программисты, то подобная ситуация и в любом нормальном императивном языке исключается на раз.
BTW, было show и read, стало (show . show) и (read . read). Это, практически, все требуемые изменения. Но примерно то же и в императивном ЯП.
T>>В принципе, это возможно при изменении широко используемой (библиотечной) функции. Но это решается изменением типа функции, либо копированием функции, изменением типа копии и использовании копии функции. В сравнении с нарушением негласного инварианта в наследнике широкой и глубокой иерархии с количеством методов за сотню штук это всё мелочи жизни. E>Наличие больших и реально работающих ОО программ показывает, что все эти страшилки несколько преувеличены.
Их разрабатывает нереальное число людей.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Tonal-, Вы писали:
T>А можно без boost::bind?
Не не не Девид Блэйн... Написание функтора это, довольно просто.
T>Несколько длинно, но вполне шаблонно и читаемо.
Ты, кстати, ошибку допустил std::map::find возвращает итератор. Ладно, мы возьмём такой случай, что в поиск в словарике не может закончится неудачей, чтоб не добавлять Maybe. Я пытался operator[] забаиндить, мне это так и не удалось, между прочим, пробовал на 2х современных компиляторах использовал std::tr1::bind. Ну как? На стандартных биндерах скомбинировать эти функции получается очень нетривиальная задача, которая не только усложняет понимение кода, но ещё и сильно усложняет его отладку. Я, конечно, тоже слукавил: функтор, в принципе, аналог именованной лямбды, но если определена функция доступа к соответствующему члену Foo, то лямбда, которую я написал, превращается в тривиальную комбинацию функций.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, VladD2, Вы писали:
VD>Видимо я плохо изъясняюсь на русском. Скажу еще раз, последний. Проще осваивать ФП на языке синтаксис которого близок к синтаксису знакомого языка.
Синтаксис должен хорошо отражать семантику. В С++ нет конструкций которые хорошо отражают семантику приёмов ФП (лямбды, карринг, ФВП и т.п.), в С# возможно есть конструкции, которые лучше отражают некоторые из приёмов, а в Nemerle допустим их ещё больше. Т.е. следуя твоим рекоммендациям, мне надо сначала освоить C# (с кучей шелухи которая к ФП не имеет никакого отношения), а потом Nemerle, который похож уже не на С++, а на C# ( и кстати тянет из него в основном шелуху, которая к ФП отношения особого не имеет)?
VD>Несомненно понять и выучить можно все что угодно. Ядерную физику, например. И несомненно учить ФП на языке его не поддерживающем путь тупиковый. Но причем тут эти, совершенно корректные, размышления?
Я говорю о том, что похожесть синтаксиса второстепенна (для меня так вообще особо не важна, мне синтаксис как Scheme, так и Хаскеля видятся довольно красивыми и логичными), главное чтоб синтаксис не отвлекал от новых концепций.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, lomeo, Вы писали:
L>Это как то отменяет тезис о том, что Хаскель помогает писать в ФП стиле? L>... L>Да ну и пусть. Разве это отменяет тезис о том, что (надоело повторять)?
Это зависит от вкладываемого смысла в «помогает». Можно понимать в смысле «помогает по сравнению с». По сравнению с C++, возможно, Хасель помогает. По сравнению с Nemerle и F# — нет.
L>>>Ленивость by default в чистом языке очень сильно помогает писать в ФП стиле. Но это большая (больная) тема. Q>>Возможно. (Не будем вспоминать тред с обсуждением утечек невычисленных цепочек :) К слову, работа с коллекциями в C# по сути тоже ленива по умолчанию.)
L>"А у меня вся тела такая!" :)
А мне «вся тела такая» не нужна. В F# мне нравится энергичность по умолчанию.
L>Я правильно понял, что единственная претензия к синтаксису Хаскеля, это наличие в библиотеках идентификаторов типа восклицательного знака?
Нет, не правильно. Выше встречались примеры кода на Хаскеле в сравнении с другими языками. Из этих примеров молчаливые анонимусы, читающие из-за спины спорщиков, могут сделать определённые выводы. И, боюсь, не в пользу Хаскеля.
L>Только это скучно — БД, гуй... Есть библиотеки, значит их можно нарисовать или сгенерить — интереснее дизайн и алгоритмы.
Должен же кто-то и горшки обжигать. GUI, кстати, вовсе не так скучно, если инструмент правильный.
L>4) грязные L>5) энергичные
Здравствуйте, thesz, Вы писали:
T>>>Итак, мы пишем систему на ФЯ. Как мы можем напортачить технически, чтобы внесение изменений стало приводить к неконтролируемому распространению ошибок? LP>>Неужели ты в самом деле считаешь, что ФП настолько посеребрена, что с ним становится невозможен плохой дизайн?
T>Хороший доступней, плохой невозможней. Переход к лучшему проще.
На самом деле при проектировании программных систем парадигма не имеет никакого значения, или по крайней мере значит очень мало. На первое место выходит такие общие, более высокоуровневые характеристики, нежели используемая парадигма, как то: слабосвязанность, разделение ответственностей, изолированность подсистем и пр. ФП там или ООП — уже побоку. Разница между парадигмами сказывается максимум на уровне модулей, а потом начинают работать более общие законы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, dr.Chaos, Вы писали: T>>Несколько длинно, но вполне шаблонно и читаемо. DC>Ты, кстати, ошибку допустил std::map::find возвращает итератор.
Я ж вроде там его разименовал.
DC>Ладно, мы возьмём такой случай, что в поиск в словарике не может закончится неудачей, чтоб не добавлять Maybe.
По твоей постоновке (transform) и реализации на haskell (map) вроде бы поиск всегда должен быть удачным. иначе нужен фильтр или Maybe
DC> Я пытался operator[] забаиндить, мне это так и не удалось, между прочим, пробовал на 2х современных компиляторах использовал std::tr1::bind. Ну как?
Вот этот код скомпилировался без проблем на g++ (GCC) 3.4.5 (mingw-vista special r3):
#include <string>
#include <map>
#include <algorithm>
#include <boost/bind.hpp>
struct Foo {
std::string name;
};
struct Bar {
long val;
};
typedef std::map<std::string, Bar> bar_map_t;
template <class IterF, class IterB>
void foo2bar(bar_map_t barMap, IterF first, IterF last, IterB result) {
using boost::bind;
std::transform(
first, last, result,
boost::bind(
&bar_map_t::operator[], &barMap, boost::bind(&Foo::name, _1)));
}
Вчера было ленно проверять.
Хотя я согласен, что распознать в этом обращение по индексу довольно проблематично, а если ещё заметить, что barMap используется по значению а хочится по ссылке, поэтому нужно использовать find и разименовывать итератор или нужна таки композиция, то bind всяко сольёт функтору по понятливости. А вся конструкция тупому for-у.
В новом стандарте С++ насколько я понял лямбды будут реализовываться именно подобными функторами.
Вот тогда писать с использованием transform и компании будет приятно.
L>>Это как то отменяет тезис о том, что Хаскель помогает писать в ФП стиле? L>>... L>>Да ну и пусть. Разве это отменяет тезис о том, что (надоело повторять)? Q>Это зависит от вкладываемого смысла в «помогает». Можно понимать в смысле «помогает по сравнению с». По сравнению с C++, возможно, Хасель помогает. По сравнению с Nemerle и F# — нет.
Хаскель помогает авторам самих Nemerle и F#. Если, вдруг, ты этого не заметил.
L>>"А у меня вся тела такая!" Q>А мне «вся тела такая» не нужна. В F# мне нравится энергичность по умолчанию.
Ещё один сторонник преждевременной оптимизации.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
К слову, работа с коллекциями в C# по сути тоже ленива по умолчанию.)
Написание функтора это, довольно просто.
