Моя ИМХА, почему функциональные языки не получат широкого распространения.

1. Традиционное мышление.
Написание задачи на функциональном языке требует от человека перед тем как начать писать код четко, формально сформулировать задачу. Функциональное программирование пошло от математики, а императивное от техники. Для функционального программирования надо мыслить абстракциями, а в императивном можно более конкретными вещами.
Пример написать текстовый редактор аля блокнот. В современной RAD среде быстро накидывается формочка, а затем к ней прикручивается функциональность (открытие документа, сохранение и т.д.). А вот много ли программисто смогут описать этот же редактор в терминах функций?
Я помню с каким трудом я учился писать на ML, желание применять наработанные методы было непреодолимо, но они не работали, приходилось ломать себя и искать новые пути решения

2. Производительность.
Да развитие современной техники позвляет не заниматься оптимизацией на уровне комманд ассемблера, но это не значит что требования к производительности приложения можно совсем отбросить. Для компилятора это может быть приемлемо, или для системы поддержки принятия решений (и то не всегда). А для системы реально времени это не приемлемо совершенно, равно как и для системы взаимодействующей с пользователем. стали бы вы пользоваться текстовым редактором, в котором после ввода каждого слова следует секундная задержка на проверку орфографии?

3. Мелочевка.
Серьезные конторы не вкладывают деньги в развитие таких языков, в основном это все университетские проекты. Отладка в функциональных языках затруднена.

Самое главное: не видно особо сильных преимуществ функциональных языков, для того чтобы развернуть всю отрасль разработки ПО. А без этого ничего не будет, слишком много сил, денег и знаний вложено в традиционные языки.

Цитата

Написание задачи на функциональном языке требует от человека перед тем как начать писать код четко, формально сформулировать задачу.

а на императивном?

Цитата(setq @ 1.11.2005, 22:41)

а на императивном?

Не всегда, особенно в ООП часто просто определяешь пару основных интерфейсов, а затем пишешь прогу по кускам, порой совсем не зависимых друг от друга, благо ООП подход силён в этом.

Сильно добивает в функциональных языках(по крайней мере в тех что я видел), так и в Питоне, это кривые названия функций/обьектов. Ужать имя до нескольких согласных могут все, а вот помнить это и с лёгкостью после читать код - не каждый.

может не полениться и потратить время на решение какой-нибудь задачи на одном из императивных и на одном из функциональных языков? почему бы нам не сравнить потом эти программы по 1) скорости написания 2) производительности 3) читаемости 4) красоты кода :-D 5) наличию багов 6) и прочее

LSD

Цитата

1. Традиционное мышление. <skip> Пример написать текстовый редактор аля блокнот. В современной RAD среде быстро накидывается формочка, а затем к ней прикручивается функциональность (открытие документа, сохранение и т.д.). А вот много ли программисто смогут описать этот же редактор в терминах функций?

Думаю, из этого следует только один вывод - для написания текстового редактора ФЯ мало подходят Хотя вот в caml-list утверждали, что GUI прекрасно ложится на функциональную модель. Попробовать, что ли, на lablgtk посмотреть.

Цитата

2. Производительность.

Вот как раз с этим пунктом проблем все меньше. Ряд языков имеют весьма эффективные компиляторы в нативный код, ряд генерируют байт-код управляемых платформ, на скорость которых тоже вроде не особо жалуются. У меня есть сильное подозрение, что во многих современных приложениях основная причина недостаточной производительность - не в языках/платформах на которых они пишутся, а в дизайне самих приложений.

Цитата

А для системы реально времени это не приемлемо совершенно

Телефонные коммутаторы - это системы реального времени или нет? Erlang - пожалуй, самый коммерчески успешный из функциональных языков.
Кстати, вот еще один очень полезный атрибут ФЯ - легкость распараллеливания программ.

Цитата

3. Мелочевка. Серьезные конторы не вкладывают деньги в развитие таких языков, в основном это все университетские проекты.

