Смотря на чём будете разрабатывать, мог бы и я подключиться если бы разработка велась на Java.

[flood]Вот сколько dilma меня не пинал, насчёт Java и я сам уже давно на PHP сижу, но всё равно я считаю его самым идеальным для создания IDE сред. Элементарно потому, что, он изначально рассчитан на работу с большой сложной кодовой базой, чем и является IDE.[/flood]

Угу. Понял.
Но это техника дела. Определяется особенностями некого конкретного проекта. Тут мои коллеги лучше меня в сетевых технологиях разбираются, пожалуй.
Моя задача не дублировать их, а "летать выше", заниматься более фундаментальными вопросами.

Ну, например, вышеотмеченный (на картинке) блок NetPSMProtocol - это, на самом-то деле, одна реализация из двух разных функциональностей (алгоритмов, объектов - называйте как хотите). Это сетевой мастер (у нас физическая реализация - 485-й интерфейс), или сетевой слэйв.
[flood]Это я еще имена вдвое посокращал. Как отучить плюшников писать имена на полстроки -- не пойму[/flood]
Ну, скажем, это два разных контейнера с одинаковыми интерфейсами (точками). Оба этих кода должны быть в прошивке, ибо перепрограммированием под землей заниматься нет никакого настроения.
Контейнеры активные. Т.е., могут самостоятельно стрелять вверх и вправо, по своей собственной инициативе.

Чего мы обычно делаем в таких случаях Обкладываем эти сущности сложной системой переключателей. Очень легко выйти на систему, в которой без пол-литры не разберешься, хотя она и работает. Сегодня. А мне надо, чтобы ВСЕГДА
А теперь вспомним постановку задачи. Мы занимаемся графическим программированием вовсе не для того, чтобы впихнуть это дело в какой-то конкретный графический интерфейс, а для того, чтобы было ПОНЯТНЕЕ.
По словам Паронджанова - чтобы "Улучшить работу ума".

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

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

---

В общем, как-то так. BoardCasting -- коллегам, философский аспект проблемы -- мне

Тут так примерно.
Есть определенный уровень познания, после которого язык -- не самая существенная деталь. Просто техническая подробность, до какой-то степени затрудняющая или облегчающая труд программиста.
Тут, правда, очень важно, что понимается самим программистом под словом "труд". Что следует понимать - я как бы изложил с самого начала
Скорость написания кодов (нужных буковок) меняется очень сильно. А скорость разработки - почти никак.
Тем спамерам, которые обещают каким-то новым языком увеличить скорость именно разработки - плюньте в глаза. Можно и от моего имени.
Потому что настоящая разработка не имеет ничего общего с написанием "Hello word". 99% времени ты думаешь, проверяешь, экспериментируешь, дискутируешь с коллегами -- а не пишешь.

Общий обзор всех языков... Не, ну в посте описать затруднительно. Почитайте, к примеру, Свердлова "Языки программирования и методы трансляции" -- там почти про все и довольно подробно.

А если, все-таки, в двух словах...
Есть языки, которые заточены под чукчу-писателя, а есть под чукчу-читателя. Это две ветки развития, антиподы, в общем-то.
Все C-подобные языки - для писателей. В инженерной практике таковые противопоказаны, хотя порой - просто деваться некуда.
Антиподом (для читателей) является Виртовская линейка языков. У них тоже есть недостаток - ради читателя они готовы жертвовать эффективностью. Т.е., вводить такие особенности в язык, что вытащить потом эффективность становится теоретически невозможно. Не инженеры они, хотя таковыми себя декларируют.
Про герметичные/не герметичные типы данных - углубляться не буду. Тут лучше чего-то (хоть бы того же Свердлова) почитать.

А вот есть в системе типов одна особенность которую мало кто описывает. Разве что я, пару раз издевался над Плюшниками.
Кажется где-то в личке даже диспут tsdima был. "Продвинутые" могут и помнить.

Речь о чудесном типе данных procedure of object. Почти прямым воплощением его в HiAsm является связь между объектами. И, кстати говоря, 14-й тип данных в свойствах элемента.

Так вот, C++, который декларируется как специально сделанный для создания пользовательских типов - такого не умеет. Не умеет, и все.
Плюшники после таких слов обычно начинают горячиться, говорить, что вот щаз, они шаблоны ка-а-ак нарисуют....
Но начинают грустить, после контрольного выстрела: "Хорошо, нарисовали, а какой получится тип переменной, в которую можно поместить и структуру {Obi1, Method1}, и - {Obi2, Method2}, если это объекты разных классов. Хотя структуры и описаны одним шаблоном"

