Lisp, стратегия изучения.

супер

А я решил сначала PLC прочитать, а уже потом за SICP браться.

Вполне.

Странное решение, ввиду того что SICP освещает общие вопросы вообще программирования.

Наоборот, это хорошо. Сказано же: «Занимаюсь наукой, то есть не програмист».

читай Пол Грема «On Lisp». PCL к этой книгой и рядом не валялся.

Как знал, что надо было процитировать. Это был ответ не ТС, с ним как раз все хорошо, он четко знает, что ему нужно.

Ты бы ещё LoL посоветовал для изучения. Эта штука бьёт по мозгам посильнее штанги, я уж молчу про Фауста Гёте.

SICP это же учебник по программированию. А программировать я уже умею.

А программировать я уже умею.

Скромности вам не занимать, да.

Объяснить почему PCL - неудачный выбор вы не можете, это я уже понял.

Сразу с PCL и PAIP. SICP - про схему и программировать не научит, так же как и HTDP.

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

> А программировать я уже умею.

Ну так зачем тебе Лисп? Поднимайся на следующую ступень - учись рулить прогерами.

Нормальный.

как раз таки СИКП научит именно программировать

По сравнению с SICP HTDP кажется детской книжкой, поэтому если в программировании совсем ни бум бум, то лучше читать HTDP.

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

> Сразу с PCL и PAIP. SICP - про схему и программировать не научит, так же как и HTDP.

то, что ты — дебил, понятно было и без этого «высказывания»

> как раз таки СИКП научит именно программировать

Как раз не учит. Я вот совсем не понимаю, откуда такое благоговейное отношение к sicp. Максимум, на что способна эта книжка - это объяснить базовые понятия программирования - подстановочная модель, объектная модель, лексические замыкания и прочее, как практическое руководство оно очень слабое. Действительно учит программировать PAIP - задачи там намного серьезнее и ближе к реальным.

> то, что ты — дебил, понятно было и без этого «высказывания»

:)

> Нормальный план, или что-то еще посоветуете?

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

Пользы от этого для ваших (как я понимаю, юных) мозгов будет значительно больше. Считайте меня «быдлом», но копание в академически-яйцеголовой литературе для меня кажется сомнительным с точки зрения фана, развития кругозора и тренировки мозгов. Как мудро заметил давеча тов. halturin, «голова не резиновая». Если чувствуете, что в мозгах образовалась незанятая ниша, займите ее, ей-Б-гу, иностранным языком. От того, что вы забьете голову абсолютно непрактичным знанием (каковым является знание лиспа), толку не будет никакого.

Применимость лиспа на практике сильно преувеличена ЛОРовскими адептами. Лисп - язык с некоторыми отличительными чертами, как-то: 1) единство кода и данных, 2) макросистема и возможности метапрограммирования (в частности, написания самомодифицирующегося кода) и 3) инкрементальная компиляция. Реально «выстреливают» все эти фишки на очень узком классе задач; в остальных же случаях от них зачастую больше вреда, чем пользы. Не следует ожидать какого-то особенного чудесного «прозрения» от изучения лиспа, это - миф, довольно успешно распространяемый сектантами по обе стороны океана.

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

Мамочки, сколько пафоса.

А всё лишь для того, чтобы сказать, что лучше python и ruby ничего и не придумаешь. :)

> Применимость лиспа на практике сильно преувеличена ЛОРовскими адептами

наличие здравого смысла у куки сильно преувеличена кукой

> numerical methods, не вижу, чтобы лисп был здесь сильно востребован

Предчувствия вас не обманули. В применении к численным методам лисп терпит стабильное фиаско. На ЛОРе с завидной регулярностью кто-нибудь да пытается решить на лиспе вычислительную задачу, подчас тривиальную - и шумно садится в лужу. После разбора полетов оказывается, например, что на 32-битных платформах в лиспе не бывает 64-битных целых. Что максимальный размер массива на 32-битной платформе - 512М элементов, и так далее. После этого начинаются рекомендации от адептов переходить на 64-битную платформу, и прочая клоунада.

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

Для определённости, что из вышеперечисленных книг ты относишь к академически-яйцеголовой литературе?

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

Если это про трэд с телескопами, то 4.2, там требовалось читать в массив (с 32-битными элементами, например) из файла - а это одна строчка.

> Применимость лиспа на практике сильно преувеличена

По крайней мере он отлично подходит для разработки высоко-интерактивных веб-приложений, а за ними будущее ;)

инкрементальная компиляция

Х.з. как это правильно трактовать, я бы сказал - полностью интерактивная разработка.

> Для определённости, что из вышеперечисленных книг ты относишь к академически-яйцеголовой литературе?

