Джентельменский набор ЯП

>>> c чего бы отображение (хеш-функция) было не сюръективно, если множество значений и есть множество хеш-кодов?
>> А с того, что так бывает в узком и никому не нужном частном случае.
> Например md5 хэш - сюръективная функция (для любого 128 битного числа найдется прообраз). Это "узкий и никому не нужный частный случай"?

Покажи, где это применяется. (Кроме доставания болванки из хеш-кода через astralctl)

>> Отлично, докажи мне биективность хеш-функции f(int x)=x%2.
> Сначала придется кому-то доказать, что эта функция имеет обратную :)

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

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

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

Зобанедь бы вас за оффтопик... нашлись мне Гедель с Тьюрингом %)

>Зобанедь бы вас за оффтопик... нашлись мне Гедель с Тьюрингом %)

никакого оффтопика, я специально даже GNU упомянул :)

и чур я не Тьюринг

> никакого оффтопика

Вот если бы вы поспорили, какое из ответвлений математики сильнее в работе помогает, с use-case'ами... или хотя бы о том, какая именно математика должна преподаваться прогерам - это был бы не оффтопик :)

> и чур я не Тьюринг

эээ... ладно, про Тьюринга я не подумав ляпнул %) фон Нейман, скажем... хотя у него тоже тараканы в голове были... блин, да не было на свете нормальных математегов :D

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

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

P.S. А тут ещё злой пи скор откусывает :)

> и чур я не Тьюринг

А, кстати, он всё-таки не_такой_как_все или всё же это утка википедийная?

>Вот если бы вы поспорили, какое из ответвлений математики сильнее в работе помогает, с use-case'ами... или хотя бы о том, какая именно математика должна преподаваться прогерам

Кабы знать с чем каждому студенту дальше работать придётся...

Наибольшая вероятность востребованности в дальнейшей профессиональной деятельности имеет теория управления, как мне кажется.

>А, кстати, он всё-таки не_такой_как_все или всё же это утка википедийная?

Да не, не утка. И варвары британцы его за это и затравили.

> Покажи, где это применяется.

http://en.wikipedia.org/wiki/MD5#Applications

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

А где здесь речь про хеш-функцию:

>>>> функция имеет обратную iff она биективна :)

>>> так и запишем, не помнит ревнитель дискретки предмет своего обожания

>> доказательство провести, или сам справишься?

???

>> Да-да, пусть он сначала предъявит мне обратную функцию для произвольной хеш-функции.
> А где здесь речь про хеш-функцию:

Разобрались уже. кое-кто баловался фигурным квотингом.

> Уймитесь вы уже со своей сюръективностью. Есть более простые слова - однозначное, взаимно-однозначное и т.п. Все нормальные кодеры прекрасно понимают эти понятия и без специальной математической терминологии.

Если кодеру объяснить что-то "на пальцах", потом он всегда этим объяснением и будет пользоваться, снова и снова прокручивая его в уме. Как первоклассники лет 100-150 назад считали на пальцах и только на пальцах, потому что их так обучили.
Пример: один мне встречавшийся овощ разницу между клиентом и сервером постоянно выводил из прочитанной им когда-то статьи о клиент-серверном вирусе. До кучи ещё и неправильно выводил :)

>> А, кстати, он всё-таки не_такой_как_все или всё же это утка википедийная?
> Да не, не утка. И варвары британцы его за это и затравили.

Как страшно жить: налево пойдёшь --- не_таким_как_все станешь, напроаво пойдёшь --- жену убьёшь.

>> Покажи, где это применяется.
> http://en.wikipedia.org/wiki/MD5#Applications

Опять фигурный квотинг!? Покажи мне, как применяется факт того, что md5-отображение сюрьективно.

> Покажи мне, как применяется факт того, что md5-отображение сюрьективно.

Если бы md5-отображение было не сюръективно, а использовало, например, 1% от всех 128 битных чисел, то было бы больше коллизий и находить их было бы проще.

А вообще, изначально кто-то утверждал, что сюръективные хеш-функции "бывают в узком и никому не нужном частном случае". Что, очевидно, не верно.

