Рабочее место начинающего лиспового программиста

А можно где-нибудь глянуть ваши конфиги emacs?

(define √ sqrt)
(define ² sqr)

(require scheme/control)

(define (± x y)
 (shift k (values (k (+ x y)) (k (- x y)))))

(define (quadratic-formula-roots a b c)
 (reset (/ (± (- b) (√ (- (² b) (* 4 a c))))
           (* 2 a))))

Scheme.

Мопед не мой. Это шутка, если кто не понял :)
Однако, код рабочий.

А что на пол-пути остановился? Сделал бы уж и умножение классической точкой: «·». Кстати, читаемости не прибавилось. Тот же самый ворох скобок.

Особенно умиляет (² b). Просто убойно.

Просто убойно

Вот и убейся :)

ъ - труёвее не бывает :)

Прошлый скрин более трушным :)

использую старый тошибовский ноутбук

а куда же делся т61?

Ты мне поясни, вследствии какого постулата

(+ 1 
   2 
   (* 5 
      6))

Читается лучше, чем 1 + 2 + 5 * 6?

Если хочется инфиксной записи - на CL она реализуется, см., например, здесь. Там и математические операторы, и вызовы функций в стиле си, и даже условные операторы. Не надо только говорить про «много кода» - стоит иметь в виду, что это - реализация «неродного» для лиспа синтаксиса (к тому же довольно сложного, гораздо более сложного чем sexp-ы).

Только вот почему-то этой возможностью не особо-то пользуются. Почему? Причина, в принципе, понятна - на небольших выражениях (при правильном форматировании - расстановка отступов где надо и т. д, все вменяемые редакторы кода такое форматирование делают автоматически) читаемость sexp-ов не хуже (а иногда - даже лучше) инфиксной записи (да, на мой взгляд, приведённое тобой выражение в виде sexp читается лучше - ибо сразу видно два уровня вложенности и две операции (+ и *). А записанное в 1 строчку ещё надо распарсить, понять, что у * приоритет выше чем у +, в уме расставить скобки и уже только после этого понять, что там написано). А когда выражение слишком большое - то как его ни пиши, всё равно трудночитаемо. И вот писать такие многоэтажные выражения (на любом языке программирования) не разбивая их на более мелкие логически завершённые части - это действительно мазохизм.

Ещё один момент - математические выражения, записанные в виде s-выражений, гораздо легче и удобнее редактировать (благодаря, опять же, явному выделению аргументов каждого оператора и отсутствию неявной группировки, связанной с приоритетами операторов). Лучше поддержка со стороны редакторов (автоматическое форматирование кода) - опять же, за счёт простоты синтаксиса.

И, в целом, запись выражений в виде s-выражений не более и не менее человекопонятна, чем традиционная запись. Инфиксная запись более понятна на очень простых выражениях (типа 1+2-3), а вот когда выражение становится более сложным и появляется хотя бы 2 уровня вложенности (и, как следствие, необходимость «считать скобки») - все её преимущества в этом месте теряются. Здесь вопрос привычки - к инфиксной записи все привыкли, поэтому на все другие варианты и смотреть не хотят и кричат «непоятно!» (прямо как виндузятники по отношению к Linux). Между тем, если хотя бы немного (несколько дней) поработать с лиспом и привыкнуть к нему, то все «проблемы», связанные с «понятностью» его синтаксиса, куда-то пропадают... Наоборот, начинаешь видеть некоторые недостатки синтаксиса других языков, которые ранее не замечал.

ЗЫ кстати, в математике-то как раз почти всё, что выходит за пределы простой арифметики, записывается именно в префиксной нотации. Корень, интеграл, оператор дифференцирования (d/dx), функция (f(a,b,c)), всякие операторы в функциональном анализе... Разница только в том, где ставятся скобки (в математике - после оператора, в лиспе - перед ним).

> Инфиксная запись более понятна на очень простых выражениях (типа 1+2-3), а вот когда выражение становится более сложным и появляется хотя бы 2 уровня вложенности (и, как следствие, необходимость «считать скобки») - все её преимущества в этом месте теряются.

А ничего, что в префиксной записи скобки надо считать уже начиная с 1-го уровня вложенности? И это речь только о самом арифметическом выражении, не считая объемлющего Лисп-кода.

