Существующее положение дел таково:
Программисты пишут тексты на языке программирования, эти тексты сохраняются в файлы, файлы хранятся на диске или в системе контроля версий.
Такой вид хранения удобен человеку(и то не всегда), но не удобен для автоматеческой обработки.
Преимущества для человека — простота подхода, возможность работы с программами средствами обработки текстовых файлов — простенькие редакторы и т.д.
С другой стороны, всякая попытка автоматической обработки встречает колоссальные трудности.
Каждая программа автоматической обработки должна содержать парсер языка, корректные парсеры современных языков сложны и недоступны каждому желающему в свободном виде.
Кроме парсера такая программа должна понимать форматы файлов проекта — для корректного разбора одного файла могут понадобиться все файлы проекта, а так же данные, сохраненные в бинарном виде во всяких компилированных источниках.
В общем, безумно сложно.
Некоторые IDE предоставляют API для этого, но качество этого API в руках его разработчиков.

Альтернатива — парсить текст программы сразу и сохранять его в базе данных в виде AST.
Ну, может не совсем AST, но по крайней мере с детализацией до отдельных функций,
сами функции может лучше представить в виде XML с обязательным разрешением всех имен внутри.
То, что не удалось распарсить, сохранять в сыром виде и пытаться обработать позже.
Для отображения код программы генерируется на основе представления в бд

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

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

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

Здравствуйте, Chrome, Вы писали:

C>Альтернатива — парсить текст программы сразу и сохранять его в базе данных в виде AST.

Обсуждалось сто тыщ раз. Воспользуйся поиском.

Здравствуйте, Lloyd, Вы писали:
L>Обсуждалось сто тыщ раз. Воспользуйся поиском.
ну простите за баян.
Поделитесь ссылкой или намекните ключевые слова для поиска, а то гугл идею не улавливает )

Здравствуйте, Chrome, Вы писали:

C>Поделитесь ссылкой или намекните ключевые слова для поиска, а то гугл идею не улавливает )
SymADE и mkizub пророк его.

Здравствуйте, Chrome, Вы писали:

C>Альтернатива — парсить текст программы сразу и сохранять его в базе данных в виде AST.
C>Ну, может не совсем AST, но по крайней мере с детализацией до отдельных функций,
C>сами функции может лучше представить в виде XML с обязательным разрешением всех имен внутри.
C>То, что не удалось распарсить, сохранять в сыром виде и пытаться обработать позже.
C>Для отображения код программы генерируется на основе представления в бд
Это же все равно не избавит от парсера, и никак не позволяет ему быть более простым.

C>Разумеется, все это может быть достигнуто в рамках традиционного способа хранения текста программ,
C>но предварительный разбор и сохранение в базу, похоже, данных дадут качественный эффект.
А что в этом плане меняет предварительный разбор и сохранение в базу данных? Только то, что проект не нужно полностью парсить перед загрузкой в IDE. Кстати, так в основном и делают.

C>Человек так же получает огромные преимущества.
C>Могут быть сознаны разные вьюверы и репорты для текстов программ(например, списки классов, списки фукций, списки изменений в проекте)
C>- индивидуальная настройка синтаксиса и форматирования (например, скобочки в том виде, который удобен каждому, пробелы где надо, отступы и т. д.)
Это реализовано кое где.

Здравствуйте, Chrome, Вы писали:

[]

А как же Lisp?

Здравствуйте, Chrome, Вы писали:

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

Этого недостаточно. Такой способ имеет преимущества и недостатки. И традиционный способ имеет
преимущества и недостатки. Но над недостатками текстового представления программ работают
уже десятки лет, и кое как научились с ними жить. А бороться с проблемами хранения в уже распарсенном
представлении (условно AST) не умеют совсем. Их даже толком не представляют во всей совокупности.
Просто не имели с этим дело.

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

Здравствуйте, Roman Odaisky, Вы писали:

RO>А как же Lisp?

А что у нас с Lisp-ом на этом фронте?

Здравствуйте, mkizub, Вы писали:

M>Здравствуйте, Roman Odaisky, Вы писали:

RO>>А как же Lisp?

M>А что у нас с Lisp-ом на этом фронте?

Программа на Lisp и есть синтаксическое дерево.

Здравствуйте, gandjustas, Вы писали:

RO>>>А как же Lisp?

M>>А что у нас с Lisp-ом на этом фронте?

G>Программа на Lisp и есть синтаксическое дерево.

