LINUX.ORG.RU

Не учите Common Lisp!

 ,


1

7

Хочу предостеречь форумчан от изучения Common Lisp. Возьмите самую лучшую имплементацию — SBCL и скомпилируйте следуюущие лямбды:

;; Взятие элемента по индексу x из массива x
(lambda (x) (aref x x))
;; Взятие элемента по индексу y из массива x и прибавление к x
(lambda (x y) (+ x (aref x y)))
;; Один из путей выполнения: прибавление X к NIL
(lambda (x y) (+ x (funcall (lambda (x) (if x 0 x)) y)))

Ни на одной из этих бессмысленных функций компилятор не ругнётся. Вы скажете: «А что такого? Это же язык с динамической типизацией!» А то, что если вы хотите хоть насколько нибудь быстрого кода, вам нужно делать какие-то утверждения о типах, производя только лишь статический анализ кода.

Минус коммон лиспа как языка — слишком разрешательский стандарт. Почти сплошь и рядом там фразы вроде «Эффект, производимый объявлением inline, определяется реализацией» или «Реализация вольна игнорировать то-то и вместо этого делать то-то». Из-за этого разработчики того же SBCL будут игнорировать твои баг репорты, где из-за неправильного поведения компилятора (с точки других опубликованных алгоритмов) твой код будет работать раза в 2 или 3 медленнее, чем должен бы.

Написали бы в стандарте «реализация ДОЛЖНА поступать так-то и так-то», и можно было бы тыкать разрабов носом в это место и требовать корректного поведения. А раз написали «реализация может делать, что ей захочется», то и прижучить их нельзя. В итоге все занимаются чем хотят, кроме починки багов.

Короче, учите языки с хорошей теоретической базой и статической типизацией. Байкам @lovesan не верьте ни одной.



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

Я вообще не понимаю, зачем нужен лисп, если есть JavaScript. Семантика ровно такая же. Ну фигурные скобки вместо круглых, ничего страшного.

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

Я хз, не знаю JavaScript. Не могу сказать про него ничего

dura4ok11
() автор топика
Ответ на: комментарий от vbr

Всё бы ничего, но ТС не только в лисп попал, сколько вообще в динамическую типизацию, каковую и JavaScript имеет

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

Ну по факту жаваскрипт быстрей С++ порой, так что весь вопрос упирается в качество интерпретатора.

Для любителей статической типизации есть нашлёпка в виде TypeScript. Тоже гениальное творение гениального человека. Очень нравится.

vbr ★★★★★
()

Кстати, теоретическая база по выводу типов в Common Lisp есть здесь:

https://www.researchgate.net/publication/220997326_A_General_Scheme_for_the_Automatic_Inference_of_Variable_Types

В Common Lisp система типов идентичная, разве что в лиспе добавили составные типы и теоретико-множественные операции над типами (AND, OR, NOT, CONS). Странно, что эта статья почему-то прошла мимо разрабов современных имплементаций.

dura4ok11
() автор топика
Ответ на: комментарий от zurg

Да, но прикол в том, что какой-нибудь пистон особо и не пытается быть чем-то большим, чем пистон. Ошибся с типами — получай падение. А тот же SBCL вроде и пытается в статическую типизацию (как может).

Ну например, компилируя

(lambda (x) (1+ (find "abc" x)))

Получаем

; in: LAMBDA (X)
;     (1+ (FIND "abc" X))
; ==>
;   1
; 
; caught WARNING:
;   Derived type of (FIND SB-C::ITEM SEQUENCE :TEST (QUOTE EQ)) is
;     (VALUES (OR (SIMPLE-ARRAY CHARACTER (3)) NULL) &OPTIONAL),
;   conflicting with its asserted type
;     NUMBER.
;   See also:
;     The SBCL Manual, Node "Handling of Types"
; 
; compilation unit finished
;   caught 1 WARNING condition

И это сначала подкупает, а когда он фейлится на чём посложнее, ещё и с последствиями для перформанса, начинает гореть жопа.

dura4ok11
() автор топика
Ответ на: комментарий от ugoday

CLOS — это вообще хуже всего. Тут весь тайп инференс идет лесом.

Что им мешало разрешить добавлять декларации к генерикам?

dura4ok11
() автор топика

ахаха, хотел написать внесите царя лавсана, а ты его уже скастовал.

штошь ))

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

Нет, про такое не слышал. Объектная система в JS прототипная, перезапусков в том виде, в котором они есть в лиспе - нет, хотя через async/await можно попробовать что-то подобное сымитировать, если на практике нужно…

vbr ★★★★★
()

