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

M>2. Оно устареет уже через несколько месяцев.

Вообще вся эта затея с SymADE больше похожа на "пойди туда, не знаю куда — найдти то, не знаю что".
Никто этого ещё не делал, никто не сталкивался со всеми проблемами, и курс приходится менять "на ходу".
Я простой пример приведу.
Поставил я себе задачу реализовать IDE для редактирования своего текста.
И решил её! Сделав достаточно сложным язык отображения дерева (для структурного редактора), потратив кучу времени и сил — решил.
Но оказалось, что при всём удобстве редактирования деклараций (в структурном редакторе), редактирование выражений практически невозможно. Жутко неудобно.
У меня было два варианта — делать как в MPS, подставляя костыли и хаки. Или придумать кардинальное решение.
Ясен пень, я пошёл по второму варианту. Это ясно уже из того, что если б я искал простых путей, то мне даже идея SymADE-а не пришла бы в голову.
Итак, я стал искать решение для проблемы редактирования выражений.
Промежуточной идеей было (автоматически, при начале редактирования) конвертировать дерево выражения в список или текст, его редактировать, и обратно компилировать в дерево. Реализовал прототип. Тоже потратил кучу времени.
В процессе долгих и мучительных размышлений я обобщил эту идею редактирования выражений до идеи создания проекций дерева в другое дерево, при котором оба дерева остаются свянанными, и могут синхронизировать свои состояния после изменений.
В результате, оказалось не нужнной такая сложность для языка отображения и структурного редактирования дерева, и ненужным реализация автоматического конвертирования деревьев выражений в списки токенов. Объём работы размером в пол-года (или больше) фактически прийдётся выкинуть. И реализовывать эти самые проекции деревьев (чем я сейчас и занимаюсь) и их редактирование, синхронизацию и пр.

Да, я сходил в одно место, нашёл там тупик, теперь иду в другое место, и там надеюсь найти проход дальше. И когда пройду дальше — там тоже окажется ещё один лабиринт. Се ля ви. Но дорогу осилит идущий.

T>>Обобщённое программирование? GADT? Зависимые типы?
T>>Ты всё это знаешь, точно можешь указать на слабые места?
V>Программы — это код+данные. Структуры данных и связанный с ними код не всегда удобно описывать (даже не сам код, а мета-код), используя существующие ЯП, иногда хочется наиболее удобного и декларативного (банальности, собственно).

Чем не декларативны обобщённое программирование? Чем не декларативны GADT? Чем не декларативны зависимые типы данных?

Ты не отвечаешь на вопросы.

T>>Lazy не навязан, а предложен для использования в качестве самого удобного из умолчаний.
T>>Тебе тоже объяснить, почему он удобен, или ты, всё же, читаешь RSDN?
V>Он неэффективен для обработки массивов заведомо известной длины или иных фиксированных структур, например, мне для VoIP, кодеков, фильтрации и работы с сокетами — это седло для коровы. Для GUI — аналогично. Всё хорошо к месту.

"Неэффективен" — это как? Как я понимаю, с точки зрения "производительности", то есть скорости выполнения. Так? Про производительность программиста здесь ни слова.

Из чего заключаю, что, вот, ещё один сторонник преждевременной оптимизации. Блин.

И эти люди указывают мне на "lazy". Да ещё говорят, что я "разговариваю, как сам с собой."

"Врачу, излечися сам."

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

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

T>Ты уж извини, но дальше мне совсем неинтересно. Ты меня не поймёшь, поскольку не желаешь отвечать на вопросы, задаваемые тебе, а я не хочу объяснять тебе долго и нудно истины, ставшие для меня прописными.

А как же просвещение? Тут вас много читают. У вас очень здоровый (в смысле достаточно конструктивный) спор. Я, например, много почерпнул и от тебя и от твоего оппонента.

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

M>>2. Оно устареет уже через несколько месяцев.

M>Вообще вся эта затея с SymADE больше похожа на "пойди туда, не знаю куда — найдти то, не знаю что".

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

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

