![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Левенчук пишет, что все серьёзные программисты мечтают программировать на фукнциональных языках. Не знаю, как серьёзные, а у меня лично никогда желания программировать на Лиспе не возникало. Нечеловеческий он какой-то. Пусть ворлоны на нём программируют.
Tags:
Re: ага, а вот и флейм!
дяденька! окащенять меня бесполезно, я в этом деле нетренированный. я HyperSpec читал, покуда вы в федошной песочнице друг другу письки показывали и Y-combinator трактовали.
отсутствие хвостовой рекурсии в стандарте CL — это не ¨бяда¨, это вполне сознательный фичер.
> За неё можно простить даже раздельные пространства имён для функций и всего остального
каковые тоже есть сознательные фичеры. которые мне очень нравятся, кстати. если бы я всосал Y-combinator с молоком лямбда-матери и был бы академик, моё мнение могло бы быть и другим. в чём я совершенно не сомневаюсь, впрочем, так это в том что в подобном случае я полностью отдавал бы себе отчёт об отличии академии от реального мира, и не выдавал бы свои предпочтения за истину в последней инстанции.
Re: ага, а вот и флейм!
Фигнанына. Это ни разу не сознательное, а только лишь вынужденное решение. И практически все *вменяемые* компиляторы CL таки хвостовые рекурсии разворачивают. Однако:
a) закладываться на это НЕЛЬЗЯ, так как "практически" - это не "все"
b) в силу этого, ФУНКЦИОНАЛЬНО писать на CL - тоже нельзя (да и на фиг не надо), всегда, когда глубина рекурсии непредсказуема, она должна заменяться на цикл.
Имеешь что либо супротив возразить - вперёд. Иначе - не хер вякать.
Re: ага, а вот и флейм!
создатели стандарта безусловно знали о хвостовой рекурсии, и не стандартизивовали её сознательно. не потому что не могли, а потому что не хотели.
по крайней мере я склонен интерпретировать публичные высказывания того же Кента Питмана на данную тему именно таким образом (и несложный поиск на Google Groups с соответствующими ключевыми словами мне свидетель).
если есть свидетельства обратного, то давай их сюда.
> практически все *вменяемые* компиляторы CL таки хвостовые рекурсии разворачивают
и правильно делают, ибо это вполне приятная и недорогая для компилятора оптимизация. но заметь также, что ни один *вменяемый* компилятор не производит этой оптимизации когда (> debug optimize), что характерно.
> в силу этого, ФУНКЦИОНАЛЬНО писать на CL - тоже нельзя (да и на фиг не надо)
золотые слова, в скобочках-то!
Re: ага, а вот и флейм!
Я понял так: не хотели заставлять тех, кто не может. То есть, сочли это не обязательным требованием. Откуда и вышеизложенные выводы.
> но заметь также, что ни один *вменяемый* компилятор не производит этой оптимизации когда (> debug optimize), что характерно.
Да нет, тому же OCaml по сараю, он всегда развернёт.
> золотые слова, в скобочках-то!
Так я вообще не понимаю, об что мы таки спорим. Лисп - не функциональный язык, на Лиспе и нельзя писать чисто функционально, да и не для того он нужен, чтоб чисто функционально писать. С этими утверждениями тут хоть кто-то не согласен?!?
Re: ага, а вот и флейм!
вполне возможно, что кто-то и не мог.
факта явно осознанного предпочтения это не отменяет.
> тому же OCaml по сараю
а кто говорит про, прости оссподи, O'Caml?
> Так я вообще не понимаю, об что мы таки спорим
а мы не то чтобы и спорим. просто я пытаюсь пояснить тебе явную неуместность мелкого сектантского миссионерства в данном контексте. плюс по поводу данной конкретной темы слегка наболело: откуда, по-твоему, у человека ¨знания¨ о лиспе на уровне ¨всюду списки, рекурсия и скобочки¨? от таких вот умников, которые вместо того чтобы рассказать что-нибудь существенное, с блеском в глазах гонят телеги про хвостовую рекурсию и прочую откровенную (для девственной аудитории) эзотерику.
no subject
Лисп в вышеуказанном тексте можно заменить на любой извод Лиспа или любою производную его типа Схемы, по желанию.
no subject
http://www.gigamonkeys.com/book/
no subject
миссионерства я зело не люблю, и считаю что покуда человека изнутри не припекло, морочить ему голову совершенно не нужно и даже бесполезно.
так, зашёл на огонёк, указал на фактические ошибки в посте, а тут ксендзы подтянулись... :)
no subject
Это позволяет нам расширять язык, используя функции, выполняющиеся во время компиляции - то есть, макры.
К примеру, если мы хотим ввести в язык новую конструкцию
APPRIGHT, такую, что код
(APPRIGHT + 1 2 3 4 5) будет компилироваться как
(+ 1 (+ 2 (+ 3 (+ 4 5)))), то мы просто говорим:
(defmacro appright (f &rest args)
(if (null (cdr args)) `(car args)
`(,f ,(car args) (appright ,f ,@(cdr args)))
))
То есть - мы расширяем сам *компилятор* языка. Не нравятся скобочки? Можем заменить синтаксис - см. мою статью, там, правда, Схема, но это без разницы, если кому интересно, дам то же самое для CL.
no subject
no subject
Пример (действующий) - http://dslengine.sourceforge.net/
no subject
Ну, я примерно так себе и представлял дело, хотя меня тут разубеждают, что это совсем не так. ;)
то мы просто говорим:
Вот слово "просто" меня тут немного смущает. Т.е. я понимаю, что для вас, судя по всему - человека, который на этом деле собаку сьел - это просто. Но для меня, например, это не очень просто. Это, в частности, то, что мне в Лиспе изрядно мешает - через его синтаксис надо продираться. Вы, конечно, можете сказать, что это от недостатка опыта. Возможно, и так. И скажете, что это всё можно поменять как угодно - статью я прочитал, да. Ну, так почему не поменяли, а? Почему вы не написали тот же appright в более человекопонятной форме?
Но в целом, мне кажется, я уловил вашу мысль - что в Лиспе правила, по которым ведётся разбор выражений на языке, поддаются модификации. Вернее, думаю, всё же расширению? Или полной модификации? И что среда исполнения Лисп включает в себя компилятор и исполнитель кода (что, понятно, не есть уникальное свойство Лиспа).
no subject
Не надо. У Лиспа - минимальный синтаксис. S-выражения. Это, с одной стороны, плохо - человекам, или некоторым из них, сложно воспринимать S-выражения или
тот же XML, но с другой стороны это замечательно, потому как синтаксис совпадает с AST языка. Мы видим ровно то, что у него внутри, уже распарсенное.
> Ну, так почему не поменяли, а?
Да поменяли - к примеру, RLisp, весьма известная фишка... Просто это никому не надо - синтаксис S-выражений, на самом деле, близок к идеальному. Это я утверждаю, как полиглот, программировавший практически на всех языках, какие только когда либо существовали, и собственноручно реализовавший множество языков под разные цели. Да, синтаксис того же Хаскелля может завораживать, казаться немерянно удобочитаемым и красивым, синтаксис Java может быть привычным, но по сумме критериев S-выражения лидируют.
> Почему вы не написали тот же appright в более человекопонятной форме?
Потому как тогда там или пришлось бы splice-образную семантику неявно использовать, или явно прописать генерацию S-выражений, что затруднило бы понимаение. Когда и макра, и исходный код, и результат - в одном синтаксисе, понять, что происходит, несколько проще.
> Но в целом, мне кажется, я уловил вашу мысль - что в Лиспе правила, по которым ведётся разбор выражений на языке, поддаются модификации. Вернее, думаю, всё же расширению?
Не только разбор. Ещё и все этапы компиляции и оптимизации. Изменять (не только расширять, но и ограничивать) можно абсолютно всё.
> И что среда исполнения Лисп включает в себя компилятор и исполнитель кода (что, понятно, не есть уникальное свойство Лиспа).
Не совсем так. Компилятор Лиспа включает в себя среду исполнения. Обратное не обязательно (ну да, есть любители попользовать eval, но я не из их числа).
no subject
По-моему, это получается таки плохо. Что есть язык программирования? Способ сокрытия сложности задачи/решения (кривой перевод complexity encapsulation, ага). Если язык Лисп-VM не скрывает сложности этой самой VM, так ли это хорошо? Т.е. у ассемблера есть свои многочисленные прелести, но есть также и вышеописаный существенный недостаток.
синтаксис S-выражений, на самом деле, близок к идеальному
Идеальному - для чего? Или вы скажете, что существует синтаксис, идеальный для описания - чего угодно?
но по сумме критериев S-выражения лидируют.
А какие, опять же, критерии-то?
no subject
Поскольку существенная часть Лисп-программы - это код, который читает Лисп-программы и пишет Лисп-программы, то однозначность отображения синтаксиса на AST тут весьма полезна.
> Или вы скажете, что существует синтаксис, идеальный для описания - чего угодно?
Существует синтаксис, *достаточный* для описания чего угодно. Это - S-выражения. Аналог, ужасно громоздкий и нелепый, но столь же универсальный - XML. Не знаю, на фига XML придумали, когда были S-выражения, ну да ладно...
При этом, такой синтаксис относительно легко воспринимается человеком - он вполне естественный, и, что немаловажно, примитивный, его легко изучить и легко читать.
> А какие, опять же, критерии-то?
- Универсальность - не должно быть конструкций, принципиально невыразимых в этом синтаксисе, и не должно быть конструкций, которые было бы сложно отобразить на такой синтаксис.
- Ортогональность. Не должно быть взаимозаменяемых элементов.
- Минимальность. Лишние элементы только отвлекают.
- Возможности для редактора или IDE проявить немерянный интеллект. Для S-выражений их - полно, для сложных синтаксисов - приходится bovinator-ы всякие рисовать - кошмар...
- Однозначность отображения на внутреннее представление. S-выражения тривиально переводятся в двоичные деревья, и наоборот.
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
CL-USER(4): (APPRIGHT + 1 2 3 4 5)
Error: Attempt to take the value of the unbound variable `ARGS'.
[condition type: UNBOUND-VARIABLE]
Софт - Allegro CL.
no subject
(defmacro appright (fn &rest args) (if (null (cdr args)) (car args) `(,fn ,(car args) (appright ,fn ,@(cdr args)))))
no subject
no subject
Re: ага, а вот и флейм!
опять об тоже место
угу.
> в Лиспе нельзя не пользоваться императивными возможностями
а каким боком циклы обязательно "императивны", не подскажешь?
(то есть про необходимость как-то ¨деструктивно¨ апдейтить переменные, в которых сидит loop state, я вполне понимаю. но считать на данном основании любой цикл императивным — чистой воды академическое крючкотворство, и ты это, надеюсь, прекрасно понимаешь. если подходить с подобной логикой, то функциональных языков вообще в природе нету, поскольку всё в конце концов превращается в ни разу не функциональный Мойшинный Кодъ).
> Предложение не пугать человека хвостовыми рекурсиями выглядит в этом контексте, мягко гойворя, странным
и пойчему? показывать собственную образованность — это одно, а пытаться что-то действительно объяснить (в смысле так чтобы поняли и не ушли в несущественные дебри) — другое.
Re: опять об тоже место
Таким, что неимперативный цикл сводится к хвостовой рекурсии.
> но считать на данном основании любой цикл императивным — чистой воды академическое крючкотворство, и ты это, надеюсь, прекрасно понимаешь.
Это крючкотворство абсолютно необходимо, когда ты пишешь компиляторы. Практика требует. Есть в конструкции сайд-эффект - теряем сразу огромное количество возможностей статического анализа и оптимизаций, нет сайд-эффектов - делаем с ней всё, что угодно.
> если подходить с подобной логикой, то функциональных языков вообще в природе нету, поскольку всё в конце концов превращается в ни разу не функциональный Мойшинный Кодъ).
Зависит от того, на каком этапе компиляции эта неиллюзорная мойшинная императивность вылезает. Разница чисто практическая, в удобстве анализа и оптимизации.
Re: опять об тоже место
что является типичным времяпровождением любого практикующего программиста, не так ли?
Re: опять об тоже место
Каждая большая задача лучше всего решается именно таким образом: придумывается язык, заточенный под предметную область этой задачи, пишетя абы какая его реализация, задача в пол-пинка решается, заказчик почти-доволен, пишем эффективную реализацию языка.
Интересно, что ты считаешь за среднестатическое промышленное программирование?
Re: опять об тоже место
тут надо с 17-го году начинать, видимо.
накатаю отдельный пост, вот только ребёнка спать отложу...
Re: опять об тоже место
Re: опять об тоже место