clojure после common lisp - насколько омерзительно и в чём именно?

всё-таки не соглашусь, что типизация бесполезна при наличии контрактов.

Я, кстати, нигде не утверждал, что она бесполезна (в целом). А говорил о том, что в том виде, в котором она присутствует в большинстве статически типизированных языков (включая раст) это плохой подход к типизации, который помогает в ограниченном классе случаев (3%, в основном про опечатки, сложение енотов с калькуляторами) и мешает в остальных 97% - не позволяет быстро прототипировать в парадигме алгоритмов, а не типов. И дает ложные иллюзии проверки типов по смыслу (на самом деле нет). Ну раст это хотя бы низкоуровневый язык, заменитель С++ типы тут оправданы хотя бы для производительности, а раз они уже есть, то уже лучше пусть будут такими как есть, чем как в С++.

«Продакшен» всё-таки не стоит на месте. На мой взгляд, мейнстримные языки вполне себе развиваются в правильную сторону (ну кроме Go), пусть и медленно.

Да, давайте еще 60 лет подождем. Вместо того, чтобы прямо сейчас использовать нормальные инструменты. Но зачем? А если мы возьмем ситуацию 10 лет назад, а это было совсем недавно - там тоже рассказывали о том, что «все движется, просто медленно», вот подождите новой версии java, C#, C++ и будет счастье. Или хайп на хаскель, который заменит С++. Но оно все не наступает и не наступает :)

Думаю, что интерес к более мощным системам типов будет рости. Ну посмотрим со временем.

В racket и clojure контрактам более ~10 лет, в Common Lisp лет 30 можно писать в контрактном стиле.

Хаскелю уже 30 лет, Coq 30 лет, Idris и Agda лет 14 - это в контектсе их популярности в мейнстриме. Но мы конечно «посмотрим со временем».

В статических языках весь этот процесс - адский ад.

Наоборот.

Сильный аргумент, ниче не скажешь.

А чем по-твоему является Rust как не С++ с немного измененным синтаксисом «обложенный анализаторами, санитайзерами и прочими верификаторами»?

По-моему, тут количество переходит в качество.

Красивая, но пустая фраза из серии «каждый прав по-своему». Выше ты указывал на то, что это якобы «совсем не так»:

На мой взгляд это звучит так же убедительно как заверения, что если С/С++ обложить статическими анализаторами, санитайзерами и т.д., то результат ничем не будет отличаться от раста. Вроде да, но нет.

Но раст это и есть С++ обложенный санитайзерами и анализаторами с немного измененным _синтаксисом_, и это его *единственное* ключевое отличие от.

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

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

С типами (и чем они строже, тем проще) мне всё понятно: изменяем тип, получаем список мест, которые надо поправить.

Угу. Причём 99% этих мест не меняют алгоритм, их просто так приходится править. Вот поменял std::string на какой-нибудь vtkString и любо в куче мест преобразователи, либо по всему проекту занимаешься заменой.

Александреску это так задолбало, что он придумал шаблон со стратегиями и призывал все реальные типы выносить в параметры шаблона, чтобы замена double на long double не приводила к переписанию половины программы.

А если поменялись не просто типы, а их семантика (была температура в цельциях, а стала в кельвинах или результат начал требоваться с протоколом расчёта), то вообще всё печально. И ракеты падают.

А если поменялись не просто типы, а их семантика (была температура в цельциях, а стала в кельвинах или результат начал требоваться с протоколом расчёта), то вообще всё печально. И ракеты падают

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

поменял std::string на какой-нибудь vtkString и любо в куче мест преобразователи, либо по всему проекту занимаешься заменой.

Этим сейчас по-идее ide занимаются, нет?

А если поменялись не просто типы, а их семантика (была температура в цельциях, а стала в кельвинах или результат начал требоваться с протоколом расчёта)

Это уже хуже, но самое плохое - это прототипирование самого алгоритма и интерфейсов, статика тут вообще убивает.

Этим сейчас по-идее ide занимаются, нет?

А как это выглядит? Я меняю в одном месте тип переменной, а IDE каскадом меняет тип у всех функций, где она используется и у всех переменных, которые передаются в эти функции?

А как это выглядит? Я меняю в одном месте тип переменной, а IDE каскадом меняет тип у всех функций, где она используется

