LINUX.ORG.RU

Анализ пользователей Common Lisp и Racket

 , ,


8

6

Common Lisp разрабатывался и используется в предположении, что пользователь программы — программист. Поэтому из языка намеренно исключены сложные для понимания конструкции (пользователь не обязательно квалифицированный программист), поэтому в языке мощнейший отладчик, позволяющий без остановки программы переопределять функции и вообще делать что угодно. Но из-за этого документация по большей части библиотек Common Lisp существует только в виде docstring и комментариев в коде (некоторые вообще считают, что код сам себе документация). Из-за этого обработка ошибок почти всегда оставляется на отладчик (главное сделать рестарт «перезапустить с последней итерации», а там пользователь сам разберётся). Из-за этого в программе проверяется только happy path (пользователь ведь «тоже программист»).

Racket разрабатывался и используется в предположении, что пользователь программы не программист, а задача разработчика написать программу так, чтобы она корректно работала при любых входных данных (если данные некорректны, то сообщала об этом в том месте, где данные были введены). Поэтому в языке эффективная библиотека для написания тестов, система контрактов на уровне модулей, макимально широкий спектр инструментов программирования (разработчик должен быть профессионалом!). Также реализована идея инкапсуляции: считается, что пользователь модуля не должен знать особенности реализации и, более того, не может в своём коде изменить функцию чужого модуля если это явно не разрешено разработчиком того модуля. Исходный код разумеется доступен, но его не требуется смотреть, чтобы использовать модуль. Достаточно документации. Поэтому реализована мощнейшая система документировния Scribble, а при реализации макроса есть возможность обеспечить указание на ошибки в коде, предоставленном макросу пользователем, не показывая потроха макроса.

И поэтому в Racket нет CLOS (есть как минимум две реализации, но не используются) - провоцирует заплаточное программирование (monkey patching), поэтому отладчик намеренно ограничен (если ты отлаживаешь программу, значит ты не знаешь как она должна работать!), поэтому нет разработки в образе (image based) - она провоцирует разработку через отладку (а значит непонимание программы и проверку только happy path).

Таким образом, Racket и Common Lisp несмотря на внешнее сходство являются очень разными языками. И я рекомендую писать на Racket, если только конечными пользователями программы не являются исключительно программисты на Common Lisp.

Взято с http://racket-lang.blog.ru/#post214726099

Хотелось бы знать, что по этому поводу думают пользователи ЛОРа. А также, мне кажется, что для Java и C++ будет где-то такая же разница.

★★★★★

Чувак, обычно программы которые ты видишь - это нечто, написанное индусами в течение последних лет 8 под веществами. Обычно когда такой код приходит тебе в руки, он даже не компилируется, не то чтобы нормально работать. Как работает этот код не знает никто, включая его создателей (они - в особенности). Тестов в типичном коде нет, и не предвидится (состояние кода и скорость, с которой заказчик хочет новые фичи, не позволит).

поэтому я использую java, чего и всем советую. в жабке нормальный отладчик и всегда можно понять, что «как бы хотел сказать» автор кода. А если уж от синтаксиса жабки рвёт с кровью, то судя по этой статье нужно юзать CLOS.

stevejobs ★★☆☆☆ ()

Я думал, anonimous воскрес.

Кажется, автор путает понятия «пользователь», «тестировщик» и «пользователь библиотеки».

buddhist ★★★★★ ()

Common Lisp лучше всего описывается цитатой из «Нейроманта»:

платиновый бюст, покрытый перегородчатой эмалью и усыпанный мельчайшим жемчугом и ляпис–лазурью. [...] Это, сказал он, компьютерный терминал. Она умеет говорить. И не каким–нибудь там синтезированным голосом, а с помощью миниатюрных органных труб, мехов, рычагов и прочих прибамбасов. Трудно сказать, кому и зачем понадобилось делать такую изощренную игрушку. Даже извращенную — ведь чипы, синтезирующие голос, продаются на каждом углу, они дешевле пареной репы.

А весь треп о профессиональной ориентации Racket - дешевая разводка. Делать в 21-м веке язык с динамической типизацией - это роспись в профессиональной непригодности (и да, я знаю о Typed Racket).

(Толсто, да. Но я в самом деле так думаю)

tailgunner ★★★★★ ()

И я бы советовал Standard ML и Tcl

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

я знаю о Typed Racket

Обратного, кстати, пока не желаешь?

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

я знаю о Typed Racket

Обратного, кстати, пока не желаешь?

Ммм... чтобы Typed Racket знал обо мне?

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

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

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

