LINUX.ORG.RU

Подскажите язык?

 , ,


2

4

Обязательно:

  1. Функциональный
  2. С отличной обратной совместимостью
  3. Компилируемый

Желательно:

  1. Сильная статическая типизация
  2. Умеет в многопоточность

Как я понимаю, Haskell отпадает по 2-му пункту. Нравящийся мне Erlang по 3-му. Какой пройдёт первые три условия? CL (SBCL) или OCaml? Как у них с обратной совместимостью?

Upd: компилируемый в бинарь

Upd: Я выслушал много Ваших мнений, мудрецы. Сворачиваем наш уютный срачик. Ща посмотрим, что пережуёт моя анальнозондированная. Надеюсь на CL, F#, OCaml (в этом порядке). Scala, Haskell и другие на старость.

Deleted

Последнее исправление: merhalak (всего исправлений: 4)

Ответ на: комментарий от staseg

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

Deleted
()
Ответ на: комментарий от Deleted

Ускорение ничтожно

Компилируемые чаще работают шустрее.

Преждевременная оптимизация зло. Скорость написания ПО гораздо важнее скорости их исполнения. Кроме того современные интерпретируемые языки весьма быстры, это не Бейсик из начала 90-х.

Camel ★★★★★
()

Использую окамл. Брат жив.

ymn ★★★★★
()

CL вроде неплохо вписывается. Там правда 4-й пункт смотрится довольно дико.

UPD ХЗ походу нет в CL никакого 4-го пункта.

ados ★★★★★
()
Последнее исправление: ados (всего исправлений: 1)
Ответ на: комментарий от ymn

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

#include пасты_с_кодача

Deleted
()
Ответ на: Ускорение ничтожно от Camel

Ситуация несколько поменялась в последние годы. В мобильных устройствах от производительности софта зависит время жизни батарейки. В датацентрах от производительности софта зависит стоимость электроэнергии на питание и охлаждение серверов. Да и персоналки уже перестали устаревать морально каждые 1.5 года. Игровые приставки обновляются так же не каждый день. Встраиваемых компьютеров все больше и больше (а там и мощность не такая, и работать они должны от батареек годами).

Так что не все так просто и однозначно, как 10 лет назад.

eao197 ★★★★★
()
Ответ на: комментарий от Deleted

Реализации отличаются между собой

Это да.

ymn ★★★★★
()

CL (SBCL)

Erlang

у термина «функциональное программирование» есть 2 значения

Традиционное: Подстановочная модель

Современное: Статически-типизированный + подстановочная модель + костыли, позволяющие отчасти преодолеть ограничения подстановочной модели

Иногда ко второму еще приплетают нормальный порядок редукций, как в хаскеле.

Ни CL ни эрланг сюда не входят никаким боком. Какого хрена их постоянно пытаются притянуть за уши к ФП?

newquestion
()

OCaml с 4.03 будет, вроде как, уметь multicore, в остальном полностью подходит.

mix_mix ★★★★★
()
Ответ на: комментарий от ovk48

Rust буду смотреть после версии 2.0. Пока студент - можно. Но из императивных мне больше ANSI C по душе, хоть и использую for и stdint.h из c99.

Deleted
()
Ответ на: комментарий от newquestion

Какого хрена их постоянно пытаются притянуть за уши к ФП?

Если в языке хотя бы отлично работают ФВП лямбды и замыкания, то язык всё равно никак не относится к ФП?

ados ★★★★★
()
Ответ на: комментарий от Deleted

F# — это такой ocaml.NET без функторов и с некоторыми прочими отличиями, зато с доступом ко всему .NET включая async и threading и генерацией кода для GPU из коробки.

x3al ★★★★★
()
Ответ на: комментарий от den73

Мне нравится некоторое подмножество свойств: иммутабельность, функции как объекты, сопоставление с образцом. Понятное дело, что тот же Erlang больше похож на императивный язык, если использовать wxErlang, но тем не менее, стиль отличается от сишки.

Deleted
()
Ответ на: комментарий от x3al

В основном пока приходится использовать Java. Та же Scala ближе, если использовать свой же код.

Deleted
()
Ответ на: комментарий от Deleted

Но из императивных мне больше ANSI C по душе

Rust функциональный побольше, чем императивный. И это вот

иммутабельность, функции как объекты, сопоставление с образцом