Собственно, я только два языка-то и знаю, в которых этот тип данных - родной.
Дельфи.
И Active Oberon. Оно же - A2, оно же - Blue Bottle
Есть еще QT, который есть расширение C++. В котором методом шанхаестроения добавлена концепция слотов/сигналов - это тоже самое, только понтов выше крыши.
Даже странно... Очень простой тип из ООП, предком которого в Структурном Программировании был сверх-полезный процедурный тип. А объяснить религиозным фанатам это дело -- гиблое занятие.

Ладно, бог с ними, с языками. Тем более, что Правильно было бы сделать HiAsm так, чтобы он уронил все остальные ниже плинтуса.
Есть ведь еще работа - "Генеральная схема IDE".

Уважаемые коллеги - попробуйте нарисовать верхний Уровень, и Вы окончательно начнете меня понимать
Не надо верить на слово, проверьте.
Даже у Tad-а есть возможность проверить "профпригодность" карандаша и резинки

Microsoft "порадовал" очередным шедевром инструмента разработки программ для мобильных устройств:
http://blogs.msdn.com/b/nikolait/archive/2012/11/27/touchdevelop-create-apps-on-ipad-iphone-android-in-addition-to-pc-mac-windows-phone.aspx
touchdevelop1.zip - video demo mp4

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

В той теме особое внимание стоит обратить на обсуждения стандарта будущего универсального формата файлов блок-схем. Схемы HiAsm тоже попадают в эту категорию.

-

[flood]А здесь  
   ... продемонстрировал способ, как лишний раз не подставляться под бесперспективное общение: даже лучшие и умнейшие люди решили, что это флуд. И правильно

… Гораздо правильней извести здесь ещё несколько сотен страниц «облизываясь» (в бесплодных попытках понять), почему в HiAsm (да и в других языках и средах разработки) существует непреодолимое ограничение на сложность кода (вероятность ошибок нарастает быстрее, чем пропорционально). И эта проблема не лечится вложенностью структур. Понимание этой истины может стать для вас шагом в сторону решения этой проблемы. А может и не стать (раз даже подсказку приняли за флуд)). Скорее всего, её решит кто-либо другой (хотя это решение уже прозвучало на страницах этой, и некоторых других тем с участием Galkov)).

… Извести десятки страниц, потратить уйму времени. А потом сказать:
http://forum.d2h.ru/forum.html?q=3&p=256271#p256271
http://forum.d2h.ru/forum.html?q=3&p=256282#p256282
, и скопировать опыт буржуев (если они к тому времени смогут продвинуться в решении этой задачи).

[/flood]

А вот я попросил бы в суе - свою фамилию не упоминать
Если по делу - так нет вопросов.

А вот употребление всяких неочевидных прилагательных - это в суе

Galkov-Кирилл Пименов? Намбы хиасм поднять до высокого уровня и элементы все отточить а потом другими средами заниматься.

Ни в коем случае.
Galkov -- это Галков Владимир Алексеевич. И все. Особо не шифровался, как видите.

Про ДРАКОН я в курсе.
Мое мнение: они не прошли еще и десятой части нашего пути, следовательно -- на такое же количество граблей ЕЩЕ не наступили.
Главный, и принципиально неустранимый недостаток у них: это всего лишь полу-визуализация. У них визуализирована лишь императивная часть алгоритма, а декларативная остается в виде неких текстовых таблиц. По словам Паронджанова: "потому что невозможно скрестить ужа с ежом"
Если посмотреть на HiAsm, можно сказать: "не невозможно, а просто ума не хватило"
В принципе, что-то похожее я Паронджанову и говорил, там же, на oberoncore.
Может быть, несколько в более мягкой форме... Типа - у нас обыкновенный Memory является примером этого гибрида. И прекрасно себя чувствует.

http://apptractor.ru/develop/app-constructors - интересная подборка приложений конструкторов программ.

Подведём итоги друзья

Создавать алгоритмы неких действий человек не перестанет никогда. Даже прежде чем перейти улицу здравомыслящий индивидуум составит некий план поведения. А «лень-матушка» будет всегда толкать пытливый ум к оптимизации телодвижений с целью достижения максимального комфорта в ближайшем к нему окружении. Поэтому сама идея создания чего-либо путём манипуляции абстрактными объектами не умрёт никогда, а вот форма реализации будет постоянно изменяться. Будет ли это какой-то конструктор или быть может считыватель мыслей человека напрямую из мозга - сие представить трудно. Можно только фантазировать какими будут будущие «кубики» для творчества.

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

p.s запостил сюда так как тема обширна и интересна, "ленивые кидайте в меня тапки, от благодарных и спасибо достаточно"

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