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

[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, которые осложняют работу оптимизаторов. И от которых стремятся отказываться (эту команду уже начинают убирать из языков программирования)

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

[it_romance]

вернее ваш подход не подразумевает CFG в чистом виде.

Но проблемы скорости создания программ, мне кажется, остаются актуальными.