Ну и что? Он же не Lisp-программы предлагает хранить в виде дерева, а программы вообще.
На всех языках.
Как-то в этом лисп может помочь? Или это разговоры о том, что все должны переходить на лисп?

Здравствуйте, mkizub, Вы писали:

M>Здравствуйте, gandjustas, Вы писали:

RO>>>>А как же Lisp?

M>>>А что у нас с Lisp-ом на этом фронте?

G>>Программа на Lisp и есть синтаксическое дерево.

M>Ну и что? Он же не Lisp-программы предлагает хранить в виде дерева, а программы вообще.
M>На всех языках.
M>Как-то в этом лисп может помочь? Или это разговоры о том, что все должны переходить на лисп?
На Lisp, вернее Scheme можете показать преимущества таких систем. Ибо солжного преобазования программа<->AST не потребуется.

Здравствуйте, gandjustas, Вы писали:

G>На Lisp, вернее Scheme можете показать преимущества таких систем. Ибо солжного преобазования программа<->AST не потребуется.

Нельзя, ибо не получится отделить мух от котлет.
В довесок к хранению программы в виде дерева, они имеют ещё определённый синтаксис, определённый минимальный базовый
набор семантики, и очень даже определённую модель исполнения вообще и рантайм в частности.
Простой пример. Chrome предлагал различные отображения кода, для удобства человека. Lisp/Scheme это могут предложить?
Не могут. Значит на них проверить преимущество этого подхода не удастся.

Здравствуйте, mkizub, Вы писали:

M>Здравствуйте, gandjustas, Вы писали:

G>>На Lisp, вернее Scheme можете показать преимущества таких систем. Ибо солжного преобазования программа<->AST не потребуется.

M>Нельзя, ибо не получится отделить мух от котлет.
M>В довесок к хранению программы в виде дерева, они имеют ещё определённый синтаксис, определённый минимальный базовый
M>набор семантики, и очень даже определённую модель исполнения вообще и рантайм в частности.
M>Простой пример. Chrome предлагал различные отображения кода, для удобства человека. Lisp/Scheme это могут предложить?
M>Не могут. Значит на них проверить преимущество этого подхода не удастся.

Почему не могут?
да и не в представлении дело, было высказано предположение о приемуществах хранения AST в репозитарии

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

Особо интересует выделенное. Как раз можно показать на примере Scheme.

Здравствуйте, gandjustas, Вы писали:

G>Почему не могут?
G>да и не в представлении дело, было высказано предположение о приемуществах хранения AST в репозитарии

В представлении тоже. А то так можно дойти до предложения проверить принципы ООП (наследование, полиморфизм,
инкапсуляция) на модульном программировании. В Си можно инкапсулировать методы в одном файле? Можно.
Вот на примере Си мы ООП и будем рассматривать

G>

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

G>Особо интересует выделенное. Как раз можно показать на примере Scheme.

а) по моему опыту, отдельная, и достаточно нетривиальная система контроля версий всё равно нужна будет,
и с ней проблем будет достаточно много (просто методы контроля версий для деревьев слабо разработаны,
в отличие от текста).
б) с каких пор в Scheme можно к каждому узлу прилепить произвольную мета-информацию?
Вот написано (+ a 1) — где тут можно вставить дополнительную информацию? Под-узлы семантически определяются
по индексу, а не по имени. Вот если бы в Scheme можно было писать
(operation: "+", expr1: a, expr2: 1)
тогда можно было-бы прилепить произвольную информацию, вроде
(operation: "+", expr1: a, expr2: 1; comment: "комментарий", execution: lazy)

Lisp/Scheme тут не при чём по совершенно тривиальной причине. Хранение и обработка программ в виде AST —
это среда программирования, грубо говоря IDE. А lisp/scheme — это языки программирования.
Понимаешь? Это просто разные вещи.

Здравствуйте, mkizub, Вы писали:

M>б) с каких пор в Scheme можно к каждому узлу прилепить произвольную мета-информацию?
M>Вот написано (+ a 1) — где тут можно вставить дополнительную информацию? Под-узлы семантически определяются
M>по индексу, а не по имени. Вот если бы в Scheme можно было писать
M>(operation: "+", expr1: a, expr2: 1)
M>тогда можно было-бы прилепить произвольную информацию, вроде
M>(operation: "+", expr1: a, expr2: 1; comment: "комментарий", execution: lazy)
А в каком языке такое вообще возможно?
Я так понимаю что произвольная метаинформация задается сторонними средствами, отличными от стандартных языковых.
Кстати (operation: "+", expr1: a, expr2: 1) такая запись в Scheme избыточна.