M>>Вообще вся эта затея с SymADE больше похожа на "пойди туда, не знаю куда — найдти то, не знаю что".

E>Имхо: после того, как автор проекта приходит к пониманию того, что он не знает цели своего проекта, то самое лучшее (как для проекта, так и для автора) -- выбросить проект нафиг.

Подставился ты...
Любое творчество — есть путь в неизвестное.
Неужели ты до такой степени банальный?

E>>Имхо: после того, как автор проекта приходит к пониманию того, что он не знает цели своего проекта, то самое лучшее (как для проекта, так и для автора) -- выбросить проект нафиг.
M>Подставился ты...
M>Любое творчество — есть путь в неизвестное.

Это неверно.

Например, иконопись. Творчество, и результат всегда заранее известен (за исключением качества исполнения).

Технический дизайн.

Да ещё найдётся, если поискать.

T>>Ты уж извини, но дальше мне совсем неинтересно. Ты меня не поймёшь, поскольку не желаешь отвечать на вопросы, задаваемые тебе, а я не хочу объяснять тебе долго и нудно истины, ставшие для меня прописными.

L>А как же просвещение? Тут вас много читают. У вас очень здоровый (в смысле достаточно конструктивный) спор. Я, например, много почерпнул и от тебя и от твоего оппонента.

Я не железный, всё не могу.

Лучше я где-нибудь в другом месте себя проявлю.

И на ниве просвещения тоже.

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

M>>Любое творчество — есть путь в неизвестное.

T>Это неверно.
T>Например, иконопись. Творчество, и результат всегда заранее известен (за исключением качества исполнения).

Ю. М. Лотман. "Каноническое искусство как информационный парадокс". Ознакомься.

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

M>Любое творчество — есть путь в неизвестное.

Ну ты уж определись -- творчеством ты занимаешься, или продукты делаешь.

M>Неужели ты до такой степени банальный?

Я -- да, банальный. Не совсем стандартный, но банальный.
А вот инвесторы, они еще банальнее меня. Им банально жалко денег на твое творчество.

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

T>Из чего заключаю, что, вот, ещё один сторонник преждевременной оптимизации. Блин.

Замечание про массивы фиксированной длины было ключевым. На это всё завязано в VoIP, в первую очередь — управление памятью. Нет никакой преждевременной оптимизации, отсутствие постоянного перераспределения памяти как такового — это условие существования, без этого система не живёт. Считай, что входное условие. Там 50 фреймов в секунду на участника, да в обе стороны, да через кодеки и препроцессоры, да в минимальном варианте на lazy это будет по 300 выделений памяти в сек. на участника, и скольких же пользователей одновременно потянет сервак? А пару тысяч, хотя бы, потянет? А десять?


T>И эти люди указывают мне на "lazy". Да ещё говорят, что я "разговариваю, как сам с собой."

Есть немного. Суть всех подобных разговоров — это разговоры о приоритетах, даже если явно это слово не используется. Так вот, задачи "просто реализовать" даже не стояло, ибо никто и не сомневался. Надо реализовать в определённых характеристиках.


T>Ты уж извини, но дальше мне совсем неинтересно. Ты меня не поймёшь, поскольку не желаешь отвечать на вопросы, задаваемые тебе, а я не хочу объяснять тебе долго и нудно истины, ставшие для меня прописными.

А как я тебе буду объяснять банальности про зависимые типы и обобщённое программирование, если всё-равно речь упрётся в итоге в много раз обжёванные здесь DSL? Твой поинт в том, что ты считаешь возможности синтаксиса, предоставляемыми некоторыми ЯП (Хаскелем, например) вполне достаточными, а мне даже лень это обсуждать, почему вовсе не являются достаточными — у меня другие требования. Мне не нужны "достаточно широкие возможности", мне нужен именно тот синтаксис декларации данных/метаданных, который хочется использовать для конкретной ситуации, без подгона под "существующие широкие возможности". В условиях активно-используемых генераторов парсеров я могу и хочу себе это позволить.

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