>> Покажи мне, как применяется факт того, что md5-отображение сюрьективно.
> Если бы md5-отображение было не сюръективно, а использовало, например, 1% от всех 128 битных чисел, то было бы больше коллизий и находить их было бы проще.

А если бы 2^128-1? Много проще бы стало?

> А вообще, изначально кто-то утверждал, что сюръективные хеш-функции "бывают в узком и никому не нужном частном случае". Что, очевидно, не верно.

Факт сюръективности никак не используется => "не нужно".

>> Просто в твоём случае это случилось сразу (а иначе и быть не могло, когда всего три строки).

В моем случае это случилось во время компиляции, не важно в вобщем...

>> Что происходит дальше? Дальше нужно стереть все fasl-ы, где этот bar мог использоваться, перезапустить образ и загрузить всё по новой (а это занимает минуту и больше).

Это не только проблема лиспа, в любом другом языке после рефакторинга надо пересобирать весь проект (в общем случае). И это то же время.

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

Это у тебя LispWorks так работает? При компиляции slime+emacs показывает все проблемные места, тыкай мышкой и получай описание ошибок.

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

Ты хотел сказать не существует нормальной среды разработки?

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

Опять же это вопрос среды разработки. Например, далеко не секрет, что в, например, NetBeans производительность жава-проггера возрастает в разы, потому, что половина кода генерится самой средой. А уж там то писанины в разы больше чем в лиспе. А про слабость приложений и библиоек не понял, что ты под этим подразуеваешь?

>> А до этого не было никакой другой возможности рефакторить, кроме как перебрать ВСЕ определённые функции и переменные по одной и искать их во всех местах? где они используются. Что непроизводительно. В С и Паскале это решается проще - ты просто переносишь определения, запускаешь компилятор и ловишь сообщения об ошибке.

Оригинальный способ рефакторинга, я доложу! Во-первых открой для себя slime, а в нем crossrefernce. Во-вторых у тебя очень странные представления о рефакторинге С и Паскаля, обычно в ихних IDE достаточно жмакнуть пимпу Refactor и оно само переместит/переименует/добавит/удалит все что надо.

>> В динамической среде все ошибки остаются в образе

В статической среде все ошибки остаются в файлах.

> При компиляции slime+emacs показывает все проблемные места, тыкай мышкой и получай описание ошибок
> Во-первых открой для себя slime, а в нем crossrefernce

Во-вторых, открой для себя asdf и убедись, что мышкой станет тыкать некуда. Ну и кроме того, при той ошибке, о которой я говорю, даже в одном файле тыкать некуда, потому что ошибка будет в конце файла и сказано в ней будет "ссылка на неопределённую функцию". И я не понял, какое отношение cross-reference имеет к рефакторингу.

> Во-вторых у тебя очень странные представления о рефакторинге С и Паскаля, обычно в ихних IDE достаточно жмакнуть пимпу Refactor и оно само переместит/переименует/добавит/удалит все что надо

Возможно, я не пользовался такими фичами. Хотя мне кажется, что ты немного завираешься, если речь идёт о С. Но если это правда, то тем хуже для лиспа. В нём нет кнопки "refactor", хотя язык вроде бы такой весь из себя крутой!

> Ты хотел сказать не существует нормальной среды разработки
Я уже два раза сказал, и мне кажется, что достаточно однозначно :)

> А про слабость приложений и библиоек не понял, что ты под этим подразуеваешь?
Я подразумеваю ровно то, что вижу. Приложений я вообще не вижу на лиспе. Библиотеки убогие. Примеры? Да сколько угодно.

clsql - нет параметризованных запросов
сl-ppcre - не умеет парсить потоки, а умеет только строки
alexandria - вообще очень маленькая и слабая библиотека
tinaa - ладно, что тормозит и неправильно работает под win32, я не смог вообще сгенерить документацию для своего проекта - мне сказали "класс nil не найден". Это после того, как я потратил полчаса времени на то, чтобы её собрать и пофиксить один баг. Плюнул после этого. Но даже если бы не плюнул, то сравнить с Doxygen её нельзя. Doxygen круче в 10 раз, хотя написан "всего лишь" на С.
asdf - вообще, кроме мата, никаких других слов. Это надо испытать, чтобы понять. Хотя, если выучить исходники наизусть и программировать отдельно под каждую систему, даже можно работать.
clbuild - может собирать только последние версии. Т.е., unstable всегда (и кстати, он в основном написан не на лиспе, а на шелле. Автор даже как бы извинялся :)
asdf-install - стабилен, но чё-то там много тухляка. Как правило, рекомендуют брать текующую версию из репозитория.

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

