LINUX.ORG.RU

Common Lisp VS Racket

 , , ,


2

7

Комрады. Очень давно тыкал в Cl/SBCL, не так давно написал пару сервисов для этого вашего web’a на Racket.

Вопрос - Common Lisp VS Racket, что более живо для написания web’a, что имеет больше батареек, какая IDE лучше (кроме Emacs), etc.

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

Поздравляю, выстрелил себе в ногу. Нормальные люди этим не занимаются, естественно.

Такой выстрел возможен и случайно. И любой setf/nreverse/… на константе или литерале может закончится непредсказуемой работой программы.

С таким же успехом можно сделать (setf (car ’(1 2 3)) 4)

Да. Константных списков в CL (в отличие от Racket) тоже нет.

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

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

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

В языке с горячей заменой константность ограничивает общность горячей замены.

Если так рассуждать, то и defconstant там лишний. Вот эта «общность горячей замены» и не позволяет писать на CL надёжные системы. При разработке библиотеки приходится делать выбор: или в каждом вызове проверять целостность данных (будет тормозить) или надеяться, что пользователь библиотеки не будет к ней применять эту самую горячую замену (что чаще и делают). В результате вся программа работает на честном слове (пользователя библиотеки).

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

IDE под названием clcon/яр я пилил, но она была никому не нужна (редкий лиспер её не проклял)

Я не проклинал. Я вообще только сейчас о IDE этой узнал. :)

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

А можно ещё пользоваться горячей заменой только в процессе разработки и не пользоваться вне её. Конечно, тут нужен более высокий уровень доверия между участниками сделки. А defconstant реально создаёт трудности.

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

Ну ладно, может я слегка сгустил краски.

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

Ну что ты меня совсем за школьника то принимаешь. Конечно же не путаю.

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

Вот эта «общность горячей замены» и не позволяет писать на CL надёжные системы.

Бред собачий. Наоборот, с ней удобнее, и дебажить итд. Что в CL, что в Erlang например. Кстати, на CL и Erlang большие системы почему-то пишутся, в отличие от Racket(известно почему)

или в каждом вызове проверять целостность данных

Целостность данных необходимо проверять на границе API, вне зависимости от языка, и типизация тут вообще не при чем.

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

Целостность данных необходимо проверять на границе API, вне зависимости от языка, и типизация тут вообще не при чем.

На Racket мне достаточно проверить тип объекта (тэг структуры), а на CL необходимо проверять данные. Или верить пользователю, что он не подсунет вместо отсортированной последовательности неотсортированную, например.

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

Целостность данных необходимо проверять на границе API

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

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

Кстати, на CL и Erlang большие системы почему-то пишутся, в отличие от Racket(известно почему)

У Erlang и с модульностью и с константными данными всё замечательно, не надо к нему примазываться.

А CL по той же причине, по которой пишутся большие системы на Коболе, Алголе и Фортране. Наследие. Или есть большие системы на CL, которые начали разрабатывать после 2010 (в 2010 вышел Racket)?

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

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

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

А CL по той же причине, по которой пишутся большие системы на Коболе, Алголе и Фортране.

Нет не поэтому. И «новый-модный» не значит «лучше». Racket - объективно, говно. Как и куча других новомодных языков.

Или есть большие системы на CL, которые начали разрабатывать после 2010 (в 2010 вышел Racket)?

Конечно есть.

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

Racket - объективно, говно.

Да ладно, я бы не был столь категоричен. Ракет, в отличие от обычных схем, вполне практичный язык. Ну простоватый, конечно, не без этого, но совсем говном я бы его называть не стал. После guile мне он вообще как глоток свежего воздуха показался. Правда, в итоге всё, что было на ракете, я на CL переписал.

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

Конечно есть.

Не троллинга ради. Для просвещения - можно примеры? Если OpenSource проекты вообще прекрасно было бы с ссылками

silver-bullet-bfg ★★
() автор топика
Ответ на: комментарий от lovesan

В кои-то веки ты написал что-то хорошее.

den73 ★★★★★
()
Ответ на: комментарий от silver-bullet-bfg

