Обсуждение

Да, весь R такой от рождения :)

Другие языки, например, Julia, в нём не упоминаются. Church и Julia упоминаются, я по крайней мере токо что обнаружил :) даже справа есть две сцылы на архивные публикации надо все-таки асилить probabilistic programming по "работе" мне не нужно, но я недавно прорабатывал унифицированный подход МЛ, и туда MCMC всякий и проч вполне себе просится для полноты картины

julia конечно получился один из самых интересных языков за последнее время не только с точки зрения искусства программирования, но и как инструмент я вот сегодня как раз задумался. Возникла задача с моделированием сетевых протоколов. При том, что там много нод и памяти может не хватить, и по идее, лучше статистические/вероятностные модели делать. Хотя и обычное (имитационное) моделирование может понадобиться. Вот и думаешь, Питон - медленный, Жаба - пошустрее, но для стат мод ниочень. А Джулия в самый раз получается :).

А, да помянули таки. Я споткнулся на ссылке 2010 года на Church, когда и Julia не существовало. Ну не буду ничего менять. По факту ничего ведь в сути поста не поменялось. Julia помянута, похоже, просто как "тоже изобретено в MIT", акцента на ней не делается. Этих differentiable, probabilistic и прочих подобных programming сейчас тьма разных.

Что-то немного на R инженерного моделирования ))) Как и на Хаскеле )))

О, Спасибо! Почитаем

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

настоящая история появляется в тот момент, когда писать нужно одновременно на трёх-четырёх DSL и заодно дописывать какой-то очередной DSL. Вот тут и оказывается, что знать нужно и хост-язык, желательно в совершенстве.

Мне думается дело тут в том, что чем больше язык пригоден для создания DSL тем он заморочнее, и тем сложнее полноценно его изучить. Скала/Хаскел тому пример. А на ниочень языках типа Жаба, особо DSL и не попишешь, зато их и любой дурак изучить может. Т.е. eDSL кагбэ подразумевает грабли с хост языком, но мне думается не потому что это DSL, а потому что хост-язык :).

Ну вот Julia время от времени претендует на звание "не очень сложного языка", а я на такие заявления говорю обычно "не обольщайтесь". Вообще, современные все языки нельзя назвать "не очень сложными". Чтобы писать на них, нужно хорошо ломать мозг во многих местах. "Во многих местах" -- в этом проблема. Нет уже давно языков одной зубодробительной идеи. В Julia там ведь отнюдь не только multiple dispatch из мозгодробительных штуковин.

А что насчет Ruby? Для DSL-ей он очень приятен, при этом вроде и не сложный. В более общем случае это просто классический случай протекающих абстракций. В eDSL они протекают особенно быстро.

Язык обычно сложен из-за того что они там формальные системы используют (конечно могут быть и другие источники сложности, есть ведь Perl или даже, прости господи, brainfuck :)). Опять же пример Скала/Хаскел. Когда в Жаба добавили generics, то она тоже посложнее стала. Посему, хотя я конкретно с Ruby плохо знаком, но он мне видится как очень хороший вариант :). Имеется в виду что очень выразительный язык, и не переусложненный. Я просто в основном в Жаба мире обитаю (хотя сейчас больше Питон, но это из-за МЛ), и мне как очень удачные языки видятся Groovie, Kotlin, Xtend, ну и Scala в какой-то мере (хотя все же сложновато). Условно говоря, я не то чтобы жуткий фанат eDSL, обычно через некоторое время приходишь к мысли, что все равно весь этот удобный синтаксис оттранслируется внутри в какие-то библиотечные вызовы. Ну и наверное проще и лучше иметь хорошую библиотечку, а удачный eDSL сверху может помогать, может быть привлекателен для неискушенной публики, но в целом, особой роли не играет. Т.е. я согласен насчет leaky abstraction - она скорее всего протечет, так что все равно надо иметь дело с хост-языком, и лучше чтобы это был удобный и выразительный язык. ИМХО, тут рулит комбинация функционального, ОО и императивного программирования (чтобы все-таки можно было иногда переменные апдейтить). Т.е. Питон прикольно но функционалки не хватает. Скала - круто, но по мне все же сложновато. Котлин - судя по всему в самый раз. Руби - очень близко к идеалу, но немного в стороне от меня :). Там еще вроде многопроцессорные реализации появились, всякие там JIT.

Прочитал, подумал: "О, конечно, DSL для описания физ. моделей, уж эти-то ребята наверняка придумали, как текстом выразительно описывать связи, надо у них подсмотреть". Открыл пример с главной, а там вот это https://github.com/ModiaSim/Modia.jl/blob/master/examples/CauerLowPassFilter.jl Учитывая, что оно описывает вот эту простую схему, по-моему, это фейл https://github.com/ModiaSim/Modia.jl/raw/master/docs/CauerLowPassFilter.png Читал вашу книгу "Визуальное мышление" и во многом с ней согласен. Но, кажется, областей, где текст работает плохо, гораздо больше, чем вы там упоминаете. Другое дело, что и графика там тоже не очень хорошо работает. В связи с этим вопрос — а что происходит с гибридными системами? Есть какие-то хорошие примеры? В первую очередь в голову лезут системы вроде Mathematica, Jupyter. Припоминается "ОРГ-Мастер", который вы недавно упоминали. А есть ли еще какая-то жизнь в этой области? Для понимания контекста: пытаюсь родить DSL для описания сложной музыки: спектральной, микрохроматики, сложных ритмов и т.д. Текстовая нотация в музыкальной области даже в базовом случае превращается в ад. Например, ABC Music, который задумывался как простая нотация для кантри-музыкантов, после добавления в него всех базовых фич стандартной пятилинейой нотации стал таким монстром, что его даже программисту читать тяжело) LilyPond получше, но тоже не фонтан. Мне кажется решением тут может быть именно какая-то гибридная система и, конечно, декомпозиция. Или я что-то упускаю?

