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

> В питоне каждая переменная - как boost::shared_ptr в C++. Надеюсь, как связан shared_ptr с RAII, вы знаете?

Считай, что нет.

Переводя на технический язык, предлагается реализация метода __del__, который вызывается сборщиком мусора? И это выдается за RAII, при том, что порядок и время вызова этих методов не определены. Я правильно понял?

> Переводя на технический язык, предлагается реализация метода __del__, который вызывается сборщиком мусора? И это выдается за RAII, при том, что порядок и время вызова этих методов не определены. Я правильно понял?

Правильно, только время вызова определено: при выходе из функции, в локальных переменных которой живёт рассматриваемая ссылка. А порядок удаления объектов соответствует их связям. Два никак не связанных объекта удалятся как попало, но на то они и несвязанные...

Разумеется, реализация в конкретном случае может отличаться по виду от плюсовой, но идея та же. Или есть какие-то контрпримеры, где RAII питоном ну никак не сделать?

finally в питоне как раз потому и не юзаю, что и без него все сопли подтираются правильно.

> Правильно, только время вызова определено: при выходе из функции, в локальных переменных которой живёт рассматриваемая ссылка

Кем и где?

> А порядок удаления объектов соответствует их связям

Чему? O_o В RAAI порядок удаления определяется порядком объявления.

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

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

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

1. мне тогда было 10 лет

2. слишком толсто

А какой-нибудь with у вас есть? Заwithенные объекты будут грохаться по выходу из lexical scope в порядке fifo. Это можно считать RAII?

> какой-нибудь with у вас есть?

Ну ты же знаешь, что есть. Не во всех версиях, правда.

> Заwithенные объекты будут грохаться по выходу из lexical scope в порядке fifo. Это можно считать RAII?

Нет. Это такой finally на стероидах. RAAI основывается на вызове конструкторов и деструкторов в строго определенном порядке. Это есть только в Си++ (насколько я знаю).

> RAAI основывается на вызове конструкторов и деструкторов в строго определенном порядке. Это есть только в Си++ (насколько я знаю).

Педивикия про RAII: "ensures that when resources are acquired they are properly released by tying them to the lifespan of suitable objects: resources are acquired during the initialization of objects, when there is no chance of using them before the resource is available, and released with the destruction of the same objects, which is guaranteed to take place even in case of errors."

Смотрим на питон: конструктор есть, деструктор тоже, вызывается гарантированно в вполне определённый момент. Про порядок в определении ничего не сказано, да и здравый смысл подсказывает, что бог с ним, с порядком. Пусть в C++ он есть, но это ж не значит, что в RAII без него никак. Я всё-таки жду плохой для питона пример.

>МК-61 -> Basic -> Focal -> Asm 8080 -> Асм PDP -> Forth -> Си, Паскаль -> Асм x86 -> FORTRAN -> Perl -> PHP -> Java ... :)

GWBasic -> SWI-Prolog -> C -> C++ -> Tcl, Expect, Yorick -> Haskell

отдельным пунктом IA-32, MIXAL, MMIXAL. и всякие Python'ы при необходимости отладки чужих скриптов

> Педивикия про RAII

В ланном случае педивикия не катит ни разу.

> вызывается гарантированно в вполне определённый момент

Пруфлинк или GTFO.

> Про порядок в определении ничего не сказано, да и здравый смысл подсказывает, что бог с ним, с порядком.

Это всего лишь _твой_ здравый смысл :D

>игрушку околоакадемических кругов - Хаскел.

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

Раз пошла такая пьянка... PL/I+asm IBM/370 -> C -> C++ -> Python, ну REXX и shell, конечно.

>> игрушку околоакадемических кругов - Хаскел.

> Спасибо, не надо. Во-первых там виртуальную машину еще пилить и пилить

ЕМНИП, там компиляция в нативный код.

>> Нет. Это такой finally на стероидах. RAAI основывается на вызове конструкторов и деструкторов в строго определенном порядке. Это есть только в Си++ (насколько я знаю).

