Не согласен с заявлением, что functor - это high-kinded type, это typeclass, нет никаких высших порядков.
И вот это позабавило:
Язык формирует стиль кода и культуру — не через запреты, а через то, что в нём естественно.
Поэтому, когда вы открываете чужой код на этих языках, вы видите FP-паттерны не потому что автор был дисциплинирован, а потому что язык просто не давал писать иначе.
Я был излишне краток. Имел в виду во-первых, что называть работу с AST фундаментом - это большая переоценка той роли, которую AST играет в процессе компиляции. А во-вторых, что у интересных языков программирования самое важное будет в той части мета-аст, которая специфична только для этих языков. Я думаю, что универсальный супер-компилятор для тучи языков программирования, backend которого принимает мета-аст, пытающийся абстрагировать все частные случаи конкретных языков, написать не получится.
Я кратко глянул вашу либу, и проверил, что вы мигрировали свой cure на неё, насколько я помню, изначально он её не использовал, либа появилась позже. Хз, насколько вам удобно иметь этот уровень абстракции и распаковывать его, спускаясь к конкретике cure. Также хз, насколько полезен анализ кода, выполняемый на этом высоком уровне абстракции. Не имел в виду, что вы не написали либу или что либа не делает того, что вы описываете. Под хвастовством я имел в виду громкость заявлений.
Metastatic делает то же самое, но не для диаграмм классов, а для синтаксических деревьев программ. Это не IR, не компилятор, не транспайлер. Это фундамент, на котором все перечисленное может быть построено – один раз, и для всех языков сразу.
Это, конечно же, изрядное хвастовство, и я даже затрудняюсь сказать, это авторское или LLM-ка добавила?
mov rax, [rsi + 8] ; загрузить адрес vtable из fat pointer
mov rax, [rax + 24] ; загрузить адрес метода из vtable (смещение 24 = 3 × 8)
call rax ; вызвать по указателю
Получается, что rsi - это указатель на толстый указатель. Я понимаю, что это кусочек кода функции draw_all_dyn , и rsi - это указатель на текущий элемент массива, по которому происходит итерация, так что здесь первый mov - это налог на упаковку толстых указателей. Для функций, которые работают с дженериками, вроде как не нужно этого действия, но и им из указателя-итератора нужно читать, например self.
Вам уже выше про "чучел" указывали, теперь вы и мне опровергаете то, что я не утверждал. Soft skills - это не искусственное ненужное вмешательство, это не про нравится/не нравится вообще ни разу. Это про трудноуловимую логистику командной работы. Я вот хз, что значит слово "свою" в фразе "выполнять свою работу качественно и в срок", я в команде работаю, если у тестировщика проблемы, то я помогаю, если у коллеги проблемы - я помогаю, а они помогают мне, и общий прогресс движется, фирме хорошо, нашей общей зарплате тоже хорошо. Отсутствие soft skills - это и "я сделал то, что написано, больше ничего не буду", и "я за всех бездельников сделаю их работу и буду молчать". Skill - это по-английски "полезное умение".
Посыл очень простой: когда происходит оценка вклада человека в дело, то, помимо hard skills, которые технические навыки, оценивают ещё и soft skills, то есть вклад в коммуникацию и прочее согласование отдельных личностей, чтобы они действовали как команда. Soft skills важны и ценны, они позволяют команде делать больше, чем набору индивидуумов.
Вам не кажется странным называть «софт скиллами» то, что нам привили родители еще в детском саду? Основы общения, вежливость и этикет это база любого нормального человека
Кому-то привили вежливость, а кому-то агрессивность, обосновав это "не будь лохом, иначе на тебе все ездить будут". Вежливость - редкое качество, а вежливость за пределами формальностей - ещё более редкое.
Но комментатор, как мне кажется, имел в виду другое: не держать язык в жопе и ждать, что само всё поймётся и решится, а понимание, что нужно озвучивать и транслировать информацию. Причин проблемы много : неосознаваемые (в IT дофига интровертов) и осознаваемые (некоторые не делятся инфой, потому что job security).
Я посканил комменты автора, да, ему, похоже, во времена ковида чуть досталось, но больше всего, я думаю, вот за это https://habr.com/ru/articles/482812/comments/#comment_21098052 . Хотя он там не грубит и не понтуется, просто не понимал. Докинул кармы.
С точки зрения семантики языка - да, это сахар для анонимного класса, реализующего функциональный интерфейс. Детали реализации (MethodHandle, invokedynamic) этого не меняют.
издержки от ошибок в ПО всегда ложатся на конечных пользователей, а не на разработчиков, поэтому у последних нет рыночного стимула к их полному устранению.
Вы описываете ситуацию с коммерческой разработкой. А ещё бывает внутрикорпоративная, когда из-за бага, уронившего прод, разработчику позвонят в 3 часа ночи. Это стимулирует.
Продукт, который активно развивается, естественным образом избавляется от старых ошибок - не потому, что кто-то целенаправленно их ищет, а потому, что переписывание улучшает его качество.
Не только улучшает, но и ухудшает. Статическая типизация, авто-тесты и borrow checker помогают бороться с добавлением новых косяков.
Функциональный стиль не является декларативным ни в коем разе, и все эти фразочки "вы описываете, ЧТО вы хотите, а не КАК это сделать" не объясняют ничего. Функциональный стиль является функциональным, и демонстрировать его отличие от не-функционального надо так:
Сейчас будет не-функциональный (процедурный)
int a;
int b;
int result;
void calculate() {
sum = (2*a + 3*b)/7 - 5;
}
void main() {
a = 5;
b = 8;
calculate();
print("Result is:" + result);
}
А сейчас - функциональный:
int calculate(int a, int b) {
return (2*a + 3*b)/7 - 5;
}
void main() {
int a = 5;
int b = 8;
int result = calculate(a, b);
print("Result is:" + result);
}
Обе эти программы выдают правильный результат. С точки зрения CPU процесс вычисления в обоих случаях будет практически одинаковым (забудем про нюансы передачи параметров, считаем, что код заинлайнится). Принципиальна разница с точки зрения разработчика в том, как происходит shunting данных. В случае с функцией параметры в неё пропихиваются вызывающей стороной, у вызывающего нет никакой возможности не передать параметр, у него не получится забыть это сделать. А у функции нет необходимости куда-то идти за значениями, они в аргументах. Также у вызывающего функцию нет необходимости куда-то идти за результатом вызова, он не доступен никак иначе, кроме как значение, получаемое в месте вызова. Иммутабельность - это следствие.
Предлагаю изучить, что такое continuation-passing style. Это когда функция принимает дополнительный аргумент-функцию, и вместо возврата результат передаётся в эту функцию. Это будет максимально выраженной реализацией той вашей картинки, где стрелочки передаются между модулями напрямую. Насколько я знаю, BEAM оптимизирует хвостовые вызовы, так что вы сможете сидеть в своём REPL до посинения.
Нифига не понял страданий автора, он заинлайнил переменные, и сделал так, чтобы результат одной функции передавался в другую, и чего в этом достойно публикации?
Неплохо.
Не согласен с заявлением, что functor - это high-kinded type, это typeclass, нет никаких высших порядков.
И вот это позабавило:
"нейровно" - это существительное или наречие?
Я был излишне краток. Имел в виду во-первых, что называть работу с AST фундаментом - это большая переоценка той роли, которую AST играет в процессе компиляции. А во-вторых, что у интересных языков программирования самое важное будет в той части мета-аст, которая специфична только для этих языков. Я думаю, что универсальный супер-компилятор для тучи языков программирования, backend которого принимает мета-аст, пытающийся абстрагировать все частные случаи конкретных языков, написать не получится.
Я кратко глянул вашу либу, и проверил, что вы мигрировали свой cure на неё, насколько я помню, изначально он её не использовал, либа появилась позже. Хз, насколько вам удобно иметь этот уровень абстракции и распаковывать его, спускаясь к конкретике cure. Также хз, насколько полезен анализ кода, выполняемый на этом высоком уровне абстракции. Не имел в виду, что вы не написали либу или что либа не делает того, что вы описываете. Под хвастовством я имел в виду громкость заявлений.
del
Это, конечно же, изрядное хвастовство, и я даже затрудняюсь сказать, это авторское или LLM-ка добавила?
Зря, первая трилогия вся очень хороша, про вторую мнения различаются.
Очень-очень хорошая статья!
Я хотел бы остановиться вот на этом моменте:
Получается, что rsi - это указатель на толстый указатель. Я понимаю, что это кусочек кода функции
draw_all_dyn, и rsi - это указатель на текущий элемент массива, по которому происходит итерация, так что здесь первый mov - это налог на упаковку толстых указателей. Для функций, которые работают с дженериками, вроде как не нужно этого действия, но и им из указателя-итератора нужно читать, например self.Привиделось в заголовке "Как филолог сделал предложение", подумал, какая красивая игра слов. Потом протёр глаза и опечалился.
Вы точно филолог?
Задолбали со своей рекламой
Вам уже выше про "чучел" указывали, теперь вы и мне опровергаете то, что я не утверждал. Soft skills - это не искусственное ненужное вмешательство, это не про нравится/не нравится вообще ни разу. Это про трудноуловимую логистику командной работы. Я вот хз, что значит слово "свою" в фразе "выполнять свою работу качественно и в срок", я в команде работаю, если у тестировщика проблемы, то я помогаю, если у коллеги проблемы - я помогаю, а они помогают мне, и общий прогресс движется, фирме хорошо, нашей общей зарплате тоже хорошо. Отсутствие soft skills - это и "я сделал то, что написано, больше ничего не буду", и "я за всех бездельников сделаю их работу и буду молчать". Skill - это по-английски "полезное умение".
Посыл очень простой: когда происходит оценка вклада человека в дело, то, помимо hard skills, которые технические навыки, оценивают ещё и soft skills, то есть вклад в коммуникацию и прочее согласование отдельных личностей, чтобы они действовали как команда. Soft skills важны и ценны, они позволяют команде делать больше, чем набору индивидуумов.
Кому-то привили вежливость, а кому-то агрессивность, обосновав это "не будь лохом, иначе на тебе все ездить будут". Вежливость - редкое качество, а вежливость за пределами формальностей - ещё более редкое.
Но комментатор, как мне кажется, имел в виду другое: не держать язык в жопе и ждать, что само всё поймётся и решится, а понимание, что нужно озвучивать и транслировать информацию. Причин проблемы много : неосознаваемые (в IT дофига интровертов) и осознаваемые (некоторые не делятся инфой, потому что job security).
Я посканил комменты автора, да, ему, похоже, во времена ковида чуть досталось, но больше всего, я думаю, вот за это https://habr.com/ru/articles/482812/comments/#comment_21098052 . Хотя он там не грубит и не понтуется, просто не понимал. Докинул кармы.
Про уровень критичного мышления мы поняли, а что насчёт умения писать код? Статья вроде про это.
Сеньор Матюшкин, вы снова с нами?
С точки зрения семантики языка - да, это сахар для анонимного класса, реализующего функциональный интерфейс. Детали реализации (MethodHandle, invokedynamic) этого не меняют.
Вы описываете ситуацию с коммерческой разработкой. А ещё бывает внутрикорпоративная, когда из-за бага, уронившего прод, разработчику позвонят в 3 часа ночи. Это стимулирует.
Не только улучшает, но и ухудшает. Статическая типизация, авто-тесты и borrow checker помогают бороться с добавлением новых косяков.
Похая нейростатья, с дурацкими примерами.
Функциональный стиль не является декларативным ни в коем разе, и все эти фразочки "вы описываете, ЧТО вы хотите, а не КАК это сделать" не объясняют ничего. Функциональный стиль является функциональным, и демонстрировать его отличие от не-функционального надо так:
Сейчас будет не-функциональный (процедурный)
А сейчас - функциональный:
Обе эти программы выдают правильный результат. С точки зрения CPU процесс вычисления в обоих случаях будет практически одинаковым (забудем про нюансы передачи параметров, считаем, что код заинлайнится). Принципиальна разница с точки зрения разработчика в том, как происходит shunting данных. В случае с функцией параметры в неё пропихиваются вызывающей стороной, у вызывающего нет никакой возможности не передать параметр, у него не получится забыть это сделать. А у функции нет необходимости куда-то идти за значениями, они в аргументах. Также у вызывающего функцию нет необходимости куда-то идти за результатом вызова, он не доступен никак иначе, кроме как значение, получаемое в месте вызова. Иммутабельность - это следствие.
Предлагаю изучить, что такое continuation-passing style. Это когда функция принимает дополнительный аргумент-функцию, и вместо возврата результат передаётся в эту функцию. Это будет максимально выраженной реализацией той вашей картинки, где стрелочки передаются между модулями напрямую. Насколько я знаю, BEAM оптимизирует хвостовые вызовы, так что вы сможете сидеть в своём REPL до посинения.
Нифига не понял страданий автора, он заинлайнил переменные, и сделал так, чтобы результат одной функции передавался в другую, и чего в этом достойно публикации?