Между тем, если хотя бы немного (несколько дней) поработать с лиспом и привыкнуть к нему, то все «проблемы», связанные с «понятностью» его синтаксиса, куда-то пропадают

Наверное, поэтому именно для Лиспа придумали подсчет скобочек в редакторах %)

За музыку +

Такую техногенность можно простить разве что сабжевому клипсовому программисту.

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

В этом случае сразу вспоминается Fortran. В новых версиях возможны удобные операции произвольной разрядности/точности. Реализовано вроде через тот же gmp.

LISP всегда меня как-то привлекал, но далее «Hello World» я как-то не продвинулся. Ниасилил, да... Остаюсь пока преимущественно в рамках C/C++/Perl/Shell.

Удивительно, что вы действительно применяете LISP на практике, причем для необычных вещей. Это действительно интересно.

а куда же делся т61?

Это был рабочий, я работу поменял.

темно, у меня бы глаза устали.

emacsos, красота

Попытка сделать инфиксную запись чем-то большим, чем синтаксическим сахаром для арифметических выражений со стандартными типами - закончилась провалом. Я имею в виду перегрузку операторов в Си. Вдруг выяснилось, что в сложном коде 17 уровней приоритета операторов, каждый из которых может быть перегружен неизвестно чем - создаёт полный хаос. Тут даже не в читаемости дело, всё куда хуже. Итог - инфиксная запись совершенно не годится для программирования.

Да, в лиспе нет нормального инфиксного сахара, но зато префиксная запись в виде s-expов достаточно удобна.

Насчёт шестого уровня вложенности посмеялся - я пишу s-expы по 25 килобайт длиной, и ничего. Насчёт того что Лисп плохо влезает в eighty columns вы может где-то и правы.

Кроме того, у лиспа развитая макро-система. Например (dolist (elm lst) ...) куда удобнее чем for(int i = 0; i < lst.length(); i++) {...}. Внедрение такой формы записи не требует переработки стандарта языка, не требует добавления функционала в компилятор, этот макрос раскрывается в (while ...

Как например внедрить паттерн-матчинг в си-подобный синтаксис? case\switch? else if? Всё костыли, в s-expах он смотрится как влитой.

В общем, s-expы может и не самый удобный способ записи, но весьма обобщённый(ведущий себя одинаково в любой ситуации), и главное - легко распарсиваемый. Грамматика s-expов очень проста. Грамматика C++ - охохохо.

Насчёт того что Лисп плохо влезает в eighty columns вы может где-то и правы.

У нас в coding style прописано 100 :) Это примерно 2/3 ширины нормального экрана (1600x1200) немелким шрифтом.

Например (dolist (elm lst) ...) куда удобнее чем for(int i = 0; i < lst.length(); i++) {...}.

foreach - эо такая мелкая мелочь, что она есть в любом ЯП, либо просто реализуется.

>Итог - инфиксная запись совершенно не годится для программирования.

А мужики-то не знают!

Да, в лиспе нет нормального инфиксного сахара, но зато префиксная запись в виде s-expов достаточно удобна.

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

Насчёт шестого уровня вложенности посмеялся - я пишу s-expы по 25 килобайт длиной, и ничего.

Я тоже много гадости пишу — и ничего. Попробуй почитай чужие sexp'ы аналогичных размеров и расскажи о результатах.

Кроме того, у лиспа развитая макро-система.

Я в курсе. Однако нельзя отрицать, что возможность нагородить свой синтаксис в некоторых запущенных случаях приводит к появлению диалектов, изучение которых вызывает некоторые напряги.

главное - легко распарсиваемый

В 16 лет и правда главное, чтобы парсилось легко. К 30 годам требования смещаются в сторону легкой читаемости.

Я в курсе. Однако нельзя отрицать, что возможность нагородить свой синтаксис в некоторых запущенных случаях приводит к появлению диалектов, изучение которых вызывает некоторые напряги.

Невозможность нагородить свой синтаксис к запущенным случаям приводит во много раз чаще.

> Попробуй почитай чужие sexp'ы аналогичных размеров и расскажи о результатах.

Настоящий Рыцарь Скобки и Квазиквотации обязан сам выковать двуручный меч написать для себя стандартную библиотеку, объектную СУБД и веб-фреймворк. Так что конструкция «почитать чужие sexp'ы» для Ъ-лиспера ереси подобна. (Но мы-то с вами знаем, что в реальности все дело в шестиуровневых макросах и хрестоматийных «вложенных квазиквотациях на три строки», выкованных другим рыцарем, которые быстрее переписать, чем постичь за разумное время.)