sbcl - ты никогда, ни при каких флагах компиляции не увидишь имена всех своих переменных. Что-то увидишь, но параметры - никогда. Некоторые кадры стека будут уничтожены при любом раскладе и ты вообще их не увидишь. Я уже не говорю об отсутствии чего-либо похожего на визуальную отладку, о возможности поставить брекпойнт, о возможности увидеть результат макрорасширения иначе, чем вручную писать macroexpand. Был проект lispdebug, котрый всё это умел, но он похерился почему-то.

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

Всё это вместе выглядит похожим на большую помойку! Каждую проблему по отдельности можно было бы пережить, но они всё лезут и лезут изо всех щелей. И, самое главное - море СКОБОК!

Справедливости ради, конечно, нужно сказать, что на лиспе есть и гениальные проекты, например, ap5. Но они сделаны давно.

А есть ещё и другие проблемы в самом языке (совсем не маленькие и не смешные). Но я лучше пойду спать...

>> тем, что на их написание и поддержку уходит слишком много времени, которое можно потратить непосредственно на разработку

>Быдлокодеришко?

нет ты

> За тебя кто-то программу продумывает и даёт листок со спецификациями, по которому код клепать надо?

по твоему, разработка -- это "клепать код"?

>> Человек, имевший Спектрум в 5 лет, но не программировавший на ассемблере, право на собственное мнение не имеет.

>Починено.

ололо

>Да юзай что угодно, только не называй это RAAI.

Почему? Где-то существует Комитет По Стандартизации Значений Плюсовых Аббревиатур?)

Имхо, RCSP (да, еще одна аббревиатура!:)) имеют полное право называться реализацией RAII. Другое дело, что не всегда их использование оправдано.

> Это есть только в Си++ (насколько я знаю).

Точно есть в D, а Педивикия говорит, что это также есть и в Аде.

>> Да юзай что угодно, только не называй это RAAI.

> Почему? Где-то существует Комитет По Стандартизации Значений Плюсовых Аббревиатур?)

Чтобы не обозначать одним термином разные вещи.

>> Это есть только в Си++ (насколько я знаю).

> Точно есть в D

IIRC, в D есть и конструкторы/деструкторы, так что в нем RAII можно сделать точно как в Си++.

> также есть и в Аде.

Самой Ады нет :)

> Самой Ады нет :)

Почему же? Как минимум есть в автоматической ветке Парижском метрополитена :) Еще есть на каких-то GPS'овых спутниках. Вообщем, пока есть :)

> сl-ppcre - не умеет парсить потоки, а умеет только строки

А что умеет? pcre со строками работает, ~= в перле со строками работает, boost:regex со строками работает. Там ведь вообще идеология работы со строками.

> sbcl - ты никогда, ни при каких флагах компиляции не увидишь имена всех своих переменных. Что-то увидишь, но параметры - никогда.

Это ты про что?

> Некоторые кадры стека будут уничтожены при любом раскладе и ты вообще их не увидишь.

Опять, ты про что?

> Я уже не говорю об отсутствии чего-либо похожего на визуальную отладку, о возможности поставить брекпойнт,

(break)?

> о возможности увидеть результат макрорасширения иначе, чем вручную писать macroexpand.

В slime кнопки нажать можно.

> windows - до сих пор только коммерческие реализации нормально работают с тредами.

Смею предположить, что кому треды по винду нужны, тот сам сделать не может, а кто может, тому не нужны. Типичная ситуация.

> по твоему, разработка -- это "клепать код"?

Нет, бОльшую часть времени занимает проектирование и проверка соответствия функционала кода проекту.

>> Да юзай что угодно, только не называй это RAAI.