M>>>Любое творчество — есть путь в неизвестное.
T>>Это неверно.
T>>Например, иконопись. Творчество, и результат всегда заранее известен (за исключением качества исполнения).
M>Ю. М. Лотман. "Каноническое искусство как информационный парадокс". Ознакомься.

Ознакомился.

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

Это не отрицает предсказуемость результата канонического искусства.

И чтобы два раза не вставать.

"Пойди туда, не знаю куда, принеси то, не знаю, что" лучше всего делать с наиболее быстроходными и грузоподъёмными инструментами.

Java/Kiev в эту категорию, по-моему, не попадают.

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

T>Ознакомился.

Угу. До смысла парадокса, как я понял, ты не дочитал.

T>Это не отрицает предсказуемость результата канонического искусства.

То есть разницы между лубочными иконами и "Троицей" Рублёва ты не видишь? А если видишь, то как ты объяснишь, что и те и те писались по канону, а результат разный?

T>И чтобы два раза не вставать.

T>"Пойди туда, не знаю куда, принеси то, не знаю, что" лучше всего делать с наиболее быстроходными и грузоподъёмными инструментами.

T>Java/Kiev в эту категорию, по-моему, не попадают.

Попадают. Мне хочется это практически сделать, а не теоретически. Толку-то, что я напишу IDE которая ни в одну ОЗУ не влезет, по причине immutable структуры дерева программы, занимающего 100 мег в памяти. Покажи мне вообще хоть одну приличную IDE написанную на хаскеле. На лиспе я одну знаю, emacs называется — мне такой не подходит, в том числе и по причинам тормознутости.

T>>"Пойди туда, не знаю куда, принеси то, не знаю, что" лучше всего делать с наиболее быстроходными и грузоподъёмными инструментами.
T>>Java/Kiev в эту категорию, по-моему, не попадают.
M>Попадают. Мне хочется это практически сделать, а не теоретически.

То есть, быстрого прототипа для выяснения реализуемости идеи ты не делал. Это великолепно.

M>Толку-то, что я напишу IDE которая ни в одну ОЗУ не влезет, по причине immutable структуры дерева программы, занимающего 100 мег в памяти.

По-моему, это нормально. Даже мало. Тот же Eclipse на работе не влазит в гиг, а я всего десяток файлов смотрю.

M>Покажи мне вообще хоть одну приличную IDE написанную на хаскеле.

Я IDE не пользуюсь. Глядел ли ты на http://haskell.org/haskellwiki/Leksah хотя бы?

M>На лиспе я одну знаю, emacs называется — мне такой не подходит, в том числе и по причинам тормознутости.

А также по причине того, что он готов и его можно использовать.

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

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

tid>>У тебя есть более подробная информация: структура Symade, описания классов, пакетов, форматов данных; что сделано, что планируется сделать?

M>Простой ответ — нету.

Я имею ввиду не документацию, а небольшое описание деталей. То есть почему ты создал свой язык, чем он отличается (хотя бы в основном) от java, какие новшества. В двух словах как устроена среда и общее видение дальнейшего процесса.

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

tid>Я имею ввиду не документацию, а небольшое описание деталей.

tid>То есть почему ты создал свой язык, чем он отличается (хотя бы в основном) от java, какие новшества.