К академически-яйцеголовой я отношу (в данном конкретном контексте) литературу, практическая ценность которой стремится к нулю.

Прежде всего это PCL, LoL и OL, то есть то, что касается конкретно лиспа. В значительно меньшей степени - SICP и HTDP, поскольку они затрагивают общие проблемы дизайна, алгоритмов и структур данных. Но о том же самом написано и у Вирта, и у Кнута, и, не побоюсь этого слова, у Страуструпа. И написано у них это для человеков, а не для скобкодрочеров.

И что же акадедемически-яйцеголового в PCL?

на 32-битных платформах в лиспе не бывает 64-битных целых

А в си бывает, за вычетом слово+слово и регистр+регистр? А как же

(deftype uint64 () `(integer 0 ,(1- (expt 2 64))))

Что максимальный размер массива на 32-битной платформе - 512М элементов

Аналогично - в си вы не адресуете больше 2^32, тут вы не адресуете больше 2^29 (почему меньше - указатели тэгированные, т.е. VM у SBCL так устроена). И, кстати, это не про «лисп», а про одну из реализаций (SBCL) одного из его диалектов (CL). Вложение такое - Lisp -> CL -> SBCL, нехорошо распостранять свойства текущей версии SBCL на всё семейство вообще.

и так далее

А что ещё?

> читай Пол Грема «On Lisp». PCL к этой книгой и рядом не валялся.

Если цель — подрочить макросы, то да, безусловно. Если цель — освоить язык, то нет, ни в коем случае.

А что, в CL по стандарту нет длинной арифметики?

А что, в CL по стандарту нет длинной арифметики?

Ну вот как раз в этом и дело - есть fixnum который как-то сопрягается с машинным словом (например, в SBCL это 29 бит, остальные 3 бита - тайп-тэг для VM) и bignum т.е. большие числа. И в отличии от си потребности делать примитивный тип с внутренним представлением «два слова» (или четыре) нет. Все остальные числовые типы (вроде «интервал от -7 до 5») это на тему бронирования кода (declarations is assertions) и подсказок компилятору.

> А в си бывает, за вычетом слово+слово и регистр+регистр?

Бывает. По крайней мере, uint64_t в Си - тип с фиксированной точностью и быстрой арифметикой.

А как же (deftype uint64 () `(integer 0 ,(1- (expt 2 64))))

А вы в курсе, что на 32-битной машине реально это будет bignum? с соответствующими катастрофическими последствиями для арифметики?

в си вы не адресуете больше 2^32, тут вы не адресуете больше 2^29

Да, а что не так? Именно поэтому у того вьюноши сишная программа прожевывала массив, не кашлянув, а чтобы то же самое заработало на лиспе, ему порекомендовали купить новый кластер :)

> После разбора полетов оказывается, например, что на 32-битных платформах в лиспе не бывает 64-битных целых.

А зачем 64-битные целые, когда есть bignum? Чисто для хохмы?

> А зачем 64-битные целые, когда есть bignum? Чисто для хохмы?

Молодой человек, такое впечатление, что к реальным вычислительным задачам вы имеете сильно опосредованное отношение... домашнее задание вам: написать простенький арифметический бенчмарк, ну, скажем, умножение больших матриц, или там решение СЛАУ. И посмотрите, КАКАЯ будет разница при использовании 32-битных целых (fixnum) и 64-битных (bignum).

В том же примере, реализованном на Си, разница будет несущественной.

Бывает.

Не, это как раз слово+слово, gcc имеет правила трансляции таких чисел - приходится сначала разбивать на части, складывать lo части, потом hi части, потом сбрасывать остаток и собирать всё вместе. Эмуляция ради удобства, короче.

А вы в курсе, что на 32-битной машине реально это будет bignum? с соответствующими катастрофическими последствиями для арифметики?

Да, это только для assertion. Если вам реально нужны 64-битные числа нужно определять примитив и набор VOP-ов (речь про компилятор SBCL, я не в курсе есть ли в других реализациях эмуляции 64-битных примитивов на 32-битных архетектурах). Но я не знаю зачем это может быть нужно.

Да, а что не так?

2^29 и баста. SBCL не единственная реализация динамического ЯП в которой используются tagged pointers с соответсвующим уменьшением размера максимального монолитного объекта в пямяти (Factor, Erlang/HiPe).

Академичность КЛ обосновывается невозможностью решать на нём СЛАУ. Цирк на выезде, что я могу сказать.

В этом треде решительно не хватает Love5an

Немолодой человек, такое впечатление, что Вы уже впали в маразм. Много Вы знаете вычислительных задач, где критична производительность 64-битного целого? Скажем так. Какой процент они занимают среди всех вычислительных задач? Хотя бы по порядку.

