История изменений

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

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

Но в ЛИСПе ты по крайней мере увидишь структуру взаимосвязей. Тебе не придётся её в голове выстраивать.

Спасибо, не понял

Объясняю на примере. Путь у тебя есть функция для работы с api, которая принимает 2 функции get_response для получения ответа и save_data для парсинга и сохранения данных из ответа. Т.е.

api(get_response, save_data)

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

const proxied_get_response = new ProxyDecorator(get_response)
api(proxied_get_response, save_data)

Т.о. ты динамически, в виде алгоритма определил взаимосвязь между ProxyDecorator, get_response и api. Чтобы понять эту взаимосвязь тебе нужно «прокрутить» код в голове и понять какое состояние будет в динамике в момент вызова api.

В ЛИСПе ты вместо этого пишешь макрос, с помощью которого взаимосвязи задаются явно в декларативной форме:

(with-proxy (api get-response save-data))

В питоне для декораторов есть сахарок на эту тему, но как всегда это там сугубо костыльное и специфичное решение. Но даже оно сильно помогает в тех же web-фреймворках декларативно задавать роуты, мидлварь и т.п., а не писать лапшу в стиле app.use и route.get.

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

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

Но в ЛИСПе ты по крайней мере увидишь структуру взаимосвязей. Тебе не придётся её в голове выстраивать.

Спасибо, не понял

Объясняю на примере. Путь у тебя есть функция для работы с api, которая принимает 2 функции get_response для получения ответа и save_data для парсинга и сохранения данных из ответа. Т.е.

api(get_response, save_data)

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

const proxied_get_response = new ProxyDecorator(get_response)
api(proxied_get_response, save_data)

Т.о. ты динамически, в виде алгоритма определил взаимосвязь между ProxyDecorator, get_response и api. Чтобы понять эту взаимосвязь тебе нужно «прокрутить» код в голове и понять какое состояние будет в динамике в момент вызова api.

В ЛИСПе ты вместо этого пишешь макрос, с помощью которого взаимосвязи задаются явно в декларативной форме:

(with-proxy (api get-response save-data))

В питоне для декораторов есть сахарок на эту тему, но как всегда это там сугубо костыльное и специфичное решение. Но даже оно сильно помогает в тех же web-фреймворках декларативно задавать роуты, мидлварь и т.п., а не писать лапшу в стиле app.use и route.get.