Common Lisp лучше всего описывается цитатой из Пола Грехема (осторожно, волны ненависти):

DLW's thesis that Symbolics lost as part of the general losing of custom hardware (including all the parallel computer companies) is basically correct. Lucid on Suns was as fast as ZetaLisp on Symbolicses. But not so fast that that alone made me switch. What made me switch was that Lisp machines (both Symbolics and LMI) were so gratuitously, baroquely complex. The manuals filled a whole shelf. Each component of the software was written as if it had to have every possible feature. The hackers who wrote it were the smartest and most energetic around. But there was no Steve Jobs to tell them «No, this is too complex.» So the guy in charge of writing the pretty-printer, for example, would decide. «This is going to be the most powerful pretty-printer ever written. It's going to be able to do everything!» I learned how to program a Symbolics myself, from reading the manuals. I sometimes suspected that I was the only person who'd ever done this-- that everyone else who knew how to use the damn things had either learned how from the guys who invented them, or had learned from someone else who had. The libraries were so hairy that I generally found it was faster to write something myself than find and understand the documentation for the built-in way of doing it. Unfortunately this complexity persists in Common Lisp, which was pretty much copied directly from ZetaLisp. In fact, both of the worst flaws in CL are due to its origins on Lisp machines: both its complexity and the way it's cut off from the OS.

Raket — столь же уродлив и сложен, но там запилили дополнительную фичу: bondage&discipline, для ценителей остренького. Поэтому +1 в пользу Racket — языка с лиспоподобным синтаксисом.

anonymous ()

Не угадал автора по первому абзацу.

postman_ ★☆ ()
Ответ на: комментарий от tailgunner

Тебе статика нужна чтобы в идешечке ковыряться, да малыш?

anonymous ()

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

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

Не, автора ты угадал, просто он еще одну учетку увел.

anonymous ()

Common Lisp разрабатывался и используется в предположении, что пользователь программы — программист.
Поэтому из языка намеренно исключены сложные для понимания конструкции.

Racket разрабатывался и используется в предположении, что пользователь программы — не программист.
Поэтому в язык намеренно включены сложные для понимания конструкции.

Лан.

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

