Поиск функционального языка

Ответ 1

Если вам нравится использовать списки для большинства вещей и заботиться о производительности, используйте Haskell или Ocaml. Хотя Ocaml значительно страдает от того, что Floats на куче необходимо вставлять в коробку из-за дизайна VM (но массивы поплавков и записи с чисто плавающей точкой не индивидуально в штучной упаковке, что хорошо).

Если вы хотите использовать массивы больше, чем списки или планируете программирование с использованием изменяемого состояния, используйте Scala, а не Haskell. Если вы хотите написать многопотоковый многопоточный код, используйте Scala или Haskell (Ocaml требует от вас вилки).

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

Ocaml не работает на Vista 64 для меня, я думаю, потому что они просто изменили компоновщик в последней версии (3.11.1?), но более ранние версии работали нормально.

Scala поддержка инструмента в настоящий момент глючит, если вы используете ночные сборки, но должны быть хорошими в ближайшее время. Есть плагины eclipse и netbeans. Вместо этого я использую emacs. В прошлом я использовал оба графического интерфейса отладчика eclipse и netbeans.

Ни один из Scala, Ocaml или Haskell не имеет поистине замечательных стандартных библиотек, но по крайней мере вы можете легко использовать Java-библиотеки в Scala. Если вы используете mapreduce, Scala выигрывает при интеграции. У Haskell и Ocaml есть разумное количество сторонних библиотек. Меня раздражает, что в Haskell существуют разные имена комбинаторов для 2-3 типов монады.

http://metamatix.org/~ocaml/price-of-abstraction.html может убедить вас остаться с С++. Возможно написать Scala, который почти идентичен по производительности Java/С++, но не обязательно в функциональном или высоком стиле высокого уровня.

http://gcc.gnu.org/projects/cxx0x.html, кажется, говорит о том, что авто х =... (тип вывода для выражений) и lambdas можно использовать. С++ 0x с повышением, если вы можете его погладить, кажется довольно функциональным. Недостатком библиотек с высокой производительностью для сценариев С++ является, конечно же, время компиляции.

Ответ 2

В моем сознании есть три жизнеспособных кандидата: Haskell, Standard ML, OCaml. (Scala отсутствует на том основании, что он компилируется в JVM-коды и поэтому вряд ли будет достаточно быстрым, если программы должны работать в течение нескольких дней). Все они в основном функциональны. Я буду комментировать, где у меня есть знания.

производительный

• OCaml дает наиболее стабильную производительность для всех ситуаций, но производительность трудно улучшить. Вы получаете то, что получаете: -)

• Haskell обладает наилучшей параллельной производительностью и может отлично использоваться из 8-ядерной или 16-ядерной машины. Если ваше будущее параллельное, я настоятельно рекомендую вам осмыслить вашу неприязнь к системе типов и научиться эффективно использовать Haskell, включая расширения Data Parallel Haskell.

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

• Стандартный ML с компилятором MLton дает отличную производительность. MLton - компилятор цельной программы и выполняет очень хорошую работу.

Высокоуровневый и элегантный

• Синтаксически Haskell является явным победителем. Однако система типов захламлена остатками недавних экспериментов. Ядро системы типов, однако, является высокоуровневым и элегантным. Механизм "тип класса" особенно эффективен.

• Стандартный ML имеет уродливый синтаксис, но очень чистая система и семантика.

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

В основном функциональный

Haskell является чисто функциональным; Стандарт ML очень функциональный; OCaml в основном функционирует (но следите за изменчивыми строками и за некоторые удивительные упущения в библиотеках, например, функции списка небезопасны для длинных списков).

Портативность

Все три очень хорошо работают в Linux. Разработчики Haskell используют Windows и хорошо поддерживаются (хотя это и вызывает у них агонию). Я знаю, что OCaml хорошо работает на OSX, потому что я использую приложение, написанное в OCaml, которое портировано на OSX. Но я плохо информирован здесь.

Объектно-ориентированное

Нельзя найти в Haskell или SML. OCaml имеет стандартную систему OO, заполненную болотами, привитую на основной язык, не хорошо интегрированный с другими языками.

Вы не говорите, почему вы увлекаетесь объектной ориентацией. ML-функторы и классы типа Haskell предоставляют некоторую инкапсуляцию и полиморфизм (например, "общее программирование" ), которые находятся на С++.

Система типов, которая может быть подвергнута опрокидыванию

Все три языка предоставляют небезопасные роли. Во всех трех случаях они являются хорошим способом получения дампов.

Мне нравится иметь возможность делать неявное кастинг.

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

Инструменты

