Комментарии 24
Интересный подход к генерации случайных объектов. Прям поэкспериментировать захотелось.
А в чём принципиальная разница? Допускаю, что это был один из вариантов произношения th в algorithm.
Алгоритм - это московская математическая школа. Алгорифм - это питерская школа.
Разница - огромная, на самом деле. Тут как между шавермой и шаурмной - первое - еда богов, второе - типичный джанкфуд
Вы когда-нибудь слышали про ипликатор Кузнецова? Конечно, правильнее
было бы назвать его «аппликатор», но Кузнецов умышленно изменил
название, чтобы отделить свое изобретение от других аппликаторов.
Вспомнилось это нетленное жизнеописание одного изобретателя.
По моему все эти замещения легко реализуются универсальными языками программирования. Максимум, можно библиотеку собрать. Да, это интересный класс задач и картинки красивые, но сочинять узкоспециализированный ЯП под каждый узкий класс задач это подход сомнительный.
Ну всякие ямлы и схемы эксемеля по сути являются тем же самым — маленьким узкоспециализированным языком. Да каждый программист, когда пишет конфигурирование по сути придумывает специализированный недоязык. Я уж молчу о всяких си-мейках.
Так что узкоспециализированные вспомогательные ЯП — очень широко распространённый подход.
Скажем так, если сделать библиотеку к Питону, то ей воспользуется гораздо больше людей, чем каким-то экзотическим языком, который скорее всего не выйдет из стен своих создателей, а со временем и развиваться перестанет. Мало кому надо решать задачи строго в рамках какого-то узкого ЯП. Обычно в рамках большой задачи надо встроить что-то специфичное. Подключаем к проекту библиотеку и вперёд!
Ну например, у вас на столе есть ручка? Чтобы выточить штамп для отливки её деталей пишется программа на очень-очень узкоспециализированном и очень бедном ЯП. Как вы думаете много ли таких и подобных задач решается? И я ещё раз молчу про Cmake который используется для сборки 90% системного софта и игр (я ничего не хочу про него говорить. Ничего.)
Так что это ещё не факт, на каких языках больше задач решается!
Разница в том, что специализированный язык для ЧПУ решает понятные и востребованные задачи. И его специализированность и бедность понятно почему и зачем. Есть ли для обсуждаемого языка та ниша, в которой он востребован? Ну, не знаю. А чем оправдана его специализированность? Тоже не знаю.
Какой язык тут обсуждается? Их "яхык" это просто xml схема с параметрами модели
Вот этот DSL и будет лежать в основе интерфейса такой библиотеки. А вы говорите скорее про ее реализацию. И тут я согласен - встраивание DSL в ЯП общего назначения имеет свои преимущества.
Круто. Очень похоже на клеточные автоматы.
Упражнение: доказать, что следующий алгоритм Маркова находит наибольший общий делитель двух чисел, записанных в унарном представлении.
Там от чисел A и B, где A>=B, переходим к числам (A-B) и B, как и происходит в алгоритме Евклида. Это легко проследить в обоих случаях, когда число справа больше чем слева, и наоборот.
Очень интересно!
И здорово, что сделан порт в веб, чтобы это можно было самостоятельно потыкать. https://yuu6883.github.io/MarkovJuniorWeb/
P.S. если от длиннющих XML схем перейти к компактным схемам на TOML или tree ast, ясность и удобство конфигураций выросло бы в разы
Изучал в своё время на факультете язык Рефал (3. Валентин Турчин, REFAL language, 1968 год). Для работы с текстами, очень удобный и красывый инструмент..
Спасибо за очень интересную статью) программы выглядят внешне очень простыми, можете дать пару идей, как их можно строить исходя из задачи?
Стохастический язык программирования на основе алгоритмов Маркова