Я бы не сказал, что это мелочевка... Это очень важный фактор, противодействующий распространению ФЯ. Я вот с интересом смотрю на MS: ну ладно, F# и SML.NET - это все-таки исследовательские проекты. А вот то что поддержка функционального стиля была заявлена едва ли не как основная цель в C# 3.0 - "это ж-ж-ж неспроста"

Цитата

Отладка в функциональных языках затруднена.

Ну разве что в ленивых. А для остальных - проблема скорее просто в том, что никто не торопится писать отладчики (да и вообще сопутствующий инструментарий).

Цитата

Самое главное: не видно особо сильных преимуществ функциональных языков, для того чтобы развернуть всю отрасль разработки ПО. А без этого ничего не будет, слишком много сил, денег и знаний вложено в традиционные языки.

Да кто ж предлагал разворачивать индустрию? Речь идет не о замене императивного стиля функциональным, а о внедрении второго там, где он действительно нужен. К тому же в современных языках эти две парадигмы явно идут на сближение.

setq

Цитата

может не полениться и потратить время на решение какой-нибудь задачи на одном из императивных и на одном из функциональных языков? почему бы нам не сравнить потом эти программы

Пусть народ предлагает задачи. Может, удастся и сравнить

Цитата(setq @ 1.11.2005, 23:41)

а на императивном?

Запросто, особенно на всяких современных RAD средах.
У нас была одна программа, программа взаимодействовала с некой аппраратурой, принимала сигналы от нее, обрабатывала, вообщем управляла процессом и плюс взаимодействовала с оператором. Программа была написанна на C++ Builder, а когда захотели перенести ее на Visual C++, выяснилось, что код настолько плотно завязан на C++ Builder, что выдрать его отуда практически нереально. Т.е. не было никакого разделения классов по функциям, визуальная чать отдельно, логика работы с аппаратурой отдельно, все было в перемешку. Вообщем в итоге бросли ее и стали писать заново.

Цитата(setq @ 2.11.2005, 09:24)

может не полениться и потратить время на решение какой-нибудь задачи на одном из императивных и на одном из функциональных языков?

У нас как раз открылся раздел тестов, предложи эту идею там.
Добавлено @ 17:44

Цитата(Void @ 2.11.2005, 17:37)

елефонные коммутаторы - это системы реального времени или нет?  Erlang - пожалуй, самый коммерчески успешный из функциональных языков. Кстати, вот еще один очень полезный атрибут ФЯ - легкость распараллеливания программ.

Капля в море. В любом случае языки которые идут от аппаратуры, будут потенциально более эфективнее, чем языки которые идут от задачи.

Цитата(Void @ 2.11.2005, 17:37)

Ну разве что в ленивых. А для остальных - проблема скорее просто в том, что никто не торопится писать отладчики (да и вообще сопутствующий инструментарий).

У нас уже был спор можно ли считать SQL языком программирования (я считаю что да), и если это так то почему для него нет отладчиков?

Цитата(Void @ 2.11.2005, 17:37)

Речь идет не о замене императивного стиля функциональным, а о внедрении второго там, где он действительно нужен.

И где он действительно нужен?

Цитата(LSD @ 2.11.2005, 19:37)

Капля в море.

Были упомянуты системы реального времени и проблема эффективности. Я показал, что эти понятия ФЯ не противоречат. Думаю, в Ericsson умеют считать деньги и используют Erlang не ради собственного удовольствия.

Цитата(LSD @ 2.11.2005, 19:37)

В любом случае языки которые идут от аппаратуры, будут потенциально более эфективнее, чем языки которые идут от задачи.

Потенциально... Мне почему-то кажется, что эффективность инструментов проверяется только на практике. Не забываем и про стоимость разработки. Понятно, что, к примеру, на ассемблере можно выжать из железа все, что возможно, только софт золотым становится.

Цитата(LSD @ 2.11.2005, 19:37)

