Вышла новая статья о закономерностях в программировании. Приведу несколько выдержек из нее:
"При этом каждое следующее серьезное изобретение в области программирования — это почти всегда изобретение следующего интерфейса (это и есть «этаж») между системными «слоями»:
Изобретение операционной системы — это изобретение интерфейса между машиной и приложениями. Операционная система инкапсулирует в себе соотв. функции.
Изобретение языков программирования (например, ассемблера) — это изобретение интерфейса между кодом и человеком. Язык инкапсулирует в себе код.
Изобретение языков более высокого уровня – то же самое на следующей стадии.
Изобретение объектно-ориентированного программирования – это попытка создать интерфейс между функциями ("методами") и разработчиком.
Поэтому нынешнее явление миру «шаблонно-ориентированного программирования» [12, стр 163] — совершенно закономерный надсистемный переход от «объектов» и «классов» к их готовым контекстным сочетаниям.
Наверное, закономерен и дальнейший переход от «мышления отдельными шаблонами» к мышлению их готовыми сочетаниями (готовыми надсистемами из шаблонов). Давайте назовем эти готовые сочетания шаблонов «стилями». И тогда будет переход к «стильному программированию»".
"Вспомним «эволюцию языков программирования»:
Вначале были «нули и единицы»
Позже произошел первый надсистемный переход: «нули и единицы» сгруппировались в «мнемоники» — часто повторяющиеся готовые сочетания «нулей и единиц», например, для команды пересылки данных – MOV, для команды сложения – ADD и т.п. Т.е. появились «ассемблеры» [8].
Заметим: мнемоники, как бы сказали теперь, «инкапсулировали» (закрыли) «нули и единицы» от программиста. Стали «интерфейсом» между программистом и «нулями».
Затем произошел второй надсистемный переход: «простые ассемблеры» заместились «макроассемблерами», которые могли оперировать уже «группой мнемоник». И в этом смысле их стали называть «более мощными» [9].
Затем произошел третий надсистемный переход: «языки высокого уровня» вытеснили в узкую нишу «ассемблеры» и «макроассемблеры».
И здесь надо отметить сразу два «надсистемных эффекта»:
Каждая инструкция языка высокого уровня стала «еще мощней», т.е. компилировалась «сразу в десятки машинных команд».
Инструкция языка высокого уровня понималась целиком, а операторы, входящие в инструкцию сами по себе (вне ее контекста), не имели смысла. Подобно тому, как в литературе обладают своим смыслом целиком фраза или стихотворение, а слова, их образующие, этим смыслом не обладают [9].
В результате исчезло соответствие между теми командами, которые пишет программист, и теми командами, которые исполняет процессор.
Как известно, это позволило создавать языки, «заточенные» под предметную область:
Фортран – для решения инженерных задач и научных расчетов.
Кобол – для решения экономических задач.
Алгол-68, Паскаль – для обучения студентов программированию.
Бейсик – для написания диалогов пользователя с ЭВМ.
Си – для написания операционных систем, трансляторов, баз данных и других системных и прикладных программ.
Пролог – для методов автоматического доказательства теорем.
Ада – для моделирования параллельного решения задач. [7]
Изобретение языков высокого уровня позволило осуществлять перенос программы с машины на машину. И это позволило программисту (пишущему на высоком уровне) «не знать» или «знать минимально» устройство машины. Как бы сказали теперь, эти языки «инкапсулировали» (закрыли) «устройство машины» от программиста. Стали «интерфейсом» между программистом и компьютером.
Затем произошел четвертый надсистемный переход: «структурное программирование» вытеснило «линейное». Программа стала пониматься как группа (читай: «надсистема») модулей, которые можно писать отдельно, а проектирование в значительной степени стало пониматься как проектирование интерфейсов для общения модулей.
Затем произошел пятый надсистемный переход: … впрочем, дальнейшую логику вдумчивый Читатель продолжит сам."
У меня были похожие мысли. Сейчас можно выделить несколько слоев абстракции для программирования
1. Машинный код
2. Ассемблер
3. Языки среднего уровня (модульное программирование (си), процедурное программирование (pascal))
4. Языки высокого уровня (ООП, функциональное программирование etc.)
5. Паттерны проектирования, UML – диаграммы классов, взаимодействия, состояний
6. Паттерны предметной области (?) (более сложные UML диаграммы ? диаграммы пакетов?)
7. UML – диаграммы вариантов использования, различные Mind Maps, описания из предметной области
Сейчас наименее формализован уровень 6. (хотя чувствуется что там должен быть какой-то уровень)
очень хотелось бы чтобы все эти слои были доступны в IDE. Т.е. я ставлю квадратик "программа", и от него могу постепенной детализацией спуститься вниз вплоть до машинного кода.
Здравствуйте, x-code, Вы писали:
XC>У меня были похожие мысли. Сейчас можно выделить несколько слоев абстракции для программирования XC>
XC>1. Машинный код
XC>2. Ассемблер
XC>3. Языки среднего уровня (модульное программирование (си), процедурное программирование (pascal))
XC>4. Языки высокого уровня (ООП, функциональное программирование etc.)
XC>5. Паттерны проектирования, UML – диаграммы классов, взаимодействия, состояний
XC>6. Паттерны предметной области (?) (более сложные UML диаграммы ? диаграммы пакетов?)
XC>7. UML – диаграммы вариантов использования, различные Mind Maps, описания из предметной области
XC>
XC>Сейчас наименее формализован уровень 6. (хотя чувствуется что там должен быть какой-то уровень)
XC>очень хотелось бы чтобы все эти слои были доступны в IDE. Т.е. я ставлю квадратик "программа",
Графическое и текстовое представления — это всего лишь два представления (интерфейса к, если угодно) одной семантической сущности — программы. Блок-схемы можно иметь и для машинных кодов.
XC> и от него могу постепенной детализацией спуститься вниз вплоть до машинного кода.
Согласен, тут вопрос формализации. Если на каком-то уровне у тебя есть полная формализация программы — т.е. что должно быть на выходе, что на входе и компьютер может вывести (возможно, с подсказкой) как это надо делать, то тебе в принципе не нужно спускаться на более низкие уровни, поскольку там уже за тебя решено все автоматически. Сейчас большинство программ пишутся на уровне 4, все что выше слабо формализовано, от этого определенные проблемы в том числе с обратной связью, т.к. модель нижнего уровня может начать расходиться с моделью верхнего, но у нас есть мало инструментов для автоматического приведения их в соответствие, а также на задание constraints сверху вниз.
Здравствуйте, Андрей Хропов, Вы писали:
XC>>очень хотелось бы чтобы все эти слои были доступны в IDE. Т.е. я ставлю квадратик "программа", АХ>Графическое и текстовое представления — это всего лишь два представления (интерфейса к, если угодно) одной семантической сущности — программы. Блок-схемы можно иметь и для машинных кодов. XC>> и от него могу постепенной детализацией спуститься вниз вплоть до машинного кода. АХ>Согласен, тут вопрос формализации. Если на каком-то уровне у тебя есть полная формализация программы — т.е. что должно быть на выходе, что на входе и компьютер может вывести (возможно, с подсказкой) как это надо делать, то тебе в принципе не нужно спускаться на более низкие уровни, поскольку там уже за тебя решено все автоматически. Сейчас большинство программ пишутся на уровне 4, все что выше слабо формализовано, от этого определенные проблемы в том числе с обратной связью, т.к. модель нижнего уровня может начать расходиться с моделью верхнего, но у нас есть мало инструментов для автоматического приведения их в соответствие, а также на задание constraints сверху вниз.
Я скорее имел в виду представление не на уровне данных, а представление для самой IDE. UML тоже можно создавать в текством редакторе. Так сложилось, что для классического программирования текст — наиболее удобный формат. Наиболее компактный (на экране больше всего влезает именнт текстовой информации, в сравнении например с любыми диаграммами), и наиболее удобный для редактирования.
Вообще, для дальнейшего продвижения по уровням IDE становится не менее важной частью программирования чем ЯП.
Сейчас в основе лежит текстовый редактор, а поверх него навешиваются различные парсеры, Class Brower'ы и визуализаторы. А хотелось бы наоборот. Пусть программа как и раньше хранится в файлах в текстовом виде (это чем двоичные форматы), но при загрузке в IDE она СРАЗУ загружается в какое-то AST, и вся дальнейшая работа происходит уже через это AST. А текстовый редактор можно вызывать если программисту "по старинке" заходелось написать кусок кода (причем именно ограниченный кусок кода — метод или блок в методе), и сразу же когда программист закончит вводить код, этот код нужно преобразовать в AST. А если там ошибки — сразу же указать на них в окне редактора.
Тогда полностью исчезнет проблема синхронизации уровней, а заодно и куча других проблем.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>"При этом каждое следующее серьезное изобретение в области программирования — это почти всегда изобретение следующего интерфейса (это и есть «этаж») между системными «слоями»:
Я бы сказал, что важнее всего — это развитие железа и инструментов оптимизации, которые делают возможным применение новых уровней абстракции на практике. К примеру, в те времена, когда повсеместно писали макаронный код, было прекрасно известно что такое функция, но их редко использовали, "потому что вызов функции — это слишком дорого"
x-code,
XC>Сейчас в основе лежит текстовый редактор, а поверх него навешиваются различные парсеры, Class Brower'ы и визуализаторы. А хотелось бы наоборот. Пусть программа как и раньше хранится в файлах в текстовом виде (это чем двоичные форматы), но при загрузке в IDE она СРАЗУ загружается в какое-то AST, и вся дальнейшая работа происходит уже через это AST.
То что ты предлагаешь некоторые люди давно прошли. Читаем Пола Грэхема:
If you understand how compilers work, what's really going on is not so much that Lisp has a strange syntax as that Lisp has no syntax. You write programs in the parse trees that get generated within the compiler when other languages are parsed. But these parse trees are fully accessible to your programs. You can write programs that manipulate them...
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
XC>>Сейчас в основе лежит текстовый редактор, а поверх него навешиваются различные парсеры, Class Brower'ы и визуализаторы. А хотелось бы наоборот. Пусть программа как и раньше хранится в файлах в текстовом виде (это чем двоичные форматы), но при загрузке в IDE она СРАЗУ загружается в какое-то AST, и вся дальнейшая работа происходит уже через это AST.
LCR>То что ты предлагаешь некоторые люди давно прошли. Читаем Пола Грэхема: LCR>
LCR>If you understand how compilers work, what's really going on is not so much that Lisp has a strange syntax as that Lisp has no syntax. You write programs in the parse trees that get generated within the compiler when other languages are parsed. But these parse trees are fully accessible to your programs. You can write programs that manipulate them...
Читаем внимательно и понимаем, что Грэхем писал о совсем другом.
Здравствуйте, x-code, Вы писали:
XC>Вообще, для дальнейшего продвижения по уровням IDE становится не менее важной частью программирования чем ЯП. XC>Сейчас в основе лежит текстовый редактор, а поверх него навешиваются различные парсеры, Class Brower'ы и визуализаторы. А хотелось бы наоборот. Пусть программа как и раньше хранится в файлах в текстовом виде (это чем двоичные форматы), но при загрузке в IDE она СРАЗУ загружается в какое-то AST, и вся дальнейшая работа происходит уже через это AST. А текстовый редактор можно вызывать если программисту "по старинке" заходелось написать кусок кода (причем именно ограниченный кусок кода — метод или блок в методе), и сразу же когда программист закончит вводить код, этот код нужно преобразовать в AST. А если там ошибки — сразу же указать на них в окне редактора. XC>Тогда полностью исчезнет проблема синхронизации уровней, а заодно и куча других проблем.
Может я опять путаю, но по-моему это(см. выше) является частью концепций DSL.
Все привыкли, что программа хранится в виде текста – потока символов. Почему бы и нет? В конце концов, существует огромное количество инструментов для редактирования, отображения и манипуляции текстом.
...
При компиляции исходного кода компилятор представляет текст в виде древовидного графа, называемого «абстрактным синтаксическим деревом». Ту же самую операцию программист выполняет в уме, читая исходники.
...
...
Если мы хотим сделать создание языков легким, нужно отделить представление и хранение программы от самой программы. Мы должны хранить программы прямо в виде структурированного графа, что дает возможность вносить любые дополнения в язык. Временами текстовое хранилище вообще не нужно.
...
Проблема в том, что текстовый редактор глуп и не умеет работать с графом, лежащим в основе программы. Но при помощи соответствующих инструментов редактор сможет напрямую взаимодействовать с графом программы, что даст свободу выбора визуального представления.
Здравствуйте, x-code, Вы писали:
XC>Вообще, для дальнейшего продвижения по уровням IDE становится не менее важной частью программирования чем ЯП. XC>Сейчас в основе лежит текстовый редактор, а поверх него навешиваются различные парсеры, Class Brower'ы и визуализаторы. А хотелось бы наоборот. Пусть программа как и раньше хранится в файлах в текстовом виде (это чем двоичные форматы), но при загрузке в IDE она СРАЗУ загружается в какое-то AST, и вся дальнейшая работа происходит уже через это AST.
На самом деле так и делается в хороших IDE для хороших языков (читай не С++).
Так как сам работаю над этим могу сказать, что IDE оперирует именно с AST. Только вот от ткста отказываться не стоит. Это ошибка. В свое время был продукт (он наверно и сейчас существует) Gupta SqlWindows. Потом его вроде как переименовывали в Centura SqlWindows или SqlBuilder... давно было, уже не помню. Так вот у него как раз вместо радактора код был АСТ-редактор. Не могу сказать, что это было совсем неудобно, но реально плоский текст с поддержкой IDE все же удобнее... по-моему.
Забавно, что современные IDE уже не обходятся просто AST. Они практически полностью компилируют программу и вынимают из нее всю информацию от положения лексем, до типов (как объявленных в программе, так и импортируемых из внешних длл-ей). Так что они куда интеллектуальнее чем многие думают.
XC> А текстовый редактор можно вызывать если программисту "по старинке" заходелось написать кусок кода (причем именно ограниченный кусок кода — метод или блок в методе), и сразу же когда программист закончит вводить код, этот код нужно преобразовать в AST.
Как не странно "по старинке" писать удобнее. И банально удобнее работать с файлом или даже целым проектом, нежели с одельным методом, к примеру.
И ты уж совсем удивишся, но разработчикам IDE в сто раз было бы проще давать редактировать только один метод. Но они поступают сложнее. Они дают тебе править код где угодно и уже сами отслеживают что ты там на редактировал чтобы соотвествующим образом изменить внутренние структуры данных (в том числе и AST).
XC> А если там ошибки — сразу же указать на них в окне редактора.
Дык так и делают лучшие IDE. РеШарпер практически в риалтайме отображает ошибки. Мы в Интеграции для Немрла делаем это когда после небольшой паузы после того как программист закончил ввод. А когда кто-то пытается посмореть хинт или воспользоваться автодополнением, то обновление внутринних структур фарсируется. Так что фактически прогараммист всегда имеет возможность получить помощь от IDE.
XC>Тогда полностью исчезнет проблема синхронизации уровней, а заодно и куча других проблем.
К сожалению, тогда появится другая проблема. Дело в том, что очень сложно ввести сразу полностью корректный код. А такая IDE обязана будет отвергать некорректный ввод. В итоге программист попросту не сможет ввести код программы, или будет вынужден ужасно мучиться.
Современная IDE разрешает вводить любую фигню и в теневом режиме контролирует то что вводит программист. Если в коде появлются ошибки IDE их подсвечивает. Если код становится верным подсветка ошибок убирается.
Ну, а чтобы программисту было удобно ползать по коду IDE предоставляет такие вещи как список классов и фукнций вверху редактируемого файла. Возможности навигации по коду, поиску вхождений, контекстной подсветки, броузеров и т.п.
Так что вы просто плохо понимаете как устроена современная IDE и почему все сделано именно так, а не иначе.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>То что ты предлагаешь некоторые люди давно прошли. Читаем Пола Грэхема: LCR>
LCR>If you understand how compilers work, what's really going on is not so much that Lisp has a strange syntax as that Lisp has no syntax. You write programs in the parse trees that get generated within the compiler when other languages are parsed. But these parse trees are fully accessible to your programs. You can write programs that manipulate them...
Скажи ты что вообще современных IDE не видел? Или просто сообщение прочел по диаганали?
Какое отношение твоя цитата имеет к поддержке IDE?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > К сожалению, тогда появится другая проблема. Дело в том, что очень > сложно ввести сразу полностью корректный код. А такая IDE обязана будет > отвергать некорректный ввод. В итоге программист попросту не сможет > ввести код программы, или будет вынужден ужасно мучиться.
Так когда-то разные Бэйсики работали, на Спектруме точно так было
VladD2,
VD>Или просто сообщение прочел по диаганали?
Да, действительно, речь шла об главным образом об IDE, а не о AST. А я то сначала подумал, что человеку хочется просто писать в синтаксических деревьях...
Прочитал ещё раз: X>> А хотелось бы наоборот. Пусть программа как и раньше хранится в файлах в текстовом виде (это чем двоичные форматы), но при загрузке в IDE она СРАЗУ загружается в какое-то AST, и вся дальнейшая работа происходит уже через это AST.
То есть я так понимаю, что человек хочет иметь что-то типа редактора реестра, только вместо реестра там будет AST?
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>То есть я так понимаю, что человек хочет иметь что-то типа редактора реестра, только вместо реестра там будет AST?
Turtle.BAZON.Group,
LCR>>То есть я так понимаю, что человек хочет иметь что-то типа редактора реестра, только вместо реестра там будет AST?
TBG>Я так понял, что типа того, что сам же и показывал.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, x-code, Вы писали:
VD>На самом деле так и делается в хороших IDE для хороших языков (читай не С++).
к сожалению, для меня пока языки типа C# непреемлемы, т.к. разрабатываю системы реального времени. Со временем, конечно, когда количество процессорных ядер будут измеряться десятками, а поддержка кода MSIL наверняка будет аппаратной (?), C++ уйдет в прошлое, но вот сейчас очень не хватает всего того что есть под .NET (хотя даже там нет всего что хочется)
А пока я невооруженным глазом (!) по скорости открывания меню и диалогов определяю, написан ли софт на Java, каком-либо managed-языке .NET, или под реальный процессор, пишу на C++. Хотя уже достало
VD>Так как сам работаю над этим могу сказать, что IDE оперирует именно с AST. Только вот от ткста отказываться не стоит. Это ошибка. В свое время был продукт (он наверно и сейчас существует) Gupta SqlWindows. Потом его вроде как переименовывали в Centura SqlWindows или SqlBuilder... давно было, уже не помню. Так вот у него как раз вместо радактора код был АСТ-редактор. Не могу сказать, что это было совсем неудобно, но реально плоский текст с поддержкой IDE все же удобнее... по-моему.
AST-редактор для всего кода конечно же неудобен. Но, например, структуры и классы было-бы удобнее заполнять в виде таблиц, а не текста. Например, для полей данных минимальная таблица "доступ — тип — имя — значение по умолчанию — комментарий", для методов "доступ — тип — имя — раскрывающееся дерево с таблицей аргументов — комментарий".
функции и методы, безусловно, удобнее в виде текста, но чтобы в одном окне ("отсеке" окна? здесь есть место для новых концепций UI) было тело одного метода, а в какой-то заголовочной части была таблица аргументов, аналогичная таблице структуры или класса.
Речь идет просто об отказе от длинных "полотен" кода в котором свалены и классы и методы и все остальное.
Еще одна проблема — в программах нет связи с логикой предметной области. Я сейчас разрабатываю плагин для студии, чтобы добавить такую связь в простейшем варианте (по сути "иерархическая база букмарков с метаданными"). В C# эту область частично могут покрывать атрибуты. А то плоский список классов из нескольких сотен классов, в каждом из которых десятки методов и переменных, уже раздражает.
XC>> А текстовый редактор можно вызывать если программисту "по старинке" заходелось написать кусок кода (причем именно ограниченный кусок кода — метод или блок в методе), и сразу же когда программист закончит вводить код, этот код нужно преобразовать в AST. VD>Как не странно "по старинке" писать удобнее. И банально удобнее работать с файлом или даже целым проектом, нежели с одельным методом, к примеру.
Это как? Если я работаю с методом, ни разу не нужно было выходить за его пределы. Если мне нужно перейти к другому методу — пользуюсь деревом классов (к сожалению, его тоже приходится прокручивать)
А для проекта есть древовидное представление — дерево классов или то что будет вместо него на более высоких уровнях программирования. От него как раз никто и не предлагает отказываться.
VD>И ты уж совсем удивишся, но разработчикам IDE в сто раз было бы проще давать редактировать только один метод. Но они поступают сложнее. Они дают тебе править код где угодно и уже сами отслеживают что ты там на редактировал чтобы соотвествующим образом изменить внутренние структуры данных (в том числе и AST).
зачем так сделано? не вижу смысла. ради простой навигации по коду? поиск по файлам быстрее работает.
XC>>Тогда полностью исчезнет проблема синхронизации уровней, а заодно и куча других проблем. VD>К сожалению, тогда появится другая проблема. Дело в том, что очень сложно ввести сразу полностью корректный код. А такая IDE обязана
будет отвергать некорректный ввод. В итоге программист попросту не сможет ввести код программы, или будет вынужден ужасно мучиться.
В реалтайме проверять код ненужно, ИХМО это будет просто раздражать (как минимум — тормозами). Идеальный вариант — кнопочка типа "ввести" по которой файл/фрагмент кода будет преобразовываться в AST и при необходимости указываться ошибки.
Здравствуйте, x-code, Вы писали:
VD>>На самом деле так и делается в хороших IDE для хороших языков (читай не С++). XC>к сожалению, для меня пока языки типа C# непреемлемы, т.к. разрабатываю системы реального времени. Со временем, конечно, когда количество процессорных ядер будут измеряться десятками, а поддержка кода MSIL наверняка будет аппаратной (?), C++ уйдет в прошлое, но вот сейчас очень не хватает всего того что есть под .NET (хотя даже там нет всего что хочется)
Ради интереса — конкретизируйте, если не трудно, область применения разрабатываемых вами систем реального времени.
Мне казалось, что для встраиваемых систем(встраиваемых систем on-line обработки данных, встраиваемых АСУП и т.д.), для систем телекома и т.д. наоборот уже давно применяют Model-driven development(DSL+кодогенерация)
С промышленными вариантами MDD-систем-разработки встраиваемых систем я не знаком. В научных кругах наработок достаточно много(как в теории, так и в практике). Например, проект Ptolemy II, ориентированный на "modeling, simulation, and design of concurrent, real-time, embedded systems".
Концепция таких(как ptolemy) систем разработки — выбираем "правильную" для нас модель вычислений(сети Петри, конечные автоматы, как самые известные или CSP-Хоара,...) или создаём гибридную модель вычислений, затем моделируем в рамках выбранной модели нашу систему и генерируем код(в случае ptolemy возможна генерация Java, C++ кода и ранее была возможна генерация кода определённого семейства микропроцессоров Motorolы).
Вопрос: считаете ли вы такие системы разработки тем самым недостающим уровнем в проектировании систем, систем реального времени ? и вообще мой ответ в русле вопроса или я упустил суть проблемы(подменив её на свою) ?
Здравствуйте, x-code, Вы писали:
VD>>На самом деле так и делается в хороших IDE для хороших языков (читай не С++). XC>к сожалению, для меня пока языки типа C# непреемлемы, т.к. разрабатываю системы реального времени. Со временем, конечно, когда количество процессорных ядер будут измеряться десятками,
Ты очень сильно приувиличиваешь тормоза управляемых сред. Очень сильно. XC>а поддержка кода MSIL наверняка будет аппаратной (?),
Это не нужно. И даже вредно. Пусть лучше нормальный риск процессор сделают без x86'ой нашлепки. XC>C++ уйдет в прошлое, но вот сейчас очень не хватает всего того что есть под .NET (хотя даже там нет всего что хочется)
XC>А пока я невооруженным глазом (!) по скорости открывания меню и диалогов определяю, написан ли софт на Java, каком-либо managed-языке .NET, или под реальный процессор, пишу на C++. Хотя уже достало
Жаба да. .NET извини не поверю.
XC>AST-редактор для всего кода конечно же неудобен. Но, например, структуры и классы было-бы удобнее заполнять в виде таблиц, а не текста. Например, для полей данных минимальная таблица "доступ — тип — имя — значение по умолчанию — комментарий", для методов "доступ — тип — имя — раскрывающееся дерево с таблицей аргументов — комментарий".
Представил. Ужаснулся. ИМХО в морг. XC>функции и методы, безусловно, удобнее в виде текста, но чтобы в одном окне ("отсеке" окна? здесь есть место для новых концепций UI) было тело одного метода, а в какой-то заголовочной части была таблица аргументов, аналогичная таблице структуры или класса.
Зачем? чем плох простой текст? XC>Речь идет просто об отказе от длинных "полотен" кода в котором свалены и классы и методы и все остальное.
Те у тебя весь код в одном файле? Я тебя правильно понял?
XC>Еще одна проблема — в программах нет связи с логикой предметной области. Я сейчас разрабатываю плагин для студии, чтобы добавить такую связь в простейшем варианте (по сути "иерархическая база букмарков с метаданными"). В C# эту область частично могут покрывать атрибуты. А то плоский список классов из нескольких сотен классов, в каждом из которых десятки методов и переменных, уже раздражает.
А пространства имен тебя чем не устраивают?
XC>Это как? Если я работаю с методом, ни разу не нужно было выходить за его пределы. Если мне нужно перейти к другому методу — пользуюсь деревом классов (к сожалению, его тоже приходится прокручивать) в текстовом редакторе это сделать быстрее. А в IDE которая предоставляет навигацию вобще моментально. И не нужны тут никакие деревья.
VD>>И ты уж совсем удивишся, но разработчикам IDE в сто раз было бы проще давать редактировать только один метод. Но они поступают сложнее. Они дают тебе править код где угодно и уже сами отслеживают что ты там на редактировал чтобы соотвествующим образом изменить внутренние структуры данных (в том числе и AST). XC>зачем так сделано? не вижу смысла. ради простой навигации по коду? поиск по файлам быстрее работает.
Может попробуешь поработать и ReSharper'ом? Иначе если ты не видил ничего умнее IDE для С++ разговаривать с тобой о IDE не имеет смысла.
XC>В реалтайме проверять код ненужно, ИХМО это будет просто раздражать (как минимум — тормозами). Идеальный вариант — кнопочка типа "ввести" по которой файл/фрагмент кода будет преобразовываться в AST и при необходимости указываться ошибки.
Нет никаких тормозов. Те вобще нет.
Всеравно у тебя процессов постоянно бездействует вот пусть и подсвечивает ошибки в отдельном потоке с очень низким приоритетом.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
А я то сначала подумал, что человеку хочется просто писать в синтаксических деревьях...
в текстовом редакторе это сделать быстрее. А в IDE которая предоставляет навигацию вобще моментально. И не нужны тут никакие деревья.