Новый подход к программированию.

[sergeydmitriev]

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

Comments

[all_x]

Я плохо понимаю, как предложенный подход достигает указанной цели:

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

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

Мне кажется, что часто для этого достаточно мощного языка высокого уровня, той же Java. И трансляторов со специализированных языков в неё.
Получаем те же возможности по расширению языка и интеграции языков.
Задача задания семантических типов по сложности сравнима с написанием транслятора :)

Прошу заметить, что вы предлагаете способ обработки графа. То есть, с точки зрения интерпретатора, все семантические типы получаются "на одно лицо".
Точно так же, как классы Java. Имеем то же самое, только на другом уровне.

Во всех специализированных областях базовые конструкции управления ходом обработки данных (условие, цикл и т.п.) остаются актуальными. То есть,
речь может идти только о расширении набора конструкций специфическими для данной области.

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

Я по работе занимаюсь сходными вещами, немного думал на аналогичную тему.
В голове сложилось странное представление о роли синтаксиса программы.
Фактически, можно заменить синтаксис любого языка программирования XML представлением дерева синтаксичесго разбора. Получается альтернативный способ представления исходного текста программы. С синтаксисом, одинаковым для всех языков. Для каждого тега надо задать правила выполнения или трансляции. Расширение языка - добавление новых тегов и правил для них.
Это проще, чем расширение языка, ровно на трудоемкость модификации парсера.

Кстати, есть реализации executable XML, например, jelly, на котором пишутся plug-ins для maven. (см. http://jakarta.apache.org, http://maven.apache.org).
Всё-таки язык с нормальным синтаксисом удобнее.

[sergeydmitriev]

Спасибо за комментарий по существу!

По поводу аналогии семантических типов и классов:

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

По поводу эффективности текстового представления по сравнению с картинками:

Во первых я вовсе не предлагаю все рисовать мышкой.

Во вторых способов представления информации гораздо больше чем просто текст или просто диаграмма. Например - электронные таблицы, математические формулы, редакторы визуальных форм, редакторы сцен и т.д. Предлагается как раз обрести свободу по представлению информации оптимальным для ее отображения и редактирования способом. Кстати текстовые редакторы тоже постепенно перестают быть только редакторами набора букв - в современных IDE (например в IntelliJ IDEA) текст синхронизируется с некоторой сложной структурой типа AST.

Вы утверждаете: "Задача задания семантических типов по сложности сравнима с написанием транслятора"

Вот с этим я как раз не согласен. В предлагаемом подходе как раз одно из главных преимуществ - это простота описания семантичских типов, в первую очередь за счет отсутствия парсеров, грамматики и т.д. Кроме того не требуется писать кодогенератор/компилятор в другой язык или машинный код а вместо этого просто описывается поведение разных семантических типов в рамках простой модели.

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

[all_x]

Я говорю, что семантические типы аналогичны объектам языка программирования. А семантическому классу соответствует то, что объединяет семантические типы.
Вы переносите ту же самую структуру на другой уровень. Получается что-то вроде метаклассов. Как раз метаклассы могут отличаться с точки зрения среды разработки.

Что меня ограничивает при моделировании предметной области средствами языка программирования? Синтаксис. Для понятий я могу создать свои классы, сущностями будут объекты этих классов. Действия - методы. Это меня устраивает. Ограничения возникают с обработкой сущностей. Набор управляющих конструкций определяется синтаксисом языка (Надо заметить, не всегда. Почти забытые макрогенераторы позволяли это ограничение преодолеть. Но и они имели свои недостатки)

Едем дальше. Я говорил не про способы представления информации вообще. Данные, конечно, очень часто удобнее не в тексте представлять и редактировать по-другому (взять хотя бы звук. очень неудобно его как текст редактировать :) Я говорил о способах представления именно алгоритмов.
Что для них есть, кроме текста?

Да, конечно, текст в средах разработки синхронизируется с некоторым внутренним представлением. Я ж говорю, у меня в голове всё сейчас так повёрнуто, что именно внутреннее представление является основным для обработки. Но для человека удобнее текст. И как универсальный текст, соответствующий ASTу, можно использовать XML. Это альтернативное текстовое представление AST.

Если XML использовать, парсер как раз и не нужен. Но в трансляторе парсер - самое простое. А вот backend по сложности остаётся почти таким же.

Кодогенератор нужен для эффективности. Рано или поздно Ваш проект столкнётся с проблемой производительности, вот тогда станет понятно, что эта высокоуровневая модель работает достаточно медленно. Собственно, это ещё один скриптовый язык и получается. Хотя нет, скорее общая платформа для разработки скриптовых языков.

В Jelly можно расширять набор тегов. Это тоже платформа для создания специализированных языков. Единственное, чего не хватает - разного представления тегов в среде разработки. Но принципиальных сложностей нет, можно прикрутить. Где-то рядом с DTD, описывающем синтаксис конкретных XML тегов, надо будет описывать способ представления тега в среде разработки и другие свойства.

[sergeydmitriev]

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

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

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

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

А насчет того что классами можно промоделировать все что угодно, я согласен только частично. Промоделировать - можно, но получается часто криво. А что, например, если понятию соответствуют более одного класса? Или например - моделирование аспектов на классах.
Вообще с моей точки зрения ООП - "классово-ориентированный" взгляд на вещи (то есть попытки все свести к классам) сильно обедняет наше воображение.

[all_x]

Вычислительная модель Форта довольно бедна - бестиповый двухстековый калькулятор. Эффективно интерпретировать его можно, а оптимизюче компилировать в машинные инструкции трудно (бестиповость, невозможность отличить число от указателя, открытый потенциально бесбалансированный доступ к обоим стекам, и особенно стеку возвратов).

Забавно сделать содержательный язычок, способный раскрутить себя с небольшим ядром. Рефлексия и откладывание связывания идентификаторов с конструкциями (виртуальность, динамическая загрузка, линковка с внешними библиотеками) тому сильно мешают.

[ex_juan_gan]

"Вычислительная модель", может, и бедна, да зато концептуальная богата.