x → y
y → x
И помер терм реврайтинг.
Логично что его используют для систем символьной алгебры. Но для языков программирования, что он даст?
y → x
И помер терм реврайтинг.
Логично что его используют для систем символьной алгебры. Но для языков программирования, что он даст?
Про терминальные правила мы не слышали?
> Но для языков программирования, что он даст?
Полную свободу выражения. Можно строить любые абстракции, DSLы, что значит понятный и расширяемый код.
>Про терминальные правила мы не слышали?
И все удобства будут перечеркнуты тем что ты будешь сидеть и выписывать портянки этих терминальных правил.
> Можно строить любые абстракции, DSLы, что значит понятный и расширяемый код.
А мы разве сейчас этого не можем? Так-то и машина Тьюринга всё может, и брейнфак. Но зачем?
Всё дело в выразительности. Да, на брейнфаке можно написать ОС, но это максимально сложно. В TR любая задача сводится к построению формул редукции, и при этом нет никаких ограничений со стороны самого языка.
Написать брейнфак в TR просто, а вот TR на брейнфаке (и даже лямбдах) - не очень.
https://pchiusano.github.io/2017-01-20/why-not-haskell.html
Почитай эту статью. Хотя она не про TR, а про хаскель, но должна вполне ответить на твой вопрос почему не. Хотя я бы перефразировал почему не для всего.
Если совсем по-простому объяснять аналогиями, зачастую даже ООП сильно излишне. ООП это по сути такое же автоматическое создание множества точек расширения и абстракции. Иногда эти точки расширения удачно подходят под меняющиеся требования, иногда не очень. Иногда это приводит к пиздецу из сплошных AbstractSingletonFactoryBeanAdapter.
TR на самом деле применяется повсеместно. Макросы это типичный TR. Кодогенерация это TR. Грамматики парсеров это TR. Редукция графов в вычислениях в хаскеле это TR. Разница только в том, что эти все TR направленные и работают за предсказуемое с небольшим разбросом время. Prolog и Mathematica нужны для другого, для перебора этих самых TR чтобы вместо человека "подумать", поискать, где же тут удачно можно редуцировать выражение, чтобы синтезировать новое знание. Никто не будет применять TR для эффективных вычислений по заранее известному алгоритму, потому что это сложно, накладно, это трудно для людей в первую очередь.
> Написать брейнфак в TR просто, а вот TR на брейнфаке (и даже лямбдах) - не очень.
При этом использовать готовый брейнфак и готовый TR одинаково сложно.
> готовый TR одинаково сложно.
Чем сложно? Не сложнее, чем всё остальное FP. Я бы даже сказал, проще, ибо не надо задумываться о том как лучше сделать api.
Я правильно понимаю, что такие вопросы возникают у людей, никогда не писавших промышленного кода?
Нет. Такие вопросы возникают у людей, открывших для себя отрасль дизайна языков программирования. Там есть довольно стройные, зачастую основанные на математической логике, модели вычислений, на основе которых создано несколько не самых популярных языков. И у неподготовленного мозга возникает иллюзия что все вокруг заняты чем-то не тем, и что у нас мог бы быть лучший мир, если бы все начали писать на языке NN. На деле далеко не всегда основная проблема программ написанных на популярных языках это то что пытается решить язык NN.
Почему так мало языков, которые используют такую фичу? Я знаю только Lisp, Prolog (которые не используют напрямую, но достаточно расширяемы, чтобы можно было прикрутить TR) и Pure с Mathematica (у которых TR - основной способ вычислить что-либо).
Почему столь простую, мощную, и невероятно выразитильную вещь никто не использует?