Язык я свой создал по причине того, что я люблю делать языки программирования.
Желание улучшить свой текущий язык программирования я пытался неоднократно (лет 15 назад пытался сделать макросы для С/С++ вроде тех, что сделаны в Nemerle).
Лет 10 назад написал таки расширенную java. Понадобавлял туда кучу всего, и в результате пришёл к тому, что это это не выход. С ростом количества фич в языке они начинают конфликтовать друг с другом, всё сложнее поддерживать целостность языка. И самое обидное — всех необходимых фич в язык не добавишь. Каждый новый проект, который я пытался делать на своём языке — требовал новых возможностей, или изменения поведения старых. В результате я пришёл к выводу, что не имеет смысла развивать язык добавляя к нему новые возможности, а нужно сделать нормальные возможности для мета-программирования.
Вариант с макросами я рассматривать не стал (был опыт попытки их реализации, и все ограничения и проблемы этого подхода были мне знакомы).
Пару лет я просто ничего не делал, поскольку не знал что именно делать.
Потом мне пришла в голову идея, которая рано или поздно приходит в голову всем разработчикам языков и IDE — использовать дерево (внутреннее представление) вместо текста.
Я сделал прототип, поплясав от самой печки, то есть имея в распоряжении только понятия "символ", "пространство" (контейнер), попробовал реализовать через них всё остальное. Ну, чтоб уж совсем мета-программирование получилось. В результате я понял, что теория это хорошо, но это уж слишком высокий уровень абстракции, надо что-то более приземлённое взять в качестве основы, а то так оно в теории работать и останется.
Я взял свой компилятор, и переписал его в соответствии со сформировавшимися к тому времени представлениями о SOP (семантическом программировании).
Все (почти все) расширения, которые я добавлял (и которые появились в результате развития java), я сделал не hardcoded, а в виде плагинов. Сделал удобную работу с семантическими понятиями (узлами дерева программы), добавил упрощённое мета-программирование (когда дерево не вручную модицицируется, а макросами, которые реализованы просто в виде ещё одного плагина).
Ну и стал делать IDE к этому компилятору. Вот этот процесс длится уже несколько лет (с перерывами на рождение ребёнка), в свободное от основной работы время.

В язык понадобавлено много чего (ещё когда он был просто расширением к яве, а не своеобразной библиотекой для мета-программирования).
Multimethods, closures, mixins, forwarding (наследование агрегированием, делегированием), properties (доступ к полу через getter/setter), user-defined operators & operator overloading, assert/trace/work-by-contract, встроенный движок логического программирования (поиск решений с бэктрекингом, что-то вроде интегрированного пролога), switch по типам, goto, битовые поля (упакованные битовые поля), части из pizza (был такой проект у Мартина Одерски, который перерос в явовские параметризованные типы и scala), параметризованные типы без erasure (параметры доступны в рантайме), расширения для работы с деревьями, для генерации специальной мета-информации для SymADE, view (что-то вроде existential types) и так далее.

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

tid>В двух словах как устроена среда и общее видение дальнейшего процесса.

Весь код доступен среде в виде семантических узлов. Работает с ними она через мета-информацию сгенерированную компилятором.
Есть язык для задания отображения для конкретных узлов, это отображение рисуется на Canvas, или (если присутствуют только текстовые элементы) может быть использовано для экспорта в текстовое представление.
Редактор — структурный. Можно посмотреть на документ с картинками (на сайте есть, в документации). Собственно, идея практически та-же, что и в MPS (поскольку задача одна и та-же — редактирование непосредственно дерева программы). Вообще, нынешнее состояние очень похоже на MPS, только менее доделанное.
Разница в том, что у меня в дереве хранятся семантические узлы, а у MPS синтаксические.

Что дальше.
Главная задача для развития среды — это наконец реализовать IDE для редактирования кода на моём языке программирования.
Тут надо решить ещё много задач. Главная задача — доделать projections семантического дерева в синтаксические деревья.
Вторая задача — это редактирование синтаксических деревьев. Что до редактирования декларативной части — оно было удобно и раньше, с ним почти никаких проблем.
А вот редактирование списков токенов надо доделывать. Теоретически до такого уровня, чтоб его редактирование было максимально похоже на редактирование текста Word и прочих WYSIWYG редакторах. Сам GUI написан на Java, и почти вся эта работа может делаться в Java.
Есть ещё работа по собственно IDE — фоновая компиляция, удобное выведение ошибок и прочее.
Есть задачи по работе с деревьями как таковыми. Например, сейчас они дампятся в XML. Это и долго (для экспорта и импорта), и приводит к необходимости линковки (резолвинга) символов после загрузки дерева из дампа. Хотелось-бы написать экспорт в binary формат, который просто можно было-бы сохранить и загрузить как snapshot дерева. Это было-бы значительно быстрее и решило ещё несколько мелких проблем. Ну, и экспорт/импорт этого бинарного формата в текст (вроде XML или json и пр). Эту часть работы можно легко сделать на обычной Java.
Далее, необходимо что-то делать с версионностью семантических понятий. Они имеют тенденцию меняться со временем, и надо сделать с одной стороны, поддержку указания версий, и с другой стороны, конвертацию из старой версии в новую. Попутно это приведёт к созданию специального языка описания трансформации дерева, возможности декларативно задавать простые projections дерева и пр. Эту часть работы можно почти полностью делать в SymADE (как IDE), без глубокого залазанья в потроха компилятора.

