Действительно ли языки функционального программирования хороши для практических задач? [закрытый]
Я заставил это работать благодаря некоторой внутренней справке в Apple Devforums , необходимо подписаться, если Вы - преданный разработчик iPhone.
Первая первая вещь, это __ asm __ () , не просто asm () .
, Во-вторых, по умолчанию, XCode генерирует цель компиляции, которая компилирует встроенный ассемблерный код против системы команд Ползунка ARM, таким образом usat не был распознан как надлежащая инструкция. Для фиксации этого действительно "Получите Информацию" о Цели. Прокрутите вниз к разделу "GCC 4.0 - Code Generation" и снятию флажка "Компиляцию для Ползунка". Тогда этот после отрывка скомпилирует очень хорошо при установке Активного SDK на "Устройство"
inline int asm_saturate_to_255 (int a) {
int y;
__asm__("usat %0, #8, %1\n\t" : "=r"(y) : "r"(a));
return y;
}
Естественно теперь это не будет работать с IPhone Simulator. Но TargetConditionals.h имеет, определяет Вас, может #ifdef против. А именно, TARGET_OS_IPHONE и TARGET_IPHONE_SIMULATOR.
8 ответов
Что касается языков, я думаю, что F # - это пример языков, которые в первую очередь «функциональны», но также «практичны». Scala и Clojure, вероятно, относятся к этой категории.
(Углубляясь на один уровень глубже, я думаю, что «формула успеха» здесь - это язык, который сильно склоняется к «функциональному», но имеет доступ к обширным практическим библиотекам (например, .Net / JVM / some C FFI) и имеет хороший инструментарий (например, поддержку IDE).)
Я, по крайней мере, частично согласен с неявной предпосылкой вопроса, а именно, что существует противоречие между «краткой / красивой аналитической силой» и « прагматика ».
Erlang хорошо известен его надежность и возможности для написания серверов с высокой степенью параллелизма.
Он также имеет СУБД из коробки.
IMO, Схема слишком минималистична для практического применения - она используется в нескольких учебных курсах (см. Структура и интерпретация компьютерных программ). Однако современные языки Lisp, такие как Common Lisp и особенно Clojure, приобретают все большее значение. Erlang используется несколькими крупными отраслями для приложений с высоким уровнем параллелизма, и я лично не видел, чтобы его использовали программисты конечных пользователей. С другой стороны, Haskell - это вполне реальный язык, который использовался для написания множества замечательных программ, включая:
- XMonad - оконный менеджер X Window System, написанный исключительно на Haskell.
- Leksah, IDE для Haskell написан на самом Haskell.
- Pugs, одна из ведущих реализаций Perl 6, написана на Haskell.
- Наконец, компилятор Glasgow Haskell написан на Haskell.
Есть ли у кого-нибудь примеры функциональных языков, которые отлично подходят для выполнения практических задач, или практические задачи, которые лучше всего выполняются функциональными языками?
Наш бизнес работает на коде F # для всего от онлайн-транзакций по кредитным картам до веб-аналитики. Эти LOB-приложения состоят из крошечных сценариев F #, которые делают все необходимое быстро и просто, используя бесшовное взаимодействие .NET и автоматизацию таких приложений, как Outlook и Excel.
Наш бизнес зарабатывает большую часть своих денег на продаже программного обеспечения, написанного на F #, которое решает практические проблемы для клиентов из многих секторов, от встроенного программного обеспечения для медицинского оборудования до поставщиков морских интернет-услуг.
Забавно, у нас с вами очень разные представления о «практических задачах». Вы говорите, что это:
Принять запрос, найти и обработать запрошенные данные и вернуть их в необходимом формате.
Это в значительной степени то, для чего создан функциональный язык: функции, которые принимать данные и возвращать новые данные без сохранения какого-либо состояния между вызовами (т.е. без побочных эффектов). Это то, что у вас есть, и это также называется трубопроводом.
Это не то, что я бы назвал практической задачей. В современных программах вам приходится иметь дело с графическим интерфейсом пользователя, многопоточными функциями и сетевым вводом-выводом. Все они имеют состояние, необходимое для хранения данных между вызовами функций. Данные не передаются по конвейеру в функцию, а результат не передается по конвейеру, функции также влияют на «глобальное» состояние.
И это определение «практической задачи», при котором функциональные программы начинают давать сбой. Написание графического интерфейса в функциональной программе практически невозможно, если, например, вы не используете их императивные расширения.
Итак, в заключение, ответ, о котором вы просите, - искреннее «да», функциональные программы справляются с этой задачей. Однако ответ, который вы действительно ищете, заключается в том, что это немного сложнее.
В основном, задачи, которые я бы назвал 'практическими', такие как
Принять запрос, найти и обработать запрошенные данные, и вернуть их отформатированные по необходимости
Вы экспериментировали с Erlang и не смогли найти для него практическую задачу под это описание практической?
Принять запрос.
Вы имеете в виду принять. Или просто вызывается прямо как функция.
Найти и обработать запрошенные данные.
Я не совсем понимаю, что вы имеете в виду, но для поиска данных есть файловый ввод-вывод, сетевой ввод-вывод, (распределенное) межпроцессное взаимодействие и т.д. и т.п. и т.д.. Для поиска подмножеств этих данных есть регулярные выражения, сопоставление шаблонов и т.д.
Для обработки есть целая куча вещей для строк, списков, математики, множеств, графов и т.д. Разве этого недостаточно для обработки? Что еще вам нужно?
Верните его в нужном формате.
Я могу вернуть результирующие данные в виде атомов, списков, двоичных блоков, форматированных строк, чисел и т.д. Чего не хватало в Erlang в этом отношении? Честно говоря, я совсем запутался.
Вы когда-нибудь использовали LINQ?
Если да, поздравляю. Вы использовали функциональный язык в практическом контексте. В этом суть функционального развития.
И да, F # ОЧЕНЬ полезен.