Скорее, меняет тип параметров в ф-циях, в которые передается эта переменная в качестве параметра. Но, на сколько я понимаю, делается это не автоматически, а ты так же прыгаешь по исходникам и подтверждаешь, что «да, тут вот так вот можно изменить», просто не с помощью ctrl+f. Иначе ide может заменить и что-то лишнее. Допустим, ты изменил тип переменных и в _части_ использующих эту переменную ф-ция надо изменить сигнатуру, другая же часть ф-ций должна остаться со старой сигнатурой, т.к. теперь будет, например, использовать другую переменную с предыдущим типом. Если заменять это все автоматом - получится хуже, чем если не заменять вообще. Поэтому замена, как я понимаю, идет в полуручном режиме - ide дает тебе возможность быстро бегать по коду, и показывает, что еще потенциально осталось для замены - маркирует «заменили / оставили как есть» и копипастит за тебя, чтоб не удалять руками старый тип и набирать новый.

и у всех переменных, которые передаются в эти функции?

Если я выше ответил на этот вопрос, тогда я не понял про «меняет тип у всех функций, где она используется» - имеется ввиду меняет тип результата, возвращаемого ф-цией, использующей переменную с новым типом или что-то другое? Под рукой сейчас нет ide для статических языков, но я что-то подобное видел, и уже достаточно давно, лет 7-10 назад. Возможно, кто-то из активных статикофанбоев расскажет здесь, как у них происходит рефакторинг.

На мой взгляд, мейнстримные языки вполне себе развиваются в правильную сторону (ну кроме Go), пусть и медленно.

Еще вопрос к этому веселому тезису - почему сейчас хайп на раст, а не на, казалось бы, Idris или любой другой статически типизированный язык с зависимыми типами, допустим, без сборщика мусора (если вопрос именно в этом и нам нужен низкоуровневый статический язык)? Что правильного в этом «развитии»?

ide дает тебе возможность быстро бегать по коду

Ну кнопка «перейти на все использования переменной» у меня и в Racket есть.

Ну кнопка «перейти на все использования переменной» у меня и в Racket есть.

Разница все же есть, во-первых у тебя в разных файлах переменные могут называться одинаково, не всегда есть возможность узнать что это та же переменная, а не какая-то другая. В статике у тебя дополнительный маркер это тип. То есть переменные с одинаковыми именами, но разными типами - это разные переменные. А с остальным да, придется разбираться. В изначальном ответе я всего лишь указал, что в части случаев ide решает некоторые из них.

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

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

То есть переменные с одинаковыми именами, но разными типами - это разные переменные.

А с одинаковыми типами - одинаковые? Не понял.

В

void f()
{
   int x;
...
}

void g()
{
   int x;
...
}

Если я x в f тип сменю, то у x в g он тоже сменится?

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

Это в Dr. Racket? Т.е. при открытии каждого файла там уже происходит статический анализ, какие имена чему принадлежат и при изменении исходников перестраиваются графы зависимостей, лексические привязки? Если в файле явно импортируется модуль и из нее переменная - тут да, проблем по-идее быть не должно. Реализовано оно нормально или как - уже другой вопрос. А, если у тебя файл в котором условно «набор команд» (и все в палидных схема-секспах), которые подставляются при выполнении в другой файл. И имена специально совпадают с другими переменными. То есть такой вариант пользовательского ввода - только у тебя есть возможность просмотреть исходник заранее. Но однозначно там ничего не привязано к конкретным модулям, а следовательно однозначно сказать что переменная in-my-namespace/var и var это одна и та же сказать нельзя. Случай утрированный, но тем не менее.

То есть переменные с одинаковыми именами, но разными типами - это разные переменные.

А с одинаковыми типами - одинаковые? Не понял.

Нет, вроде бы из написанного мной это не следовало.

Это в Dr. Racket? Т.е. при открытии каждого файла там уже происходит статический анализ, какие имена чему принадлежат и при изменении исходников перестраиваются графы зависимостей, лексические привязки?

Да. Включая раскрытие макросов.

А, если у тебя файл в котором условно «набор команд» (и все в палидных схема-секспах)

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

которые подставляются при выполнении в другой файл

Что значит «подставляются»? Как в сишном #include ? Есть racket/include, но с точки зрения языка и DrRacket это обычный макрос и раскрытие даёт привязку к переменным. Да. править менее удобно, так как привязка закончится на (include «myinclude.inc»), а этот myinclude.inc придётся править вручную посматривая в Macro Stepper.

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

