.
Это где ты там "открытое хамство" заметил? И вообще, кто бы говорил, а ты молчал Тебе подборку твоих высказываний дать? Искать долго не придется — хамишь ты постоянно и всем. Да ты и в этом письме успел отличился, что искать.
G>>А что будет, когда реализуют? Страшно подумать. VD>А ты не думай. А то хамство сразу прет и зо всех щелей.
Да я вижу, что прет. Если бы я так реагировал на многочисленные провокации по поводу ФЯ, как ты на единственную подколку по поводу твоего R#, меня бы давно забанили, или я бы удавился от расстройства. Спокойнее, Влад, без истерик. Ведь ваш R# и вправду ведь еще... гхм... не закончен? Ну так что ты шумишь?
Хочешь в бан на недельку?
G> Тебе подборку твоих высказываний дать? Искать долго не придется — хамишь ты постоянно и всем.
Давай.
G> Да ты и в этом письме успел отличился, что искать.
Ты видимо не умешь отличать хамства и оскорблений от не лестных слов. Это твои проблемы. Но знай, что подобная "агитация" резко отталкивает разумных людей от того чтобы заниматься тем за что агитируют.
G> Если бы я так реагировал на многочисленные провокации по поводу ФЯ
Да нет никаких провокаций. Люди тебе говорят что думают. А ты все провокациями считаешь. Плевать всем на эти ФЯ. Людям нужен удобный инструмент простой в изучении и использовании. А то что есть сейчас даже запустить тяжело. Не то что изучить и использовать на практике. Статья об этом собственно и говорит.
G>, как ты на единственную подколку по поводу твоего R#, меня бы давно забанили,
Плевать мне на твои потколки. Но слышать подобное процетированному не охота даже не всвой адрес.
G> или я бы удавился от расстройства. Спокойнее, Влад, без истерик. Ведь ваш R# и вправду ведь еще... гхм... не закончен? Ну так что ты шумишь?
А я не шублю. Я тебе сказал свое мнение. ФЯ ужербны и недоработаны. В них есть рациональное зерно, но оно отнюдь не в ругательствах вроде "lazy evaluation, lazy data structures" (это скорее затычки проблем чем достоинства). Достоинства в декларативности и в ином взгляде на код (под другим углом). Но они же порождают и недостатки. Как минимум используя ФЯ я не могу добиться построения такого исполнимого кода который я хочу получить. Отсюда и все споры о производительности. Когад ФЯ оказывается заточен на решение конкретной задачи, то производительность у него приемлемая. Но как только задача не стыкуется с концепцией, то код плучается медленным и мало пригодным. Именно по этому мне интересен подход с преобразованием декларативного стиля в имперетивный. Это позволяет контролировать результат. А так же добиваться большей выразительности.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
VD>>Тут ты не прав. Функциональные языки не дают сами по себе приемуществ. Просто они ближе к идеи декларативности. Причем качественной декларативности в них добиться не удается. Причем именно из-за того, что ни заточены на функциональную запись. G>Да я уже привык, что как только ты пишешь — то я сразу не прав . Правда, как и всегда, сложно понять, в чем? В том, что OCaml — это не то, что хочет Павел? Это, пардон, ему решать, а не тебе и не мне.
Да сказал бы проще. Возразить нечего но хочется остаться правым. А то целый абзац и никакого смысла.
VD>>И если выделить идею декларативного описания, то станет понятно, что средства которыми етого можно достичь не сводятся к функциональным языкам. G>Да ради бога, я не против.
Судя по твоим возражениям и безграничной агитации — против.
VD>>Возьми к примеру BNF/EBNF натацию и сравни ее с описанием парсера на функциональном языке. BNF/EBNF намного чище и понятнее. G>Тут ты не прав. Про комбинаторные монадные парсеры слыхал?
Я слыхал, что монады не во всех ФЯ есть. А там где есть языки обычно невыдерживают никакой критики по другим вопросам.
G> Почитай про них. Код парсера будет выглядеть если не один в один как BNF/EBNF, то очень близко .
А мне не нужно "очень близко". Мне нужно EBNF. Попробуй на досуге переиписать кусок парсера того же шарпа. Сравним результат.
G>Кстати, отчего ты не предлагаешь посмотреть код автомата, который генерится для С#?
Посмотри. Парсер доступен публично. Првда там банальный рекусивный спуск с некоторыми проверками. Но все же.
G>Да ради бога. Или так. Или генерировать эффективный парсер на функциональном языке, например на OCaml или Clean.
Этов все языком. А кода люди берутся за дело, то применяют генераторы и С/С++/C#.
G> Или императивную на OCaml — как душе угодно. Хочешь померятся скоростью с OCaml?
А что мне мериться? Мой парсер готов и летает. Пиши свой помериемся. Но не верится даже то, что он будет написан. А уж то что он окажется сильно шустрее просто выглядит нереально.
G> А что практичнее — каждый решает для себя сам. Ты я вижу — решил.
И, что любопытно, решили все кто делает парсеры. Причем тех кто выбрал ФЯ оказались еденицы и делают они обычно парсеры для те хе ФЯ.
VD>>Имея удобный и простой в использовании механизм трансформации можно создать даже генератор преобразующий функциональные конструкции в императивные. Таким образом язык основанный на трансформации позволяет превратить себя в фукнционльный язык. Причем мы не будем завязаны исключительно на функциональный подход, а сможем выбирать наиболее удбный подход для конкретного случая.
G>Попытка не пытка — зачем дело встало?
Низачем. Делаем. И не только мы.
G> Попробуй реализовать функции высокого порядка
Думаю, с этим проблем не будет.
G>, карринг, lazy evaluation, lazy data structures, и list comprehensions.
Блин. А по русски все это нельзя? Ну, lazy evaluation и т.п. я конечно могу в уме обратно перевести "ленивое выполнение кода". Но все эти "карринги" и т.п...
Что касается отложенных вычислений. То это затыкание дыр функционального подхода. В императивном коде в них нужны нет. От функционального подхода мне интереснее другое. Повторне исползование частей алгоритмов и декларативность. Вот это со временем мы постараемся привнести в R#. Остальное от лишнее.
G> Очень интересна также будет реализация алгебраических типов.
Кому? Мне они не нужны. Кому будут нужны реализует. Моя задача не создать узкоспециализированные решения для конкретных проблем (чтобы прозибать как современные ФЯ). А создать средство позволяющее максимально просто создавать такие прикладные решения путем создания прокрамм преобразующих декларативную или смешанную запись в императивный код на популярном и общепризнанном языке.
G> Обеспечь нам прозрачность по ссылкам.
Зачем? Меня полностью удовлетворяет ситуация со сылками в C#.
G> Все то, к чему мы привыкли в функциональных языках.
Твоя фамилия случаем не Макидонский? А что ты тогда о себе во множественном числе? Или ты не заметил, что в основном тут все с тобой не согласны?
В общем, то к чему ты привык в функциональных языках ни мне, ни очень многим другим попросту не нужно. ФЯ имеют довольно убогии выразительные средства и сложны в изучении и применении. Повторять подвиг горбатого я не хочу.
К примеру, напиши программу на любом ФЯ которая сравниться по простоте и понятности с XPath- или SQL-запросом. Ну, например, вот такой запрос:
//class[@Name='AstNodeCollectionBase']
возвращает классы с именем AstNodeCollectionBase.
G> И вот тогда мы дружно все перейдем на твой R#.
Дык. Работаем... Ищем...
G>А вообще, кое-кто уже давно наслаждаются parse transform, встроеным в Erlang .
Рад за них. Прадва можно посочувствовать тому, что тех кто вообще наслаждается Erlang очень мало. Я по крайней мере в живую не видел.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Почему никто не использует функциональные языки
Здравствуйте, Gaperton, Вы писали:
G>Эта тема несколько раз поднималась на форуме, но ни до чего серьезного не договорились. Вот, нашел перевод статьи господина Вадлера на эту тему. Хорошо дядька пишет, правильно.
G>Почему никто не использует функциональные языки
хм.. простите, может я не в кассу...
но был у меня один предмет в ВУЗе — там триггеры изучали... так вот, что-то спор между императивным подходом и функциональным уж очень мне напоминает спор между описанием модели работы автомата (триггера) конечный он или бесконечный, Милли или Мура, не важно.. НО тем не менее двумя вариантами — статической формулой (что соответствует концепции ФЯ) или системой динамических формул (что соответствует концепции ИЯ) Как говорилось профемморами — последнее намного прощще, так как представляет собой как раз ту модель мира, в которой мы живем, т.е. учитывает чудодейтвенное присутствие времени а над первой моделью какой-нить попавшейся сложной системы из этих автоматов можно биться и биться до изнеможения, но добиться умопомрачительной компактности её представления на все века вперед — а вот в результате всё зависит от того, случится ли менять систему когда-нить... ведь всё течет, всё меняется.
Поправьте меня, если мои догадки не совсем в правильном русле данного философского течения
Re[7]: Почему никто не использует функциональные языки
Здравствуйте, Курилка, Вы писали:
G>>> Они, не поверишь, реализуются простейшим образом. В две строки. G>>>
G>>> transform( [ H | T ], F ) -> [ F( H ) | transform( T, F ) ];
G>>> transform( [], _ ) -> [].
G>>>
G>>> Вот и все.
hrg>>(задумчиво) кто-то мне недавно про нечитаемость perl'a говорил
К>Вот как человек явно считающий перл нечитаемым скажу, что такая запись вполне читаема, если читатель имеет понятия о том, что такое функциональное программирование
Вот только почему даже в примитивных случаях нужно мыслить рекурскией? И почему мне вот такая запись:
foreach (X x in xs)
xxx(x);
кажется понятнее и проще?
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Почему никто не использует функциональные языки
Здравствуйте, Цунцуяби, Вы писали:
Ц>Что-то Gapertona сильно бьют Ц>в этой ветке
Дык кусается, вот и бьют.
Ц>Вроде используют ФЯ : Ц>SQL, например, чем не ФЯ. Специализированный малость.
Это скорее декларативный язык. ФЯ все же это отдельный класс прикладных языков. Собственно Gapertona пытается доказать, что ФЯ круче паравоза, а ему в ответ отчечают, что не вдили пока ФЯ в рельной жизни. И что основное приемущество ФЯ в декларотивности, но ее можно достичь из без ФЯ. Так что SQL и XPath — это хорошие примеры декларативных языков не являющхся ФЯ и их наличие как раз говорит, о том что н все впорядке в стане ФЯ.
Согласись, что SQL и XPath учатся очень быстро. А за ФЯ люди берутся, обламываются и начинают спрашивать зачем они нужны.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Почему никто не использует функциональные языки
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, AndreyFedotov, Вы писали:
AF>> Согласен — всё это безусловно так. Правда отсутствие императивности интересно при взаимодействии со внешеней системой. Например когда делается запрос к БД — совсем не интересно (как правило), что он там делает, что бы его выполнить. А вот при реализации оконного интерфейса — предсказуемость (императивность) необходима. Я это собственно к тому — что эти подходы объединять и дополнять ими друг-друга, а не противопоставлять. G>Ты опоздал со своим предложением лет на 40. Со времени появления лиспа, который допускает побочные эффекты, все ФЯ всегда содержали императивные возможности. Иначе они не смогли бы выполнять ввод-вывод и взаимодействовать с внешним миром.
И в очередной раз колумб открыл америку... Я же как раз писал, что успехи в "промышленном применении" у тех языков, AZ которые имеют императивные возможности.
AF>> Беда с ФЯ в том, что их апологеты часто пытаются противопоставлять их императивным языкам. В то же время факты показывают, что наиболее успешны или ФЯ с императивными элементами или императивные языки с функиональными элементами (типичный пример связка С++/C# с запросами SQL). G>Так что не надо рисовать чорный образ апологета ФЯ, который раздувает пламя флейма и ненавидит все императивные проявления.
Естественно не надо. Реальность гораздо страшнее любых литературных образов
А если серьёзно — то не в приведённой ли статье приводилось описание причин, почему не используются ФЯ там — где успешно и эффективно применяются C++ и Visual Basic? Что это как не попытка захвата территории и анализ причин её провала? Зачем ФЯ к примеру для рисования интерфейса?
И опять таки — я за ФЯ, но я против того, что бы заявлять, что язык "XXX лучше всех" или "подход XXX лучше всех" (в том числе и императивый)
За ФЯ действительно может оказаться будущее — но не сейчас, а позднее — с появлением квантовых вычислений или многослойных (а возможно и многомерных) кристаллов. Т.к. там ленивые вычисления — естественное состояние работы такой структуры, т.е. ФЯ гораздо для них ближе, чем для современных нам процессоров — возможно это сделает их более востребованными.
Ну а сейчас есть некоторые задачи и области — где эти языки успешно применяются и скорее всего постепенно сфера применения ФЯ будет расти, хотя в ближайшие 15-20 лет править будут языки императивные.
Re[8]: Почему никто не использует функциональные языки
Здравствуйте, VladD2, Вы писали:
VD>И что забавно, все в ужасных пдф-ах. Почему чем хуже дела с раскруткой тем больше ПДФ-ов? Такое ощущение, что ПДФ — это такое символ консерваторства.
Это не впечатление — это факт!
Re[11]: Почему никто не использует функциональные языки
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Курилка, Вы писали:
G>>>> Они, не поверишь, реализуются простейшим образом. В две строки. G>>>>
G>>>> transform( [ H | T ], F ) -> [ F( H ) | transform( T, F ) ];
G>>>> transform( [], _ ) -> [].
G>>>>
G>>>> Вот и все.
hrg>>>(задумчиво) кто-то мне недавно про нечитаемость perl'a говорил
К>>Вот как человек явно считающий перл нечитаемым скажу, что такая запись вполне читаема, если читатель имеет понятия о том, что такое функциональное программирование
VD>Вот только почему даже в примитивных случаях нужно мыслить рекурскией? И почему мне вот такая запись: VD>
VD>foreach (X x in xs)
VD> xxx(x);
VD>
VD>кажется понятнее и проще?
И понятнее и проще. Но не функционально-языкасто. А потому есмь ересь и должно Mustdie (следуя логике проповедников ФЯ).
А потом они удивляются, почему "никто" не хочет пользоваться ФЯ.
Было бы интереснее добавить возможности ФЯ в языки обычные. Что то а-ля:
__functional
{
...
};
Или хотя бы так, как обычно задаются запросы к SQL серверу. Это было бы весьма полезно.
Здравствуйте, serg_mo, Вы писали:
_>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Здравствуйте, serg_mo, Вы писали:
AF>> Верно. Только для полноты картины вспомни о затратах ресурсов на переключение контекста.
_>Ну, вообще-то самосовершенствование в любом аспекте (и не только в профессиональной области) требует усилий. Тем не менее, это же не повод почивать на лаврах, начав писать на С++ в институте и до гробовой доски, не замечая ничего вокруг.
А это другая крайность. Крайности, как известно, вредны
Как вредно писать только на C/C++/C# или Haskell, так я думаю ещё вреднее — изучать каждыя язык — просто времени на написание кода не отсанется.
_>А затраты ресурсов чаще всего не такие уж и большие, надо сказать. Сложно только в первый раз
Это слова увлечённого программста (и совершенно прекрасные как для специалиста), а не менеджера или инвестора, который реально реализует промышленные проекты. Посмотри на всякие переходы туда — сюда ИХ глазами. Представь — что ты бы платил за подобные развлечения свои деньги, а не какого то дяди.
Причём таки переходят же. Иначе никаких ФЯ в телекоме не было бы. Просто на практике всё чуть сложнее, чем прочитать описание языка и написать пару программ.
Re[3]: Почему никто не использует функциональные языки
Здравствуйте, VladD2, Вы писали:
VD>Мне кажется, что единственный реальный шанс выйти в массы для компонентных языков — это быть встроенными в какой-нибудь императивный язык. Например, в R#.
Какое-то странное утверждение. Почти на любом более-менее развитом императивном языке можно программировть, используя приёмы функционального программирования. Только всегда ли это нужно?
Здравствуйте, Gaperton, Вы писали:
G>Правильнее (и честнее) сказать, что ты их не знаешь. G>Ты их не знаешь, [а так как ты видимо думаешь, что знаешь все,] следовательно их нет .
Не надо только снова про мобильную связь! Это узкая ниша — там этих проектов всего пара будет, остальное это их поддержка и небольшие расширения со временем. Широко, вне этой ниши, они не применяются. Десктоп приложения на них не пишут.
The God who walks is among us...
Re[8]: Почему никто не использует функциональные языки
Здравствуйте, VladD2, Вы писали :
V> Согласись, что SQL и XPath учатся очень быстро. А за ФЯ люди берутся, V> обламываются и начинают спрашивать зачем они нужны.
Здравствуйте, VladD2, Вы писали:
VD>Вот только почему даже в примитивных случаях нужно мыслить рекурскией? И почему мне вот такая запись: VD>
VD>foreach (X x in xs)
VD> xxx(x);
VD>
VD>кажется понятнее и проще?
В Haskell то, что ты написал, выглядит так.
map xxx x
В других ФЯ примерно так же. При чем map — это не встроенная функция, а часть стандартной библиотеки. А то, что написал Гапертон — это как раз код аналога этой самой "map", работающий для любых функций и списков. Или других котейнеров.
Кстати, если ты хочешь получить не функционального варианта — в OCaml есть метод List.iter fun list, которая работает с функциями, имеющим побочный эффект.
Здравствуйте, ArtDenis, Вы писали:
AD>Какое-то странное утверждение. Почти на любом более-менее развитом императивном языке можно программировть, используя приёмы функционального программирования. Только всегда ли это нужно?
Тебе подборку твоих высказываний дать? Искать долго не придется — хамишь ты постоянно и всем. Да ты и в этом письме успел отличился, что искать.
.