Потому, что только в С++ есть деструкторы (ну почти только в нем :)). А ту же самую концепцию - автоматическое освобождение ресурсов при выходе из области видимости можно реализовать не только в конструкторах/деструкторах. Тот же with-open-file, если такие вызовы вложить друг в друга закроет ресурсы в порядке обратном их созданию при выходе ссылок на ресурсы их лексической области видимости. Так почем же это не RAII?

>Около-lisp, выведение типов (опциональное!), паттерн матчинг.

Лисп только один - CommonLisp. Аффторов "лисп-подобных" систем нужно жестоко убивть.

В CL тИповая сигнатура связана не с символом, а с объектом. Это его ключевое свойство, блин. И любые попытки это изменить - ересь.

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

Потому что в нем конструкторов нет, блин. Ты лучше скажи, чем это не finally?

>>виртуальную машину еще пилить и пилить

>ЕМНИП, там компиляция в нативный код.

Тьфу ты, не виртуальную машину а рантайм.

>> Потому что в нем конструкторов нет, блин.

Дык для реализации RAII коснтрукторы/деструкторы особо не нужны, вот в чем фишка.

> Дык для реализации RAII коснтрукторы/деструкторы особо не нужны, вот в чем фишка.

Я спросил, на что больше похожи with-блоки - на finally или на RAII в понимании Си++. Ты ответишь? Еще - где, кроме Си++, принят термин RAII?

>> Ты лучше скажи, чем это не finally?

Ну да, оно накручено вокруг finally (unwind-protect если быто точным), ну и что? Ресурсы освобождаются гарантированно и котролируемо при уничтожении объектов (если считать таковым выход из lexical scope) Захватываются при инициализации объектов. Какая нафиг разница как оно там внутри устроено?

> Ну да, оно накручено вокруг finally (unwind-protect если быто точным), ну и что?

Ну и всё. RAII - это попытка (не очень удачная) обойтись без finally.

> Какая нафиг разница как оно там внутри устроено?

Название RAII не подходит, всего-навсего.

>> Я спросил, на что больше похожи with-блоки - на finally или на RAII в понимании Си++. Ты ответишь? Еще - где, кроме Си++, принят термин RAII?

Похоже оно на finally, и что с того? То что в понимании с++ это должно работать как это работает там еще не значит, что оно там сделано единственно возможным способом. Блин ну че далеко ходить то, ООП а-ля С++ - яркий тому пример.

Хохохо!

Отличный вопрос!

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

Вот некоторые противопоставления:
1. Нативный код-виртуальная машина. В общем-то, честно сказать, я не вижу преимуществ виртуальных машин. На самом деле, они не дают преимуществ, кроме того, что якобы можно свалить проблемы переносимости на разработчика языка. Причём, эти проблемы можно свалить на разработчика и в случае нативного кода. При прочих равных рекомендуется нативный код, но в наше время это становится всё менее доступным.
2. Сборка мусора-явное управление памятью. Нужно знать и уметь работать с обоими вариантами. В основном, сборка мусора предпочтительна, кроме отдельных случаев. Хотя и у неё есть свои ловушки. Явное управление памятью необязательно означает явный delete и new. Это может быть и размещение на стеке и модель владения. Подсчёт ссылок я бы тоже отнёс к частному случаю явного управления. Впрочем, я с ним никогда не работал.
3. Динамизм-статичность. Динамизм хорош, чтобы подкрутить в рантайме работающую программу. Основные примеры динамизма - это операционная система (состоит из программ и скриптов, которые можно менять без остановки ОС), SQL сервера (состоит из таблиц, хранимых процедур и других объектов, к-рые можно менять без остановки сервера), Веб-сервера (контент меняется динамически), Common Lisp (многое можно менять без остановки лиспа), Python (что-то вроде можно менять, хотя я не знаток), clojure и наверняка ещё многие современные языки.

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

Продолжение следует...

Хохохохо (продолжение)

