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

В частности, в лиспе бида-бида с инфиксными операциями

Они тоже есть ещё с 1995 года. И тоже никому не интересны кроме неофитов

infix reader macro

Опять же, это не s-выражения, а значит это не лисп. Оно написано на лиспе, но это не лисп.

Оно перехватывает штатный REPL.

Так макросам в Common Lisp это позволено.

Оно написано на лиспе, но это не лисп.

Оно компилируется компилятором лиспа и подключается как библиотека.

У меня в Vue.js ошибка выдается на исходную строку кода.

А там разве JavaScript расширяется новыми операторами?

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

Везде, где в обычных языках приходится использовать копирование/вставку, её можно заменить макросом

Ты уверен, что копипаста нужна в тех языках, которые ты упрекаешь в онной?

это не s-выражения, а значит это не лисп.

Интересно, а выражения #(1 2 3) и #S(1 2) тоже «не лисп»?

Оно компилируется компилятором лиспа и подключается как библиотека

И на Си, и на JS ты можешь написать свой REPL и свой компилятор, и подключать его куда хочешь. Да, у Си сложный транслятор, да, JS браузеры потребляют только в виде исходных кодов — так ли страшен черт, как ты его рисуешь? Я же настаиваю на том, что менять DSL десять раз в день одновременно с разработкой программы на этом DSL — это симптом проблемы.

Интересно, а выражения #(1 2 3) и #S(1 2) тоже «не лисп»

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

Ты уверен, что копипаста нужна в тех языках, которые ты упрекаешь в онной?

Вот пример: https://github.com/notepad-plus-plus/notepad-plus-plus/blob/3cf65ade8198b02f26b652c99499d93b23d61179/PowerEditor/src/ScintillaComponent/UserDefineDialog.cpp#L201

С макросом было бы что-то вроде

withmacro send_all_dlg()
  {
    for(auto i : (CODE1, CODE2, COMMENT))
      for(auto j : (OPEN, MIDDLE, CLOSE))
        $$::SendDlgItemMessage(_hSelf, IDC_FOLDER_IN_$i_$j_EDIT,     WM_SETTEXT, 0, reinterpret_cast<LPARAM>(_pUserLang->_keywordLists[SCE_USER_KWLIST_FOLDERS_IN_$i_$j]));
  }
  { send_all_dlg(); }

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

На вкус и цвет… Я уже писал, что все попытки расширить синтаксис были непопулярны.

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

Потому что Emacs не осилили.

Вполне сбее запиливают новые ключевые слова, и используют трансляторы

То есть разработчиков движка теперь ждать не надо, надо ждать разработчиков транспайлера. Ну окей, чо.

Про Зарю не в курсе, а ВНИИНС (разработчик МСВС) это, внезапно, АО (хотя на их сайте этот факт зарыт максимально глубоко, но найти можно).

Похоже, поэтому у Зари разработчик Объединённая Приборостроительная Корпорация.

Вот пример: https://github.com/notepad-plus-plus/notepad-plus-plus/blob/3cf65ade8198b02f2...
С макросом было бы что-то вроде

Не вижу преимущества. В оригинальном коде мне сразу ясно, что и как делается. В твоем коде я должен понять семантику кодогенерации и развернуть ее в уме до исходного кода. Или же сделать macroexpand.

То есть разработчиков движка теперь ждать не надо, надо ждать разработчиков транспайлера. Ну окей, чо

Транспайлер можно и самому допилить, никто ведь не запрещает.

Транспайлер можно и самому допилить, никто ведь не запрещает.

И движок можно. Но макрос напейсать обычно проще.

Потому что класс-ориентированный C# вообще не похож на Nemerle.

Не согласен. В немерле вполне себе обычное ООП присутствует. Нет никаких проблем писать на языке как на «better C#».

И движок можно. Но макрос напейсать обычно проще

Допиливать движок = допиливать компилятор лиспа. А транспилятор достаточно туп, хоть и сложнее макросов, которые идут прямо из коробки и не требуют вообще никаких усилий для написания. Однако же, на прогнутом под макросы языке сложнее писать, а преимуществом упрощенного написания макросов злоупотребляют, что особенно вредит низкоквалифицированным кодерам — за это индустрия и похоронила лисп.