Делать в 21-м веке язык с динамической типизацией - это роспись в профессиональной непригодности (

Га-га-га.

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

Ты сам расписался в собственной проф непригодности. Харе так уверенно пороть чушь. Здесь речь идёт не об убогих динамически типизированных ОО языках.

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

Здесь речь идёт не об убогих динамически типизированных ОО языках.

Не знаю, где твое «здесь», а я говорил о любых динамически типизированных языках. Специально для тебя уточняю - о Clojure тоже.

tailgunner ★★★★★ ()

Хотелось бы знать, что по этому поводу думают пользователи ЛОРа

Типичная речь вождя от IT. В которой он тараканов из своей головы возводит в сиепень непреложной истины ипризывает на борьбу с проблемами существующими в его воображаемом мире. Вождь ракеты вобще славен такими «широкими» заявлениями и толковать их дело не благодарное.

antares0 ★★★ ()

Вобще забавно следить за тем как на ЛОР-е поколение схемеров упирающих на то что их стандарт в n-цать ра меньше CL-овского, сменилось на поколение ракетчиков у которых догнал, перегнал и переплюнул.

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

в жабке нормальный отладчик

Лол

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

Делать в 21-м веке язык с динамической типизацией - это роспись в профессиональной непригодности

Как раз в большинстве задач 21 века типизация только мешает.

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

Вобще забавно следить за тем как на ЛОР-е поколение схемеров упирающих на то что их стандарт в n-цать ра меньше CL-овского, сменилось на поколение ракетчиков у которых догнал, перегнал и переплюнул.

Стандарт ракетки немногим больше стандарта схемки.

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

Стандарт ракетки немногим больше стандарта схемки

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

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

Только пиарится ракетка вот таким вот как в переводе ТС набором обязательных модулей, принципиально не видя того факта что в CL штуки такого рода принято делать библиотеками.

Они и в Racket сделаны библиотеками.

И получаем такую вот партянку в стиле в CL ничего , а вот в ракетке как в греции все ...

Можно мне библиотеки для cl, в которых реализованы нормальные макросы, паттерн-матчинг, контракты, например?

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

библиотеки для cl, в которых реализованы нормальные

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

И попробуй перечитать и понять, что я говорил о другой стороне проблемы.

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

Нормальность, она в глазах смотрящего.

«Нормальная» - значит обладающая необходимым функционалом.

И попробуй перечитать и понять, что я говорил о другой стороне проблемы.

Ты начал кукарекать о том, что стандарт ракетки сильно большой - он не сильно больше стандарта схемки и уж точно ЗНАЧИТЕЛЬНО меньше стандарта CL. Слова же на счет того, что «в CL это делается библиотеками» - ложь, нету таких библиотек.

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

Арументы кончились, перешли к бросанию фекалий. До свидания! Приходите еще, когда дорастете до Homo Sapiens

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

Какие фекалии, лол? Что-то ты совсем уж затолстил.

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

что стандарт ракетки сильно большой - он не сильно больше стандарта схемки и уж точно ЗНАЧИТЕЛЬНО меньше стандарта CL.

Что понимаем под стандартом? Если только язык без библиотек, то и CL надо считать без CLOS и большей части модуля CL. Останутся только special functions, которых даже меньше, чем в Scheme (продолжений-то нет, модули (пакеты) проще, синтаксических объектов нет). Если брать ANSI CL, то сравнивать надо с модулем racket. В котором (length (namespace-mapped-symbols)) = 2302 символа. Против чуть более 900 в CL. И даже в racket/base 1436 символов.

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

да не корми ты его, ему это всё не подойдёт, ибо надо именно так, как в ракетке...

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

И получаем такую вот партянку в стиле в CL ничего , а вот в ракетке как в греции все ...

По ссылке в топике есть именно описание, чего нет в CL, но есть в ракетке. Из неустранимых: продолжения и синтаксические объекты. Из трудно устранимых: стабильное окружение компиляции. В CL есть xcvb, но им мало кто пользуется.

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

Что понимаем под стандартом?

Семантика и core-формы. Их в racket меньше 30.

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

ибо надо именно так, как в ракетке

Если не считать гигиену и продолжения, то всё остальное можно сделать и «именно так». Думаю, гигиену тоже можно прикрутить (изнасиловав reader). Но тогда получится ракетка, но без продолжений. А зачем такая, если есть уже работающая с продолжениями...

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

По ссылке в топике есть

Это твои мысли или перевод? Я проглядев .ru решил что ты ссылаешся на офф. блог racket-а. А по стилю то похоже.

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

http://www.ccs.neu.edu/home/dorai/mbe/mbe-lsp.html

Я про syntax-parse. И как там по ссылке работает гигиена в случае переопределения, например, let?

cl-match

как там вот такой паттерн, например, выглядеть будет:

(vector (? list? f) ... (? integer? x) ...)

?

Например, https://github.com/sellout/quid-pro-quo

Это на классы. А на ф-и? В частности, фвп/forall контракты?

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

То есть столько же, а вот семантика у CL значительно сложнее будет.

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

Думаю, гигиену тоже можно прикрутить (изнасиловав reader).

Изнасиловав reader/eval/expand и т.д. можно, очевидно, все, даже те же продолжения, т.к. никто не мешает экспандеру перепидорасить все в cps. Но какбы толку? Это аналогично написанию с нуля.

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

Можно мне библиотеки для cl, в которых реализованы ...

А мне библиотеки для Racket, в которых реализован нормальный отладчик (с произвольными действиями по останову программы), нормальные дженерики (как в CLOS), нормальные read-time макросы (в смысле #+, #-, #.)

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

Нет, нельзя. Я ж не говорил, что в racket это есть, речь шла о том, что там товарищ утверждал, будто «в CL все сделано библиотеками.». Не сделано.

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

Это твои мысли или перевод

Скорее мои. Компиляция из разных сравнений в интернете. К офф. блогу отношения не имеет.

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

там товарищ утверждал, будто «в CL все сделано библиотеками.»

Про «все» это ты сам придумал. Я даже строго говоря не про макросы говорил. Но однако пофиг, чисто для уточнения.

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

Тогда твой пост вообще не имел смысла, ок.

anonymous ()

Common Lisp разрабатывался и используется в предположении, что пользователь программы — программист.
Поэтому из языка намеренно исключены сложные для понимания конструкции (пользователь не обязательно квалифицированный программист)

Деление на ноль в первых двух предложениях, что же будет дальше?

anonymous ()

И я рекомендую писать на Racket, если только конечными пользователями программы не являются исключительно программисты на Common Lisp.

Полиморфизма-то нет. Генерики сырые. Только если через классы, а в таком случае, почему бы на руби не писать? Нет биндингов к Qt и gtk. Вообще нихуя нет, только макросы.

anonymous ()

А также, мне кажется, что для Java и C++ будет где-то такая же разница.

Какая?

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

нормальные дженерики (как в CLOS)

Есть же классы. Зачем это нужно? Что в них там особенного? Параметрический полиморфизм?

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