все в нем тоже есть.

ovk48 ★★★
()
Ответ на: комментарий от Legioner

breaking changes в 7.10. Я бы понял breaking changes как при переходе с Java7 до Java8 String.split(""). Я (может быть ошибочно) считал, что такие вещи должны меняться с GHC 7 до GHC 8 (если первая цифра - мажорная).

Просто у меня любопытство просыпается, если начало очень лёгкое: понравился синтаксис, посмотрел чуть более сложный, чем совсем базовый пример на concurrency или opengl, скомпилировал без ошибок - заработало на моей машинке: «ура, читаем теорию». Я же ленивая задница: стащил пример на concurrency с eax.me, попробовал собрать через cabal, попробовал так: ругается на отсутствие нужных версий либ, попробовал загуглить: не нашёл за 10 минут, расстроился, пошёл взгрустнул. Erlang же жрёт всё из интернета.

Deleted
()
Последнее исправление: merhalak (всего исправлений: 1)
Ответ на: комментарий от Deleted

~ 3 года, во второй версии будут предупреждения по всему, что меняется.

qnikst ★★★★★
()
Ответ на: комментарий от Deleted

Отвечу по SBCL:

1. Иммутабельность не особо хорошо поддерживается. Две недели искал ошибку, а ошибка была в голове. Функция sort меняет свой аргумент, а я думал, что копирует. В языке нет встроенных средств для контороля.

2. Функции как объекты есть почти во всех языках, в т.ч. в С (указатели на функцию). Другое дело, раньше в С не было замыканий, не знаю, как сейчас. С замыканиями в SBCL всё хорошо. Зачем нужен, к примеру, карринг, я не знаю, никогда им не пользовался. Предикат или декларация чистоты - вот это полезная вещь, но в SBCL его нет. С другой стороны, само по себе понятие чистоты не однозначно определено.

3. Сопоставление с образцом. В общем-то, не имеет отношения к ФП, в моём понимании. Это работа с данными. В SBCL нет сопоставления с образцом, оно есть в библиотеках, например, в SWANK. На практике лично я почти не пользуюсь им. Проблема в том, что сопоставление - это широкая тема. Вряд ли то сопоставление, которое есть в языке «из коробки», будет подходить для всех случаев. Для каких-то подойдёт, для каких-то нет. В этом плане SBCL тоже будет хорошим выбором.

Ну и по остальным твоим пунктам:

- обратная совместимость в лиспе прекрасная, спокойно собираются проекты из 90-х.

- компилируемый - да. По скорости уступает С в 1,5-3 раза. Раньше был хороший сайт «computer benchmark game», где можно было строить сравнительные гарфики. Но прогресс добрался до него, теперь там нужно выписывать результаты на бумажку и строить графики самостоятельно.

- статическая типизация - да, опциональна. Писать определения типов неудобно, но сама система типов очень хороша, наверное, я не видел лучше. Эффективная, простая, не мешает когда не надо.

- многопоточность - да, офтопик и онтопик. Хотя говорят, что по надёжности лучше CCL. CCL генерирует более медленный код, но в целом качество продукта выше.

den73 ★★★★★
()
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от eao197

Ситуация нисколько не поменялась в последние годы

Ситуация несколько поменялась в последние годы.

Отнюдь. Всё ещё программа работающая за дорого ценнее программы пока не работающей никак.

Camel ★★★★★
()
Последнее исправление: Camel (всего исправлений: 1)
Ответ на: комментарий от Deleted

Он себе runtime компилером в .exe (для той же Win) запаковывает?

Не более, чем Scala делает это. Разница в том, что Scala больше ООП и синтаксис в ней дальше от SML. Ну и CLR против JVM.

x3al ★★★★★
()
Ответ на: комментарий от Deleted

нету там breaking changes. Есть несколько неожиданностей:

1. в 1.5 местах придётся прописать FlexibleContexts (т.к. раньше код, который не должно было пускать пускало)

2. возможно в паре мест прописать явно, что используются списки, т.к. функции в Data.List полиморфные (это сделано, чтобы не сломать *все* программы, а только чуть-чуть). В общем-то это самая проблемная часть

3. Ну и AMP, но если код в 7.8 собирается с -Werror -Wwarn, то проблем нету.

В общем на все про все на проекте с 10kloc можно потратить полчаса максимум.

qnikst ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.