Редактирование кода программы как дерево, а не текст

Mar 17, 2009 17:33

Чтобы понять, чем SOP/SymADE отличается от MPS или IP надо вначале разобраться, что у них общего.

Прежде всего, все эти средства разработки программ предполагают переход от представления программы в виде текста к представлению (редактированию и хранению) в виде дерева. В таком подходе нет ничего нового, именно эту идею использует Lisp, что в ( Read more... )

ip, symade, sop, mps

Leave a comment

mkizub March 20 2009, 13:29:21 UTC
Да, совмещение нескольких языков в одном проекте - это очень хороший способ писать сложные программы. Но! только если различные части (написанные на разных языках) хорошо изолированы друг от друга.
Например, то-же совмещение явы с прологом. Много лет назад у меня встала такая задача. У меня было несколько под-задач, где основная идея пролога (доказательство или поиск решения при сложных правилах, с возможным бэктрэкингом) мне бы очень пригодилась. Это были такие части как а) разбор кода при наличии новых (определяемых программистов) операторов (с приоритетом и ассоциативностью), и б) резолвинг имён (то есть дано имя 'foo' и надо найти декларацию - переменной, метода, типа и так далее). Для разбора кода с определяемыми операторами мне нужно было перебрать все варианты (и доказать, что это единственный возможный способ разбора выражения). А для резолвинга имён правила поиска были уж очень сложными. Без поиска решений с бэктрекингом было очень сложно писать для них код.
Так вот, конечно я первым делом взглянул на реализации пролога (для JVM). Но увы, ни одна из них мне не подошла. По той причине, что данные (факты и правила) содержались в самой программе. Чтоб использовать внешний пролог мне нужно было-бы экспортировать все данные из своей программы в прологовское представление, что само по себе достаточно трудоёмко. И плюс, эти данные постоянно могут меняться (удалили переменную - беги в пролог и сообщай, что такой переменной больше нет). И мне пришлось написать свою пролог-подобную систему. Просто из-за того, что эти две под-системы (компилятор и система поиска решений) были очень тесно связаны.

Другой пример. Пишут компьютерные игры. У них есть несколько отдельных частей - движок игры (то, что рисует), модель мира (дизайн уровней, данные для движка), сценарий игры. Они могут быть достаточно независимыми, то есть графический движок совершенно не зависит от дизайна уровня и сценария игры и так далее. Тогда движок пишут на С/C++, мир моделируют в отдельном редакторе (вообще-то это тоже такой DSL, без текстового представления), сценарий кодируют на скриптовом языке. Есть несколько точек соприкосновения этих независимых частей (скажем, движок определяет, что мы попали в пределённую точку на карте мира и вызывает для неё интерпретатор скриптовой функции), но их не много. Такой вариант - вполне жизнеспособный для гетерогенного программирования. Завели по языку на каждую часть проекта, и работаем.
Но эти части могут оказаться и очень зависимыми, сильно связанными друг с другом. Например, динамическое изменение мира вызываемое скриптами (вызываемыми по сценарию игры или в зависимости от действий пользователя). В этом случае нам надо почти всё экспортировать/импортировать методов между движком и скриптами. Нам надо менять модель мира из скриптов. Нам надо в модели мира укзывать вызываемые скрипты. И так далее. Работа по связыванию всего этого вместе может оказаться больше, чем если писать всё это на одном языке... Как-то я пробовал к 3D игрушке прикрутить скрипты на TCL... прикрутил, конечно, но либо функциональность у скриптов получалась минимальная, либо почти всю логику программы пришлось-бы писать на TCL, а это жуткий тормоз для реал-таймовой 3D игры.

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

Reply

raydac March 20 2009, 13:44:16 UTC
да, языки могут быть разными, но желательно работать в одной среде, тут согласен..
я то явовский пролог опенсорсный подключал + соединил его с ява-частью через аннотации, которые очень удобны для метапрограммирования и вроде ничего так заработало, удобно если ява функция превращается в предикат при помощи аннотации
(Reply) (Thread)

Reply

mkizub March 20 2009, 13:49:12 UTC
Кстати, какая это была реализация, кто умеет подхватывать явовские методы по аннотации?

Reply

raydac March 20 2009, 13:54:28 UTC
я взял опенсорсный tuProlog и написал к нему расширение которое аннотации разбирало и формировало на лету из класса прологовскую библиотеку автоматически приводя и переводя списки и типы данных туда-обратно что делало работу с явой для пролога прозрачной.. единственный минус - tuProlog написан мегатормознуто и очень медленный, хотя пытался его зарефакторить, надо будет свою реализацию писать эдинбургского

Reply


Leave a comment

Up