Есть ли у кого-нибудь практический опыт использования Racket для написания реального софта?

С одной стороны я вижу что он в основном используется для обучения. И его IDE DrRacket мягко говоря не впечатлило (а есть ли другие?).

А с другой стороны вроде бы далеко не примитивный язык с якобы неплохим Foreign Function Interface, многопоточностью, ленивостью (если надо) и т.д.


Я пока что пользовался Haskell, но очень утомило следующее:

1. Dependency Hell. Это просто убивает. Собрать мало-мальски сложный софт с множеством зависимостей почти невозможно, т.к. cabal в них путается. И если даже удалось проблему победить, то очередной "cabal update" ломает всё. Известные "решения" этой проблемы слишком похожи на костыли.

2. Для почти любого кода со сложным состоянием (не факториалы же считаем) нужно дико извращаться с records (и захламлять этим local scope), писать свои монады по поводу и без и всё это быстро превращается в кромешный ад.

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

2. Средства разработки, мягко говоря, удручают.


Думал о переходе на Ocaml, но слышал что:

1. Там свои проблемы со сборкой.

2. FFI уродлив.

3. Есть странные ограничения на длину массивов.

Здравствуйте, Rtveliashvili Denys, Вы писали:

RD>Думал о переходе на Ocaml, но слышал что:

RD>1. Там свои проблемы со сборкой.

В юниксах/маках вроде все довольно неплохо. В винде сильно сложнее, разве что overbld спасает. Количественно библиотек, наверное, поменьше чем в хаскеле.

RD>2. FFI уродлив.

Если использовать в лоб, то нужно писать сишные обертки специального вида. Например,

value get_perf_counter() 
{
  LARGE_INTEGER  cnt;
  QueryPerformanceCounter(&cnt);
  return copy_int64(cnt.QuadPart);
}

external get_perf_counter : unit -> int64 = "get_perf_counter"

Не особо сложно, но не так удобно, как в более других языках. Кажися, были какие-то утилиты, упрощающие это дело.

RD>3. Есть странные ограничения на длину массивов.

В 32-битной версии да, есть. Массивы и строки не шибко длинные (несколько миллионов элементов). В 64-битной версии практически не ограничены.

Еще с многопоточностю беда — GIL.

Здравствуйте, Rtveliashvili Denys, Вы писали:

RD>Есть ли у кого-нибудь практический опыт использования Racket для написания реального софта?

Вот описание создания серьезного коммерческого софта на PLT Scheme http://fprog.ru/2009/issue2/alex-ott-using-scheme-in-dozor-jet/.
Насколько я понимаю, PLT Scheme предшественник Racket.

Здравствуйте, Rtveliashvili Denys, Вы писали:

RD>Есть ли у кого-нибудь практический опыт использования Racket для написания реального софта?

У меня встречный вопрос... Глянул на этот Ракет. Это ж Лисп. Причем какой-то новомодный. Чем определяется выбор? И как соотносятся рассуждения о статически-типизированных не расширяемых языках вроде Хаскеля и ОКамла с Лиспом (динамическим и макросным)?

Здравствуйте, VladD2, Вы писали:

VD>У меня встречный вопрос... Глянул на этот Ракет. Это ж Лисп.
Это Схема.
> Причем какой-то новомодный.
17 лет проекту.
>Чем определяется выбор? И как соотносятся рассуждения о статически-типизированных не расширяемых языках вроде Хаскеля и ОКамла с Лиспом (динамическим и макросным)?
Разработчики последние годы активно пилят типизированную часть, которая называется Typed Racket. Присутствует локальный вывод типов.

Здравствуйте, FragMent, Вы писали:

FM>Это Схема.

Как Лисп не называй, он все равно Лисп.

>> Причем какой-то новомодный.
FM>17 лет проекту.

О, как? Я раньше про такой не слышал даже. Захожу вот на форум, а тут аж несколько тем про него. Век живи...