Из этого вытекает следующое противопоставление:
4. Динамическая-статическая типизация. Начиная с определённого масштаба, динамическая типизация должна быть допустима. Статическая типизация - это удел маленьких программ. Опять же, большинство тупиц этого не понимает. С другой стороны, статическая типизация придаёт программе надёжность и хорошо влияет на быстродействие. Влияние типизации на выразительность кода двояко. Динамическая типизация допускает больший полиморфизм, а статическая даёт контекст, в котором код становится более однозначным. Говоря по-Русски, мы иногда хотим сказать что-то конкретное, а иногда тяготеем к обобщениям. Нельзя сказать, что нужно всегда говорить конкретно и всегда общо. Нормальный язык должен давать обе возможности. В реальности я считаю практичным компромисс, когда типы могут генерироваться как в статике, так и в рантайме, при этом существуют "коробочки", дающие возможность хранить информацию о типе вместе с объектом, получая нужную степень полиморфизма там, где это действительно нужно. Я знаю только один язык, который полноценно реализует эту возможность - это SQL.
Также есть ещё одна очень важная вещь - возможность полиморфной инициализации. В С и подобных языках нужно сначала задекларировать тип переменной. Хотя можно вместо этого принять некие соглашения, позволящие писать polymorphicArray x = {1,"sdfasdf",new foo())}
Это - большое ограничение на С- образные языки, которое мешает в работе. Нужно изучить другие языки, чтобы понять, что это ограничение излишне. Например, в Object Pascal есть open array. Ну, я уже не говорю про Лисп...

5. Изменяемые-неизменяемые данные и сюда же относится транзакционность. Чисто функциональные языки пытаются работать со структурами, которые можно только создать, но нельзя редактировать. Многие среды поддерживают транзакции как способ обезпечения атомарности и обратимости операций. Оба эти подхода более-менее полезны (особенно, транзакции). Но они имеют ограничения. Наша жизнь необратима. Мы живём и совершаем поступки в условиях неопределённости, которые влияют на всю дальнейшую судьбу. Модель вычислительной чистоты неадекватна для решения задач реального мира. Она имеет право на существование в определённых областях (их не очень много), но должны быть предоставлены средства, чтобы разграничить её от императивной части, при этом, не осложняя жизнь. В этом смысле, Хаскель является очень пагубной и опасной религией, которая провозглашает, что чистые вычисления лучше необратимых действий. И вводит наказание за необратимые действия. Это - бред. Как и обычно бывает в религиях, у входа стоит мужик с дубиной, который "проверяет" всех приходящих на конформизм. После того, как ты прошёл через этого мужика, дальше всё может казаться стройным и логичным. Т.е., основная ложь любой религии кроется в самых её основах. Это имеет отношение и к Хаскелю. В роли мужика выступают старослужащие (что естественно), в роли дубины - понятие монады. Это понятие целенаправленно запутано, чтобы шокировать новичка. При этом, общий смысл понятия состоит всего лишь в лицемерном скрытии императива. В общем, я бы оценил Хаскель как достаточно грамотно сконструированную секту, хотя я бывал в сектах и покруче. Модель транзакций всё же адекватна жизни, причём есть многоверсионная модель и модель, основанная на блокировках. По правде говоря, мне ближе вторая, хотя не все со мной согласятся.

ещё продолжение будет...

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

6. Потоки выполнения (нити, процессы). Некоторые языки обладают врождёнными средствами параллельности (SQL, Java, clojure, Erlang). Это не моя сильная сторона, поэтому я промолчу. Однако нужно иметь представление о разных путях обезпечения параллельности. Я только скажу, что стремление выработать "общие" механизмы приводит к извращениям. Пример тому - популярность MYSQL. MYSQL использует блокировки таблиц, которые считаются не Ъ, однако, он популярен. Программировать с мультиверсионными транзакциями иногда оказывыется труднее, хотя вроде бы они представляют из себя более Ъ механизм.

7. Пространства имён. Эта идея довольно тривиальна, но она критично важна для достижения приемлемой производительности труда при программировании в больших масштабах. Один из ключевых недостатков Common Lisp (из-за которых я его не рекомендую) - это плохой дизайн пространств имён. Примеры хорошего дизайна - SQL и Pascal. С++ вроде тоже ничего.

8. ООП. ООП - это одна из вредоносных концепций. Полезного в ней - это структурирование программной среды. Когда код и данные принадлежат классам, это структурирует пространство имён. Фактически, каждый класс задаёт пространство имён и это позволяет структурировать программу. У этого подхода есть альтрнатива - организовать сущности в дерево. Первый тому пример - это файловая система. Второй пример - tcl.

