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

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

http://banshee-project.org/

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

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

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

Looking over your requirements, I would recommend VB on either Mono, or a virtual machine running windows. As a previous poster said, the first thing to ask about a language is "What is the debugger like" and VB/C# have the best debugger. Just a result of all those Microsoft employees hammering on the debugger, and having the teams nearby to bug (no pun intended) into fixing it.

The best thing about VB and C# is the large set of developer tools, community, google help, code exapmles, libraries, softwaer that interfaces with it, etc. I've used a wide variety of software development environments over the past 27 years, and the only thing that comes close is the Xerox Lisp machine environmnets (better) and the Symbolics Lisp machines (worse).

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

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

Я взглянул на clojure, но если вам не нравится java, вам, вероятно, не понравится clojure. Это' sa, реализованный на основе функционального языка Lisp поверх java, но вы, вероятно, обнаружите, что все время используете библиотеки java, которые добавляют многословность java. Мне нравится шепелявить, но, несмотря на шумиху, мне не нравится закрытие.

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

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

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

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

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

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

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

2. D Это похоже на C ++, сделанный правильно. В нем есть все функции, которые вам нужны, за исключением того, что он слабо подходит для функционального программирования.

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

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

Clojure и / или Scala - хорошие кандидаты для JVM

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

Ням-ням-ням, это большой набор требований.

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

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

1. Объектно-ориентированное представление
2. Низкая сложность управления памятью
3. Разрешает стиль функций
4. Это не Haskell (черт возьми)

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

1. Пост для науки
2. Сбор мусора

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

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

Удачи

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

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

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

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

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

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

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

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

Performant

• 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 имеет стандартную объектно-ориентированную систему, привитую к основному языку, но плохо интегрированную с другими языками.

Вы не говорите, почему вы увлечены объектной ориентацией. Функторы ML и классы типов Haskell обеспечивают некоторую инкапсуляцию и полиморфизм (так называемое «общее программирование»), которые можно найти в C ++.

Система типов, которую можно изменить.

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

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

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

Инструменты

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

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

Сборщик мусора и компиляция в собственный код

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

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

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

I think that Common Lisp fits your description quite well.

1.1: Performance: Modern CL implementations are almost on par with C. There are also foreign function interfaces to interact with C libraries, and many bindings are already done (e.g. the GNU Scientific Library).

1.2: High-level and elegant: Yep.

1.3: Primarily functional: Yes, but you can also "get imperative" wherever the need arises; CL is "multi-paradigm".

1.4: Portability: There are several implementations with differing support for each platform. Some links are at CLiki and ALU Wiki.

1.5: Object-oriented, preferably under the "everything is an object" philosophy: CLOS, the Common Lisp Object System, is much closer to being "object oriented" than any of the "curly" languages, and also has features you will sorely miss elsewhere, like multimethods.

2.1: "Not-too-strong" typing: CL has dynamic, strong typing, which seems to be what you want.

2.2: Tools: Emacs + SLIME (the Superior Lisp Interaction Mode for Emacs) is a very nice free IDE. There is also a plugin for Eclipse (Cusp), and the commercial CL implementations also oftem bring an own IDE.

2.3: Garbage collected, but translated or compiled without a virtual machine. The Lisp image that you will be working on is a kind of VM, but I think that's not what you mean.

A further advantage is the incremental development: you have a REPL (read-eval-print-loop) running that provides a live interface into the running image. You can compile and recompile individual functions on the fly, and inspect the current program state on the live system. You have no forced interruptions due to compiling.