Недостатки Racket

ты же евангелист, у евангелистов нет недостатков. или ты еще не успел начать, а уже сомневаешься в своей религии?

Только становлюсь евангелистом), поэтому хотелось бы узнать какие недостатки у религии, чтобы придумать методы обхода и кричать потом «нинужно» на все остальные религии.

Только становлюсь евангелистом), поэтому хотелось бы узнать какие недостатки у религии, чтобы придумать методы обхода и кричать потом «нинужно» на все остальные религии.

Попробуй это выяснить практикой, а не провоцировать флейм.

Зачем самому набивать шишки о разложенные грабли, если есть люди, которые уже о грабли убились не раз?

разложенные грабли

Хреновый из тебя «эванжелист». Очень.

Зачем самому набивать шишки о разложенные грабли, если есть люди, которые уже о грабли убились не раз?

В случае IT, это единственный путь составить объективное мнение.

Начинающий)

В случае <%любая_отрасль>, это единственный путь составить объективное мнение.

Не с того начинаешь.

провоцировать флейм.

Злобный анонимус уже здесь. Ждём остальных...и продолжения банкета. :)

евангелизм не нужен

Сложный язык с кучей сущностей.

какие у него есть недостатки

Программировать неудобно, это же Lisp-like, что еще надо?

Для ЛОРа нужен. Как источник...гхм...сам знаешь, чего.

кстати, да, CL внезапно проще

Racket по сравнению с...

tcl,

Многословный. Нет встроенного цикла событий.

F#,

Нет интеграции с .Net

Common Lisp,

Нет unwind-protect, CLOS, вроде как нет special variables, нет сигнального протокола.

Haskell,

Нет immutable типов. Плохая поддержка программирования в статических типах (с точки зрения вывода и контроля корректности).

Python3,

Нет такой большой библиотеки готовых модулей и биндингов на все случаи жизни.

Erlang

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

По сравнению с ocaml/haskell код медленней.

typed racket еще развивается и много где приходится ставить аннотации типов.

иногда появляются баги в инфраструктуре (raco).

Многословный.

давай пруфе программ.

Нет встроенного цикла событий.

что имеется в виду?

Нет unwind-protect, CLOS, вроде как нет special variables, нет сигнального протокола.

для unwind-protect есть аналоги, объектная система на сообщениях есть (мультиметоды тоже есть).

нет сигнального протокола.

аналогичная функциональность возможна при помощи продолжений

special variable

что это?

Нет immutable типов.

есть. все типы подефолту immutable

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

есть futures и много других хороших примитивов. хотя может быть erglang и получше. но все равно хотелось бы более развернутого сравнения.

Плохая поддержка программирования в статических типах (с точки зрения вывода и контроля корректности).

согласен, но это сейчас развивается. typed racket выглядит неплохо.

Столько много вранья в одном посте, что даже и отвечать не хочется.

я ответил, поправь если что не так

с таким подходом ничего не научишься

special variables это видимо переменные с динамической областью видимости. В рэкете это, вроде, называется параметры.

Объектная система из коробки какая-то усложнённая и похожа на плюсы.

Банальные структуры с одной стороны переусложнены, с другой в них невозможно задать дефолт значение для каждого слота своё.

зачем вам этот непопулярный диалект лиспа?
ведь есть же популярный диалект — javascript

кроме стандартных недостатков лиспов (минимум синтаксиса, невнятный код в виде каши из коллбэков) javascript обладает и немалыми преумуществами
* высокая востребованность на рынке
* v8 engine, над которым сейчас работают настоящие титаны, создававшие виртуальные машины для разных языков десятилетиями
* самые интересные библиотеки (именно так, чем меньше синтаксиса и беднее среда программирования, тем креативнее программисты)

Нет unwind-protect, CLOS, вроде как нет special variables, нет сигнального протокола.

для unwind-protect есть аналоги, объектная система на сообщениях есть (мультиметоды тоже есть).

+ параметры вместо специальных переменных.

Много интересного в этом есть, как в ЯП.
Но, как мне кажется, это так и останется штукой для обучения потому, что это — виртуальная машина,
вряд ли код написанный на Racket можно будет использовать вместе с компилированными библиотеками на C(или других ЯП).
С выше указанной Java тоже самое, с помощью JNI к ней можно код подцепить С-библиотеку, но не обратно.

Т.е. когда работаешь с ЯП, который работает только внутри VM(или в интерпретаторе), то это будет ограничивать других.

Неправда, Racket VM можно встраивать в сишные программы
http://docs.racket-lang.org/inside/overview.html#(part._3m_.Embedding)

И вызывать сишные модули из Racket через ffi тоже можно, конечно.