>>Чем определяется выбор? И как соотносятся рассуждения о статически-типизированных не расширяемых языках вроде Хаскеля и ОКамла с Лиспом (динамическим и макросным)?
FM>Разработчики последние годы активно пилят типизированную часть, которая называется Typed Racket. Присутствует локальный вывод типов.

Где про это можно почитать?

Хотя что-то не верится, что из этого выйдет что-то. Слишком уж лисп динамически по природе. Чтобы от типизации был толк, нужно в первую очередь типизированные структуры данных вводить. А как они могут в лиспе то выглядеть? Там же все структуры являются разновидностью списка.

Скоре всего будет как с V8. Ряд локальных успехов на фоне общей бессмысленности.

Сдается мне проще взять изначально статически типизированный язык хоршо поддерживающий ФП. Скала/Немер/Окамл отлично заменят Хаскель в реальных задачах.

Здравствуйте, VladD2, Вы писали:

FM>>Разработчики последние годы активно пилят типизированную часть, которая называется Typed Racket. Присутствует локальный вывод типов.

VD>Где про это можно почитать?
http://www.cs.unb.ca/~bremner/teaching/cs3613/lectures/lecture0.web.pdf

Здравствуйте, VladD2, Вы писали:

VD>А как они могут в лиспе то выглядеть? Там же все структуры являются разновидностью списка.

Глупость.

Здравствуйте, VladD2, Вы писали:

FM>>17 лет проекту.

VD>О, как? Я раньше про такой не слышал даже.

Само название Racket сравнительно новое, но это так переименовался довольно старый проект.

>>>Чем определяется выбор? И как соотносятся рассуждения о статически-типизированных не расширяемых языках вроде Хаскеля и ОКамла с Лиспом (динамическим и макросным)?

Расширение синтаксиса макросами и в окамле с хаскелем есть. См. camlp4 и template haskell.

VD> А как они могут в лиспе то выглядеть? Там же все структуры являются разновидностью списка.

Совсем необязательно. Глянь на clojure для примера, там со входа родные вектора и ассоц.массивы.

VD>Сдается мне проще взять изначально статически типизированный язык хоршо поддерживающий ФП. Скала/Немер/Окамл отлично заменят Хаскель в реальных задачах.

Боюсь, после хаскеля они могут выглядеть недостаточно функциональными.

Здравствуйте, D. Mon, Вы писали:

DM>Совсем необязательно. Глянь на clojure для примера, там со входа родные вектора и ассоц.массивы.
Насколько я знаю, даже в "обычном лиспе" (common lisp) есть и хеш-теблицы и массивы.

Здравствуйте, D. Mon, Вы писали:

>>>>Чем определяется выбор? И как соотносятся рассуждения о статически-типизированных не расширяемых языках вроде Хаскеля и ОКамла с Лиспом (динамическим и макросным)?

DM>Расширение синтаксиса макросами и в окамле с хаскелем есть. См. camlp4 и template haskell.

Как-то не убедительно. Сравнивать эти вещи с макрами Лиспа, на мой взгляд, нельзя. TH это вообще игрушка плохо применимая на практике, а Camlp4 — это чистый препроцессор, что недостаточно для серьезного расширения статически-типизированного языка. Да и использовать его крайне не просто.

VD>> А как они могут в лиспе то выглядеть? Там же все структуры являются разновидностью списка.

DM>Совсем необязательно. Глянь на clojure для примера, там со входа родные вектора и ассоц.массивы.

Clojure ничем не отличается в этом отношении от CL. Там тоже есть захардкоженные массивы и хэш-таблицы. Типизации это не прибавляет. Более того для CL есть реализации реализации авторы которых заявляют, что код на них сравним по скорсоти с кодом на С (что в прочем, не соответствует действительности). Но кое что там сделано.

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

Дженериков нет. Вместо этого предлагается полагаться на тип Any являющийся объединением всех типов. А это уровень дотнета 1.0 и Явы первых версий. В прочем ява и сейчас не далеко ушла.

Для работы с целыми используется какой-то базовый тип Number. Ничего кроме тормозов этот подход не даст.