Безнес-часть проекта заключается в доработке IDE до состояния беты, и выхода на бизнес-ниши где технология вроде SymADE/MPS может быть использована (с большим эффектом) уже сейчас, при минимальной адаптации. Соответственно, если инвесторы дадут денег (от 0.5 до 1 лимона баксов), то приоритеты изменятся, комманда будет заниматься не столько доведением SymADE до состояния возможности редактировать код для моего компилятора, сколько доведением его до состояния возможности редактировать код для программ из этих ниш на IT рынке.

Есть ещё задачи, которые могут стать приоритетными при изменении условий — сделать плагин для Eclipse (GUI умеет работать как со Swing, так и с SWT), перейти на .NET платформу (написать backend, заменить прямую работу с базовыми объектами вроде string, hashtable на работу с концепциями строк, хэш-таблиц, для которых будет генерироваться разный код для JVM и .NET) и так далее.

Когда будет нормально работать IDE, к этому времени уже, наверное окончательно, установится API компилятора и внешний вид GUI, и можно будет писать документацию и систему тестирования. То есть когда будет бета — надо будет делать релиз

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

M>Подставился ты...
M>Любое творчество — есть путь в неизвестное.
M>Неужели ты до такой степени банальный?

Такое творчество — путь в никуда.
Творчество — процесс поиска пути к цели, сама же цель вполне известна.

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

VE>Творчество — процесс поиска пути к цели, сама же цель вполне известна.

Цель то у меня известна — реализовать SOP. Мне не известно ни как к ней прийти, ни как реализация (SymADE) будет выглядеть в конечном итоге.

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

M>Это всё должно работать в динамике. Модель динамическая с непредсказуемыми элементами, отображение динамически должно меняться в зависимости от команд пользователя и пр.

Именно для подобного сценария замечательно подходить WPF из 3-го дотнета. Никакой SWING так не умеет, ибо у него отображение<=>контрол, в то время как в WPF контрол<=>(много отображений) + настраиваемые шаблоны, декларативный биндинг и т.д.

Тем паче, если у тебя есть в планах поддержка дотнета, то сделай паузу, потрать месяц-другой на плотную работу с WPF, оно того стоит. SWING — прекрасно разработан, образец того, как надо абстрагироваться от оконных систем. WFP — образец того, как надо абстрагироваться от GUI как такового. Там, где в SWING настраиваются скины, в WPF настраиваются сами принципы отображения и поведения, да еще с потрясающим уровнем декларативности.

M>Но если у тебя есть мысли, почему это надо делать именно на .NET, а не Java или ещё чём — расскажи.

В основном из-за того, чтобы не делать приличную часть работы по дизайнеру, а сосредоточиться на "ядре".
Генерики, опять же, экономят много времени, ибо доступны в run-time и можно использовать для заранее неизвестных типов. Опять же, хранить данные как value-types в коллекциях — это эффективно использовать память ввиду понижения косвенности обращений к данным. В этой задаче и так предполагается крайне высокий уровень косвенности, всё априори будет тормозить, а на value-type можно уменьшить косвенность примерно вдвое.

А для твоего языка — прекрасный шанс начать уходить от конкретных примитивных классов, завязанных на конкретную платформу, типа строк, чисел, основных коллекций и т.д.

Да и что-то мне подсказывает, что под .Net ты гораздо легче найдёшь волонтёров, ибо мейн-стрим джава-разработок как-то в другой области. Не хочу никого обидеть, но широкое использование XML джавистами и шараханье от задач кастомного парсинга — это не тот контингент, который тебе нужен. Путь себе своим контентом управляют на джумлах и иже с ним.