К 30 годам требования смещаются в сторону легкой читаемости.

Как, вы еще не в курсе, что читаемость - это для monkey-кодеров? И вообще, что Ъ при выборе языка не смотрят на такую незначительную мелочь как синтаксис, и руководствуются лишь возможностями языка? :)

>У нас в coding style прописано 100 :) Это примерно 2/3 ширины нормального экрана (1600x1200) немелким шрифтом.

Я обычно ограничиваю код 80-ю столбцами. Вообще, было бы неплохо написать (может, уже кто-то написал? Я не искал еще) некий общий функционал для кода на s-выражениях, чтобы он по возможности встраивался в указанное пользователем число столбцов автоматически. Разумеется, тут нужен умный алгоритм, который красиво сделал бы отступы и по-умному вставил переносы на следующую строчку. Это было бы очень полезно и сэкономило бы кучу времени на соблюдение ограничений по ширине кода.

> foreach - эо такая мелкая мелочь, что она есть в любом ЯП, либо просто реализуется.

Про «просто реализуется» - можешь посмотреть на это «просто» в boost/foreach.hpp (это для c++, естественно). Там это «просто» занимает >1000 строк кода. Минимальная реализация (которая в большинстве случаев вполне работает) укладывается в ~50 строк, причём 90% кода - это костыли для преодоления ограничений c++.

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

А sexp-based синтаксис, как известно, наиболее удобен для кодогенерации (ибо, фактически, представляет собой человекопонятную запись AST). И именно поэтому лисп именно sexp-based. И именно поэтому до сих пор нету сопоставимых по возможностям макросов в других языках.

Я обычно ограничиваю код 80-ю столбцами.

Я тоже. whitespace противно нарушения стиля цветом выделяет, первым делом их фикшу :)

>foreach - эо такая мелкая мелочь, что она есть в любом ЯП, либо просто реализуется.

Может быть в C есть? В плюсах-то и то только в майкрософтовских. В Джаве появилось только в jdk 5.0. Это действительно мелкая мелочь, одна из многих подобных мелких. Моя мысль состояла в том, что макросистема позволяет получить нужные синтаксические плюшки без изменения стандарта и спецификаций языка, без ожиданий когда это сделает Sun, и.т.д. Подобные мощные макросы можно встроить только в язык с простой грамматикой.

Подобные мощные макросы можно встроить только в язык с простой грамматикой.

Я вообще не вижу причин, почему foreach должен быть сделан в виде макроса.

80 columns это не только для того чтобы в экран 80х25 влезало и в страницу при печати.

Это ещё и призвано при случае указать, что твоя программа слишком сложная.

Ну и кроме того, не очень понимаю выгоду в 2/3. Тогда уж выгодней ровно 1/2 чтобы C-x 3 и профит.

>Это ещё и призвано при случае указать, что твоя программа слишком сложная.

Эта оценка по вложенности имеет отношение больше к Си¸ Си++ и т. п. По-моему, этот критерий был озвучен в гайдлайнах для kernel hackers, когда оговаривается, что восемь отступов для блока — это нормально. В Lisp же количество вложенностей больше и оно еще ниего не говорит о сложности программы. Особенность синтаксиса такая.

> Я вообще не вижу причин, почему foreach должен быть сделан в виде макроса.

Просто чтобы не тащить в «ядро» языка сложные конструкции. Зачем вводить ещё одну специальную форму, когда она легко (и столь же эффективно) реализуется макросом? Если уж разработчик компилятора хочеть именно для foreach-подобной формы что-то жёстко пооптимизировать - никто не запрещает раскрыть этот макрос в какую-нибудь implementation-specific форму, которую потом и заоптимизировать как надо. Правильность разделения логики на небольшие базовые операции и более сложные, строящиеся поверх базовых, думаю, ни у кого сомений не вызывает.

Да большая часть CL именно так и реализована, макросы поверх небольшого количества базовых специальных операторов.

Просто чтобы не тащить в «ядро» языка сложные конструкции.

Если ты про синтаксис, то foreach туда и не надо тащить. Это банальная функция для итеративного перебора sequence'ов (контейнеров, whatever).