Опубликован Google Common Lisp Style Guide

viaweb?

И при чём здесь он?

вопрос времени

Вопрос нужности. И анонимус там выше уже сказал (правильно) о сути Racket.

там же все переписали с CL на другой язык

если процесс пойдет, то все будет ок.

вон ML тоже начинался как академ проект, а превратился в ocaml и haskell - вполне серьезные инструменты.

И что?

и что?

И что?

А то, что маргинальные языки непригодны для промышленной разработки. Что не так?

Просто феерическое 4.2. Лисп самый легкочитаемый язык.

Я просил пруф, а вы мне подсовываете свои измышления. Читать умеете?

Лисп самый легкочитаемый язык.

Вообще-то, нет.

Хм. Логично.

Не согласен с пунктом про документацию, про docstring. Я пишу docstring только к функциям, переменным и макросам, которые предназначаются для пользователя (т. е. API). Внутренним функциям я не делаю dostring, а описываю в комментариях.

Почему? Да потому что тупое документирование в docstring только путает. Есть очень много пакетов без документации, поэтому docstring - это единственный способ узнать, какими функциями и макросами пользоваться, а какими не стоит.

Чушь. Промышленная разработка почти вся состоит из маргинальных, криво слепленых, уродливых языков, на каждом из которых пишет полтора человека (и те только по пьяни). Такова уж суть промышленной разработки - NIH везде и велосипедостроительство. У каждого говноCAD-ика свой говноязычок. У каждого говнопроектика своя система сборки, со своими самопальными препроцессорами (поверх Fortran77 или вовсе PL/I). Десятое правило Гринспуна не на ровном месте родилось, между прочим.

довольно глупо делать industrial-quality язык на базе схемы.

А в чем проблема?

В том, что схема изначально академический язык. Но, о Racket я утрирую, как я сказал в самом первом своем посте.

Тогда попрошу определений «академический язык» и «industrial-quality язык».

Уж лучше на базе чего-то хоть немного академического делать, чем, как обычно, без всякой базы вообще, из соплей и какашек лепить.

Чтобы долго не распинаться: loop в CL видели? Так вот, в Схеме за такие фичи бьют ногами, а в CL это православная вещь.

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

В Схеме начиная с R6RS официально, а до того во всех реализациях тихой сапой, есть точно те же макросы, что и в CL. И никто никого ногами бить не станет за реализацию LOOP, за list comprehensions и прочие кошмары. А самые практичные Схемы и вовсе на стандарт клали (Bigloo, например, с его презрением к numeric tower).

В Схеме начиная с R6RS официально

Так почитайте бугурт столпов Scheme в обсуждении R6RS :)

Ну а кого это колышет? Всех, кто разрабатывал непосредственно реализации Схемы, эти академические бредни никогда не интересовали (и потому во всех реализациях всегда были кошерные макросы).

Racket это большой язык. http://pre.racket-lang.org/docs/pdf/reference.pdf - 1023 страницы. И в нем, кстати, есть расширяемый for. И на нем тоже можно писать, руководствуясь тем же девизом. Чем я и иногда и занимаюсь для души :)

Серьезно, если язык вышел из «академических» кругов, это еще не значит, что на нем можно только факториалы на континуешенах.

Не троллинга ради.

Какие задачи решаете на Racket?

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

Ничего сложного: небольшое веб-приложение, генерация изображений - racket/draw и школьная геометрия и десктопное приложение - racket/gui и xml. Ну и изучаю Scheme и сам Racket - очень многие детали и концепции пока что непонятны.

У меня нет задач, критичных по скорости. Когда появятся, достану CL ;)

Спасибо.

Ну, я, например, прототипы языков на нем делаю (потом переписываю на C++ с LLVM).

А что толку, что он большой, он не такой удобный как кл. Разве, что гуйня есть.

поэтому docstring - это единственный способ узнать, какими функциями и
макросами пользоваться,

А экспорт на что?

Для CL потребовалось бы немного батареек, чтобы достичь подобного эффекта

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

Чтобы долго не распинаться: loop в CL видели? Так вот, в Схеме за такие фичи бьют ногами, а в CL это православная вещь.

И большинство коммон лисперов плюется при виде кривого и глючного лупа, спокойно используя вполне scheme-style няшный, удобный и расширяемый iterate.

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

Вобщем-то при идеоматической реализации racket идет на равне с CL, иногда обгоняет, иногда уступает. Да, на CL _можно_ (обычно) написать программу так, чтобы она опережала решение на Racket, только это решение будет в десять раз уродливее, чем аналог на сишке.