M>Lisp/Scheme тут не при чём по совершенно тривиальной причине. Хранение и обработка программ в виде AST -
M>это среда программирования, грубо говоря IDE. А lisp/scheme — это языки программирования.
M>Понимаешь? Это просто разные вещи.
Scheme предлагается не как решение всех проблем, а как один из компонент этого решения.

Здравствуйте, gandjustas, Вы писали:

M>>тогда можно было-бы прилепить произвольную информацию, вроде
M>>(operation: "+", expr1: a, expr2: 1; comment: "комментарий", execution: lazy)
G>А в каком языке такое вообще возможно?

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

G>Я так понимаю что произвольная метаинформация задается сторонними средствами, отличными от стандартных языковых.
G>Кстати (operation: "+", expr1: a, expr2: 1) такая запись в Scheme избыточна.

Вот именно. В Scheme это запись. И она избыточна, то есть мешает человеку удобно писать на этом языке.
А в нашей гипотетической среде — это не запись, а способ хранения и обработки информации (кода).
А "запись", отображение и редактирование — могут быть любыми. В том числе и отобразить этот кусок кода как
(+ a 1), как a+1, как (a 1 +), как "сложить а и 1" и так далее. В том числе — отображать или не
отображать дополнительные данные (вроде комментариев). Или редактировать дополнительные данные в отдельном
окне. Или ещё как угодно.

G>Scheme предлагается не как решение всех проблем, а как один из компонент этого решения.

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

Здравствуйте, mkizub, Вы писали:

M>Здравствуйте, Roman Odaisky, Вы писали:

RO>>А как же Lisp?

M>А что у нас с Lisp-ом на этом фронте?

Например SLIME — IDE для Lisp'a, состоит из двух частей: расширение для Emacs, и сервер работающий в интерпретаторе лиспа. Весь разбор AST, ложится на интепретатор. И например код который подбирает варианты для автозавершения, работает с AST, а не с простым текстом.

Здравствуйте, mishaa, Вы писали:

M>Например SLIME — IDE для Lisp'a, состоит из двух частей: расширение для Emacs, и сервер работающий в интерпретаторе лиспа. Весь разбор AST, ложится на интепретатор. И например код который подбирает варианты для автозавершения, работает с AST, а не с простым текстом.

Ты не поверишь, но любой IDE для любого языка работает с AST для автокомплита.
AST-шность лиспа даёт ему возможность встроенного мета-программирования и расширяемость. Если другие языки программирования хранить в виде AST — они тоже будут расширяемые и иметь возможности мета-программирования. Но при этом потеряют текстовое представление, или это должен быть настолько же общий синтаксис как у лиспа.
Предложи C-шникам писать программу в виде

(def-method foo
  (params (var a int) (var b String))
  (...)
  )

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

(def-method name:"foo"
  params:[(var name:"a" type:int) (var name:"b" type:String)]
  (...)
  )

но для читабельности это ещё хуже, чем упрощённый лисповский синтаксис. Или вон, были попытки писать код программ в XML, иначе чем как анекдот это никто не воспринял. А компы отлично работают с XML, им человеческая нечитабельность по барабану.

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

Здравствуйте, mkizub, Вы писали:


M>Ты не поверишь, но любой IDE для любого языка работает с AST для автокомплита.
M>AST-шность лиспа даёт ему возможность встроенного мета-программирования и расширяемость. Если другие языки программирования хранить в виде AST — они тоже будут расширяемые и иметь возможности мета-программирования. Но при этом потеряют текстовое представление, или это должен быть настолько же общий синтаксис как у лиспа.

Ты видимо ничего не понял. Речь идет о там что SLIME — не парсит файлы — это все на совести интерпретатора. SLIME — работает с родной AST, которая доступна _внутри интерпретатора_
Погляди еще на Smalltalk'овские среды разработки.

M>Простое же решение у этой проблемы — пусть код хранится как компу удобно, а отображается как человеку удобно.

Тут так и получается. С кодом среда общается так как компу удобно, с текстом работает человек, как удобно человеку.

И не надо троллить лисп.

M>Зачем сюда пихать лисп, если он всё равно не решает проблемы — и компу неудобно, и человеку неудобно.