Угу.
Ну я же тебя на что провоцирую: скажи СВОЕ, что надо - чтобы подходило
А я скажу свое.
Может, глядя на нас, и еще кого пробьет на гениальные идеи.

А потом спросим ТС: а не слабо ли Вам, коллега, ....

Во, первый ответ

Кстати, к вопросу о ЯВУ
------------ Дoбавленo в 17.11:

Найти то, с чего начать
------------ Дoбавленo в 17.13:
Я обязательно почитаю, что ты напишешь (если напишишь, конечно). Может тогда проявится отправная точка в концепции

Дык нет вопросов, что многие почитают, еслив написать
Смысл - в беседе, а не в гарантиях согласия.
С моей стороны - опыт как в HiAsm, так и Инженера. Ну, может быть, и познания в теоретическом программировании...
Хотелось бы в ответ получить понимание Вашего опыта. Еще лучше - новые идеи.
При понимании конечной цели (иначе - фигня получится). Мне представляется что оно у нас совпадает

А не просто "было интересно, спасибо"

Во первых, зачем это делать?
А во вторых, почему бы не завернуть такие контейнеры в библиотеки, которые в свою очередь будут скомпилированы соответствующим компилятором и подключаться в коде целевого пакета...
Других вариантов, вроде как нет
------------ Дoбавленo в 18.28:

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

Затем, что каждый, в таком случае, может писать на своем любимом целевом языке

Ни что ни ново под луной, вот это самое я уже предлагал в прошлый раз, как вариант

  Мне может кажется, но Netspirit говорит примерно то, что мне пришло в голову, пока я читал последние две страницы.
  Во-первых, идея сделать свой "графический язык" - правильная, однако тут совсем не то, что имеет в виду nesco: надо не определять, как будет и что рисоваться - это лишь метод представления программы на графическом языке пользователю и рисоваться она может как угодно (конечно, лучше прийти к единому удобному и функциональному решению, но модульность - тоже хорошо, можно будет делать свои попытки представить графический язык). Во-вторых, основа языка, так сказать, его семантика должна быть в компонентах.
  Определим, что же важно программисту на графическом языке? Правильно - реализовать логику, его не интересует ни целевой язык, ни особенности компиляции, - только результирующая логика работы. Из этого приходим к следующему: на уровне графического языка не должно быть не деления на пакеты. Пакеты в том виде, в каком они сейчас, должны быть простым ComboBox-ом, в котором просто выбираем целевой язык (так мы получаем кроссплатформенность и различные языки одним ударом). Далее, компоненты должны быть едины для всех пакетов, мы составляем схему из логики, а не из наборов компонентов для целевого языка.
  К сожалению, это очень идеализированное представление графического языка, и оно имеет свои крупные изъяны:

• Так как набор компонентов один, то при поддержке множества целевых языков придется реализовывать одну и ту же логику для каждого языка. Это ооочень трудно и затратно по времени (а в некоторых языках такую логику и вовсе придется реализовывать целиком самому, а не использовать библиотечные вызовы).
• Очевидные кончились (или забылись, пока дописал до этого места). TODO: заполнить.

По идее делить нужно не на пакеты а на обработчики (Windows, Linux, Android, RTOS, Arduino...), как частично сейчас и есть. Элементы делить на стандартные и не стандартные. Стандартные это те которые не относятся к конкретной реализации обработчика.

С этого места - поподробней, пожалуйста. Непонятно потому что


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

Ну например, предположим пакет для STM32F10X. На самом нижнем уровне это набор абсолютно специфических таймеров, DMA, UART-ов, I2C, SPI, ADC, DAC-ов, и т.п... Каждых далеко не один, и все они с правыми точками (которые и являются физической реализацией многопоточности) Вектора прерываний, в общем. И общим числом 64, на моем конкретном камне.

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

Пакет	Папка	Файлов	Всего строк	Код	Комментарии
Delphi	code	937	219046	174691	44355
Delphi	conf	764	18343
CNET	code	775	52776	44569	8197
CNET	conf	690	21956

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

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

И знаю, что тут существует "гордиев узел", разрубить который можно только волевым усилием.