он не такой удобный как кл

Неудобно с анонимусами общаться, потому что не понятно, кто тролль, а кто просто дебил.

Вобщем-то при идеоматической реализации racket идет на равне с CL, иногда обгоняет, иногда уступает.

Вобщем-то, при отсутствии пруфоф ваше сообщение ни чуть не лучше распространённой надписи на заборе... Ну и при прочих равных по CL просто прорва информации по сравнению с racket, который, к тому-же, от схемы отличается как c++ от c

Никто не мешает макроэкспандер в CL подменить.

Никто не мешает макроэкспандер в CL подменить.

А еще надо переписать рантайм. Да, это тоже никто не мешает сделать. Только во-первых проще написать новый рантайм и экспандер с нуля, а во-вторых это все будет противоречить стандарту общелиспа.

Вобщем-то, при отсутствии пруфоф

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

Если же писать и там и там обычный код (без анальной оптимизационной акробатики), то в 99% случаев все идет вровень, а в оставшемся 1% дело обычно завязано на какие-то конкретные особенности реализации рантайма и там либо ракет либо сбцл отсасывает, да. Проверить это может любой - достаточно написать пару тестов.

Ну и при прочих равных по CL просто прорва информации по сравнению с racket

Чуть менее чем всегда забывают отключить debug mode и тестируют в Dr.Racket, что срезает производительность на 1-2 десятичных порядка.

Да тот же шутаут посмотреть - в трети случаев преимущество получено жутким >выдрачиванием кода, по сравнению с которым низкоуровневое перекладывание >байтиков в сишке - пример красоты и изящества.

По-моему, шутаут достаточно ясно говорит, что ракет существенно уступает SBCL по скорости и компактности _одновременно_. Правила шутаута достаточно строги. Если анонимус напишет примеры на ракете, которые не будут уступать примерам на SBCL и они будут приняты на шутауте - я скажу, что ракет догнал SBCL, а пока - нет оснований. Но, даже если догонит, разве можно, уважая себя, использовать язык с названием «грохот» или «вымогательство»? Как вы лодку назовёте...

Был ещё один забавный язык - boo, который я тоже забанил исключительно за его название.

З.Ы. а размер кода почти во всех примерах одинаков у SBCL и рэкета.

По-моему, шутаут достаточно ясно говорит, что ракет существенно уступает SBCL по скорости и компактности _одновременно_.

На шутауте специальная олимпиада по скорости, декларативностью там и не пахнет

Правила шутаута достаточно строги.

В чем выражаются?

Но, даже если догонит, разве можно, уважая себя, использовать язык с названием «грохот» или «вымогательство»? Как вы лодку назовёте...

Ну это вообще какой-то бред (если не шутка)

Был ещё один забавный язык - boo, который я тоже забанил исключительно за его название.

Критерии выбора языка у тебя просто жесть

декларативностью там и не пахнет

Какая декларативность, я говорил о потреблении памяти. Есть компромисс скорость/потребление памяти, например, программы на FreePascal медленнее программ на С, но занимают меньше памяти, что позволяет надеяться на сопоставимое качество разработки. Так вот, грохот-вымогательство одновременно _и_ медленнее SBCL, _и_ больше памяти жрёт. Откуда можно сделать выводы... Размер же исходника в большинстве тестов одинаков, и только в двух или трёх грохот-вымогательство выигрывает (вероятно, это те, где нужен call/cc или случайно попали на библиотечные функции?).

Ну это вообще какой-то бред (если не шутка)

Если бы тебе предложили работу с зарплатой в 1.4 раза больше, чем у тебя сейчас, но должность бы назвалась «говно», к тебе бы обращались официально «ведущее говно имярек», или «имярек, старшее говно», и тебе надо было бы на работе носить, скажем, арестантскую пижаму из фильмов про фашистские концлагеря с бейджиком «имярек, говно» ты бы согласился?

В чем выражаются?

Например, в SBCL есть какой-то быстрый способ чтения (unlocked-что-то там), при использовании которого он в тестах на чтение обогнал всех. Этот пример не был принят, т.к. в правилах написано «использовать стандартные функции ввода».

Критерии выбора языка у тебя просто жесть

Было бы из чего выбирать...

Будь мужиком - пиши от своего имени.

Какая декларативность, я говорил о потреблении памяти.

Да кого оно интересует, при таком как на шутауте говнокоде^W подходе?

Есть компромисс скорость/потребление памяти, например, программы на FreePascal медленнее программ на С, но занимают меньше памяти, что позволяет надеяться на сопоставимое качество разработки.