> Почему? Где-то существует Комитет По Стандартизации Значений Плюсовых Аббревиатур?)

> Имхо, RCSP (да, еще одна аббревиатура!:)) имеют полное право называться реализацией RAII. Другое дело, что не всегда их использование оправдано.

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

Scheme->C->Java->Python.

>Самой Ады нет :)

Есть как минимум ghdl

>> Возможно, я не пользовался такими фичами. Хотя мне кажется, что ты немного завираешься, если речь идёт о С. Но если это правда, то тем хуже для лиспа.

Кхм... Скажи честно, ты когда-нибудь Eclipse, NetBeans или MS VS видел?

>> В нём нет кнопки "refactor", хотя язык вроде бы такой весь из себя крутой!

А что, есть языки с кнопкой refactor?

>> И я не понял, какое отношение cross-reference имеет к рефакторингу.

Самое прямое.

>> Т.е., не существует ничего похожего, скажем, на релизы, как в дебиан. Либо у тебя trunc, либо устаревший и несогласованный между собой тухляк. Можно гарантировать, что разработка чего-нибудь сложного займёт немало времени из-за постоянных обновлений библиотек.

У-у-у друг, ты еще не видел какой тухляк творится в С,С++, Жаве, Перле и прочих языках... BTW, покажи мне язык для которого централизовно релизятся все-все-все библиотеки и я откажусь от лиспа.

>> sbcl - ты никогда, ни при каких флагах компиляции не увидишь имена всех своих переменных. Что-то увидишь, но параметры - никогда. Некоторые кадры стека будут уничтожены при любом раскладе и ты вообще их не увидишь.

Ну вообще-то чтобы увидеть имена переменных sbcl не нужен, ага.

>> Я уже не говорю об отсутствии чего-либо похожего на визуальную отладку, о возможности поставить брекпойнт, о возможности увидеть результат макрорасширения иначе, чем вручную писать macroexpand. Был проект lispdebug, котрый всё это умел, но он похерился почему-то.

Я тебе уже писал в прошлый раз, но повторюсь, открой для себя slime: macroexpand - C-c RET, breakpoint - (break), визуальная отладка - это слишком объемное понятие, чтобы понять, что конкретно ты имеешь в виду, подозреваю, что-то типа inspect, тогда C-c I. Лучше напомни язык, программу на котором можно отлаживать и перекомпилировать не останавливая саму программу, слабо? Один такой я знаю - smalltalk, остальных что-то не видать.

>> windows - до сих пор только коммерческие реализации нормально работают с тредами.

Ну меня это мало волнует. В конце концов, что тебе мешает использовать коммерческие реализации?

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

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

>> И, самое главное - море СКОБОК!

Ну и брось его, програмь на чем-нибудь, что в состоянии осилить. Делов-то!

> BTW, покажи мне язык для которого централизовно релизятся все-все-все библиотеки и я откажусь от лиспа.

Разве в жабе и дотнете основные библиотеки платформы не релизятся точно вместе с новой версией платформы?

> Лучше напомни язык, программу на котором можно отлаживать и перекомпилировать не останавливая саму программу, слабо? Один такой я знаю - smalltalk, остальных что-то не видать.

Tcl, Erlang

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

Я осилил и давно пользуюсь. Просто у меня наконец открылись глаза на то, что потенциальные возможости и доступные уже сейчас возможности - это разные вещи. Да, можно начать от Адама и попробовать переписать всю вселенную с нуля. Но просто не успеешь. Будешь всё время отставать от индустрии и в итоге окажешься в нищете и умрёшь под забором. Пока я делал всякие вещи на лиспе для себя, можно было этого не заметить. Теперь я вышел на более широкие просторы и это стало очевидно. Соответственно, нужно поставить знак "кирпич", чтобы туда никто больше не ходил.

Можно осилить разные навыки, например, как трусы через голову одевать. Но нужно ли это? Я, освоив лисп в достаточной степени, могу сказать - нет. Не нужно. Отдельные идеи лиспа хороши, и даже их сочетания хороши. Но недостатки фатальны. Даже если бы сам язык был плохим, но было бы сильное сообщество, можно было бы мириться с этим. Но слабо также и сообщество. Не найдёшь работу - тяжело получить прибыль с вложенных усилий. Не найдешь специалистов - тяжело поднять свой бизнес. Итоговый вывод: common lisp не стоит труда.