VD>>Сдается мне проще взять изначально статически типизированный язык хоршо поддерживающий ФП. Скала/Немер/Окамл отлично заменят Хаскель в реальных задачах.

DM>Боюсь, после хаскеля они могут выглядеть недостаточно функциональными.

А Лисп тип более функциональный? Ты это серьезно?

Почитай внимательно претензии автора темы к Хаскелю. Как раз нарочитая "функциональность" и не приспособленность к реальным задачам (которые обычно императивны по сути) и является его основными претензиями.

Кроме того у Хаскеля есть только одно, довольно спорное, преимущество — ленивость вычислений. В остальном язык как язык не лучше и не хуже многих. Все возможности ФП доступны и в других языках поддерживающих этот стиль. Зато в них еще МП и ООП доступны. А в некоторых еще и макросы не хуже лисповских .

Здравствуйте, VladD2, Вы писали:

DM>>Расширение синтаксиса макросами и в окамле с хаскелем есть. См. camlp4 и template haskell.

VD>Как-то не убедительно. Сравнивать эти вещи с макрами Лиспа, на мой взгляд, нельзя. TH это вообще игрушка плохо применимая на практике, а Camlp4 — это чистый препроцессор, что недостаточно для серьезного расширения статически-типизированного языка. Да и использовать его крайне не просто.

Ок, с лиспом сравнивать не буду, тут ты прав.
Что до camlp4, не вижу его большого отличия от макросов немерле. Отдельная фаза, где типизированный код оперирует AST с использованием квазицитат.

VD>>> А как они могут в лиспе то выглядеть? Там же все структуры являются разновидностью списка.
DM>>Совсем необязательно. Глянь на clojure для примера, там со входа родные вектора и ассоц.массивы.
VD>Clojure ничем не отличается в этом отношении от CL. Там тоже есть захардкоженные массивы и хэш-таблицы. Типизации это не прибавляет.

Я лишь про "все структуры являются разновидностью списка", это очевидно не так.

В защитники лиспа ты меня зря записал. А за подробности про racket спасибо.

VD>>>Сдается мне проще взять изначально статически типизированный язык хоршо поддерживающий ФП. Скала/Немер/Окамл отлично заменят Хаскель в реальных задачах.

DM>>Боюсь, после хаскеля они могут выглядеть недостаточно функциональными.
VD>А Лисп тип более функциональный? Ты это серьезно?

Не, я лисп не предлагаю. После хаскеля почти все языки "недостаточно функциональные", судя по реакции хаскеллистов на них.

VD>Кроме того у Хаскеля есть только одно, довольно спорное, преимущество — ленивость вычислений. В остальном язык как язык не лучше и не хуже многих. Все возможности ФП доступны и в других языках поддерживающих этот стиль.

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

Здравствуйте, VladD2, Вы писали:

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

VD>Дженериков нет. Вместо этого предлагается полагаться на тип Any являющийся объединением всех типов. А это уровень дотнета 1.0 и Явы первых версий. В прочем ява и сейчас не далеко ушла.

VD>Для работы с целыми используется какой-то базовый тип Number. Ничего кроме тормозов этот подход не даст.

Это не совсем верно, нужно лишь почитать документацию.

Например.

Здравствуйте, D. Mon, Вы писали:

DM>Не, я лисп не предлагаю. После хаскеля почти все языки "недостаточно функциональные", судя по реакции хаскеллистов на них.

Только непонятно, минус это, или все же плюс?!

Здравствуйте, Rtveliashvili Denys, Вы писали:

RD>Есть ли у кого-нибудь практический опыт использования Racket для написания реального софта?

Racket это бывший MzScheme. Есть практический опыт использования Сlojure и MzScheme для написания реального софта. На мой взгляд, Clojure гораздо мощнее как в плане возможностей так и в плане библиотек (возможность интеграции с Java) полистал форум, странно, что этот язык обделен здесь вниманием.

Здравствуйте, korvin_, Вы писали:

