Galkov, всё верно. Но такие разработчики - они даже не на вес золота, а скорее на вес платины...

Так я не сомневался, что тебе это будет понятно.
Главное, чтобы это поняли наши молодые коллеги тоже. У которых все впереди еще.

Если ты убежден, что светлое будущее на нашем направлении, и готов сделать многое для его приближения, так стань таким разработчиком
Про себя: именно этим я и занимался последние годы (а не типа пропал куда-то).
Факультативно...
Технологии программирования стали интересовать меня профессионально только последние года полтора.

Светлые головы, А-У-У, где Вы

Я, честно сказать, не до конца еще понимаю весь концепт Galkov-а. Чего он хочет добиться Мне оказалось проще понять концепцию квантовой запутанности и квантовой неопределенности, чем его выкладки. Но мне кажется, что объяснение концепта графической среды нового поколения выходит за рамки сей темы и требует наличия своей ветки.

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

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

Galkov, может ты возьмёшься за это дело?


Об этом я раньше говорил! ))) Было-бы не плохо это осуществить!

Тут все просто: пройди мой путь рассуждения, и ты придешь к тем же выводам.
Или к противоположным, но понимание концепта будет все равно.

Вопрос первый: ты сторонник разделения пользователей среды на гуру, и просителей новых элементов ??? Я - противник, а ты ???
Вопрос второй: как это преодолеть ??? Попробуй сам ответить... Естественно, это не тема этого топика. Есть другие - дай свои предложения там (где уже есть мои). Хотя бы попробуй - очень помогает для понимания концепта.
Вопрос третий: почему идеи утечка мозгов, и можно ли это преодолеть.
Вопрос четвертый: что конкретно надо, для достижения целей.

Здесь я пытался отвечать сразу на последний. Даже не отвечать, а высказал свое мнение. По моему - в тему.
Если одним словом: деньги не самая большая проблема. Да проблема, но вовсе не главная. Даже если будут "деньги", но не будет ума - это деньги на ветер.

И чем это не соответствует заявленной теме "Идеи по развитию HiAsm-а"

Что-то подобное же уже есть -- "Сделать элемент" вроде. Насчет своего типа, то может стоит копать не в сторону языков, а в сторону баз данных. Ведь любая структура, по сути, определяет параметры некоторой записи набора параметров
------------ Дoбавленo в 15.31:

Идеи-то идеями, но конкретное обсуждение конкретной идеи надо выводить из общего обсуждения, иначе, запутаемся
------------ Дoбавленo в 15.33:

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

Не могу сказать, что ты не прав. Я бы тоже самое сказал другими словами... Но и так - тоже ПРАВИЛЬНО, вроде.
В общем пусть будет: ДА, правильно....

Для ясности может добавлю, что меня это интересует в абсолютно практическом аспекте.
Мне, в отделе разработки нашего предприятия, необходим некий стандарт для разработки больших программных проектов.
Все эти case-системы - у меня в печенках уже сидят. Вот где действительно "квантовая запутанность" ((c) nesco)
Поэтому я пока у себя настаиваю на "генеральной схеме проекта".
И всех своих начальников-работодателей (их 4 человека) заставлю изучить концепцию HiAsm, чтобы они научились моделировать у себя в голове функционирование проекта, на который тратят деньги.

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

Давайте попробуеи немного углубится. Galkov, я так понимаю, что ты предлагаешь создать некую глобальную среду, в которой по деревне будет на каком ЯВУ будут собраны конкретные модулю, те среда должна быть всеядна, и только линковать готовые модули в единый проект. Это так или как-то иначе

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

Приведу конкретный пример, как это могло бы быть (Заранее прошу сильно не пинать это лиш ИМХО)

Почти.
Начнем уточнять.
1) Для начала задуматься о возможности создания такой среды. Но если принять за аксиому (а это лишь мое мнение пока) "выигрывать за явным преимуществом" - тогда ДА, без этого не обойтись.
2) Все сразу - слишком сложно. Задачу надо разбивать на части - оценивать риски частей (как более простых задач) легче.
3) Поэтому сначала - просто графический язык. Позволяющий убрать гуру-разделение, и утечку мозгов. Это должно быть безусловной целью модификаций - иначе нафига все это.
4) И именно поэтому - не хочу про линковку даже и говорить. Сейчас. Задача сборки тоже непростая, но преодолимая. Если есть полная ясность с графическим языком. А вот если ты трудишься полгодика под что-то конкретное, а потом выясняется, что надо половину поменять - это вечный двигатель...
5) Собственно, создание самой среды, под понятный графический язык - тоже разбивается на части с меньшими рисками. "Генеральная схема" на том же самом графическом языке. И с возможностью разделения работы на конкретных пользователей.


Собственно, как можно решать сложные задачи ??? ((мне именно это профессионально интересно))
Разбить ее на более простые части. И эти части имеют между собой информационные связи.
Ну вот и спрашивается, на каком Языке (узнаешь ли брата Колю) нарисовано это "разделение"

IDE-HiAsm сложная задача, или нет
Говорить о каких-то деньгах на этом уровне сложности - не очень перспективно, мне представляется.
А вот после "разделения" - уже можно думать...
То ли дальше делить, то ли браться за реализации кое-чего...

Ты пробовал создавать свой компонент методом "Создать элемент", чем тебя это не устраивает Как раз построено на MultiElementEx, где можно задавать любые точки, какие тебе нравятся. Что-то должно быть такое, что нельзя сделать сейчас, а сейчас у нас не получается слинковать проект с чужими модулями (IC в расчет брать не будем, тк требкет знания определенного целевого языка), нельзя назначить свой тип данных, описать его, застаить его пониматься всеми, да много чего еще нельзя

Побывал. Но я пытался представить, как можно графически создавать целый новый пакет HiAsm для любого языка.

Galkov, помнится был разговор, где ты описывал разговор с программерами, и они выпячивали глаза на то, что у нас создавался свой класс на каждый чих, нет, чтобы создать дерево классов и обращаться к ним, как к объектам. Да и линки не должны быть универсальни, как сечас, среда должна сама определять тип линка и управлять его подключением, разрешая или запрещая его подключение, если тип не соответствует. Надо отходить от позиции универсальнсти. Если уж точно надо подключить String к Integer, то среда должна предложить вставку конвертора, который можно будет видеть на схеме.

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

Определение типов должно работать и в FTCG и RTCG и прочих, значит нужен первичный слой абстракций, а уже потом кодогенератор(ы).