Должен появиться какой-то новый язык на тех же идеях, менее грязный и бардачный, чем Common Lisp. Возможно, это уже появившаяся clojure. Возможно, Nemerle. Возможно, C# дорастёт до этого уровня. Не знаю. А сами идеи лучше изучать на более простых и явных примерах. Мысль о том, что эти идеи могут сочетаться в одном языке, может дойти до разумного человека и без изучения Common Lisp.

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

Следи, кому отвечаешь.

> Разве в жабе и дотнете основные библиотеки платформы не релизятся точно вместе с новой версией платформы?

Основные библиотеки и в Lisp'е вместе с платформой. Претензии-то не к ним, а ко всяким CL-SQL (не нравится, бери Postmodern или CL-RDBMS), alexandria и прочим 3rd party libraries. В таком контексте я сейчас и для Java и для .Net накопаю полсотни условно работающего хлама (неоторый хлам даже за деньги(!) предлагают). Это что-то докажет?

А вопрос был про "все-все библиотеки". К слову, один такой язык я знаю: C + Debian repository :-) хотя в этом контексте Lisp + Debian работает не хуже.

> А вопрос был про "все-все библиотеки". К слову, один такой язык я знаю: C + Debian repository :-)

Сам же понимаешь, что это утопия.

> К слову, один такой язык я знаю: C + Debian repository :-) хотя в этом контексте Lisp + Debian работает не хуже.

Никогда не вставал на грабли с dev-пакетами? Ну ничего, ещё не вечер.

> Никогда не вставал на грабли с dev-пакетами? Ну ничего, ещё не вечер.

А ты встречал грабли с dev-пакетами в Debian-stable? Можно пример? Я всегда думал, что если они следят за стабильностью, то это глобально.

>> Никогда не вставал на грабли с dev-пакетами? Ну ничего, ещё не вечер.
> А ты встречал грабли с dev-пакетами в Debian-stable? Можно пример? Я всегда думал, что если они следят за стабильностью, то это глобально.

Безопасность(за которой действительно следят)!=стабильность. Кроме того, интересный тебе пакет может просто не оказаться в дистрибутиве.

> Основные библиотеки и в Lisp'е вместе с платформой

Cлушай, не смеши меня. Что там есть:
#+sbcl sb-ext:quit #+(or ccl lispworks) quit

Как минимум, в стандарте нет переносимой функции "выйти из лиспа". Также там нет:

- возможности узнать список аргументов функции (есть, но стандарт позволяет возвращать nil, что реализации радостно и делают)

- возможность узнать список полей структуры, хотя язык динамический и вроде бы рефлексивный. Только не надо меня лечить, что вместо структур надо пользоваться классами. Классы работают в 6-20 раз медленнее структур в нескольких реализациях, где я это проверял. Определение класса обычно втрое более объёмное, чем определение структуры. При этом, из-за своей гибкости, код с классами менее однозначен и, тем самым, более сложен для чтения. Кроме того, MOP тоже не стандартизован.

И ещё один перл:
в ccl #p"c:/systems/foo.asd.lnk" ->"c:/systems/foo'.asd.lnk"
при внимательном чтении стандарта выясняется, что physical pathnames - это implementation dependent вещь. Но нигде в стандарте не написано, что physical pathname - это имя файла, которое понимает операционная система. В ccl есть специальная (специфичная для реализации) функция для того, чтобы сделать понятное операционной системе имя файла из physical-pathname. Это нужно, например, для запуска внешней программы.

Т.е., в common lisp нету даже переносимого способа обращения к файлам!

Далее. Если попытаться сделать совершенно элементарную вещь - вызвать команду операционной системы и прочитать то, что она выводит, то и тут будут проблемы. Некоторые реализации не позволяют перенаправить выходной поток, некоторые - сливают вместе stdin и stderr. Я видел попытки сделать слой переносимости в asdf и в clsql, но нигде эта работа не доделана до конца. Под win32 всегда приходилось что-то патчить. Ну и, конечно, нет развязки по версиям реализаций.

