Исправление no-such-file, (текущая версия) :
превратить код в нечитаемый сторонним человеком китайский язык: краткий, с малым числом лаконичных сущностей, и совершенно непонятный для того, кто не изучал этот язык пару лет
Это никак не относится к языку. В «обычном» языке будет тоже самое. Возможность понять каждую инструкцию в отдельности не приводит к пониманию логики в целом. Если ты не знаешь что-такое визитор, то ты нишиша не поймёшь когда его увидишь.
Но в ЛИСПе ты по крайней мере увидишь структуру взаимосвязей. Тебе не придётся её в голове выстраивать.
Спасибо, не понял
Объясняю на примере. Путь у тебя есть функция для работы с 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.
Исходная версия no-such-file, :
превратить код в нечитаемый сторонним человеком китайский язык: краткий, с малым числом лаконичных сущностей, и совершенно непонятный для того, кто не изучал этот язык пару лет
Это никак не относится к языку. В «обычном» языке будет тоже самое. Возможность понять каждую инструкцию в отдельности не приводит к пониманию логики в целом. Если ты не знаешь что-такое визитор, то ты нишиша не поймёшь когда его увидишь.
Но в ЛИСПе ты по крайней мере увидишь структуру взаимосвязей. Тебе не придётся её в голове выстраивать.
Спасибо, не понял
Объясняю на примере. Путь у тебя есть функция для работы с 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.