Полиморфизм - это тоже хорошая идея, но она отвартительно реализована в С++. Java с наследованием интерфейсов в этом плане лучше. Наследование - это самая вредоносная из всех идей ООП, особенно, когда она сочитается с ограничением доступа к данным объекта. Также есть другой смысл ООП - представление программы в виде набора объектов, обменивающихся сообщениями. Я не преуспел в этом и мне эта парадигма не близка. Проблема тут - в том, что такой подход размазывает ответственность за правильность поведения между объектами. Объекты, по идеологии должны быть отдельными, но функционирование системы зависит от их взаимодействия. С моей точки зрения, многопоточное императивное программирование более плодотворно.

9. Сериализация. Хороший язык должен представлять средства для непринуждённого ввода-вывода данных. В этом плане С/С++ - это вообще полный мрак. XML - это ущербный формат, который плохо читается и человеком, и машиной. Более-менее пригоден json. Здесь я рекомендую изучить ввод-вывод списков, векторов, структур в Common Lisp. Это - одна из самых сильных сторон этого языка.

10. Метапрограммирование. Метапрограммирование содержит, как минимум, следующие состовляющие: - задача порождения кода - задача анализа кода - декларативное программирование - модификация процесса компиляции - рефлексия времени выполнения

Хрестоматийный пример реализации первого подхода - Common Lisp. Хотя я бы для изучения этого подхода рекомендовал изучить shell и m4 - те же идеи, но в более доступной и полезной для жизни форме. Примером низкоуровневой реализации этого подхода является Forth. Также массированная генерация кода происходит в веб-фреймворках, правда, тут нет ясности проявления идеи, потому что используется много разных языков. Красивым всё это было бы, если бы использовался лиспо-образный язык, обладающий одинаковым представлением. Т.е., если бы можно было заменить PHP, Javascript и html одним единым языком. Лисп, кстати, подходит для этого.

Может быть, для иллюстрации идей МП неплох php, хотя я его не знаю совсем. В принципе, код нормально генерируется на любом языке, у которого строковые константы могут переноситься на следующую строку и у которого есть полиморфизм параметров функции. С и Pascal не обладают такой возможностью и это просто уё.....

Пример де-факто стандартов как не надо генерить код - это cpp (препроцессор С и С++) и шаблоны С++.

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

Пример расширяемого компилятора я знаю только один - Common Lisp. Он совершенен в том отношении, что при этом генерит ещё и быстрый нативный код.

Основные примеры декларативных языков, используемых в промышленности - это SQL и make. Можно делать декларативные языки на чём угодно (для этого нужна всего лишь возможность генерировать код). Декларативный язык времени выполнения реализуется сложнее - требуется динамичность среды выполнения. Однако, это возможно в рамках динамичных сред, таких, как операционная система, веб-приложение, Java-машина или sql сервер.

11. Компоновка с внешними программами. Это не моя сильная сторона. Самое красивое, что я здесь видел - это встраивание OLE Automation в Delphi. В Visual Basic, видимо, встраивается ещё красивее. Одно только рекомендую: не пытаться линковать библиотеки, написанные на С++. Их не так уж много, чтобы ради этого так мучаться. Хотя в принципе, для этого есть SWIG.

12. ФП. Основная идея ФП - это замыкание. В принципе, замыкания возможны в любых языках, вопрос только в том, удобно ли это будет как синтаксис. Но идею знать нужно.

Ну и в итоге - рекомендации (из того, что знаю или в чём уверен) Рекомендую следующие языки для изучения соответствующих аспектов: - SQL (динамическая среда, декларативный язык, реляционный язык, транзакции, исключения, пр-ва имён таблиц в запросах) - clojure (почти идеальный язык на хорошей платформе. Очень много полезного, но не увлекаться "чистотой") - javascript (замыкания, ООП в виде простой иллюстрации) - shell,m4 (генерация кода в кристально чистом виде) - object pascal (прагматичный язык для промышленной разработки. open array, наследование интерфейсов, variants, ole automation, обработка исключений, модульность. Увы, нехватка макросов приводит к большим напрягам) - C (longjmp) - java (МП как анализ кода) - swig (для несчастных, которые захотят биндить библиотеки не С++) - php (прагматичный скриптовый язык для общего развития, хотя я его не знаю)

