При современных способах программирования есть такая проблема - очень трудно описать компьютеру напрямую то что от него хочется. Каждый раз приходится переводить то описание задачи и ее решения, которое сидит а голове, на какой-нибудь язык программирования. При этом, к сожалению, многое из смысла задачи теряется
(
Read more... )
Вы переносите ту же самую структуру на другой уровень. Получается что-то вроде метаклассов. Как раз метаклассы могут отличаться с точки зрения среды разработки.
Что меня ограничивает при моделировании предметной области средствами языка программирования? Синтаксис. Для понятий я могу создать свои классы, сущностями будут объекты этих классов. Действия - методы. Это меня устраивает. Ограничения возникают с обработкой сущностей. Набор управляющих конструкций определяется синтаксисом языка (Надо заметить, не всегда. Почти забытые макрогенераторы позволяли это ограничение преодолеть. Но и они имели свои недостатки)
Едем дальше. Я говорил не про способы представления информации вообще. Данные, конечно, очень часто удобнее не в тексте представлять и редактировать по-другому (взять хотя бы звук. очень неудобно его как текст редактировать :) Я говорил о способах представления именно алгоритмов.
Что для них есть, кроме текста?
Да, конечно, текст в средах разработки синхронизируется с некоторым внутренним представлением. Я ж говорю, у меня в голове всё сейчас так повёрнуто, что именно внутреннее представление является основным для обработки. Но для человека удобнее текст. И как универсальный текст, соответствующий ASTу, можно использовать XML. Это альтернативное текстовое представление AST.
Если XML использовать, парсер как раз и не нужен. Но в трансляторе парсер - самое простое. А вот backend по сложности остаётся почти таким же.
Кодогенератор нужен для эффективности. Рано или поздно Ваш проект столкнётся с проблемой производительности, вот тогда станет понятно, что эта высокоуровневая модель работает достаточно медленно. Собственно, это ещё один скриптовый язык и получается. Хотя нет, скорее общая платформа для разработки скриптовых языков.
В Jelly можно расширять набор тегов. Это тоже платформа для создания специализированных языков. Единственное, чего не хватает - разного представления тегов в среде разработки. Но принципиальных сложностей нет, можно прикрутить. Где-то рядом с DTD, описывающем синтаксис конкретных XML тегов, надо будет описывать способ представления тега в среде разработки и другие свойства.
Reply
Другой вопрос что в современных программах алгоритмическая часть составляет часто только небольшой процент, а остальное - это скорее описание различных структур данных и связей между ними.
По поводу эффективности: поскольку базовая модель соответствует архитектуре компьютера, то должно будет достаточно легко перевести такую программу на язык машинных инструкций. Кстати, язык Форт, построенный на похожих принципах весьма и весьма эффективен.
По поводу простоты описания нового языка - я например описал более двух десятков кострукций из подмножества Java за один день, одновременно модифицируя ядро. Я не думаю что успел бы написать компилятор с такого языка за похожее время.
А насчет того что классами можно промоделировать все что угодно, я согласен только частично. Промоделировать - можно, но получается часто криво. А что, например, если понятию соответствуют более одного класса? Или например - моделирование аспектов на классах.
Вообще с моей точки зрения ООП - "классово-ориентированный" взгляд на вещи (то есть попытки все свести к классам) сильно обедняет наше воображение.
Reply
Забавно сделать содержательный язычок, способный раскрутить себя с небольшим ядром. Рефлексия и откладывание связывания идентификаторов с конструкциями (виртуальность, динамическая загрузка, линковка с внешними библиотеками) тому сильно мешают.
Reply
Reply
Leave a comment