Не согласен. В немерле вполне себе обычное ООП присутствует. Нет никаких проблем писать на языке как на «better C#»

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

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

При заполнении массивов ты тоже пишешь

a[1][5] = f(1,5);
a[2][5] = f(2,5);
a[3][5] = f(3,5);
a[1][6] = f(1,6);
a[2][6] = f(2,6);
a[3][6] = f(3,6);
a[1][7] = f(1,7);
a[2][7] = f(2,7);
a[3][7] = f(3,7);

вместо

for(int i=1; i<=3; i++)
  for(int j=5; i<=7; i++)
    a[i][j] = f(i,j);

?

Ведь во втором случае надо «понять семантику кода и развернуть ее в уме до исходного кода». И даже macroexpand’а нет (разве что пошаговым отладчиком с трассировкой).

за это индустрия и похоронила лисп

Не за это. А за маркетинговый идиотизм производителей Lisp Machines, низкую производительность программ на лиспе на широко используемых машинах (SBCL тогда не было) и AI Winter.

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

Вот повсеместно распространённый Си:

Что делает строка

ap->amlist = sp;

в https://github.com/IanHarvey/pcc/blob/05a6d549952fe7a401b30e87b6df907f6c0a4e88/cc/cxxcom/pftn.c#L780

и строка

ap->sarg(0) = addname(typ);

в https://github.com/IanHarvey/pcc/blob/05a6d549952fe7a401b30e87b6df907f6c0a4e88/cc/ccom/gcc_compat.c#L184 ?

Ну это уже какие-то сказки.

А за маркетинговый идиотизм производителей Lisp Machines, низкую производительность программ на лиспе на широко используемых машинах (SBCL тогда не было) и AI Winter

То-то я смотрю сверхскоростные программы на питоне ставят рынок на колени.

Что делает строка
ap->amlist = sp;
и строка
ap->sarg(0) = addname(typ);

#define amlist  aa[0].varg
#define sarg(x) aa[x].sarg

Соответственно, это все макросы доступа к той же структуре атрибута. Тогда:

ap->amlist = sp;

засовывает в атрибут структуры ссылку на свою же таблицу символов, а:

ap->sarg(0) = addname(typ);

назначает атрибуту типа переменной тип «typ», после чего ниже добавит этот атрибут в таблицу символов «sp».

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

При заполнении массивов ты тоже пишешь

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

То-то я смотрю сверхскоростные программы на питоне ставят рынок на колени.

Питон, так же как и Java, жив, потому что корпорации делают для него библиотеки. И программы на питоне таки сверхскоростные, ибо на 99% состоят из кода на Си, которому код на питоне передаёт параметры.

А на лиспе корпорации поставили крест после AI Winter. И теперь ни одна из тех корпораций не может вернуться к использованию лиспа без репутационных потерь. Проще сделать ещё один язык с макросами и REPL’ом.

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

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

Можно даже такое писать (это тоже Си):

int main(int argc, char** argv) {

  /* Stack objects are created using "$" */
  var i0 = $(Int, 5);
  var i1 = $(Int, 3);
  var i2 = $(Int, 4);

  /* Heap objects are created using "new" */
  var items = new(Array, Int, i0, i1, i2);

  /* Collections can be looped over */
  foreach (item in items) {
    print("Object %$ is of type %$\n",
      item, type_of(item));
  }

  /* Heap objects destructed via Garbage Collection */
  return 0;
}

А на лиспе корпорации поставили крест после AI Winter. И теперь ни одна из тех корпораций не может вернуться к использованию лиспа без репутационных потерь. Проще сделать ещё один язык с макросами и REPL’ом

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

Наличие макросов, позволяющих писать код, пугающий и путающий низкоквалифицированных кодеров, в самом распространённом языке программирования

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