_>Это не совсем верно, нужно лишь почитать документацию.

Значит параметры типов все же есть. Странно, что об этом ни слова в презентации.

А можно ли использовать параметры типов в пользовательских типах?

_>Например.

Я так и не понял, что будет если написать функцию работающую с Number. Чем является все эти Number и Integer? Похоже что объединениями. Так же не ясно что означает "generalized from ..."?

Здравствуйте, VladD2, Вы писали:

VD>Значит параметры типов все же есть. Странно, что об этом ни слова в презентации.

VD>А можно ли использовать параметры типов в пользовательских типах?

Конечно, тип Some в моем примере.

VD>Я так и не понял, что будет если написать функцию работающую с Number. Чем является все эти Number и Integer? Похоже что объединениями.

Number здесь равносилен Number'у в джаве например, т.е. он является надтипом для все остальных числовых типов. В документации же все есть.

VD>Так же не ясно что означает "generalized from ..."?

Вероятно это особенность работы интерпретатора, означает, что результат вызова get имеет тип "...", но для вывода значения на экран оно было приведено к более общему типу. В исходном коде все остается строго, например.

Здравствуйте, Rtveliashvili Denys, Вы писали:

а чем не устраивает Scala? все пункты жалобы там норм + богатые возможности, библиотеки, IDE..

А>а чем не устраивает Scala? все пункты жалобы там норм + богатые возможности, библиотеки, IDE..

Последний раз на Scala смотрел года три назад. Она не хотела нормально общаться с Java кодом а IDE тормозило.

Еще недавно глянул на Ceylon. С ним сходу убило то, что старые Java enums на нём делаются как совершенно дикое нагромождение классов.

VD>У меня встречный вопрос... Глянул на этот Ракет. Это ж Лисп. Причем какой-то новомодный. Чем определяется выбор? И как соотносятся рассуждения о статически-типизированных не расширяемых языках вроде Хаскеля и ОКамла с Лиспом (динамическим и макросным)?

Меня он заинтересовал вот чем:

1. typed racket

Но такое ощущение, что на этапе компиляции происходит type erasure. Не уверен, так ли это на самом деле.

2. якобы есть всякие хорошие штуки в стандартной библиотеке, такие как thread-local variables

3. не поленились написать документацию

4. и даже написали IDE

Правда он не очень "способный", но всяко лучше просто текстового редактора.


---

Ну а на данный момент я смотрю на racket уже скорее скептически.

Сделал буквально пару тестов и увидел, что:

1. вызов ничего не делающей процедуры без аргументов, дёрнутой из shared object стоит 150 наносекунд (вместо 3 наносекунд, которые тратит аналогичный код на C).

2. почему-то происходит inlining для рекурсивных вызовов.

(define (do_loop i)
    (when (< i 1000000)
        (do_loop (add1 i))))

превращается компилятором в

(begin
  (module test3 ....
    (require (lib "racket/main.rkt"))
    (define-values
     (_do_loop)
     (lambda (arg0-12)
       '#(do_loop
          #<path:/home/rtvd/src/rtvd-racket/test/compiled/test3.rkt>
          3
          0
          15
          72
          #f)
       '(flags: preserves-marks single-result)
       '(captures: #%modvars (_do_loop))
       (if (#%in < arg0-12 '1000000)
         (let ((local15 (#%in add1 arg0-12)))
           (if (#%in < local15 '1000000)
             (let ((local19 (#%in add1 local15)))
               (if (#%in < local19 '1000000)
                 (let ((local23 (#%in add1 local19)))
                   (if (#%in < local23 '1000000)
                     (let ((local27 (#%in add1 local23)))
                       (if (#%in < local27 '1000000)
                         (_do_loop (#%in add1 local27))
                         '#<void>))
                     '#<void>))
                 '#<void>))
             '#<void>))
         '#<void>)))))

Зачем он это делает и почему глубина inlining'а именно пять — для меня загадка. Моя гипотеза — это очередной cargo cult, что дескать инлайнинг ускоряет работу.