У нас уже был спор можно ли считать SQL языком программирования (я считаю что да), и если это так то почему для него нет отладчиков?

Я же сказал, проблемы возникают для ленивых языков, т. е. языков, в которых порядок вычислений не определен. "Жадные" языки прекрасно отлаживаются. Для того же OCaml (уж извините, что везде вставляю, но я только с ним знаком достаточно хорошо) есть ocamldebug, правда невизуальный (а-ля gdb) и только под *nix/Cygwin.
Кстати, а как может выглядеть отладчик для SQL?

Цитата(Void @ 2.11.2005, 18:12)

Потенциально... Мне почему-то кажется, что эффективность инструментов проверяется только на практике. Не забываем и про стоимость разработки. Понятно, что, к примеру, на ассемблере можно выжать из железа все, что возможно, только софт золотым становится.

А зачем все приложение писать на ассемблере, только критическую часть, да и вообще Cи с этим неплохо справляется.

Цитата(Void @ 2.11.2005, 18:12)

Кстати, а как может выглядеть отладчик для SQL?

Вот и мне интерестно Я предполагаю что например можно использовать планы выполнения, и показывать результаты отдельных этапов.

Цитата(Void @ 2.11.2005, 18:12)

Были упомянуты системы реального времени и проблема эффективности. Я показал, что эти понятия ФЯ не противоречат. Думаю, в Ericsson умеют считать деньги и используют Erlang не ради собственного удовольствия.

Насчет Erlang ничего не скажу, я его не видел. Но при отладке SQL приходится забывать о всяких возвышенных вещах (типа оперирования множествами), и анализировать именно то как работает конкретная реализация SQL, на конкретной машине.

Цитата(LSD @ 2.11.2005, 20:20)

А зачем все приложение писать на ассемблере, только критическую часть, да и вообще Cи с этим неплохо справляется.

Для некоторых задач Си по сравнению с некоторым языками от ассемблера недалеко ушел
Почему бы не применить ту же логику уровнем выше: критичная к производительности (или тесно взаимодействующая с железом/ОС) часть на C++, а остальное - на высокоуровневом, пусть и несколько более медленном языке? Впрочем, могу сам же частично и ответить: хлопотное это занятие, интеграция мало похожих языков. Если для скриптовых языков (Python, Lua) существуют библиотеки, обеспечивающие удобное взаимодействие с C++ кодом, то с ФЯ дело обстоит гораздо печальнее.

Цитата(LSD @ 2.11.2005, 20:20)

Но при отладке SQL приходится забывать о всяких возвышенных вещах (типа оперирования множествами), и анализировать именно то как работает конкретная реализация SQL, на конкретной машине.

Если я правильно понял, речь идет скорее не об отладке, а о профилировании.

Цитата(Void @ 2.11.2005, 18:43)

Если я правильно понял, речь идет скорее не об отладке, а о профилировании.

Да, я не совсем правильно выразился.

Откопал тему! Я сильный некромант   


Применимость ФЯ сложно оспорить в свете доминирования Erlang как платформы для создания и поддержки телекоммуникационных систем. Вопрос скорее в том, что для написания кода в функциональном стиле требуется хорошая математическая, логическая подготовка и вывернутые низнанку (по сравнению со стандартным подходом) мозги - этому не учат/очень мало учат, и высокой зарплаты не сулит.


Во-первых, знакомство с несколькими языками программирования влияет на программиста резко положительно, особенно если они заставляют думать в разных парадигмах. В итоге у товарища формируется умение программировать не на языке, а с помощью языка. Во-вторых, проверенный факт - тяжело найти язык проще Erlang'а. На полноценное понимание синтаксиса достаточно суток; через неделю пишутся вполне достойные программы. И это чистый ФЯ!


Void хорошо ответил, добавлю лишь, что программы на ФЯ гораздо лучше поддаются распараллеливанию, причём на уровне компилятора. На многопоточность Эрланга равняются.