Но в данном случае макрос очень простой, и настоящий смысл его применения довольно неожииданный — это правило strict aliasing. В классическом коде на Си в подобных случаях часто встречается кастование указателя в несколько разных типов в зависимости от применения. Здесь же авторы решили пойти за модой и засунуть все типы в одну структуру, из-за чего получились гигантские идентификаторы, вроде ap->aa[0].varg, при доступе к самому-самому простецкому одиночному полю структуры. Лично я голову не морочу, пишу -fno-strict-aliasing, и спокойно кастую указатели, раз уж язык не может сделать это за меня.

Можно даже такое писать (это тоже Си)
var items = new(Array, Int, i0, i1, i2);
foreach (item in items) {

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

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

а если напишешь — не отладишь, потому что текст из макроса протекает наружу и при этом компилятор ничего не знает про существование макросов.

То есть минусы наличия макросов есть (можно сделать нечитаемо), а плюсов от нормальных макросов (как в лиспах или Rust’е) нет. При этом распространение больше, чем у лиспов и Rust’а. Вывод: причина падения популярности лиспа не в макросах.

А лисп не хотят и не пытаются вспоминать.

Кусками вспоминают: лямбды и лексические замыкания в JS (а с недавних пор и в C++), s-выражения в WebAssembly, макросы в Rust, метаклассы в Python.

То есть минусы наличия макросов есть (можно сделать нечитаемо), а плюсов от нормальных макросов (как в лиспах или Rust’е) нет

Я уже давно высказал свою позицию: макросы — зло. Сишные макросы используются в большинстве случаев для описания констант и обобщенных функций — эти применения легко реализуются в C++ безо всяких макросов, на уровне языка. Именно потому нынче никто не пишет на чистом Си, даже не ради классов и хитровыдуманных шаблонов, а просто чтобы получить обобщенные функции плана a+b в языке и нормальные константы.

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

Кусками вспоминают: лямбды и лексические замыкания в JS (а с недавних пор и в C++)

Замыкания теоретически были известны до появления первых компьютеров, а практически были реализованы впервые в языке PAL. Первые же лексические замыкания появились не совсем в лиспе, а в Scheme — лексические замыкания в лиспе появились значительно позже, а в eLisp долго жили (а может и до сих пор живут) без лексических замыканий. Более того, в лиспе жили с негигиеничными макросами, которые позволяли непреднамеренные замыкания. Так-то замыкания были еще, например, в ML и APL — так что это не исключительная для лиспа фича.

s-выражения в WebAssembly

Да. Напоминаю, что макросов там нет.

макросы в Rust

Там всё непросто.

метаклассы в Python

Метакласс в питоне — это тупо функция. И ничего больше. Модно было в то время иметь метакласс, вот и создатели питона тоже назвали что-то метаклассом у себя.

Не за это. А за маркетинговый идиотизм производителей Lisp Machines

А в чем он заключался?

низкую производительность программ на лиспе на широко используемых машинах (SBCL тогда не было)

Даже если бы и был, в 90х компы были достаточно слабыми. А в 2000х уже были perl, python, php, js с батарейками - чтобы сразу «взять и что-то запилить».

Даже если бы и был, в 90х компы были достаточно слабыми. А в 2000х уже были perl, python, php, js с батарейками - чтобы сразу «взять и что-то запилить»

Плохому лисперу и питоны мешают.

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

Реализация errno на макросах, то есть errno - макрос. Да и реализация printf – тоже.

Первые же лексические замыкания появились не совсем в лиспе

Scheme - диалект лиспа

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

В Common Lisp до сих пор так.

так что это не исключительная для лиспа фича

Я не спорю. Думаю, по остальным пунктам тоже. Но популяризовал всё перечисленное именно Common Lisp.

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

Так вот эта мода, что на метаклассы, что на лямбды — она ведь из лиспа.

А в чем он заключался?

В позиционировании исключительно на премиум сегмент. Не было совместимого по ПО массового рынка. С другой стороны, деньги они изначально заработали, компьютер сделали: возможно, у них не было цели делать это направление массовым.

в 90х компы были достаточно слабыми

PERL тянули. Лисп получался (на CMUCL/SBCL) быстрее.

Реализация errno на макросах, то есть errno - макрос. Да и реализация printf – тоже

Глибсы — это трэш, я уже отвечал. Посмотри сюда, например (printf реализуется через vfprintf):

https://git.musl-libc.org/cgit/musl/tree/src/stdio/vfprintf.c

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

так что это не исключительная для лиспа фича

Я не спорю. Думаю, по остальным пунктам тоже. Но популяризовал всё перечисленное именно Common Lisp

«Популяризировал» он их потому, что в 1986 году лисп был на позиции современной жавы, то есть, это был основной язык в индустрии, наряду с Си и Ada. Если бы ML был тогда основным языком в индустрии, то он тоже бы «популяризировал» лексические замыкания и форму однократного статичного присвоения, на которой нынче работают все ведущие компиляторы C/C++.

Так вот эта мода, что на метаклассы, что на лямбды — она ведь из лиспа

Это такая «мода», что C++ понадобилось всего-лишь 30 лет для того, чтобы наконец ввести лямбды-замыкания. Метаклассов нет по прежнему — я не спорю, что, вполне возможно, метаклассы скаргокультили с лиспа, и это был провал, на мой взгляд, потому что эти метаклассы никак не вписываются в питон.

Глибсы — это трэш, я уже отвечал.

Однако этот трэш является самой популярной реализацией libc. Так что люди любят макросы и трэш на них.

Если бы ML был тогда основным языком в индустрии

Согласен. И мы бы сейчас обсуждали, почему не пытаются вспоминать ML.

C++ понадобилось всего-лишь 30 лет для того, чтобы наконец ввести лямбды-замыкания

Замыкания в языке без сборки мусора — очень спорная вещь. А в boost их тянули уже давно.

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

Зато на них удобно делать синглтоны/мультитоны и ORM.

Однако этот трэш является самой популярной реализацией libc. Так что люди любят макросы и трэш на них

Среди кого? Среди тебя? Глибцы активно используются только в gcc. В clang они уже опциональны, у мака и винды libc свои. Та же альпина построена вокруг мюслей. У глибсов еще и LGPL, а это не всех устраивает.

Если бы ML был тогда основным языком в индустрии

Согласен. И мы бы сейчас обсуждали, почему не пытаются вспоминать ML

Мы сейчас обсуждаем, что лисп был выдущим языком индустрии 30-35 лет назад, и сдох как дворняга. Но в твоем восприятии он почему-то переродился в других языках. А в моем восприятии он сдох, его закопали, но он еще не сгнил. Даже Clojure, копируя синтаксис лиспа, предоставляет фундаментально иные механизмы для разработки алгоритмов в виде цельной системы атомов-агентов-STM-каналов с многоверсионностью, и порицает использование макросов.

Замыкания в языке без сборки мусора — очень спорная вещь. А в boost их тянули уже давно

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

Среди кого? Среди тебя? Глибцы активно используются только в gcc.

Среди пользователей Linux. Мы же на Linux.org.ru.

Та же альпина построена вокруг мюслей.

Чуть ли не единственный не-glibc дистрибутив.

Но в твоем восприятии он почему-то переродился в других языках. А в моем восприятии он сдох, его закопали, но он еще не сгнил.

Согласен. Но факты укладываются в обе модели.

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

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

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

Проще сделать ещё один язык с макросами и REPL’ом.

И много ли сделали? Из хоть слегка свежего мне только Clojure в голову приходит, правда не знаю как там с реплом.

Мне кажется, что сейчас есть тенденция отхода от динамики. Вон даже джаваскрипт типизируют как могут. А из типизированных лиспов разве что диалект Racket и всё, ну из того, что более-менее на слуху.

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

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

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

Гугл использует, хоть и не продвигает: https://google.github.io/styleguide/lispguide.xml

У Apple был свой период работы с лиспом в 1991-1994 (Macontosh Common Lisp).

У микрософта ещё раньше: Microsoft Lisp 1983-1986.

И много ли сделали? Из хоть слегка свежего мне только Clojure в голову приходит, правда не знаю как там с реплом.

Я про Rust намекал. И Scala.

А из типизированных лиспов разве что диалект Racket и всё, ну из того, что более-менее на слуху.

Ещё есть Typed Clojure. Да и Common Lisp я бы на сказал, что нетипизированный:

$ cat test1.lisp
(defun add (n)
        (+ n  1))

(defun bad-concat (n)
      (concatenate 'string (add n)))

$ sbcl
...
* (compile-file "test1")
...
; caught WARNING:
;   Derived type of (ADD N) is
;     (VALUES NUMBER &OPTIONAL),
;   conflicting with its asserted type
;     SEQUENCE.
;   See also:
...

Но полную статическую типизацию в лиспах сделать невозможно. Попробуй описать тип функции mapc, например. Видимо, именно поэтому продвигаются полностью типизированные Rust и Scala.

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

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

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

Большие конторы тоже могут себе позволить разного рода эксперименты.

Кстати, ближе всегo с лиспом я сталкивался когда общался с чуваками, который очередной блокчейн делали (Stegos - бывший Emotiq). Изначально как раз собрали небольшую команду лисперов. В итоге они не смогли найти общий язык и на этапе прототипа всё начало разваливаться. После этого приняли решение переписать на расте. Хотя один лиспер в команде всё-таки остался. Где-то год-два они ещё протянули, а потом прикрыли проект. Правда работать я к ним не пошёл так что это всё со слов знакомого, который к ним устроился.

Я про Rust намекал. И Scala.

У раста же вообще нет репла?.. У скалы есть, но насколько я понимаю, это всё далеко от лисповой «разработки в образе».

Ну и в в целом я не согласен, что раст или скала - это реинкарнация лиспа. Конечно, языки заимствуют друг у друга и бывает сложно проследить, что откуда пришло (да и так ли это важно?..). Особенно забавно смотреть в википедии, где в графе «Influenced by» перечислен с десяток языков.

На мой (не лисперский) взгляд лисп - это как раз прежде всего макросы и «гибкость» (Meta Object Protocol и вот это всё). Раст - это попытка сделать безопасный системный язык и макросы там - это скорее желание заткнуть дыры языка, который ещё только (медленно) развивается. macro_rules вынуждено стабилизировали с обещанием потом доделать (macro 2.0), но пока никак. Штуки типа try! предпочитают тащить в язык. Процедурные макросы вообще долго держали в найтли, пока не поняли, что без этого многие вещи нормально не сделать. И то в процессе тоже переосмыслили (плагины к компилятору, кажется, похоронили навсегда). В общем, вроде и есть макросы, но это далеко не подход с написанием DSL под каждую задачу.

С таким же успехом можно и хаскель наследником лиспа объявить: есть и репл и template haskell.

Попробуй описать тип функции mapc

Подвох в том, что список может содержать разные типы?

Не готов в это поверить, ну если мы не говорим об абсурдных ситуациях когда предлагается делать проект на заведомо неподходящем языке.

В случае провального проекта всегда надо обосновать причину провала. На лисп списать гораздо проще, чем на Java, например.

Кстати, аналогичная причина сложности внедрения линукса.

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

Стартапы обычно создаются командами. И пишут на том, на чём умеет писать команда.

Впрочем, лисповые команды есть. M. Wallen Software Ltd. как пример. Остальные найти сложнее, так как если нет открытых проектов, угадать, на чём пишет компания, сложно.

Большие конторы тоже могут себе позволить разного рода эксперименты.

Контора может, отдельный менеджер - нет. Вот контора, где я работаю, может позволить себе купить компьютер на Эльбрусе. Но обосновать руководству желание сделать хранилку ценных данных на нём (вирусов нет, уязвимости малоизвестные) у меня не получилось.

У раста же вообще нет репла?

https://docs.rs/papyrus/0.17.2/papyrus/

Ну и в в целом я не согласен, что раст или скала - это реинкарнация лиспа.

Так я и не говорю, что это реинкарнация. Это заполнение ниши «нужно что-то с макросами и желательно с REPL’ом».

Подвох в том, что список может содержать разные типы?

И в том. что mapc принимает произвольное количество аргументов. Получается, что либо делаем сигнатуру с первым аргументом произвольной функцией и произвольными остальными (как printf в Си) . Либо как в Typed Racket нужна навороченная система типов:

> map
- : (All (c a b ...)
      (case->
       (-> (-> a c) (Pairof a (Listof a)) (Pairof c (Listof c)))
       (-> (-> a b ... b c) (Listof a) (Listof b) ... b (Listof c))))
#<procedure:map>

До недавнего времени проверку типов проходило только если списки имели одинаковый тип элементов. Сейчас проверил: b … b раскрывается в список разных типов произвольной длины.

Кстати, если брать именно Common Lisp, то в mapc ещё одна засада: как типизировать mapc, чтобы работало не только (mapc #’+ ’(1 2) ’(3 4)), но и (mapc ’+ ’(1 2) ’(3 4)). Первый аргумент - произвольный символ? Или как-то накручивать тип «символ, являющийся представлением функции»?

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

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

PERL тянули. Лисп получался (на CMUCL/SBCL) быстрее.

Perl он для сайтиков на cgi и скриптования использовался, про лисп массы и знать не знали, кроме того смайлики непонятные, непривычный и местами многословный - финал немного предсказуем, а как язык общего назначения в 90х медленный и нет ide по сравнению с delphi и С++, а тырпрайз на джаве.

А из типизированных лиспов разве что диалект Racket и всё, ну из того, что более-менее на слуху.

sbcl много где типы выводит, но статической типизацией назвать это все же нельзя. qi / shen - попытка прикрутить к лиспу статическую типизацию в ~2008.

Мне кажется, что сейчас есть тенденция отхода от динамики

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

Вон даже джаваскрипт типизируют как могут.

В лиспе опциональная стат типизация уже лет 30 есть в отличии от.

Казалось бы лисп довольно подходящий для них язык, но что-то всплеска не видно.

Чтобы лисп использовать в стартапе о нем надо хотя бы знать для начала :) что-то кроме «а, это старый язык со скобочками на котором в 80х писали ИИ» или «я пробовал в универе, кроме emacs нет ide, скобки глазами считать больно» и так далее. А чтобы знать что-то о лиспе нужна мотивация зачем бы это знать, если вакансий на нем нет. И почему именно лисп, а не любые другие навскидку такие же «устаревшие и непонятные» иные 20 языков из учебников истории.

Большие конторы тоже могут себе позволить разного рода эксперименты.

Никаких экспериментов большие конторы тем не менее никогда не позволяют, и вообще в любой корпорации там технологиям уделяется мало внимания - больше маркетингу. Технологии выбираются на низовом уровне теми же людьми, которые «я просто 20 лет программировали на java & php», берем.

Чуть ли не единственный не-glibc дистрибутив

Ты не представляешь, как я матерился, пытаясь собрать Glibc для GCC. Для сборки GCC нужен Glibc, для сборки GLibc нужен GCC. Такой вот вендорлок на жопоели. Я понимаю, что при настойчивости это обходится. но сам факт остается — Glibc «активно используются» потому, что куда вы денетесь?

Плохому лисперу и питоны мешают.

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

Или как-то накручивать тип «символ, являющийся представлением функции»?

А почему не просто «первый аргумент ф-ция»?

то в mapc ещё одна засада

Так вроде в этих ваших хаскелях даже можно гетерогенные списки и как-то их даже типизируют?

qi / shen - попытка прикрутить к лиспу статическую типизацию в ~2008.

Дык, оно малопопулярно даже по меркам лиспа. Мне кажется, что лисперам оно не нужно (ну а остальным - лисп).

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

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

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

В лиспе опциональная стат типизация уже лет 30 есть в отличии от.

И?

Дык, оно малопопулярно даже по меркам лиспа. Мне кажется, что лисперам оно не нужно (ну а остальным - лисп).

Речь шла о том, что в лиспе якобы нет статической типизации.

Ну и я бы не сказал, что «опцинальная типизация» - это прям тенденция.

python, ruby, js (надстройки), php, clojure - везде опциональная стат типизация. Это и есть тенденция.

Нет простого способа как-то типизировать это дело

И не будет.

В лиспе опциональная стат типизация уже лет 30 есть в отличии от.

И?

Отсылка к первому комментарию.