К тому же, когда переводил неоднократно наработки из Java в дотнет, то исходники становились заметно короче, иногда более, чем в полтора раза. И если GUI-программки при переводе оказывались короче раза в полтора, то интерпретатор Scheme оказался короче раза в два. Я проникся помнится, т.к. ясно увидел, что чем меньше использовано высокоуровневых билиотек в разработке, тем бесполезнее Java-платформа как таковая. А твоё ядро — это тот случай и есть, нет ничего из готового (кроме банальных коллекций).

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

M>Весь код доступен среде в виде семантических узлов. Работает с ними она через мета-информацию сгенерированную компилятором.
M>Есть язык для задания отображения для конкретных узлов, это отображение рисуется на Canvas, или (если присутствуют только текстовые элементы) может быть использовано для экспорта в текстовое представление.
M>Редактор — структурный. Можно посмотреть на документ с картинками (на сайте есть, в документации).

[...]

M>Что дальше.
M>Главная задача для развития среды — это наконец реализовать IDE для редактирования кода на моём языке программирования.

Немного оффтопик. Сразу оговорюсь, что моих познаний не достаточно, чтобы дать характеристику вашему с Сергеем спору по существу. У меня есть несколько замечаний по форме.

Я посмотрел картинки на твоём сайте и демо-документ. Имхо всё изложено излишне сложно, и общее впечатление остаётся из серии "тяжёлая громоздка хрень для редактирования XML", и даже XML в ней редактировать неудобно — надо лазить по пунктам меню, что-то нажимать. В общем вместо обещанного повышения производительности будет её значительное замедление. Имхо чтобы привлечь инвесторов, тебе надо сделать изложение более простым и доступным.

И я до сих пор не понял, кто будет основным потребителем твоей супер-IDE. Вряд ли программисты в классическом понимании, потому что твой очень абстрактный подход всегда будет проигрывать частным специализированным решениям в прикладных областях (ну не поверю я, что с его помощью можно сделать конкурентно способный кросплатформенный веб-сервер или хороший 3D-шутер). Скриптописатели бизнес-логики? аналитики? системные архитекторы? менеджеры? — у каждой из этих специальностей есть свои особенности и пожелания к инструментам. Без них даже самый замечательный в теории проект обречён на неудачу.

И наконец, о форме представления данных — да, в теории прямая работа с деревом может давать определённые преимущества. Но на практике мне предложенный в твоём демо-описании способ кажется очень неудобным. Мне кажется, что мышь и клавиатура — не самые подходящие для этого инструменты. И настоящий вопрос на 1M$ — на самом деле больше дизайнерский, чем научный — придумать устройство ввода, удобное для работы с графическим представлением иерархической структуры данных.

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

F>Немного оффтопик. Сразу оговорюсь, что моих познаний не достаточно, чтобы дать характеристику вашему с Сергеем спору по существу. У меня есть несколько замечаний по форме.

F>Я посмотрел картинки на твоём сайте и демо-документ. Имхо всё изложено излишне сложно, и общее впечатление остаётся из серии "тяжёлая громоздка хрень для редактирования XML", и даже XML в ней редактировать неудобно — надо лазить по пунктам меню, что-то нажимать. В общем вместо обещанного повышения производительности будет её значительное замедление. Имхо чтобы привлечь инвесторов, тебе надо сделать изложение более простым и доступным.

Это 10 с плюсом. Чтоб редактировать, надо что-то нажимать.
Я понимаю, что изложить можно попроще, но тогда может получится перл вроде этого.
Конечно, лазить по пунктам меню — вещь утомительная. Но нужная, когда ты не знаешь какую клавишу нажать, чтоб это действие было выполнено.
Можно писать коротко — "создайте новый узел", и пусть читатель догадывается, как его создать. Можно написать "нажмите Ctrl+N или выберите в меню Edit->New node для создания нового узла". Так будет длинно, и туманно — где-то лазить, что-то нажимать, почему компьютер сам не догадается, что мне нужно создать новый узел...

