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

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

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

и ладно бы это была какая-то essential complexity. меня не очень смущает, что я не понимаю, как нейросетка внутри работает - это не моя предметка вообще, это какая-то вещь в себе

или предположим, какая там математика в предметке - это тоже не совсем моя зона ответственности

1. eDSL != сложно
2. Все библиотеки совершенствуются, и кмк если авторы адекватные - хотя бы рассмотрят возникшую у пользователей проблему.  Форк и патч придётся делать в любом случае, если функциональность не полностью удовлетворяет нуждам программиста. Опять же, eDSL ни при чем.
3. Если вы используете библиотеку - код не ваш, и пользуетесь вы данными вам абстракциями. Не хотели бы - написали с нуля, как считаете нужным.

Я пока просто не до конца понимаю, как это отличается от "C не нужен, я не понимаю, что делается на CPU", без обид. Есть пример того, как нужно делать хорошо?

Помню, ты говорил о Clojure, но разве data-oriented конфигурация позволяет "понять, что происходит внутри"? По мне, разбор такой конфигурации и разбор DSL - задачи не сильно далекие.

это именно что бесконечно далекие вещи, потому что пайплайн обработки данных - это абсолютно понятное ползанье по дереву, с привычными операциями(map/filter/fold), состоящее по большей части из чистых функций, это доступно и читабельно.
про edsl на макросах я, опять же, написал чуть выше - все, что видел, написаны через глобальные переменные.

Макросы обычное не про обработку данных, а про их подготовку

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

Не до конца понимаю, причём здесь пайплайн
Я не спорю, что код должен быть поддерживаемым
Но как лично тебе это мешает? Ты же не контрибьютишь 24/7 в него, верно?

Быть может, на примерах будет понятнее. Что бесит и как можно сделать хорошо

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

я уже хз как объяснить.
зачем плодить accidental complexity, если можно этого не делать?

Отлаживать то, во что разворачиваются твои макросы - не очень удобно ( Одно дело, когда это чья то либа и за тебя уже кто-то отстрадал. А когда самому... А потом кто-то будет пользовать твое поделие и считать, что там все правильно, как будто ты господь бог, не ошибаешься и все предусмотрел

А позанимался этим. Можно считать, что профессионально. То есть фуллтайм и за деньги. Вот не просто это, коллеги, в макросы писать.

А главное, потом код от этого понятнее не становится. Нужно запоминать эту вот новую абстракцию. И в прод не пойдет) И сам то я там сейчас уже не пойму ничего.

Так потом и получается. Простой эликсир учится за неделю. А потом все остальное время макро бейзет вещи. Феникс, экто. :)

да, например, вот это.
а ведь если сначала написать референсную реализацию на голых данных, то макросную реализацию(если она после такого вообще будет) можно гонять просто через тот же test suite, чтобы убедиться в корректности.

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