Будет ли функциональный язык, который делает для сообщества Java то же, что F # делает для сообщества .NET? - PullRequest
22 голосов
/ 04 октября 2008

Будет ли функциональный язык, который делает для сообщества Java то, что F # делает для сообщества .NET?

Какие функциональные языки программирования доступны или находятся в разработке для JVM?

Ответы [ 9 ]

43 голосов
/ 04 октября 2008

Scala будет языком.

Хотя он не является строго функциональным (это сочетание функциональности и объектно-ориентированного), и не строго для Java (есть .NET-версия Scala ), он был бы наиболее близким аналогом F # в JVM.

20 голосов
/ 04 октября 2008

Первое, что мне пришло в голову, было Scala , но на самом деле Ocaml-Java приближается, поскольку F # является вариантом Ocaml. См. этот пост, который сравнивает Ocaml-Java с Scala :

Программисты OCaml, как правило, более чем в 10 раз производительнее, чем Java или C ++ программисты для широкого круга практических задач. Несмотря на то, что основано на В основном платформа ООП, F # имеет большое значение для повышение преимуществ OCaml (и всей семьи ML). В отличие от Scala не в состоянии охватить многие из преимуществ, в том числе некоторые действительно основные и, следовательно, написание правильного кода гораздо сложнее в Scala, чем в любой настоящий ML.

Кроме того, семейство языков ML разработано, чтобы быть кратким, но Scala ненужно многословно для всего от "Привет, мир!" снизу вверх. Семья МЛ языков обеспечивает обширный вывод типов (OCaml больше, чем большинство), но В сравнении Scala имеет только элементарный вывод. OCaml имеет необычно система выразительных типов, но Scala мало добавляет к ООП, что имеет практическое значение важность.

18 голосов
/ 05 октября 2008

Возможно Clojure . Он не статически типизирован, но в нем больше внимания уделяется неизменности и параллелизму, чем F #. Однако, как и F # (и в отличие от Common Lisp), он предназначен для того, чтобы быть в первую очередь функциональным языком, который хорош для использования библиотек OO с базовой платформы.

3 голосов
/ 04 октября 2008

Пока я бы сказал, Скала. Но на будущее я бы взглянул на Крепость. Первая реализация спецификации была выпущена 1 апреля 2008 года. И нет, это не шутка. Ключевые особенности:

  • Статически типизировано, но много типов вывода, чтобы избежать беспорядка
  • Unicode и 2d рендеринг математических функций
  • Предназначен для параллельного выполнения (для каждого значения по умолчанию)
  • Сильная поддержка пользовательских библиотек (влияние Гая Стила)
  • Перегрузка оператора, включая оператор сопоставления

Больше информации на сайте Project Fortress Community и на странице Wikipedia Fortress .

2 голосов
/ 17 декабря 2009

Существует хороший список языков программирования для JVM, включая функциональную парадигму программирования и другие языки парадигмы на:

  • en.wikipedia.org / вики / List_of_JVM_languages ​​

Мой первый выбор - Scala (мультипарадигма; OO & FP), я потратил 5 месяцев на изучение Scala в 2009 году и создал краткий справочник: bchiprog.blogspot.com/2009/05/scala-cheat sheet.html

Я заметил, что есть и другие интересные программные парадигмы, в других сфокусированы на параллельной обработке, такие как X10, Fortress и Chapel. X10 реализован поверх Scala - http://www.scala -lang.org / sites / default / files / odersky / scalaliftoff2009.pdf

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

2 голосов
/ 20 октября 2008

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

Ближе всего к реализациям функционального языка в JVM относятся Clojure , Scala и проект OCaml-Java . Хотя существуют обходные пути для отсутствия хвостовых вызовов (например, трамплин), ни одна из этих реализаций языка не делает этого, потому что обходные пути создают еще более серьезные проблемы, например, снижение производительности и полное запутывание отладки.

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

Cheers, Джон Харроп.

1 голос
/ 25 декабря 2011

Между тем, существует Frege , чистый функциональный, нестрогий язык в духе Haskell, который компилируется в Java, который затем компилируется с помощью javac или компилятора eclipse, в зависимости от среды ( командная строка или затмение).

1 голос
/ 05 октября 2008

@ Marc Gravell - функциональные языки все чаще используются в кишках финансовых систем корпоративного уровня. В банке, в котором я работаю, мы используем много функциональных (чистых или "полупрозрачных")

0 голосов
/ 04 октября 2008

На самом деле, я могу ошибаться, но я не ожидаю, что F # будет таким же распространенным явлением, как другие языки .NET; полезно в нескольких кругах (академические, компиляторы, несколько других сценариев) - однако, не забывайте, что C # предлагает использование FP - и это улучшается каждый раз: C # 1.2 имеет делегатов; C # 2.0 имеет анонимные методы и захваты / закрытия; В C # 3.0 есть лямбды для простоты и Expression для абстракции. Анонимные типы (C # 3.0) имеют некоторое сходство с кортежами (с точки зрения удобства), но, очевидно, это очень разные звери, поэтому однозначно нельзя сравнивать.

Возможно, не так оптимизирован, как F #, но для большинства повседневных сценариев использования более чем достаточно.

Также совершенно очевидно, что лучшая поддержка неизменяемости (особенно для многопоточности) очень важна для команды по языку C # для дальнейшего рассмотрения.

Мои деньги на C # улучшаются в FP, и он является предложением .NET FP для большинства повседневных задач. Конечно, будет некоторое использование F #, но (чисто субъективно) я просто не вижу огромной миграции.

...