Удобно в нём редактировать. Я же редактирую, мне удобно. Это не plain text, по ощущениям больше похоже на работу в vi. Переключение между режимами ввода текста, ввода комманд, работы со словами-предложениями. Для редактирования деклараций мне практически так-же удобно, как текст набивать. Это если ты знаешь, какой текст набивать, а если не знаешь — то структурный редактор удобнее. Но можно и нужно сделать ещё более удобно. Чарльз Симони (который делает Intentional Programming) где-то у себя писал, что они делали и делают сравнения по удобству/эргономичности редактирования между своим редактором и текстовым — и в IP надо нажимать меньше кнопок, создание кода происходить быстрее и удобнее. Где можно поправить и улучшить у себя я тоже знаю, только не хватает времени на всё.

Я писал для инвесторов много и разнообразно. Один параграф, три параграфа, страница, три страницы...
Я писал для них ура-предложения, что дадите немного денег и будет вам щастье. Я писал объяснения откуда это щастье возьмётся. Первое им нравилось, и они говорили, что да, очень интересно, вы ещё инвесторов поищите — с таким изложением обязательно найдёте. Второе им совсем не нравилось, оно было заумно и непонятно. Они пытались выяснить что-же на самом деле имеется в виду, какое-то время со мной общались, наконец понимали небольшой процент из сказанного (и то, очень своеобразно). И удовлетворившись своей проницательностью рекомендовали мне это изложить попроще и тогда я обязательно найду инвестора.

F>И я до сих пор не понял, кто будет основным потребителем твоей супер-IDE. Вряд ли программисты в классическом понимании, потому что твой очень абстрактный подход всегда будет проигрывать частным специализированным решениям в прикладных областях (ну не поверю я, что с его помощью можно сделать конкурентно способный кросплатформенный веб-сервер или хороший 3D-шутер).

Вот именно, кросплатформенный веб-сервер, хороший 3D-шутер, и многое другое. То, что ты в этом не веришь сейчас, не значит, что это не так.
Что нужно для хорошего шутера? Красивая графика — а она делается на специализированном языке для шейдеров. Хороший скрипт (сценарий), чтоб было багов поменьше и интеллекта поболее. Значит пишут свой скриптовый язык программирования, ориентированный на данный жанр и даже на данную игру, и пишут на нём код. Много кода. Мегабайты скриптового кода. Ты думаешь, можно написать мегабайты скриптового кода быстро и без багов? Не получается. Пока это пара файлов — всё отлично. А как только пошёл большой код — баг на баге. Вот и делают игрушки 5 лет, вместо 1 года.
Или ты думаешь, что кросс-платформенный веб-сервер можно делать без кросс-платформенных абстракций? Нельзя. Можно взять яву, которая и будет кросс-платформенной абстракцией. Хорошо, если она приспособлена для изготовления веб-серверов, а если нет? Даже понятие файла, уж где взять более общее и стандартное — и то разное в разных операционках, когда доходит до деталей реализации быстрого доступа.

F>Скриптописатели бизнес-логики? аналитики? системные архитекторы? менеджеры? — у каждой из этих специальностей есть свои особенности и пожелания к инструментам. Без них даже самый замечательный в теории проект обречён на неудачу.

SymADE — Symbolic Adaptable Development Environment.
Это значит, что я его хочу написать таким, чтоб его можно было адаптировать, приспособить к разным требованиям, особенностям и пожеланиям.
Адаптировать до такой степени, чтоб он был лишь немного хуже специализированного решения.

F>И наконец, о форме представления данных — да, в теории прямая работа с деревом может давать определённые преимущества. Но на практике мне предложенный в твоём демо-описании способ кажется очень неудобным. Мне кажется, что мышь и клавиатура — не самые подходящие для этого инструменты. И настоящий вопрос на 1M$ — на самом деле больше дизайнерский, чем научный — придумать устройство ввода, удобное для работы с графическим представлением иерархической структуры данных.

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