О каких ещё "основных библиотеках" может идти речь после этого? Что конкретно ты имеешь под этим в виду?

В общем, это - полная помойка, а не среда разработки!

> Postmodern или CL-RDBMS
Я боюсь тратить своё время. Почему-то мне кажется, что они будут ещё кривее, чем CLSQL. Который, вроде бы, всё же удалось приучить к работе.

К слову, про "все" библиотеки лично я речи никогда не вёл. Это был демагогический приём моих оппонентов :)

> накопаю полсотни условно работающего хлама
Не знаю. Может быть, я в этом отношении так плохо думаю про лисп только потому, что не работал на Яве :) Хотя я читал мнения тех, кто пробовал и то, и другое, о том, что лисп как платформа слабее. Мне почему-то верится.

Но если говорить не про библиотеки, а про "стандартную библиотеку", то здесь есть ужасные пробелы. Например, нет полного набора коротких имён функций для работы с a-списками. Например, сравним получение элемента a-списка в лиспе:
(cdr (assoc key list)) - чтение
(setf (cdr (assoc key list)) new-value) - чтение
и в том же Object Pascal
list[key] - чтение
list[key]:=new_value;

да, я вру в том, что на самом деле, есть ещё &key и т.п., но почему всё же основная форма записи так длинна? Лисповый текст примерно вдвое длиннее паскалевого. Вдвое длиннее - это значит, что глазу нужно совершить вдвое больше работы для просмотра этой строки. А у меня есть такое предположение, что распознование изображений букв - это одна из наиболее трудоёмких (хотя и не осознаваемых) частей работы по чтению кода, если сам код достаточно прост. Во всяком случае, скомпилировать страницу кода на самом забористом С++ и распознать страницу кода со сканера - это задачи, отличающиеся по вычислительным ресурсам, наверное, раз в 500. Конечно, у мозга другая архитектура и задача распознавания, видимо, решается быстро за счёт параллельности. Но даже если этот коэффициент у человека равен просто единице, то всё равно потеря велика. Также нужно учесть и то, что и в мозгу есть разные кеши. Например, при чтении взглядом можно охватить только довольно небольшой кусок текста, что вызовет "атомарный акт понимания" и этот объём - это просто определённое количество букв. Если паскалевский/явовский/питоновский текст вдвое компактнее лиспового, то лисповый код может оказаться в 10 раз труднее для понимания из-за выпадения информации из кеша. Я на самом деле, думаю, что основная проблема лиспа - именно в этом. Просто, поскольку это тяжело выявить вне рамок специального исследования, мало кто из лисперов способен это заметить.

Если я прав, то какой вывод? Лисп плохо сказывается на производительности труда.

Если же написать свои макросы для сокращения кода, это будет сказываться на читабельности кода чужими и на его переносимости. Сообщество однозначно тебя отторгнет. Отторгнет тебя и среда разработки, которая будет тебе печатать твои макросы развёрнутыми и и иногда откажется помогать в навигации по коду.

Также нет таких функций, как "заменить кусок строки на строку большей длины", "взять хвост строки". Да, всё это пишется. Но при этом каждый пишет такую функцию для себя. И при чтении нового кода нужно каждый раз потратить время на изучение новых соглашений об именах и нового синтаксического сахара. Например, есть такие, удобные, но не общепринятые вещи: length=, awhen, aif. Они нужны исключительно из-за гротескной непрактичности основного синтаксиса CL. Когда работаешь над разными проектами (особенно чужими), тебе нужно постоянно тратить ресурс мозга на то, чтобы помнить, какими конструкциями можно пользоваться, а какими нельзя. Когда ты напишешь свою функцию (например, я написал sequence-last), скорее всего, со временем возникнет конфликт имён с чьей-нибудь ещё одноимённой функцией (например, у меня возник конфликт с clsql:sequence-last). Заранее это не предугадать.