Как качество разработки соотносится с потреблением ресурсов памяти и процессора конкретной реализацией, если разница как минимум не на порядок между выбираемыми языками / платформами?

Так вот, грохот-вымогательство одновременно _и_ медленнее SBCL, _и_ больше памяти жрёт.

Кого в наше время интересует производительность для решения высокоуровневых задач?

Размер же исходника в большинстве тестов одинаков

При отсутствии декларативности размер исходников не показателен и, следовательно, не интересен _вообще_

Если бы тебе предложили работу с зарплатой в 1.4 раза больше, чем у тебя сейчас, но должность бы назвалась «говно», к тебе бы обращались официально «ведущее говно имярек», или «имярек, старшее говно», и тебе надо было бы на работе носить, скажем, арестантскую пижаму из фильмов про фашистские концлагеря с бейджиком «имярек, говно» ты бы согласился?

Пример надуманный, но многие люди соглашаются быть прислугой у хамоватых «баринов», например. Другие играют в театре. В чем проблема?

Критерии выбора языка у тебя просто жесть

Было бы из чего выбирать...

Зависит от решаемых задач.

По-моему, шутаут достаточно ясно говорит, что ракет существенно уступает SBCL по скорости и компактности _одновременно_.

Нет, шутаут об этом не говорит. Шутаут вообще не несет никакой полезной информации о производительности, т.к. вместо идеоматических решений сравниваются оптимизированно-выдроченные. То есть, согласно правилам шутаута, все результаты шутаута никогда не будут связаны с практическими результатами, т.к. ИРЛ так как на шутауте НИКТО НИЧЕГО НЕ ПИШЕТ.

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

Ракет догнал (и нередко перегнал) SBCL на обычном коде (без выдрачивания оптимизаций). То есть именно на таком коде, который реально на практике пишут, а не вот такое вот говно: http://shootout.alioth.debian.org/u32/program.php?test=knucleotide&lang=s...

сравним с: http://shootout.alioth.debian.org/u32/program.php?test=knucleotide&lang=r...

Вот казалось бы - какое быстрое решение на SBCL! Да вот только никто не будет так писать на SBCL. И не будет никакого такого вот «быстрого решения». То есть SBCL быстрее исключительно потенциально - причем нигде кроме шутаутов и других подобных бенчмарков этот потенциал не реализуется, потому что нахуй никому не нужен. Если людям захочется написать нечто оптимизированное - то они возьмут ту же сишку и напишут. Причем будет быстрее, по памяти компактнее, меньше кода и понятнее.

Или вот вообще пушка: http://shootout.alioth.debian.org/u32/program.php?test=mandelbrot&lang=sb...

Анальная акробатика с генерацией воп и отсос в результате. А почему бы было не нагенерить ф-ю на асме и не запустить ее?

Или если лень на асме - создать файл с исходным кодом на си, скомпилировать его и запустить результат?

аахха, а вот кстати: https://github.com/shekari/racket-llvm/blob/master/examples/mandlebrot.rkt

Может сравним производительность вопоебли общелиспа с няшным ллвм?

но многие люди соглашаются быть прислугой у хамоватых «баринов»

Но ведь не все? Те, кто не соглашается, ведь - не маргиналы?

Ладно, извини, мне неинтересно дальше всё это обсуждать, хотя остальные твои тезисы тоже хочется оспорить.

Могу только посоветовать - не увлекайся так декларативностью, у неё есть своя изнанка. Я знаю, наверное, только два массово применяющихся декларативных языка: make (и разного рода менеджеры пакетов, построенные на том же принципе) и SQL. Make слишком прост и о нём вообще можно не говорить, а вот SQL в реальной жизни не так сильно выигрывает от декларативности, как хотелось бы. В реализациях для оптимизации зачастую не хватает подсказок оптимизаторов, а приходится переформулировать запрос в виде равного по смыслу, но не тождественного по плану исполнения, т.к. оптимизатор работает на эвристиках и не может по соображениям производительности перебрать достаточно много запросов. Это фактически перечёркивает саму декларативность SQL. При том, что существует множество реализаций SQL, и это завязано на огромные деньги, проблема до сих пор в индустрии не решена. И вообще, отладка декларативных программ существенно сложнее, чем императивных, поскольку их могущество состоит как раз в том, что существенная часть работы делается в недрах программы, способом, который может быть недоступен для исследования прикладному программисту.

Я не говорю, что декларативность не нужна, но ты, похоже, сделал из неё идола, а это - зря. Уж компактность программы она точно не заменяет :)