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

Aug 31, 2003 16:52

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

language_oriented_programming

Leave a comment

all_x September 2 2003, 03:50:34 UTC
Я говорю, что семантические типы аналогичны объектам языка программирования. А семантическому классу соответствует то, что объединяет семантические типы.
Вы переносите ту же самую структуру на другой уровень. Получается что-то вроде метаклассов. Как раз метаклассы могут отличаться с точки зрения среды разработки.

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

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

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

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

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

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

Reply

sergeydmitriev September 2 2003, 04:51:18 UTC
Вот и хорошо - там где речь идет об алгоритме, то можно представять это человеку и в виде текста, я ж не против. Только во внутреннем представлении это всегда будет только граф. Это конечно накладывает некоторые ограничения на способы редактирования этого текста, так чтобы всегда соблюдалась целостность соответствующего графа, но это же по моему дает кучу преимуществ.

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

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

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

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

Reply

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

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

Reply

ex_juan_gan July 19 2004, 21:07:15 UTC
"Вычислительная модель", может, и бедна, да зато концептуальная богата.

Reply


Leave a comment

Up