Теоретически можно сделать непросматриваемую привязку через eval. Или через извращения типа namespace-variable-value. Но если такое пишешь, обычно знаешь где и зачем. Также как если вдруг используешь include вместо нормального require.

Нет, вроде бы из написанного мной это не следовало.

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

Как в сишном #include ?

Да, типа того.

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

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

А ты, кстати, используешь dr.racket, а не emacs+geiser (или что там сейчас более актуальное) для ракеты? Почему?

А ты, кстати, используешь dr.racket, а не emacs+geiser (или что там сейчас более актуальное) для ракеты? Почему?

Привык к DrRacket’овским стрелочкам. По ссылке https://quares.ru/?id=613286 можно снимки посмотреть. И при ошибке наглядно видно: http://1.bp.blogspot.com/-wd_Z2kejSA4/TrqKRYBLY7I/AAAAAAAADIs/oRKNhLfC0pU/s1600/racketError.png

Хотя в geiser более адекватное автодополнение. И запускается шустрее.

Потому Rust — это единственный подающий надежды язык, однако же, его будущее неясно.

Кстати, к Java тоже прикрутили макросы плагином компилятора: https://github.com/manifold-systems/manifold. И к Scala тоже: https://docs.scala-lang.org/overviews/macros/overview.html. Их-то, думаю, в мёртвые не запишешь.

а не на, казалось бы, Idris […] без сборщика мусора

Idris как раз со сборщиком мусора. Кроме того, Idris – экспериментальный язык.

или любой другой статически типизированный язык с зависимыми типами, допустим, без сборщика мусора

Пока что получился С++, а не Rust.

почему сейчас хайп на раст

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

Кстати, к Java тоже прикрутили макросы плагином компилятора: https://github.com/manifold-systems/manifold. И к Scala тоже: https://docs.scala-lang.org/overviews/macros/overview.html. Их-то, думаю, в мёртвые не запишешь

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

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

Как точка зрения и личное мнение может быть верно. Как абсолютная истина - спорно.

Я спорю с тезисом «все языки с буйным метапрограммированием провалились».

Idris как раз со сборщиком мусора. Кроме того, Idris – экспериментальный язык.

А я о чем написал? Что сделали бы лучше Idris без сборщика.

или любой другой статически типизированный язык с зависимыми типами, допустим, без сборщика мусора

Пока что получился С++, а не Rust.

В С++ появились зависимые типы?

В С++ появились зависимые типы?

Если очень хочется…

https://www.reddit.com/r/cpp/comments/ccoq4z/dependent_types_in_c/

А говорил о том, что в том виде, в котором она присутствует в большинстве статически типизированных языков (включая раст) это плохой подход к типизации, который помогает в ограниченном классе случаев

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

Вместо того, чтобы прямо сейчас использовать нормальные инструменты.

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

Но мы конечно «посмотрим со временем».

Не понимаю к чему ты. Сказать хотел, что даже инертный и консервативный мейнстрим развивается. Кстати, хаскель сейчас и хаскель 30 лет назад - это примерно как С++ тогда и сейчас сравнить. Idris 2 тоже появился довольно недавно.

Но раст это и есть С++ обложенный санитайзерами и анализаторами с немного измененным синтаксисом, и это его единственное ключевое отличие от.

Ну если ты так говоришь, то конечно.

Причём 99% этих мест не меняют алгоритм, их просто так приходится править.

Не согласен насчёт процента, но не суть: для этого есть инструменты и нормальная IDE позволит сделать это переименование «в один клик».

А если поменялись не просто типы, а их семантика (была температура в цельциях, а стала в кельвинах или результат начал требоваться с протоколом расчёта), то вообще всё печально.

И в чём печаль? По моему, наоборот всё прекрасно (если типы расставлены с умом).

И ракеты падают.

А как это к типам относится-то? Давай для убедительности ещё кинь ссылку на Therac-25 и прочие «программные катастрофы».

нормальная IDE позволит сделать это переименование «в один клик».

Но как?

Если у меня был std::string s, и вызов f(s), а потом стал vtkString s, то возможно надо поменять тип f (и всех переменных, которые в неё попадают), возможно надо заменить f(s), на f(s.to_string()), возможно надо разделать f на две функции с разными типами (которые возможно надо сделать шаблоном, чтобы не копипастить). И так для каждого конфликта типов. Как IDE угадает, что в каком случае надо сделать «в один клик»?