Не рекомендую: С++ (неудачная идея и реализация). В С++ есть только одна хорошая вещь - это возможность защищать ресурсы при раскрутке стека, создавая объекты на стеке. Однако, эта возможность легко достигается в любом расширяемом языке. Достаточно иметь нормальный макропроцессор. Haskell (слишком сектантский) Common Lisp (заменить на clojure). Т.е., выучить Commmon Lisp стоит, но не стоит на нём работать. Хотя я сам его использую и может быть, мне просто кажется, что он такой плохой :)

Ну и ещё, наверное, я рекомендовал бы к изучению Erlang...

Из частоты приведения Коммон Лиспа в пример в твоем монументальном, так сказать, труде, я делаю вывод, что, по твоему мнению, Коммон Лисп - это где-то очень близко к идеалу. На столько близко, что на основе его идеологии конфетка делается весьма легко (Clojure) :)

Хотя мне лично не нравится его базирование на jvm. Вот наверняка же у любого языка на jvm ограничения будут ограничения самой jvm.

>> 8. ООП. ООП - это одна из вредоносных концепций. Полезного в ней - это структурирование программной среды. Когда код и данные принадлежат классам, это структурирует пространство имён. Фактически, каждый класс задаёт пространство имён и это позволяет структурировать программу.

Вот я как в воду глядел... А с чего ты взял, что ООП вообще как-то завязано на пространства имен? Модель, когда методы принадлежат объектам, несмотря на то, что она наиболее распространенная, не является единственной. Вот ты все про CL пишешь - ну и посмотри на CLOS.

>> 12. ФП. Основная идея ФП - это замыкание. В принципе, замыкания возможны в любых языках, вопрос только в том, удобно ли это будет как синтаксис. Но идею знать нужно.

Основная идея ФП не в замыканиях, а отсутствии побочных эффектов, а замыкания, higher-order функции и проч. - это уже рющечки.

>> Один из ключевых недостатков Common Lisp (из-за которых я его не рекомендую) - это плохой дизайн пространств имён

А поконкретнее можно?

>> Один из ключевых недостатков Common Lisp (из-за которых я его не рекомендую) - это плохой дизайн пространств имён

> А поконкретнее можно?

Достаточно прочитать хотя бы в одной книжке, как в CL реализованы пакеты.

>> 5. Изменяемые-неизменяемые данные и сюда же относится транзакционность [...]

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

>> Достаточно прочитать хотя бы в одной книжке, как в CL реализованы пакеты.

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

>> Хотя мне лично не нравится его базирование на jvm. Вот наверняка же у любого языка на jvm ограничения будут ограничения самой jvm

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

> По крайней мере в том, что он растет из jvm есть одно неоспоримое преимущество: огромная жабовская библиотека на все случаи жизни.

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

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

а лишняя математизированность - это как? где граница нелишнести?

> Ты не мудри ты пальцем покажи, что там плохо реализовано.

namespace a { namespace b { abc; namespace c { ... stuff ... }}}

a::b::c::stuff->something(a::b::abc);

Сделай такое в CL.

> а лишняя математизированность - это как? где граница нелишнести?

Как всегда, основным критерием выступает достаточность. Для забивания мебельного гвоздя достаточно среднего размера молотка, копёр здесь не нужен. У нас в городе ПТУ готовят каких-то программистов, которые где-то реально на каких-нибудь Делфях пишут программы. Значит, они востребованы. Но Хаскелль не в каждую голову с высшим образованием влезет, что про ПТУ говорить.

>> Сделай такое в CL.