Вопрос не до конца понял. Из веба юзаю clack, но там у меня просто доступ к api. Так веб не делаю особо. Если делаю, то на clojurescript. Вернулся потому что если CL и говно, то остальное не лучше, незачем метаться.

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

Вообще, претензия исходит видимо от человека, с сишным мышлением, который не допер до того что лисп это про image-based development.

Давно уже известно что в мире ракеты image-based development - ересь. При этом ракета - это диалект лиспа. Такие вот еретики.

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

В мире лиспа ересь ересью погоняет.

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

defconstant сравнивает по EQL при переопределении. Соответственно когда форма заново(второй раз скажем) компилируется, там соответственно, в случае стрингов или других сложных объектов, может получаться другой объект. В этом случае defconstant ругается на переопределение константы. Это обходится alexandria:define-constant

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

Какого рода проекты заказывают?

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

Как нашёл клиентов?

Я вот специально не искал. Точнее, искал сначала, когда я ещё на яве проекты делал. Потом как-то само всё идёт. Причём проекты там не то, чтобы сильно большие и огромные, я сам успеваю накодить что нужно. Но есть довольно долгоиграющие. Я вот один проект начинал писать на пиколиспе, потом на guile его переписал. Теперь вот на CL.

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

Искал сначала на фрилансе, но это было давно. И искал просто хоть что-нибудь. :) А потом как-то само всё получилось.

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

Это был ответ на утверждение «Кстати, на CL и Erlang большие системы почему-то пишутся, в отличие от Racket». Если «большие» - это 20К строк, то таких и на Racket много.

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

Давно уже известно что в мире ракеты image-based development - ересь.

Не так. image-based есть и в Racket, но в рамках модуля. А когда разрабатывая свой модуль по ходу дела переопределяются используемые библиотеки (кроме пакета CL), то это действительно ересь, так как изменения должны вносится в библиотеку с соответствующими модификациями тестов и документации.

monk ★★★★★
()

Вопрос - Common Lisp VS Racket, что более живо для написания web’a

А какой веб ты пишешь? Он ведь разный - просто rest-сервис или веб-службу, сайт-одностраничник с клиент-сайд рендерингом, сложный гуй с асинхронщиной и развитыми библиотеками или раздачу шаблонизированной логики в классическом стиле? Из того, что я видел, на CL классический MVC-веб ужасный, а все что SPA - там под капотом JS, а значит в лучшем случае clojure only, других вариков нет. На счет racket не в курсе, но на первый взяглд там выглядит все как из 90х, типа как в CL, но из «90х из злой параллельной вселенной», веб на продолжениях и в таком духе. Аналога clojurescript нигде не видел, что как бы намекает.

alienclaster ★★★
()
Ответ на: комментарий от silver-bullet-bfg

какая IDE лучше (кроме Emacs)

Тогда наверное тебе не в лиспы.

Интересно есть ли альтернативы скорее. Быть может что-то более удобное/модное/хипстерское.

А зачем? emacs сложный в настройке или есть какие-то еще причины?

А по теме Clojure

Отторгает сама JVM.

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

Для .Net знаю, есть. Но, ЕМНИП, сыроват.

Да он вообще нерабочий. А это оч плохо, если бы .net открыли раньше clojure была бы на .net с вероятностью примерно 99,3%, потому что .net как платформа и как набор языков намного более продвинутый, чем java-мир.

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

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

У clojure классный синтаксис, реально крутой и продуманный. Интероп с миллиардом джава либ и (что более важно) на ней легко написать lispy-обертку для какого-нибудь специфического джава-фреймворка. Всем основные проблемы clojure от jvm - отсутствие хвостовой рекурсии и нормальных рестартов. Ридер-макросы от туда убрали специально, и вот в конкретно этом случае это хорошее решение. Хотя, если бы clojure была просто развитием стандарта Common Lisp, то это просто было бы подмножеством более обобщенного языка, типа на уровне code style, и неплохого такого code style, надо заметить. Но, как бы все эти решения с хостом на джаве они тоже понятны и разумны, исходя из целей создателя языка.

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