P.S. Таки-да, я согласен с тем, что CL не очень хорошо подходит для числодробильных задач, но уж явно не из-за отсутствия высокоэффективного 64битного целого.

И посмотрите, КАКАЯ будет разница при использовании 32-битных целых (fixnum) и 64-битных (bignum).

fixnum не 32-битные они соответсвуют машинному слово. Какой резон в 64-битной арифметике на 32-битной машине? В gcc она эмулируется объектами по два слова, в других языках эту же роль играют большие числа (объекты по n-слов).

Хотя нужно признать, что emit gcc при использовании искуственных uint64_t лучше чем emit SBCL для bignum (два раза по add / mov в первом случае и неизменный generic-+ во втором), но это уже технология трансляции - вещь ортоганальная лиспам, сям и прочим языкам. SBCL мог бы успешно инлайнит generic-+ для каких-то типов bignum ограниченных верхним значением (как он инлайнит c...r меньше определённого уровня вложенности).

сначала схема SICP

Обязательно, там помимо прочего есть хороший пример символьных вычислений - символьное дифференцирование. Это более выгодная для CL сфера применения (maxima, например) чем числодробилки.

возможно HTDP

ИМХО, больше похожа на титуриал по PLT Scheme - некоторые идеи доносятся о подходе к написанию функций (типы данных -> контракты -> зарисовка -> определение), о хорошем правильном стиле написания и документирования этих функций, но слишком много Scheme-специфичных вещей.

можно что-то из AI специфики

PAIP, тоже в основном фокусируется на символьных вычислениях.

Читай PCL. Для начала хватит. Но, вообще, лучше подучить английский, залезть на planet.lisp.org и далее по ссылкам.

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

PCL, CLTL

Всем спасибо, все книжки скачал - буду смотреть, как двигаться дальше.
Отвечу на самый острый комментарий в топике:
Спасибо за совет. Но я не знаю на каком основании вы мне даете совет изучать что-то другое, вы ведь не знаете входных условий и я вообщем-то не спрашивал стоит ли мне изучать лисп или пойти в театр. :)
Кстати, вы знаете - решение задачек тренирует мозги, и я бы вам порекомендовал в ваш список включить хотя бы решение судоку, чтобы не отупеть с возрастом :)
Чтобы составить свое мнение о чем-то желательно вникнуть как обстоят дела, в противном случае это мнение часто ошибочное. Если же я не разбираюсь в вопросе, то использую такую стратегию: вижу людей, которые высказывают свое мнение по известному мне вопросу, или в котором я быстро способен разобраться, если оно мне нравится/совпадает с моим, то я часто с уважением отношусь и к их мнению по другим вопросам, в любом случае придется проверить потом.

> Что максимальный размер массива на 32-битной платформе - 512М элементов
Вот это плохо, а длинные integer мне не нужны и, я сомневаюсь, что в скором времени понадобятся.

> Как раз не учит. Максимум, на что способна эта книжка - это объяснить базовые понятия программирования - подстановочная модель, объектная модель, лексические замыкания и прочее, как практическое руководство оно очень слабое.

Сейчас читаю SICP - не соглашусь. Очень важно, что она учит декомпозиции задачи, разбиению сложного на мелкие составляющие - навыка, которого так не хватает мозгам, в своё время травмированным недо-ООП типа жабы или c++ (сужу по себе), привыкшим мыслить в рамках костылей и ограничений языка программирования. Возможно, кто-то не сталкивался с этой проблемой и сразу программировал «правильно» - тогда ему, может быть, SICP и не будет особо интересен. Для остальных SICP очень полезен.

Насчёт численных методов: моя практика показывает, что лисп (CL, SBCL) отлично подходит для _разработки_ расчётных программ, особенно в связке с C. Дело в том, что далеко не всегда ясно, какой именно алгоритм лучше всего подходит для расчёта. Иногда алгоритм вообще ещё не существует, есть идея, которую надо формализовать и воплотить в коде. В этом случае наличие REPL в лиспе в сочетании с приличной скоростью работы SBCL и возможностью переписать узкие места на C играют ключевую роль. Для собственно написания удобно использовать следующую методику. Программа пишется наиболее подходящим для лиспа методом снизу-вверх с постоянным тестированием в REPLе. По мере выявления тормозов они устраняются расстановкой деклараций, макрологией или подключением С через CFFI. Да, порой получается так, что итоговый код оказывается на чистом или почти чистом (за исключением интерфейса и ввода-вывода) C, но применение лиспа в процессе разработки обычно значительно её ускоряет.

P.S.: физик, расчётчик.