А... Я лихорадочно вспоминал протоколы обмена :) Пищалок, думаю, нет. Там какая-то плотная серверная упаковка этих нодов. Да и толку-то от пищалок, когда от вентиляции ничего не слышно

А вот если их много...))))
Ну ладно. Я просто думаю, где бы потестить мультинодовый аудиоплеер на mpi :)

LISP — это про синтаксис. Про reader + macroses VS parsers. Все. LISP, действительно, очень мощный, но относительно *синтаксиса*. Синтаксическая мощность никак (кроме как с точки зрения синтаксиса, конечно) не помогает тебе в имплементации ООП. Вот и все, а дальше языки с LISP синтаксисом имеют совершенно разные ограничения.

В LFE — мутабельность возможна только в рамках эктора (ООП в чистом виде, к слову), clojure тоже возводит вопрос иммутабельности в абсолют и разрешает ее только в рамках atom и STM, scheme и CL пытаются дать мощность не только синтаксическую, но и рантаймовую, но это не про LISP на самом деле.

Мне кажется, автор слишком сгустил краски. Да, тут типичный случай "сектантского" ЯП, и та же ситуация, например, имеет место в Форте. При этом и сам язык ведь влияет на поведение разработчиков, действительно провоцирует поведение "фрика". Никто бы не стал возиться в очередной раз с бесконечными реализациями ООП, ПМ или ленивыми вычислениями, если бы эти реализации были тривиальными, в этом ведь нет спортивного интереса.

Но самое лучшее, что случилось с Лиспом -- появление Scheme. И дело не конкретно в Scheme, а в том, что Стил и другие авторы показали путь развития Лиспа -- с помощью переосмысления прошлого и на основе создания новых, более изящных и выразительных лисп-подобных языков. Без Scheme не было бы упора метаязыковую абстракцию, языково-ориентированное программирование, не было бы компиляторной школы Стила, Дибвига и других, не было бы Nanopass и PLT Redex. Все это, утрируя, сделали отнюдь не ретрограды -- любители лисп-машин, любители писать все исключительно в S-expr, любители Common Lisp и Emacs.

А я вот одновременно и люблю лисп как программист, и терпеть не могу лисп как читатель чужого кода :-)

Петр, вы иногда меня прям удивляете :-) ну то есть я люблю лиспы, и особенно схему, и особенно работу Дибвига, но то я, у меня от емакса руки и мозг  давно сломались!

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

Ну... Это вообще особое искусство. Да ладно... Чего уж там. Нам вон притащили новые узлы в кластер, так там через MPI и Infiniband память копируется быстрее, чем через memcpy. И как с этим жить?

там подстановка страниц в разные адреса, и copy-on-write через DMA работает?

А что я такого сказал? :) Не вижу пока что предмета спора :)

По поводу синтаксиса: думаю речь о том, что дубовый скобочный синтаксис позволяет работать лисповым макросам: ведь это фактически AST- преобразовали, а когда исходный код программы и AST - считай одно и тоже, писать такие преобразователи просто. К примеру в Java и или C# нужно знать API для reflection. В Scala макросы это вообще пользовательские callback-и, которые  вызываются компилятом. А вот в lisp для написания макроса достаточно знания того что такое s-expression, ну и сам lisp.

Дело не только в макросах, а в том, что практически произвольная семантическая конструкция легко вписывается в синтаксис (точнее в его отсутствие). Чтобы воткнуть конструкцию в Scala надо очень крепко задуматься о том, как она будет взаимодействовать с другим синтаксисом, а в Lisp это делается, "не приходя в сознание".

Плохо это или хорошо - не знаю. Мы платим за это скобками. Но это точно быстро и эффективно во многих случаях.

Я о том и говорю  что синтаксис в лиспах простейший, а семантика гибкая, за что их и любят (и ненавидят) :-)

В широких пределах, семантику можно гнуть подобным же образом почти во всех динамических языках, отчего и говорят про "Python/Ruby/etc. is a viable Lisp" (про Python ляпнул Норвиг).
Проблема в том, что только очень малое подмножество возможных семантик делает что-то полезное и понятное, да ещё и так чтобы не ломать уже имеющуюся семантику. Поэтому расширять язык реально новыми семантическими кострукциями реально сложно. Если это сделать легко (в смысле "approachable" что не уменьшает внутренней сложности вопроса) - это приводит только к повсеместному распространению неудачных расширений. На что, по сути, и жаловался автор упомянутого блог-поста.

В этой связи забавно было прочитать его характеристику системы типов Qi как более мощной, чем у Haskell, поскольку она Тьюринг-полная. Эта самая "толпа академиков", разрабатывающих Haskell тем и занимается, чтобы придумывать как бы не сделать систему типов Тьюринг-полной. 😃
Оно, конечно, широко известно, что с задачей они не справились, но это говорит о сложности задаче, а не о недостатке квалификации "академиков". 😂