Опять вспомним про Erlang... и отставим его в сторону. ФП много, а вслух говорят только об Эрланге, да и то ограничивая уже привычными телекоммуникациями.

(обращаясь к любому ФП) Итак, если ты такой умный, то почему ты такой бедный? Нету денег? Ну да, кто же вложится в разработку проекта на языке, заставляющем сурово думать! Это же трудности с поиском специалистов, выплата им грандиозных (специалистских) денег, а уйдёт такое пестуемое чудо - где другого найти? Только Эрланг лёгок в освоении, и то народ его не использует! Похоже, мы попадаем в замкнутый круг: нет спроса -> нет предложения, нет предложения -> нет спроса...

А вопрос с отладчиками непрост. Для начала надо привыкнуть, что одна из парадигм ФП - отсутствие side-effects у функций, и при одинаковых поданых на вход аргументах всегда будет возвращено одно и то же значение. То есть если функция написана правильно однажды - нет нужды ползать внутри с отладчиком и искать ошибку. И ошибки чаще возникают не в деталях реализации, а в целом в логике программы - там, где отладчик бесполезен.


Python, Perl, JavaScript и иже с ними тоже имеют "поползновения" в сторону ФП, причём использующие их программисты даже не знают, что имеют дело с функциональщиной    Меня больше удивляет, почему main языки (ну как ещё объяснить их отличие от скриптовых) так тяжко и неохотно впитывают эти вкусности.

С сегодняшней колокольни считаю таковое движение очень полезным для: 1) пропаганды полезных парадигм ФП, 2) повышения общего уровня программистов. Скорее всего, за такими языками будущее. Принимаю возражения и обсуждения.


Сейчас играюсь со Scala. Язык сыроват, и самые нужные мне фичи (работа с базами данных) ещё не реализована. Но выглядит очень привлекательно.

Поправочка - некрофил  


Проверенный кем и на ком?  


Да распаралеливание нужно в единицах задач. Мне вот больше 5-8 поток ни в одном моём приложении создавать не приходилось. Да и то, в основном потоки занимались тем что ждали данные от внешних источников (сеть, com порт и т.п.). А по поводу ручное vs автоматическое управление многозадачностью, тут уже был один жаркий спор.

А вот что нужно на самом деле и чего нет ни у одного ФЯП (слово то какое  ) - это развитый фреймворк, с помощью которого можно и формочку побыстрому наваять, и XML распарсить, и с БД работать, и enterprise системку намутить.


Как все красиво звучит в теории  Вот только side-effects далекно не единственный источник ошибок. Как определить функция работает неправильно или получает на вход неправильные данные?

Ну-у, в принципе, ни для одного языка программирования сложность не была оценена объективно. Тем не менее, никто обычно не спорит, что, скажем, plain old Pascal проще, чем C++. Эрланг, в отличие от Паскаля с Сями, мало кому известен, но ежели кто осилил туториал, то не согласиться с тем, что толковый разработчик разберётся с языком за пару недель, будет трудно.

Sic! Это потому что у тебя парадигма неправильная  А писал бы на Эрланге, плодил бы по процессу на каждую сущность и все были бы счастливы, и всё масштабировалось бы до небес  

Некоторые особо хитрые товарищи (см. Scala, Nemerle) взяли, и присосались к JVM и .NET FW 
В остальных, да, фреймворков нет. Есть, конечно, OTP, который могуч и ужасен, но «страшно далёк от народа» в своём телекомовском великолепии.

Это сообщение отредактировал(а) Void - 11.2.2008, 17:26

И получили все прелести взаимодействия с императивными языками (типа side-efects) 



А вот тут и возникает вопрос, что есть процесс в Эрланге? Если это просто некая обёртка над процессами ОС, то это просто ужас. Т.к. в мейнстримовых ОС, процесс штука очень ресурсоемкая и создание его весьма длительно.

в сторону.

Нашёл "The implementation of functional programming languages" написанную Peyton'ом Jones'ом. ыыыыы.  Любопытные вещи валяются в ed2k.