Спасибо за обзор, захотел посмотреть поглубже на DSL: * Первое впечатление что Gen не тянет на DSL, скорее на библиотеку для написания ML систем в режиме "предиктор" (генератор) - "корректор" (инференс), с прибитой баесовской логикой. Стандартные библиотеки MCMC (Julia) и Deap (Python) выглядят честнее и покрывают больше кейсов, например можно отмоделитьвать evolutionary strategy. * DSL для Архимейта на скале выглядить прикольнее - особенное если к ниму базу типа grakn прикрутить.

Я уже много лет после перехода с Matlab а на Python смотрю на Julia/Scala/Haskell/Ocaml/Ruby/Kotlin и прочее и прочее; И оказывается, что большинство задач удобнее решать на Питоне, даже если любимый язык Lua - как самый маленький и простой. А домен и знания домена моделируется с помощью комбинации ini/yaml файлов, схемы базы данных и какой нибудь визуализацией.

зависит от "как собираетесь использовать" модельку, я несколько лет загонялся ns3 и ptolemy для моделирования сети самолета, потом переписал симулятьр на javascript + D3.

https://arxiv.org/pdf/1706.08605.pdf это сцыла наверное даже не оффтоп но в любом случаю, думаю Вам будет интересно, если еще не видели :) мы пару раз затрагивали тему скрещивания пруверов и МЛ, и тут по моему дык весьма интересный пример :)

ИМХО - эти подходы разрабатываются под свои use case и не переносимы из области в область даже если это ML задачи. Я смотрю на Gen пример Particle Filter и не думаю что он выиграл по сравнению с чистым python например отсюда. А унифицированный подход к ML должен покрывать не только предиктор/коректор фильтры но и более традицонные непараметрические - типа Evolutionary Algorithms и image processing. Например как будет выглядить преобразование Хофа (распознование линий/эллипсов/или пересечений) в Gen?

Синхрония: только сегодня конвертировал задачу про фильтр Кауэра из старой терминологии в новую в учебнике -- и вдруг ваш пример у меня в блоге ))) Там не фейл, а честная попытка "конвертировать модель" (то есть подразумевается, что модель делается в какой-то рисовалке типа Modelica, а потом сама считает. Отсюда и нотация -- перечислить функциональные части и соединения, разве что не табличкой). С музыкой всё хитро: там начинает работать глубокое обучение, и нотации по факту не требуется: генерация из текста отходит в прошлое, не нужна. Это, кстати, хорошо обсуждает Владимир Мартынов, рассказывая о возвращении музыки нетекстовой -- https://polit.ru/article/2007/10/05/martynov/ В принципе, в музыке напрашивается какая-то многомерность, но там ведь и цикличность наличествует. Вот, например, геометрическая нотация для ритма вот тут хороша: cинтезатор ритмов Groove Pizza https://apps.musedlab.org/groovepizza/ (работает в браузере, в моём случае в FireFox), сделанный по мотивам книги "The Geometry of Musical Rhythm: What Makes a "Good" Rhythm Good?" https://b-ok.cc/book/2551598/846a5d (2013). Но в любом случае "нотация" сводится к тому, что музыканты именуют ритмы и риффы (базовые структуры импровизационной музыки) по песенкам, где они явно слышатся. То есть нужна нейронная сетка, которая преобразует услышанный где-то ритм ("как в XYZ, только изменить вот так-то", а не заданный с нуля нотацией) в какой-то другой требуемый -- и приемлемость которого определяется по слуху. Ну, и параметризация слайдерами, как в какой-нибудь karma технологии, https://www.karma-lab.com/main.html?p=index.html В принципе, музыкальных языков тьма. Я когда-то этим интересовался, лет десять назад только ленивый этим не занимался. Сейчас же становится понятно, что при текущей коммодитизации музыки эти языки (музыка как текст) уступают другим способам работы, "непосредственному исполнению". Когда-то я в группе "Аттик" мехамата МГУ предложил режим "непосредственного исполнения", когда программа исполняется не путём интерпретации команд исполнителя, а непосредственно (например, программа Ворда дёргается кнопочками на клавиатуре, и исполнитель Ворда перемещает курсор под управлением этих кнопочек. Понятно, что можно записать последовательность нажатий этих кнопочек как вызовы соответствующих функций и дальше компилировать, или даже писать соответствующие функции в REPL и дальше интерпретировать, но это другой режим. Непосредственное исполнение -- это real time и без промежуточного текста программы, сразу работает нижележащий уровень исполнения). Вот в музыке побеждает такое при исполнительстве (тот же синтезатор так устроен), а нотные прилады с готовыми паттернами не приживаются (скажем, даже самоиграйки не царят в мире музыки, очень нишевы). Поэтому можно долго говорить про музыкальные языки, их визуальность, аудиаальность, текстуальность или непосредственность/клавиатурность/музинструментальность. Вопрос в том, зачем это всё ))) Такие же вопросы, кстати, и про танцевальные нотации. Там всё то же самое: нужно записать движения тела (где до чёртиков степеней свободы, и всё то же, что в музыке -- полиритмия, полиметрия, нюансы и т.д.).