В общем, лисп - это гениальная, но несколько недоделанная среда разработки. Моя задача - зарабатывать деньги, а не бороться с последствиями того, что кто-то поленился доделать 20 лет назад (хотя это было легко доделать тогда). Теперь болезнь запущена и я бы прописал этому языку эвтаназию. Из гуманизма.

> (cdr (assoc key list)) - чтение
(setf (cdr (assoc key list)) new-value)
и в том же Object Pascal
list[key] - чтение
list[key]:=new_value;

А в С++
list.find(key)->second - чтение
list.find(key)->second = new_value

что не менее громоздко, чем Lisp. Наличие в Pascal синтакического сахара из коробки -- не аргумент

> Например, есть такие, удобные, но не общепринятые вещи...
реально они общеприняты. Также как CFFI, ASDF и прочие соглашения. Иначе можно считать, что ODBC в C/C++ тоже удобная, не общепринятая вещь :-)

> В общем, лисп - это гениальная, но несколько недоделанная среда разработки.

Если лисп = Common Lisp как стандарт, то видимо да. Нет MOP, нет потоков, нет FFI. Если Lisp как SBCL + Linux + например, библиотеки с http://common-lisp.net/project/cl-dwim/, то язык + платформа получаются достаточно мощные и удобные для использования.

Набор библиотек, конечно раздробляет сообщество, но ведь C++ как-то живёт с Qt, std, MSVC и ещё полудюжиной несовместимых реализаций, в которых даже строки по разному представлены... :-)

Ergo, Lisp лучше C++ как язык и как платформа, по сравнению с Java, .Net проигрывает как переносимая платформа, но языковых возможностей всё равно больше.

> А в С++
> list.find(key)->second - чтение
> list.find(key)->second = new_value

Я тебя, наверно, удивлю, но в c++ можно писать и list[key] для обоих случаев.
Первое время в языкам с не c-like синтаксисом раздражает отсутствие подобного сахарка. А потом понимаешь, что запись в виде [ dict get .. ], [ array get ... ], [ something get ... ] куда более единообразна.

> фон Нейман, скажем... хотя у него тоже тараканы в голове были...

А какие? Любил сбрасывать на людей ядрёны бомбы для проверки своих расчётов, желательно на культурно-исторические центры?

>XML - это ущербный формат, который плохо читается и человеком, и машиной.

HTML это вообще просто ужас, спагетти из скобочек, знаков больше-меньше, равно, кавычек. Вообщем, мрак. Если читать html без браузера. Для XML тоже давно придумали и просмотрщики и редакторы и с валидацией и с код-комплитом и с посветкой и ...

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

Альтернатива есть? Назови ту платформу на которой и писать надо меньш из расчета "количество букв/смысл выражения", дабы как ты говоришь повысить производительность труда, и чтоб не было помойки с библиотеками, и чтоб реализации были свместимы тютелька в тютельку, и чтоб кроссплатформенность была во всем и всегда и т.д. Я таких языков/платформ не знаю и никгода о них не слышал.

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

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

>какая именно математика должна преподаваться прогерам

высшая алгебра, однозначно

>> какая именно математика должна преподаваться прогерам
> высшая алгебра, однозначно

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

К примеру, я ещё могу понять, что начала теории групп и колец помогут в раскачивании мыслепроводящих дорожек в мозгу. Но представить себе, чтобы среднестатистический "прогер" пользовался базисами Грёбнера, не могу.

> Для создания моделей нужен а) фреймворк, б) словарь предметной области. А на язык - плевать. Хотя по сути дела фреймворк - это тот же словарь предметной области.

> Черт, и сколько же пришлось преодолеть чтобы наконец "дошло". Хотя хрен я в это верил и даже смеялся.

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

> В С и подобных языках нужно сначала задекларировать тип переменной. Хотя можно вместо этого принять некие соглашения, позволящие писать polymorphicArray x = {1,"sdfasdf",new foo())} Это - большое ограничение на С- образные языки, которое мешает в работе.

ты просто с++ не знаешь, такое "соглашение" пишется в 20 строчек, я даже на ЛОРе постил такую программку

> Перл мертв. Большинство его задач (и нужно) выполнять shell или Python.

Для регулярки перл самое то. А еще для bla-bla-bla | perl -Wne '...'