Т.е. основная претензия - это то, что в лиспе нет вложенных пакетов? А какой в этом смысл? Ну предположим можно организовать некую иераррхию пакетов\пространств имен. Ну дык это можно и без вложенных пространств сделать воспользовавшись некими правилами именования пакетов, например (a#b#c::foo f#e::bar). Единственное, что остается это, как в втоем примере, доступность "abc" из пространства "c", ну дык с учетом naming conventions выглядит вот так:

(defpackage a#b#c
(:use a#b))

Совсем маленький оверхед, но это работает. А вот чего нет в си++-ных наймспэйсах, так это, например, контроля того, что экспортируется из пространства.

>> а лишняя математизированность - это как? где граница нелишнести?

mv уже ответил, от себя добавлю, что такие вещи как теория категорий, о которой так любят упоминать в литературе по хаскелю, если и преподается, то на специальностях к программированию отношения не имеющих вообще. А обычному программеру, у которого курс ВМ закончился матаном, ни или дискреткой, про которую он вспоминает как страшный сон, вникать в абстратную математику ну совсем тяжко. Оно конечно может и не надо глубоко туда нырять, но чувство стойкого отвращения при первом знакомстве с языком будет обеспечено, особенно когда вместо привычного и понятного a=b, он увидит нечто со странным названием - монада. И что он скажет? "Ахренеть!"

>дискреткой, про которую он вспоминает как страшный сон

и кому он такой нужен?

>>дискреткой, про которую он вспоминает как страшный сон

>и кому он такой нужен?

Забытая дискретка не означает плохого прогера ;)

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

Если говорить именно о языке clojure как об очередном диалекте лиспа со своими нюансами синтаксиса и заложенными идеями (*), то да, согласен. А если говорить о функционале в виде уже готового кода из JavaSE/EE, ready to use, то не соглашусь.

(*) я в этом плане вообще не понимаю нафига нужны языки сделанные по принципу "с мира по нитке": возьмем чуть чуть из перла, чуть-чуть из смалтолка, чуть чуть из паскаля (алгола) - опа, получился руби. Скрестим Си с перлом - получился ПХП, ну и так далее в том же стиле. А как результат - море безидейных уродцев, рожденных от желания одного человека заиметь новый синтаксис со старой семантикой.

>Забытая дискретка не означает плохого прогера ;)

внезапно. а что же в таком случае означает?

>> Забытая дискретка не означает плохого прогера ;)

> внезапно. а что же в таком случае означает?

"Не пригодилась" (c)

>> и кому он такой нужен?

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

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

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

Чем глубже и сильнее теория, стоящая за программой, тем программа получается лучше и качественнее. Правда халатного отношения теория не терпит. Типичный пример -- оригинальные регэкспы и перловые(pcre). Напомнить разницу между ними? :)

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

верно.

следует ли из этого, что для написание _сложных_
задач они непременно пригодятся?

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

где я могу почитать про глубокую теорию, которая является
фундаментом, скажем, linux kernel?

> следует ли из этого, что для написание _сложных_ задач они непременно пригодятся?

Естественно нет. Зато в случае их использования мы получаем определенные стопудовые и заранее известные свойства программы. Разве это не достойный профит?

> где я могу почитать про глубокую теорию, которая является фундаментом, скажем, linux kernel?

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

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

Мозг прочищает и упорядочивает. Сильно.
К примеру, приходит понимание, что operator< не обязательно задаёт полный порядок; знак "плюс" означает не сложение чисел, а некоторую бинарную операцию; что отображение объектов на их хеш-коды не сюръективно и даже не инъективно и т.д.

> Мозг прочищает и упорядочивает. Сильно.

Где бы потом работу найти таким, с прочищенными мозгами? :)

>"Не пригодилась" (c)

ты вопроса не понял. что означает плохого прогера? какой критерий, если не знание той же дискретки?

> Т.е. основная претензия - это то, что в лиспе нет вложенных пакетов? А какой в этом смысл?

В С++ двухуровневая система исключений. А какой смысл в трёхуровневой? В Си нет понятия объекта, но в структуру можно ложить указатели на функции. Какой смысл тогда в отдельных понятиях класс и объект? В CL у elt первый параметр - последовательность, второй - индекс, а у более частного nth - наоборот. Ну и что? Подумаешь, проблема...

Продолжать можно бесконечно.

> Совсем маленький оверхед, но это работает.

Любой костыль нарушает стройность хода.

> А вот чего нет в си++-ных наймспэйсах, так это, например, контроля того, что экспортируется из пространства.

В плюсах по сравнению с Лиспом много чего нет, можно и не напоминать.