По моему, наоборот всё прекрасно (если типы расставлены с умом).

double temperature;. И надо найти все функции, где double подразумевает температуру в цельсиях.

А как это к типам относится-то?

Там на преобразовании типов залёт произошёл.

для убедительности ещё кинь ссылку на Therac-25

То для любителей асинхронных микросервисов хороший пример.

статически типизированных языков (включая раст) это плохой подход к типизации, который помогает в ограниченном классе случаев

спорить не вижу смысла, потому что это всё равно у нас почему-то получается «типы отстой - нет динамика отстой».

Да нет, весь тред полон аргументами, просто ты их игнорируешь.

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

Сказать это одно, плохо что понять это для блаба сложно (невозможно).

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

Со скоростью черепахи, в то время как нормальные языки продакшн риди уже лет по 20 минимум, а то и по 30. CL за последние 10 лет особо не изменился даже в плане инфраструктуры, уже был и quicklisp, и гитхаб с либами, ide и все что ты захочешь. Но ты топишь за блаб-мейнстрим. Это не развитие.

Кстати, хаскель сейчас и хаскель 30 лет назад - это примерно как С++ тогда и сейчас сравнить.

Конечно же нет. Но ты можешь взять любой другой отрезок времени 10-15 лет. И никакой даже мнимой «такой» разницы уже не будет.

Idris 2 тоже появился довольно недавно.

Им все равно никто не пользуется, ни первым, ни вторым. А python 3.9 тоже недавно появился, но при чем тут это.

Но раст это и есть С++ обложенный санитайзерами и анализаторами с немного измененным синтаксисом

Ну если ты так говоришь, то конечно.

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

Если у меня был std::string s, и вызов f(s), а потом стал vtkString s, то возможно надо поменять тип f (и всех переменных, которые в неё попадают)

Там и методы могут по-разному называться у stings vs vtkString и придется менять сам алгоритм (если нет эквивалентных методов, а их не будет).

возможно надо заменить f(s), на f(s.to_string()), возможно надо разделать f на две функции с разными типами (которые возможно надо сделать шаблоном, чтобы не копипастить).

Никак такое не рефакторится «в один клик».

И так для каждого конфликта типов. Как IDE угадает, что в каком случае надо сделать «в один клик»?

В один клик там не будет, это сказки венского леса - в лучшем случае будет так, как я описывал выше.

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

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

CL для крупных проектов не очень хорош, так как нет изоляции модулей. Можно просто случайно запороть функцию или глобальную переменную из соседнего модуля из-за совпадения имён или неаккуратно уточнённого defmethod. Причём, если её сам не используешь, то даже ничего не заметишь. А заметят только программисты, которые используют твой модуль: если использовать отдельно библиотеку foo, то всё работает, а если совместно foo и bar, то foo адски глючит.

Кроме того, в CLOS отсутствует принцип единой ответственности разработчика за единицу кода. То есть, если какой-то метод глючит, то надо сначала найти, тело метода из какого модуля запустилось. И если авторы разных модулей чуть-чуть по разному понимают семантику метода, то всё совсем печально.

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

Так я же написал «если очень хочется». Зависимые типы вообще имеют очень ограниченную область полезности. Думаю, поэтому Idris и не очень популярен.

Зависимые типы вообще имеют очень ограниченную область полезности.

Зачем нужен статический язык без зависимых типов?

Думаю, поэтому Idris и не очень популярен

А не по тем ли причинам, что это все еще почти хаскель, только еще сложнее?

Условный раст только с зависимыми типами, имхо, взлетел бы на ура.

Что правильного в этом «развитии»?

Речь шла о «правильном на мой взгляд». Правильность в том, что раст - намного более удобный, выразительный и строго типизированный язык, чем С, на нишу которого он претендует.

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

или любой другой статически типизированный язык с зависимыми типами, допустим, без сборщика мусора

А такие есть?..

Кроме того, Idris – экспериментальный язык.

А это официальная позиция или «экспериментальный потому что на нём (пока) никто особо не пишет»? И есть ли у эксперимента конкретная (или лучше - конечная) цель?

Если что, я не придираюсь, а правда интересно. В хаскеле, вроде как, достаточный груз костылей накопился, почему бы и не «исправить» это всё в новом языке. Понятное дело, у хаскеля есть библиотеки, но если есть комьюнити, то это дело поправимое.

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