Выглядит это примерно так: ввести некие графические примитивы конечно можно же, чтобы программист на HiAsm стал конкурентоспособен в сравнении со скриптокодером.
Но это еще больше ухудшит эффективность кодов, и без того не самую высокую.
Произносится магическая фраза (почти Ваша) сделай сначала эффективную кодогенерацию, а потом добавим. Может быть.
Типа сначала сделай компилятор, а потом мы возьмем - и изменим язык. Под который этот компилятор написан.
Лично я так не умею. Тем более, что реально эффективная кодогенерация - реально сложная задача.
В процессе ее реализации придется решать примерно такие задачи: среда, а не программист должны принимать решения об инлайнинге методов; среда, а не программист должны специализировать универсальные коды элементов; среда, а не программист должна удалять неиспользуемые поля элементов; среда, а не программист должны заниматься т.н. "мемоизацией".
Это так - для начала.
Что совершенно не означает, что это невыполнимо. Просто - надо работать. И будет результат.
Причем, обращаю внимание, что ни один из известных мне компиляторов о вышеперечисленных задачах - даже думать не хочет. А нафига - программисты же есть. У них голова большая - пусть думают.

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

Из этого замкнутого круга лично я вижу только один выход. Плюнуть полностью на компилятор и кодогенератор на первом этапе. На основании самоочевидного факта, что не боги горшки обжигают. Типа: для кого - боги, просьба не беспокоиться.
Разработать графический язык. Не состряпать наспех, а именно разработать. И не приспосабливать графический язык к нашему умению стряпать коды (как сегодня, собственно говоря), а делать язык для Пользователя. И только для Пользователя.
Чтобы появились реальные основания надеяться, что его не придется дорабатывать в ближайшее десятилетие.
И, имея в виду все особенности графического языка (сегодня на него есть лишь наметки, которые я обещал изложить коллегам) плотно заняться кодогенерацией.
И никаких обратных совместимостей.
И это вовсе не месяц работы. Кодогенерацию в стиле сегодняшнего Windows - можно и быстрее месяца. Но будет ожидаемо тормузнутее сегодняшнего варианта.

---

Короче, я не верю в быстрые варианты. Настаивать, не буду - но вот не верю, что пройдет нечто похожее на Чапаевский наскок.
Не пройдет. Плавали - знаем...
Тут нужна грамотная осада по всем правилам стратегии и тактики.
А вовсе не:

а что тут наскоки скакать?

нужно:
1-2 ведущих проект
2-4 архитектора (возможно даже из тех же ведущих)
2-3 программиста
~4 средних кодера для мелких допиливаний

+ Первоначальный план "на листочке" требуемой ТЗ структуры проекта, среды, пакетов и кодогенератора.

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

Далее процесс идёт по проторённой ранее дорожке:

- Архитекторы продумывают структуру каждого нового модуля, в проекте модульным должно быть почти всё, а тем временем программисты пока пилят предыдущий модуль.

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



Если придерживаться такой тактикистратегии то до первой беты можно докатиться уже месяца через 3.

---

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

hitman249, ну я же объяснил, что ни на чем не настаиваю.

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


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

Но это -- не более, чем прогноз. Попробуй, проверим
Почему бы и не проверить

Обычно "для мелких допиливаний" нужны высококлассные спецы.

Ну nesco говорил, как я понял, о стандартизации отображения компонентов, отображения связей и вообще их наличия, отображения точек и типов точек. А я выдвинул мысль, что незачем это делать, пусть будет просто абстрактное понятие "компонент", а компоненты уже будут связаны между собой любым способом. Т.е. идет разделение на семантический слой и графический (он то и показывается пользователю).

Прошу прощения, что выдираю фразу из контекста, но если это и есть цель создания графического языка, то вот это:

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

Блин ну писатели, даже топ в экран не влазит а что если схема из одних кирпичей (в смысле кирпич = одна машинная команда) потом из этих кирпичей кубик -> потом стена -> потом дом -> потом город и кто за эту стройку отвечать станет Ну конечно же типа "я же за рукав" "а я за пуговицу"

Дышите ровней -> йёги рекомендуют.

з.ы таки не дождался от господина Galkov(а) его красочной концепции в рисунках, хотя всё только "пенопластом о пенопласт"