Комментарии 14
У любых декларативных языков есть один недостаток. То что делается левой ногой на императивных языках делается довольно сложно на декларативных. Простой пример интерфейс взаимодействия с пользователем. Не CLI а к примеру банальные меню или GUI с интерактивным вводом.
Подозреваю, именно потому, что GUI пишут на императивных языках.
А вообще да. Приходится использовать всякие "спайки".
А вообще да. Приходится использовать всякие "спайки".
>Подозреваю, именно потому, что GUI пишут на императивных языках.
Вообще нет. Функциональное программирование хорошо заточено под пакетные задания. Интерактив же с пользователем или требует ожидания поступления какого либо события. Каким образом вы это будете реализовывать ? :)
Вообще нет. Функциональное программирование хорошо заточено под пакетные задания. Интерактив же с пользователем или требует ожидания поступления какого либо события. Каким образом вы это будете реализовывать ? :)
Я вообще никакой проблемы не вижу, реализовать ожидание события в функциональном языке.
Во-первых есть понятие tail-recursion, которая эквивалентна циклу.
Во-вторых живой пример:
sender(PID) ->
PID ! {"Hello",self()},
receive
Message ->
io:format("~nReceived ~p",[Message])
end.
Всё тот же клятый Эрланг. Функция будет ждать, пока не получит ответ на отправленное сообщение.
Во-первых есть понятие tail-recursion, которая эквивалентна циклу.
Во-вторых живой пример:
sender(PID) ->
PID ! {"Hello",self()},
receive
Message ->
io:format("~nReceived ~p",[Message])
end.
Всё тот же клятый Эрланг. Функция будет ждать, пока не получит ответ на отправленное сообщение.
>Во-первых есть понятие tail-recursion, которая эквивалентна циклу.
Есть. Но шутка довольно искуственная.
Ожидание ввода это хорошо. А вот как быть с ожиданием вызова меню или еще чего либо подобного?
Есть. Но шутка довольно искуственная.
Ожидание ввода это хорошо. А вот как быть с ожиданием вызова меню или еще чего либо подобного?
Это заблуждение. Интерфейс в функциональном стиле можно увидеть, например, в Excel. Просто настолько, что даже не-программисты спокойно создат сложные формы.
Или Вы имеете в виду реализацию низкоуровневых методов drawBox, drawText?
Или Вы имеете в виду реализацию низкоуровневых методов drawBox, drawText?
Я про низкий уровень. Создание псевдографические менюшки на prolog это удовольствие ниже среднего. Хотя зато вот какая нибудь логическая шняга на prolog'е писалась на ура, но в императивном требовала довольно некислого количества телодвижений.
Я с Вами согласен в этом случае. Но хочу обратить внимание, что индустрия давно через низкий уровень переступила. Работая на Java, на C#, мы пользуемся фреймворками, не задумываясь о том, как там всё внутри реализовано.
На уровне использования практически всё-равно, на чём писать. На функциональных языках получается удобнее, поэтому, думаю, все там будем лет через пять.
На уровне использования практически всё-равно, на чём писать. На функциональных языках получается удобнее, поэтому, думаю, все там будем лет через пять.
А можно не извращаться и комбинировать :)
На intuit.ru есть отличный курс "Стили и методы программирования", рассказывается про традиционный, функциональный и другие методы программирования. Там же есть "Введение в программирование на Лиспе". Вот даже скачал IDE для Lisp - Jabberwocky (лучшее, что накопал, ато скучно в консольке то :)(а Jabberwocky на Java написан =), да решил изучить побольше чем как-то-где-то-видел-вроде.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Про ФП #2