В Haskell есть довольно хорошие инструменты для профилирования. У стандартного ML есть дерьмовые инструменты. OCaml имеет в основном стандартное профилирование Unix и неиспользуемый отладчик. (Отладчик отказывается пересекать барьеры абстракции, и он не работает с собственным кодом.)

Моя информация может быть устаревшей; изображение инструментов меняется все время.

Мусор, собранный и скомпилированный в собственный код

Check. Нечего выбирать.

Рекомендации

Преодолейте свое отвращение к безопасным, безопасным типам систем. Изучите классы типа Haskell (оригинальная статья Вадлера и Блота и учебник Маркса Джонса могут освещать). Погрузитесь в Haskell, и обязательно узнайте о огромной коллекции сопутствующего программного обеспечения в Hackage. p >

Ответ 3

Попробуйте Scala. Это объектно-ориентированный функциональный язык, который работает в JVM, поэтому вы можете получить доступ ко всему, что когда-либо было написано на Java. Он имеет все ваши важные функции и один из приятных функций. (Очевидно, не # 2.2:), но это, вероятно, будет быстрее.) У него очень сильная типизация, но с типом вывода он действительно не мешает вам.

Ответ 4

Вы только что описали Common Lisp...

Ответ 5

Ваши требования, как мне кажется, очень хорошо описывают ocaml, за исключением "не слишком сильной" типизации. Что касается инструментов, я использую и люблю режим tuareg для emacs. Ocaml должен работать на окнах (я не использовал его сам, хотя), и очень похож на F #, FWIW.

Я бы рассмотрел экосистему вокруг языка. На мой взгляд, основным недостатком Ocaml является то, что у него нет огромного сообщества и, следовательно, ему не хватает большой библиотеки сторонних модулей, которые являются частью того, что делает python настолько удобным. Чтобы написать свой собственный код или изменить какой-то еще один прототип модуля, который вы нашли в Интернете, может съесть часть времени, которое вы сохраняете, написав на хорошем функциональном языке.

Ответ 6

Вы можете использовать F # на моно; возможно, стоит посмотреть? Я знаю, что моно не на 100% совершенен (ничего не существует), но он очень далек от "ужасного"; большинство пробелов происходит в таких вещах, как WCF/WPF, и я сомневаюсь, что вы захотите использовать их из FP. Это, кажется, предлагает многое из того, что вы хотите (за исключением, очевидно, того, что оно работает в виртуальной машине), но вы получаете огромный набор доступных библиотек в сделке (то есть большую часть .NET) - гораздо проще, чем OCaml, на котором он основан).

Ответ 7

Я все равно поеду на Python, но используя NumPy или какой-нибудь другой внешний модуль для хруста числа или, альтернативно, сделаю логику в Python и горячих точках в C/ассемблере.

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

Ответ 8

Я думаю, что Common Lisp подходит для вашего описания.

1.1: Производительность. Современные реализации CL почти совпадают с C. Существуют также интерфейсы внешних функций для взаимодействия с библиотеками C, и многие привязки уже выполнены (например, Научная библиотека GNU).

1.2: Высокоуровневый и элегантный: Да.

1.3: В первую очередь функциональный: да, но вы также можете "получить императив" там, где это необходимо; CL является "мультипарадигмой".

1.4: Переносимость: Существует несколько реализаций с различной поддержкой для каждой платформы. Некоторые ссылки находятся на CLiki и ALU Wiki.

1.5: Объектно-ориентированная, желательно по философии "все является объектом": CLOS, Common Lisp Object System, гораздо ближе к объектно-ориентированной, чем к любому из "курчавых" языков, а также имеет функции, которые вы очень пропустите в другом месте, например, многоточие.

2.1: "Не слишком сильный" ввод: CL имеет динамическую, сильную типизацию, которая, кажется, нужна вам.

2.2: Инструменты: Emacs + SLIME (режим взаимодействия Lisp для Emacs) - очень хорошая бесплатная среда разработки. Существует также плагин для Eclipse (Cusp), и коммерческие реализации CL также могут привести к созданию собственной среды IDE.

2.3: Сбор мусора, но он был переведен или скомпилирован без виртуальной машины. Образ Lisp, над которым вы будете работать, - это своего рода виртуальная машина, но я думаю, что это не то, что вы имеете в виду.

Дополнительным преимуществом является инкрементная разработка: у вас работает REPL (read-eval-print-loop), который обеспечивает живой интерфейс в текущем изображении. Вы можете скомпилировать и перекомпилировать отдельные функции "на лету" и проверить текущее состояние программы в живой системе. У вас нет принудительных прерываний из-за компиляции.

Ответ 9

Краткая версия: язык программирования D

Yum Yum Yum, это большой набор требований.

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

Требования к синтаксису

• Объектно ориентированная презентация
• Низкая степень управления памятью
• Позволяет стиль функции
• Не Хаскелл (черт побери)

Требования к бэкэнд

• Быстро для науки
• Сбор мусора

На этой основе я бы рекомендовал язык программирования D, который является преемником C, который пытается быть всем для всех людей.

Эта статья о D касается аспектов функционального программирования. Он объектно ориентирован, сбор мусора и компилируется в машинный код, так быстро!

Удача

Ответ 10

Clojure и/или Scala являются хорошими датами для JVM

Ответ 11

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

• Clojure Это действительно очень хороший язык. Этот синтаксис основан на LISP, и он работает на JVM.

• D Это похоже на то, что С++ сделан правильно. Он имеет все функции, которые вы хотите, за исключением того, что он слабо работает в функциональном программировании.

• Очистить. Это очень сильно зависит от Haskell, но устраняет некоторые проблемы с Haskell. Недостатки в том, что он не очень зрелый и не имеет большого количества библиотек.

• Фактор Синтаксически он основан на Forth, но поддерживает LISP -подобное функциональное программирование, а также лучшую поддержку классов.

Ответ 12

Взгляните на Erlang. Первоначально Эрланг был предназначен для создания отказоустойчивых, высокопараллельных систем. Это функциональный язык, охватывающий неизменность и первоклассные функции. У этого есть официальная бинарная версия Windows, и источник может быть скомпилирован для многих платформ NIX (например, есть сборка MacPorts).

В терминах высокоуровневых функций Erlang поддерживает список списков, сопоставление шаблонов, предложения охраны, структурированные данные и другие вещи, которые вы ожидаете. Это относительно медленно в последовательных вычислениях, но довольно удивительно, если вы делаете параллельные вычисления. Erlang работает на виртуальной машине, но работает на собственной VM, которая является частью дистрибутива.

Эрланг, хотя и не строго объектно-ориентированный, извлекает выгоду из мышления ОО. Эрланг использует предмет, называемый процессом как его блок concurrency. Процесс Erlang на самом деле очень похож на собственный поток, за исключением гораздо меньших накладных расходов. У каждого процесса есть почтовый ящик, будут отправлены сообщения и будут обрабатывать эти сообщения. Достаточно легко обрабатывать процессы, как если бы они были объектами.

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

Ответ 13

Вы уверены, что вам действительно нужен функциональный язык? Я большую часть своего программирования программировал в lisp, что, очевидно, является функциональным языком, но я обнаружил, что функциональное программирование - это скорее ум, чем язык. Я использую VB прямо сейчас, и я думаю, что это отличный язык (скорость, поддержка, IDE), и я в основном использую тот же стиль программирования, что и я в lisp - функции вызывают другие функции, которые вызывают другие функции, а функции обычно длиной 1-5 строк.

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

Я просмотрел clojure, но если вам не нравится java, вам, вероятно, не понравится clojure. Это функциональный lisp -стильный язык, реализованный поверх java, но вы, вероятно, будете постоянно использовать java-библиотеки, добавляя вербальность Java. Мне нравится lisp, но мне не понравилось clojure, несмотря на шумиху.

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

Ответ 14

Многие из ваших требований основаны на слухах. Один пример: идея о том, что Моно "ужасно".

http://banshee-project.org/

Это официальный медиаплеер многих дистрибутивов Linux. Это написано на С#. (У них даже нет общедоступной версии Windows!)

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

Хотя вы зарабатываете очки за упоминание инструментов (хотя и не с достаточным приоритетом). Как заметил Кнут, первый вопрос о языке - "Что такое отладчик?"

Ответ 15

Оглядываясь на ваши требования, я бы порекомендовал VB либо в Mono, либо в виртуальной машине, работающей под Windows. Как сказал предыдущий плакат, первое, что нужно спросить о языке, это "Что такое отладчик вроде", а VB/С# - лучший отладчик. Просто результат того, что все эти сотрудники Microsoft врезались в отладчик, и имея команды рядом с ошибкой (без каламбура), чтобы зафиксировать ее.

Самое лучшее, что касается VB и С# - это большой набор инструментов для разработчиков, сообщества, справки Google, exapmles кода, библиотек, softwaer, которые взаимодействуют с ним и т.д. В прошлом я использовал самые разные среды разработки программного обеспечения 27 лет, и единственное, что подходит близко, - это аппаратные среды Xerox Lisp (лучше) и машины Symbolics Lisp (хуже).