Здравствуйте, Gaperton, Вы писали:
G>...ты должен признать, что они есть. И весьма положительные — отчеты публично доступны. И если ты заинтересуешься — ты найдешь еще больше примеров.
В мире создаются сотни тысяч программ в год. Сколько процентов из них созданы на ФЯ? Под примерами применения я имею ввиду не пару-тройку завершенных проектов, а сотни и тысячи успешно эксплуатируемых программ.
The God who walks is among us...
Re[10]: Почему никто не использует функциональные языки
Здравствуйте, Larm, Вы писали:
L>Здравствуйте, Gaperton, Вы писали:
G>>...ты должен признать, что они есть. И весьма положительные — отчеты публично доступны. И если ты заинтересуешься — ты найдешь еще больше примеров. L>В мире создаются сотни тысяч программ в год. Сколько процентов из них созданы на ФЯ? Под примерами применения я имею ввиду не пару-тройку завершенных проектов, а сотни и тысячи успешно эксплуатируемых программ.
Очень странно. А я под примерами применения понимаю конкретные примеры конкретного успешного применения. С отчетом о разработке, и опытом успешной эксплуатации. Мне сам факт того, что некие люди колбасят сотни тысяч программ в год на средстве Х интересен мало, потому как он ничего не показывает, кроме популярности средства Х. Это как в рекламе волшебных присадок к моторному маслу: до вас это попробовали 10000000 американцев! Ну и что, собственно?
ON>Спасибо. ON>Однако не модно уже посылать людей ... в библиотеку. ON>Не то, чтобы мне искать было лень, просто обычно лучше чего-то одного придерживаться, а то найдешь такое что потом не знаешь как потерять.
Написать примитивный интерпретатор ФЯ не проблема. Как уже выше сказали ФЯ основываются на лямбда исчислении. Это чисто математическая теория, которая возникла задолго до появления первых компьютеров и первоначально расчитывали, что она станет основанием логики и математики. Позже, однако, выяснилось, что эта теория является ни чем иным, как альтернативным способом выражения понятия вычислимости. Т.е. машина Тьюринга и лямбда исчисление в некотором роде "эквивалентны". В частности это значит, что ФЯ ничем не уступают ИЯ в выразительности.
Лямбда исчисление само по себе очень простое. Там есть переменные a,b,c... символ \lambda и скобки.
Множество лямбда выражений L определяются следующим образом:
1) x принадлежит L
2) если M принадлежит L, то (\lambda xM) принадлежит L
3) если M, N принадлежат L, то (MN) принадлежит L
Ну и есть 3 простых правила вывода (преобразования) этих выражений, которые я тут писать сейчас не буду. На первый взгляд все это выглядит очень примитивно, однако, любое лямбда выражение является по сути дела программой, а правила преобразований позволяют редуцировать большие лямбда программы к "результату". Все языки, которые сейчас принято считать функциональными, по сути дела лишь надстройки над лямбда исчислением. За любой функциональной программой без труда можно увидеть соответствующее ей лямбда выражение (с той оговоркой, что в целях оптимизации используется расширенное и типизированное лямбда исчисление с целыми числами, строками и т.п. И попробуйте ка по императивной программе построить соответствующую машину Тьюринга). А Lisp, например, вообще почти копия ЛИ, что и не удивительно.
Именно в этой близкой связи с теорией и заключена сила ФЯ. Появляется возможность относительно безболезненно анализировать функ. программы математическими методами, искать алгоритмы распараллеливания. Становится легче решать практические задачи, поскольку программы на ФЯ похожи на математические утверждения, что больше соответствует мышлению человека.
Здравствуйте, serg_mo, Вы писали:
AF>> А это другая крайность. Крайности, как известно, вредны AF>> Как вредно писать только на C/C++/C# или Haskell, так я думаю ещё вреднее — изучать каждыя язык — просто времени на написание кода не отсанется. _>Как и Вы, я не сторонник крайних мер и не призываю к изучению языков в ущерб работе. Тем не менее, думаю, полезно периодически вытаскивать голову из своей ниши и смотреть, что же нового появилось вокруг. В книге "Pragmatic Programmer" авторы рекомендуют изучать новый язык каждые полгода. Возможно, это чересчур, но рациональное зерно в этом есть .
Асолютно согласен. Дело не в том, как часто, а в том, что бы это увеличивало возможности и расширяло кругозор. Для кого то это раз в два месяца, для кого-то раз в год.
_>Как самый простой пример из собственного опыта: в бытность студентом мне часто приходилось писать утилиты по обработке текста. Я писал из на С++, считая, что лучше языка в природе нет. Сейчас я бы выбрал для этих задач, например, Ruby. На нем мои тогдашние задачи решаются на порядок быстрее.
Естественно. Думаю у каждого из нас есть подобный опыт.
_>А вообще-то, мне кажется, серьезному программисту следует достаточно хорошо ориентироваться в различных подходах/парадигмах программирования. Даже если программист выбрал для себя объектный подход раз и навсегда, это не значит, что он имеет моральное право недоуменно пучить глаза при словах "функциональное программирование". В конце концов, расширение кругозора в большинстве случаев себя оправдывает .
AF>> Это слова увлечённого программста (и совершенно прекрасные как для специалиста), а не менеджера или инвестора, который реально реализует промышленные проекты. Посмотри на всякие переходы туда — сюда ИХ глазами. Представь — что ты бы платил за подобные развлечения свои деньги, а не какого то дяди. _>Опять же, я не говорю о необоснованном выборе языка. Представляя себя на месте инвестора или менеджера, я бы, думаю, голосовал бы за самое эффективное средство разработки. Именно потому, что мне дороги мои деньги. BTW, и не обвиняйте меня в наивности, а правда ли, что это задача менеджера — выбирать средство разработки?
А вот тут вы не правы. Менеджер или инвестор — будет стремиться минимизировать риски. Любая новая технология — высокие риски.
Многочисленные исследования неоднократно показывали, что как проффесионализм команды разработчиков, так и эффективность технологии — далеко не основные факторы успеха проекта. Увы это так...
То есть при правильной организации процесса разработки, используя С++, STL и COM гораздо больше шансов на успех проекта, чем при использовании C#, но при плохой организации проекта.
Вот потому то технологии так сложно и прижываются — что они далеко не основной фактор успеха.
AF>> Причём таки переходят же. Иначе никаких ФЯ в телекоме не было бы. Просто на практике всё чуть сложнее, чем прочитать описание языка и написать пару программ. _>Мне нравятся такие тенденции . Возможно, они выведут нас из того застоя, в котором находится software индустрия
Тенденций много. Посмотрим, какие из них возьмут верх...
Re[11]: Почему никто не использует функциональные языки
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Larm, Вы писали:
L>>Здравствуйте, Gaperton, Вы писали:
G>>>...ты должен признать, что они есть. И весьма положительные — отчеты публично доступны. И если ты заинтересуешься — ты найдешь еще больше примеров. L>>В мире создаются сотни тысяч программ в год. Сколько процентов из них созданы на ФЯ? Под примерами применения я имею ввиду не пару-тройку завершенных проектов, а сотни и тысячи успешно эксплуатируемых программ. G>Очень странно. А я под примерами применения понимаю конкретные примеры конкретного успешного применения. С отчетом о разработке, и опытом успешной эксплуатации. Мне сам факт того, что некие люди колбасят сотни тысяч программ в год на средстве Х интересен мало, потому как он ничего не показывает, кроме популярности средства Х. Это как в рекламе волшебных присадок к моторному маслу: до вас это попробовали 10000000 американцев! Ну и что, собственно?
А вот ты не прав. Это показатель того, что технология X — это мейнстрим, что основная масса людей ориентируется на неё.
Доминирующее положение именно у таких технологий.
Re[2]: Почему никто не использует функциональные языки
Здравствуйте, Glоbus, Вы писали:
G>Здравствуйте, Gaperton, Вы писали:
G>А нельзя ли темному человеку раскинуть, че такое функциональые языки, потому что ранее похоже я заблуждался относительно этого термина. Желательно поподробнее и с примерами.
Функциональные языки — это языки состоящие из функций Т.е. Есть главная функция, она определяется в терминах подфункций и т.д. В императивном языке выполнение программы сводится к перекладыванию значений из одних ячеек памяти в другие, в функциональном языке ничего подобного нет. Формально (если отвлечься от физической реализации) там преобразуются строки символов по определенным правилам редукции. Поэтому возможно преобразовывать эти строки сразу в нескольких местах, в разном порядке и т.п без изменения конечного результата, в отличие от ИЯ, где есть совершенно четкая цепочка переходов программы из одного состояния в другое и изменить ее не повлияв на результат нельзя.
Здравствуйте, VladD2, Вы писали:
VD>В общем, то к чему ты привык в функциональных языках ни мне, ни очень многим другим попросту не нужно. ФЯ имеют довольно убогии выразительные средства и сложны в изучении и применении. Повторять подвиг горбатого я не хочу.
Это не верно. ФЯ просты в изучении и применении. Про убогие выразительные средства трудно что-то возразить ввиду бессмысленности данного утверждения, но позволю себе заметить, что по выразительности работы со сложными структурами данных ФЯ далеко впереди ИЯ.
Здравствуйте, Quintanar, Вы писали:
Q>Это не верно. ФЯ просты в изучении и применении. Про убогие выразительные средства трудно что-то возразить ввиду бессмысленности данного утверждения, но позволю себе заметить, что по выразительности работы со сложными структурами данных ФЯ далеко впереди ИЯ.
Выразительные средства как раз являются главным преимуществом ФЯ. А вот изучеие и применение сложно в основном, психологически. Рефлексы, заточенные (тем больше, чем опытнее программист) на императивные языки сопротивляются Т.к. мыслить во многом приходиться хотя и схожими, но различными категориями. Скажем, рекурсия, исключения, передача по значению являются нормой в ФЯ, но привычная практика сопротивляется их применению on regular basis. Трудно привыкнуть, что знакомы вещи работабют в ФЯ совершенно по-другому.
Здравствуйте, INTP_mihoshi, Вы писали:
INT>Кстати, эти HTML (те, что с зелеными заголовками, .т.е. почти вся документация) сгенерены из того же Latex Посмотри внизу заглавной страницы.
О том и речь. Более убого оформить страницы было очень трудно.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
From: Quintanar
>Написать примитивный интерпретатор ФЯ не проблема.
Меня собственно написание программ на ФЯ не интересует . Наверно буду делать как раз интерпретатор. У меня есть программа чтобы работать с графами. Сейчас на графах работает просто булева алгебра, причем все работает параллельно, и производительность не критична, т.к. это не встроенная в другую система, а среда для пользователя. Хочется сделать, чтобы вершины появлялись, связи перестраивались. Я чувствую, что ФЯ проще и естественнее чем ИЯ, но в этом какая-то своя сложность, как кто-то в письме однажды написал "Письмо большое, потому что у меня не было времени написать коротко".
>Как уже выше сказали ФЯ основываются на лямбда исчислении.
В книге про Пролог читал "После случая с Прологом логики поняли, что из любой логической системы можно сразу делать систему программирования". По идее логика с семантическим выводом была бы на порядок удобнее, но пока и дедукции хватит.
>правила преобразований позволяют редуцировать большие лямбда программы к "результату". Все языки, которые сейчас принято считать функциональными, по сути дела лишь надстройки над лямбда исчислением. За любой функциональной программой без труда можно увидеть соответствующее ей лямбда выражение (с той оговоркой, что в целях оптимизации используется расширенное и типизированное лямбда исчисление с целыми числами, строками и т.п. И попробуйте ка по императивной программе построить соответствующую машину Тьюринга).
По-моему слово "функциональный" происходит от слова функционал, а не функция. Почему-то никто не обращает на это внимания. Мне же по-настоящему интересуют даже не фунционалы, а не знаю даже как назвать, формализация что-ли. Нужно по данным построить программу их генератор. Там обязательно нужно накапливать базу знаний, функционалы как раз подходят как представление данных, это такой внутренний слой логики, я уверен что у компьютера программировать на ФЯ получится лучше чем у человека
N_>Точно так же как с вводом-выводом. Вы очень ограничено мыслите. Говоря "изменить состояние объекта" вы подразумеваете, что есть нечто имеющее имя или идентификатор которое еще и может изменить свое состояние. В функциональных языках это не так, они работают со значениями. Вы можете дать значению имя и не можете потом этому имени дать другое значение. Тоесть нет оператора присваивания.
Моделируем, мы, например, ДТП.
В итоге получается, что, например, "сегодняшний" автомобиль имеет другое имя, чем он же, но "завтрашний"?
Но как быть с внешними "ссылками"?
Допустим, у нас есть модуль, который визуализируют автомобиль, соответственно этот модуль держит какую-то "ссылку" на автомобиль.
Далее, есть модуль, которые постоянно обсчитывает новое состояние автомобиля.
Q> программы на ФЯ похожи на математические утверждения, что больше соответствует мышлению человека.
Имхо, это какие-то неправильные человеки.
Нормальные люди оперируют состояниями объектов и используют нечеткие множества (когда один и тот же идентификатор означает разное в разных условиях).
Пример:
Возьми ключ, и сними переднее колесо.
Конструкция, по сути, императивная.
Очень редкий человек скажет:
Открюченное колесо — это колесо, которое не прикручено к машине.
Сделай так, чтобы переднее колесо было открюченным колесом.
Здравствуйте, DarkGray, Вы писали: DG>Моделируем, мы, например, ДТП. DG>В итоге получается, что, например, "сегодняшний" автомобиль имеет другое имя, чем он же, но "завтрашний"?
Не обязательно давать "имя" новому значению объекта. Его можно сразу же передать другой функции.
DG>Но как быть с внешними "ссылками"?
DG>Допустим, у нас есть модуль, который визуализируют автомобиль, соответственно этот модуль держит какую-то "ссылку" на автомобиль.
DG>Далее, есть модуль, которые постоянно обсчитывает новое состояние автомобиля.
DG>Как об этом узнает модуль-визуализатор?
Если "ссылка" внешняя для программы, то работать с ней надо так же как с вводом-выводом.
Если эта "ссылка" для программы внутренняя, то один модуль просто передает обновленные данные другому по значению. И уже дело компилятора как передать его на самом деле. По ссылке или как-то по другому.
Re[12]: Почему никто не использует функциональные языки
Здравствуйте, AndreyFedotov, Вы писали:
AF>Здравствуйте, Gaperton, Вы писали:
G>>Здравствуйте, Larm, Вы писали:
L>>>Здравствуйте, Gaperton, Вы писали:
G>>>>...ты должен признать, что они есть. И весьма положительные — отчеты публично доступны. И если ты заинтересуешься — ты найдешь еще больше примеров. L>>>В мире создаются сотни тысяч программ в год. Сколько процентов из них созданы на ФЯ? Под примерами применения я имею ввиду не пару-тройку завершенных проектов, а сотни и тысячи успешно эксплуатируемых программ. G>>Очень странно. А я под примерами применения понимаю конкретные примеры конкретного успешного применения. С отчетом о разработке, и опытом успешной эксплуатации. Мне сам факт того, что некие люди колбасят сотни тысяч программ в год на средстве Х интересен мало, потому как он ничего не показывает, кроме популярности средства Х. Это как в рекламе волшебных присадок к моторному маслу: до вас это попробовали 10000000 американцев! Ну и что, собственно? AF> А вот ты не прав. Это показатель того, что технология X — это мейнстрим, что основная масса людей ориентируется на неё. AF>Доминирующее положение именно у таких технологий.
В огороде бузина, а в Киеве дядька.
Меня ни капельки не трогает их доминирующее положение. Еще раз. Сама по себе популярность ни когда не являлась и не может являться техническим аргументом. Взывая к популярности продают гербалайф и присадки в двигатель.
Переходим на яблоки. Я лить говно в двигатель только потому, что это до меня сдалало 10 миллионов дураков, не собираюсь. Моей машине от этого легче не будет.
Поэтому не надо говорить про популярность в контексте технической дискуссии, ок?
Здравствуйте, DarkGray, Вы писали:
Q>> программы на ФЯ похожи на математические утверждения, что больше соответствует мышлению человека.
DG>Имхо, это какие-то неправильные человеки.
DG>Нормальные люди оперируют состояниями объектов и используют нечеткие множества (когда один и тот же идентификатор означает разное в разных условиях).
DG>Пример: DG>Возьми ключ, и сними переднее колесо.
DG>Конструкция, по сути, императивная.
DG>Очень редкий человек скажет: DG>Открюченное колесо — это колесо, которое не прикручено к машине. DG>Сделай так, чтобы переднее колесо было открюченным колесом.
Крайности, как известно, вредны 
Тем не менее, думаю, полезно периодически вытаскивать голову из своей ниши и смотреть, что же нового появилось вокруг. В книге "Pragmatic Programmer" авторы рекомендуют изучать новый язык каждые полгода. Возможно, это чересчур, но рациональное зерно в этом есть 
Т.е. Есть главная функция, она определяется в терминах подфункций и т.д. В императивном языке выполнение программы сводится к перекладыванию значений из одних ячеек памяти в другие, в функциональном языке ничего подобного нет. Формально (если отвлечься от физической реализации) там преобразуются строки символов по определенным правилам редукции. Поэтому возможно преобразовывать эти строки сразу в нескольких местах, в разном порядке и т.п без изменения конечного результата, в отличие от ИЯ, где есть совершенно четкая цепочка переходов программы из одного состояния в другое и изменить ее не повлияв на результат нельзя.