Недостатки по сравнению с Common Lisp: более медленная виртуальная машина. И статическая типизация в виртуальной машине отсутствует (Typed Racket — не более чем надстройка, которая компилируется в динамически типизированный код).

Но, как мне кажется, это так и останется штукой для обучения потому, что это — виртуальная машина...

С выше указанной Java тоже самое

Oracle'у расскажи, ага.

Сравнил жопу с пальцем. Javascript вполне приличный язык, там синтаксиса не меньше чем в Си.

TCL: вывод строки параллельно с остальной работой каждые 10 секунд.

proc every {ms body} {eval $body; after $ms [info level 0]}
every 10000 {puts "hello world"}

do_something_useful

Erlang: через P ! Message можно отправить процессу P любой объект: массив, структуру, открытый файл, окно на экране. При том, что процесс может быть вообще на другом компьютере. И у любого процесса есть своя очередь сообщений (которая принимает сообщения всегда), поэтому нет необходимости ждать подтверждения получения.

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

s f g x = f x (g x)
k x y   = x
b f g x = f (g x)
c f g x = f x g
y f     = f (y f)
cond p f g x = if p x then f x else g x
fac  = y (b (cond ((==) 0) (k 1)) (b (s (*)) (c b pred)))

Можешь попробовать построить любую из функций s,k,b,c,y на Racket.

special variable

(defvar *global* 1)

(defun func () *global*)

(let ((*global* 2))
  (print (func))) -> 2

(func) -> 1

Причём (let ((*global*)) ...) в разных потоках не влияют друг на друга.

что позволяет писать вещи типа:

Вот и факториал №1. Ты проиграл.

special variable

Это parameters.

Причём (let ((*global*)) ...) в разных потоках не влияют друг на друга.

В racket именно для этого и используются.

special variable
(defvar *global* 1)
(defun func () *global*)
(let ((*global* 2))
(print (func))) -> 2
(func) -> 1
Причём (let ((*global*)) ...) в разных потоках не влияют друг на друга.

В Racket для этого есть т.н. параметры
http://docs.racket-lang.org/reference/parameters.html

Отсутствие MOP. Вопрос знатокам: есть этому какие-то причины? В guile объектная система GOOPS выглядит намного интереснее :(

В Racket для этого есть т.н. параметры

http://docs.racket-lang.org/reference/parameters.html

Только они функции, а не переменные.

И вместо (setf *global* 'new-value) неясно что ставить.Заново (define *global* (make-parameter 'new-value)) ?

Ну тогда в Haskell есть возможность ленивых вычислений и частичного выполнения функций что позволяет писать вещи типа:
Можешь попробовать построить любую из функций s,k,b,c,y на Racket.

• man srfi-26
• Да, то же $ нередко бывает весьма удобно, но когда с какой-то бараньей упертостью пытаются вообще убрать все скобки, какие только возможно убрать (а стандартных комбинаторов в принципе достаточно чтобы убрать ВСЕ ВООБЩЕ), то из кода получается пиздец. А если пишет апологет поинт-фри, то это не просто пиздец, однострочники перла по сравнению с этим - образец читабельности. Туда же кстати идет и частичное применение - да, это нередко удобно (да какого хуя - это часто удобно!), но когда начинают частично применять функции не из стандартной либы - это снова пиздец, хочется взять и уебать. А потом оторвать руки и засунуть применяльщику в задницу. Потому что в этих случаях приходится регулярно смотреть аргументы этой ф-и, чтобы просто понять что к чему применяется (ведь скобки, напомним, не пишут же, блять, это ж нахуй СИНТАКСИЧЕСКИЙ МУСОР, а по ним хоть предположить что-то можно было бы!). В результате вроде хорошие вещи становятся гранатой в руках обезьяны. И запретить это - ну как запретить прямую работу с памятью.

Алсо, http://docs.racket-lang.org/reference/Delayed_Evaluation.html?q=delay

И запретить это - ну как запретить прямую работу с памятью.

Запретить это в Хаскеле, всё равно как запретить прямую работу с памятью в C. Хаскель без поинт-фри превращается в ML. Так же, как Perl без «однострочников» становится Питоном :-)

«тоже самое» имелось ввиду в контексте «ограничивать других».

что имеется в виду?

event loop, очевидно

TCL: вывод строки параллельно с остальной работой каждые 10 секунд.

Нашел чем удивить.

Erlang: через P ! Message можно отправить процессу P любой объект: массив, структуру, открытый файл, окно на экране. При том, что процесс может быть вообще на другом компьютере. И у любого процесса есть своя очередь сообщений (которая принимает сообщения всегда), поэтому нет необходимости ждать подтверждения получения.