Так его не с С надо сравнивать, а с С++, да он удобнее в мелочах. Но на этом все.

На вершине популярности находятся С, джава и C#, а значит никаких подвижек нет или что?

Ну есть наверное, там на 0,001%

или любой другой статически типизированный язык с зависимыми типами, допустим, без сборщика мусора

А такие есть?..

Нет, потому что все усилия в развитии языков уходят в свисток (раст, go, D, Nim etc)

Зачем нужен статический язык без зависимых типов?

Для статической проверки простых инвариантов. И для скорости скомпилированной программы.

А не по тем ли причинам, что это все еще почти хаскель, только еще сложнее?

Есть ATS.

sortdef nat = {a: int | a >= 0 }
typedef String = [a:nat] string(a)
fun {a:t@ype}
  list_split {n:int}{k:nat | k <= n}
  (xs: list(a, n), k: int(k)) : (list(a, k), list(a, n-k))

Почти rust. С зависимыми типами, доказательством программ, скоростью как у Си.

Условный раст только с зависимыми типами, имхо, взлетел бы на ура.

Тогда почему не взлетел ATS?

Но как?

Да, ты прав, с «одним кликом» я погорячился.

double temperature;. И надо найти все функции, где double подразумевает температуру в цельсиях.

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

Там на преобразовании типов залёт произошёл.

Не согласен, что виноваты типы. Если ты строку «лор» в число попробуешь преобразовать и получишь ошибку, то этo тоже типы виноваты?

Условный раст только с зависимыми типами, имхо, взлетел бы на ура.

Тогда почему не взлетел ATS?

Не знаком с этим языком, возможно, там есть подводные камни (помимо отсутствия библиотек и поддержки какой-нибудь корпорацией). А чем он хуже раста?

Если есть такой код и он работает с температурами представленными в разных единицах измерения

Так не работает с разными. Просто в определённый момент решили изменить представление.

когда преимущество типизации не используется

А используется - это так

class Person
{
  tName name;
  tSurname surname;
  tEmail email;
  tLogin login;
  tBirthDate birthDate;
  ...
}

?

Если ты строку «лор» в число попробуешь преобразовать и получишь ошибку, то этo тоже типы виноваты?

Так там типы были виноваты именно в том, что ошибка не получилась. А вместо этого произошло преобразование в мусор. То есть если (+ "лор" 69) выдаст ошибку, это правильно. А если в ответе будет 42, то это ужас-ужас.

А чем он хуже раста?

Нет лайфтаймов.

Но ты топишь за блаб-мейнстрим. Это не развитие.

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

Опять же, пишу я на расте. Ты серьёзно предлагаешь вместо С и С++ взять Common Lisp?.. Всерьёз меня именно эта ниша интересует.

Им все равно никто не пользуется, ни первым, ни вторым.

То есть, сначала ты приводишь язык в пример, а потом он оказывается не при чём.

Да нет, весь тред полон аргументами, просто ты их игнорируешь.

Aргументы такие аргументы.

Ты вечно выдёргиваешь какие-то отдельные фразы и начинаешь непонятно с чем спорить. Неприятно вести такое общение, можешь засчитывать слив.

там есть подводные камни (помимо отсутствия библиотек

Он в Си компилируется. Поэтому библиотеку туда можно почти любую воткнуть.

Так не работает с разными. Просто в определённый момент решили изменить представление.

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

А используется - это так

Зависит от. Может и так.

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

Это, я так понимаю, уже пошла racket-вкусовщина?

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

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

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

Это, как я понимаю, только в случае с непреднамеренным затиранием имени или что-то еще имеется ввиду?

Кроме того, в CLOS отсутствует принцип единой ответственности разработчика за единицу кода. То есть, если какой-то метод глючит, то надо сначала найти, тело метода из какого модуля запустилось.

А таких средств нету что ли, чтобы найти?

И если авторы разных модулей чуть-чуть по разному понимают семантику метода, то всё совсем печально.

Это пример о том, что кто-то не разобравшись в коде все сломал?

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

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

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

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

Поэтому прототипы пишут на чём-то типа питона и только когда архитектура застыла в граните, переписывают на Java или C++. Причём не столько ради проверки на ошибки (их уже проверили тестами), сколько ради производительности. И так было практически всегда.