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

[sergeydmitriev]

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

Comments

[s1m]

Любой мало-мальски грамотный компилятор на первых шагах превращает исходный текст программы в DAG(Directed Acyclic Graph), над которым потом и идет работа. В процессе оптимизации строятся другие графы. В чем новизна-то? В том, что бы вместо получения высого-производительно машинного кода с помощью достаточно сложных в реализации алгоритмов, просто интерпретировать DAG?

[sergeydmitriev]

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

Я говорил об интерпретаторе, потому что его намного легче написать для начала, но поскольку модель ядра проста (это - набор команд, память и стек) то конечно же возможно будет написать и различные компиляторы.

[s1m]

Процесс компиляции классической текстовой программы в обычный код может выглядеть (и часто выглядит) вот так:

1) текст программы
2) граф
3) коды абстрактной стековой машины
4) байт-код (тройки или четверки)
5) ассемблерные инструкции
6) машинный код

В интерпретаторе отсутствуют шаги 5-6 (самые сложные). Иногда отсутствует шаг 4, можно исполнять сразу стековую машину, хотя это и неудобно, на мой взгляд.

Вы, фактически, предлагаете убрать шаг 1, т.е лексер и грамматику.

Грамматика, кстати, определяет язык. Так что без нее говорить о каких-либо "языковых конструкциях" не совсем уместно ;-)

[it_romance]

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

Фактически такое представление программы нас сводит к ручному выполнению того, что делает компилдятор - построение DAG и CFG (Control Flow Graph - граф потока управления, в котором ребра - инструкции перехода - видимо тот самый граф, что Вы имели в виду)

Добавление новых ребер - это команды goto, которые осложняют работу оптимизаторов. И от которых стремятся отказываться (эту команду уже начинают убирать из языков программирования)

Рекомендую:
А. Ахо, Р. Сети, Д. Ульман. Компиляторы: принципы, технологии и инструменты.

[all_x]

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

[sergeydmitriev]

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

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

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

По поводу эффективности текстового представления по сравнению с картинками:Во первых я вовсе не предлагаю все рисовать мышкой

[all_x]

Я говорю, что семантические типы аналогичны объектам языка программирования. А семантическому классу соответствует то, что объединяет семантические типы

[sergeydmitriev]

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

[llemilio]

А чем это отличается от классических Грамматик?

[sergeydmitriev]

Классические грамматики описывают синтаксис языка, здесь же предложен механизм описания семантики

[llemilio]

Есть там какой-то тип грамматик, кажется вычисляемые или что-то подобное, которые как раз и есть то о чем вы говорите.

[alex_ep]

Я, отчасти, согласен с коллегами, которые замечают, что любой транслятор превращает программу в граф. Но да дело даже не в этом. Кстати в XP, вроде, входит (забыл как называется на семинаре Зиновьева это обсуждали) промежуточный код, в который должны транслироваться программы с ЛЮБЫХ языков. Меня вот что интересует. ООП подразумевает не только написание ПРОГРАММЫ (ОО программирование) но и ее проектирование (ОО проектирование). CASE средства уверенно подходят к ситуации, когда из UML будет генериться код. Очевидно, что диаграмму можно представить и в С++ и в Java. Но этот подход позволяет решить одну из главных проблем ПРОИЗВОДСТВА: повторное использование (хотя бы на уровне паттернов проектирования :)). А как эту проблему будете решать Вы?

[alex_ep]

Трансляция из одного языка в другой всегда неоднозначна и сопровождается потерями. Нет никаких проблем стандартизовать промежуточный код (возьмите, например, просто инструкции x86) и в него транслировать все языки. Толку только с этого не много. Точно так же и с любым другим "универсальным" промежуточным языком.

[alex_ep]

Вы, конечно, правы. Идея, насколько я понимаю, там несколько другая. Разработчики средств программирования не нуждаются в написании компиллятора. Нужно написать транслятор в некий код. Оптимизировав его так, как хочется. А вот хороший компилятор из этого кода встрое в систему. Я не берусь описывать подробности - не специалист в этой области - но идея весьма соблазнительная. Например, очень удобно для специализированных встроенных систем.

[alex_ep]

От того, что вы (или кто-то другой) разделяете машинно-зависимые и машинно-независимые (но, возможно, зависимые от языка) оптимизации, ничего существенного для данной дискуссии не меняется.

И то, и другое, кстати, по определению - компиляторы.

Ничего не понял

[gdy]

Я может невнимательно читал, но чем это принципиально отличается от Лиспа?
Ещё вопрос, я так понял, вы хотите поддержать различные парадигмы программирования; у пролога, лиспа и явы общего, мне кажется, мало, чтобы имело смысл их объединять в одну систему, более высокоуровневую, чем стековая VM (.NET, скажем), или нет?
Что касается domain-specific язычков, то они, как я понимаю, реализуются в рамках какой-то одной заранее выбранной парадигмы, и от универсальности нижележащей платформы толку вроде снова мало?