http://docs.racket-lang.org/reference/concurrency.html

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

Про ленивость уже ссылку дали, а макру для определения каррированных функций даже школьник напишет.

Отсутствие MOP

Не аргумент ибо можно прикрутить, да хоть бы и tinyClos.

Нашел чем удивить.

Там вопрос был «продемонстрируй, что программы на tcl короче, чем на racket».

http://docs.racket-lang.org/reference/concurrency.html

Ну если async-bi-channel-put позволяет отправить, например, (new canvas% ...) с возможностью для удалённого процесса на этом канвасе нарисовать, или поток станлартного вывода, то тогда действительно аналог Erlang'а.

Про ленивость уже ссылку дали, а макру для определения каррированных функций даже школьник напишет.

Определи на Racket:

 
s f g x = f x (g x)
k x y   = x
b f g x = f (g x)
c f g x = f x g
y f     = f (y f)

и покажи, насколько результат будет читаем.

Ну если async-bi-channel-put позволяет отправить, например, (new canvas% ...) с возможностью для удалённого процесса на этом канвасе нарисовать, или поток станлартного вывода, то тогда действительно аналог Erlang'а.

Сам я не игрался с этой фигней, но судя по определению

(*channel-put ch msg) → void?
  ch  : (or/c place-channel? async-bi-channel? channel? (is-a?/c remote-connection%))
  msg : any

послать можно что угодно.

Определи на Racket:

#lang lazy

(defun (s f g x) (f x (g x)))
(defun (k x y)    x)
(defun (b f g x) (f (g x)))
(defun (c f g x) (f x g))
(defun (y f)     (f (y f)))

где

(define-syntax-rule (defun (name arg ...) body ...)
  (define name (fun (arg ...) body ...)))

(define-syntax fun
  (syntax-rules ()
    ((_ (arg) body ...)
     (lambda (arg) body ...))
    ((_ (arg1 arg2 ...) body ...)
     (case-lambda
       ((x)
        (let ((arg1 x))
          (fun (arg2 ...) body ...)))
       ((x . xs)
        (let ((arg1 x))
          (apply (fun (arg2 ...) body ...) xs)))))))

например.

Там вопрос был «продемонстрируй, что программы на tcl короче, чем на racket».

std::thread every(int sec, void(&f)())
{
    std::thread t { [&f]() { while(1) { f(); sleep(sec); } } };
    t.detach();
    return t;
}

    every(1, *[]() { puts("..."); });
    ... do stuff

every :: Int -> IO () -> IO (Async ())
every sec io = async $ forever $ io >> threadDelay (sec * 1000000)

  every 1 $ putStrLn "..."
  ... do stuff

думаю, на Racket будет так же - в concurrency всё нужно есть. Разве что может быть интересно насколько «лёгкие» его потоки (= OS thread, или что-то своё + , собственно, свой же event loop для IO).

у ракета один большой недостаток (не в сравнении с, а вообще) - в «реальной жизни» вечно наталкиваешься на какие-то «недостатки». что вспоминается: нормальной параллельности нет (thread'ы - это просто event loop в одном процессе, futures - только для «safe» кода, а такого, практически, не бывает, places - практически fork с ipc через pipe), «привязки» к каким-нибудь внешним библиотекам очень редко попадаются, через ffi делать - если в библиотеке используются какие-то структуры, меняющиеся от версии к версии - жопа, под каждую версию переделывать, встраивание и написание привязок на це - вечная проблема с precise garbage collection. и жутко бесит, что память оно жрёт, как не в себя. свежезапущеный интерпретатор:

dfo      12411  6.5  0.8  56600 26904 pts/25   Sl+  13:19   0:00 racket

послать можно что угодно.

Оно при посылке сериализуется, так что не все. И canvas если отошлется, то это будет копия в любом случае.

Разве что может быть интересно насколько «лёгкие» его потоки

Там green threads. Но эрланговские, конечно, легче.

послать можно что угодно.

По документации — да. В аналогичных библиотеках на Java нельзя отправить открытый файл, соединение с БД, окно на экране. Точнее отправить можно, даже получить можно (оно создаст объект Java), ошибку получаешь при попытке использовать (broken connection и т.д.). Erlang в этом смысле порадовал (он реально не сериализует объект, а отправляет «указатель» содержащий имя узла и адрес объекта). На racket не пробовал.

например.

Круто. Я думал, без косталей не получится.

послать можно что угодно

И функцию? Я на хаскеле посылал Binary => ByteString через ZMQ, но сделать Binary для функций вообще никак не получается.

Не знаю насчет легкости, но потоки выполняются в рамках одного потока ОС:

http://docs.racket-lang.org/reference/eval-model.html#(part._thread-model)