Вы скажете: «А что такого? Это же язык с динамической типизацией!» А то, что если вы хотите хоть насколько нибудь быстрого кода, вам нужно делать какие-то утверждения о типах, производя только лишь статический анализ кода.

Т.е. динамическая типизация запрещена? И define «насколько нибудь быстрый». Мне норм, например.

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

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

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

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

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

Так почему ты за лисп взялся?

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

А в чём тогда схожесть js и cl заключается? Оба динамически типизированные языки с функциями высшего порядка?

ugoday ★★★★★
()

Короче, учите языки с хорошей теоретической базой и статической типизацией! Например, C/C++.

Вот так надо было. Так есть вероятность что в теме будет 1000 постов, а не 100.

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

Так точно! Потому что надо брать научные статьи и делать по ним, а не по каким-то шаляй-валяй методам. А в стандарте нужно ссылаться на эти статьи, а не писать «имплементация вольна забить болт, на что ей пользователь пытается указать»

dura4ok11
() автор топика
Ответ на: комментарий от EXL

Это совсем жирный наброс. А у меня просто попоболь от лишпа

dura4ok11
() автор топика
Ответ на: комментарий от EXL

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

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

А ведь действительно, косяк, и довольно фундаментальный

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

CLOS — это вообще хуже всего.

В данном случае это не важно. Заявлялась эквивалентность cl и js. Вот, выясняю подробности.

Тут весь тайп инференс идет лесом.

Ужос, но ничего страшного. Для таких как вы придумали хаскел. Тоже хороший язык.

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

Ошибся с типами — получай падение.

Прям как в примерах из ОП-поста

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

Бред какой. Хаскель к цепепе никакого отношения не имеет, а по вашему Хаскель — это продолжение цепепешной говномысли.

Нет, C++ — это вообще место, где на научность клали болт

dura4ok11
() автор топика
Ответ на: комментарий от ugoday

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

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

Я тут осознал, есть же такая Julia! и у них, вроде как, получилось скрестить ужа с ежом, в смысле удобство для пользователя как в динамическом языке и скорость и защиту как в статике

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

Ну там скорость идёт за счёт того, что они в рантайме узнают, какой будет тип и житуют. JIT во все поля! В итоге дикие тормоза на компиляцию. А работает итоговый код быстро тоже не всегда. Например, факторизация многочленов над ℤ в джулии вышла в 40 раз медленнее Common Lisp. Из-за бигнумов, как я понял.

И да, Julia не научилась делать fasl файлы и образы. Каждый запуск всё по новой надо компилировать

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

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

anonymous
()

Не слушайте его, это он потенциальных конкурентов отгоняет!

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

Э э, да вообщем-то достаточно ускорили уже, и всё время ускоряют, и даже аот компилятор появился, но не факторизациями она ценна, а своим ОДЕ солвером, есть подозрение что лучший в индустрии

zurg
()

;; Взятие элемента по индексу x из массива x

это тупо s-выражение, которое надо будет вычислить в месте подстановки, когда то место будет вычисляться. чего он будет тут ругаться? он там ругнется, если ему так надо.

а пока это просто некий списочек.

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

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

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

dura4ok11
() автор топика
Ответ на: комментарий от zurg

А по поводу, что улучшают, ну пока не видно ) Образы нормальные там так и нельзя делать. Как SB-EXT:SAVE-LISP-AND-DIE ничего нет

dura4ok11
() автор топика
Ответ на: комментарий от vbr

перезапусков в том виде, в котором они есть в лиспе - нет, хотя через async/await можно попробовать что-то подобное сымитировать, если на практике нужно

не в курсе насчёт перезапусков в лиспе, это не что-то похожее на жсные генераторы?

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

а пока это просто некий списочек.

Какой списочек? Это лямбда.

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

Походу, вы язык не знаете. Ленивость в лиспе, ага

dura4ok11
() автор топика
Ответ на: комментарий от static_lab

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

dura4ok11
() автор топика
Ответ на: комментарий от static_lab

Нет

Это возможность упавший код перезапустить с любого места в стеке вызовов

Киллер-фича, которая делает разработку сверхинтерактивной. Потерянная технология давно забытых времён

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

не в курсе насчёт перезапусков в лиспе, это не что-то похожее на жсные генераторы?

Типа ты словил эксепшн выше по стеку и в обработчике можешь вернуть выполнение туда, откуда он вылетел, будто его и не было. Причём в общем случае неограниченное число раз. Т.е. нужно остаток функции завернуть в замыкание и прикрутить его к эксепшну. С неограниченным числом раз точно не получится, но один раз можно. Когда используешь async/await, то оно при каждом вызове await это и делает само, разбивая функцию на куски и автоматом собирая замыкания в нужных точках.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 4)
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.