Galkov говорил о порядке разработки:
1. Создаем "Генеральный план", т.е. ставим кубик на форму, даём ему имя, подводим к нему линки (снаружи) и, не заходя внутрь, обзываем точки.
2. Потом наполняем кубики нужным функционалом. Кто во что горазд.
А вот кто во что - это уже следующая проблема.

Я так понял.

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

СЛАБАК, вот тебе и смешно
Если только-только разобрался с арифметикой - ясный перец, тебе будут смешны попытки других людей решать сложные уравнения в частных производных.
А вот если бы ты был умным - то просто освоил бы такое "кунг-фу", и всего делов.

Лично я последние пять лет занимался медитацией и освоением основ этого кунг-фу (где находится этот монастырь - не скажу).
И я считаю это подъемным. Нет, не за год. Если честно - даже не за два. "Кавалеристы" могут отдохнуть, это не для них.

И мысли о "супер-пупер-мега-проекте" возникают не от того, что правая нога так захотела, а потому-что в этом есть реальная востребованность.
Например, andrestudio, знаешь ли ты, сколько лет термину "программирование без программистов"
Оказывается, не мы это придумали. И даже существует МЭК-стандарт, в котором описаны пять языков (из них три - графические)

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

Короче, andrestudio:


------------ Дoбавленo в 16.46:

Я смогу, и знаю что.
Я смогу научить своих начальников HiAsm-Языку. И они будут разбираться в верхнем уровне проекта не хуже меня.
Если схема верхнего уровня порядка 20-30 элементов.
Замечу - это именно они (начальники) добавляют новые функциональности в проект, вернувшись с объекта, проведя совещание с Заказчиком, и т.п..

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

---

P.S. nesco, ты как-то спрашивал, как убедить работодателей... Это не только твоя проблема. Я иду вот таким путем.

Учитывая то, что интернет скоро станет всегда и везде, а веб-приложения приоритетными, то в концепцию стоит включить и веб-ориентированность! т.е. развивать Hion а не HiAsm! ))


Это ты о чём? Думаешь на этот проект кто-то выделит деньги? ))

Ну-ну, можно подумать, что он есть в лесу или в горах

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

Парни - эти умные слова не я придумал
Очень рекомендую прочитать "Джефф Раскин. Интерфейс: новые направления в проектировании компьютерных систем"

Этот парень аннотируется как создатель проекта Apple Macintosh. Очень доходчиво объясняет, почему каждый из нас десятками раз в день ошибается в раскладке клавиатуры, и т.п..
Читаешь - веришь. И удивляешься, почему все давно так не делают.

Крайне не бесполезная информация. Для тех, кто таки Дизайном своего программного продукта занимается.
Одно из главных утверждений: этим надо заниматься ДО, а не ПОСЛЕ.
При этом, под Дизайном понимается не цвета и размеры кнопочек (хотя размеры - реально влияют на эргономику - там даже расчеты дадены), а именно эргономика человеческих мозгов.

------------ Дoбавленo в 17.30:

Это я ПРЕЖДЕ ВСЕГО о том, что у каждого из нас есть своя работа, и свой работадатель.
И свой конкретный проект, со своими проблемами.
У маленького проекта - маленькие проблемы.
У большого - большие. Он перестает быть управлямым. И мне не встречались работодатели, которым это нравится
ПОКА - не более того

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

Ну да... как-то так
Обычно так -- первые полгода есть серьезные трения. Со мной реально сложно работать. Хочется же, чтобы коллеги были твоего уровня...
Педагогического дара - вообще нет, говорю что думаю...
Хотя, с другой стороны: а почему Работать - должно быть легко...

После года - формируется команда единомышленников, которые понимают, что я никогда не говорю "со зла". Только из болезни за дело.
А сейчас, так вообще, у меня есть не убиваемый козырь: я начальник.

Последние три месяца я реально не могу плотно заняться своими программистами... Искрой занимаюсь... Второй раз уже в командировке (Моссертиум).
И, таки - ДА, программисты с ужасом ждут моего плотного присутствия (но уже и с интересом)
Т.е., Иван, твой мысленный образ -- достаточно близок к действительности

[flood]Galkov, в том что вытащить мух из котлет сумеете сомнений нет. Сама позиция Я-начальник Ты-дурак отвратительна[/flood]

Давай уточним: Про начальника - мои слова. Про дурака - твои.
Типа, сам сказал, самому же и отвратительно стало

Я тебе открою секрет эффективной работы команды из нескольких Ведущих Специалистов
Главный секрет - один из них Начальник. А остальные, не дураки, а Профессионалы.
И никакой демократии.

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

Плюс к этому, на предприятии может вестись одновременно несколько тем. С тем же набором Ведущих. И в разных темах могут быть (даже должны) разные начальники.

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

Разница огромная - заходя внутрь ты теряешь общую картину.

Да что же за беда-то такая - опять Кодинг
А с Программированием - слабо помочь


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

• Подпилить немножко наш язык напильничком. Тема достойная обсуждения, и я ее начну. Попозже чуток. Дайте из командировки приехать. И конструктивное обсуждение с коллегами, имеющими опыт работы в HiAsm - было бы бесценным (с не имеющими - у меня нет проблем).
  
  
• Прорисовать верхние два-три уровня на этом нашем как бы новом Языке, абсолютно не рассчитывая на нажатие кнопочки Compile. Специально, и еще раз, обращаю внимание - на HiAsm, а не на жабе Тут нужна помощь программистов, а не кодеров.
  
  
• Что у нас получится ??? Получится у нас HiAsm-проект, состоящий из неизвестных элементов. В чем мое утверждение ??? В том, что коды этих супер-пупер элементов на пару порядков проще написать, чем всю среду целиком. Получится работа более предсказуемая, с более надежным результатом, легко разделяемая на параллельный кодинг (здесь уже - ДА, кодинг).
  
• Пока уровень вложенности не очень высок, схема кодогенерации не очень важна - да хоть бы и тот же Windows. Придет время - решим. Но мы получим главное - среда почти собрана на самой себе. Мы имеем реальное тестирование Языка. И уже можно приступать к более совершенным схемам кодогенерации. К таким схемам, при которых уровень вложенности уже по барабану. Можете считать, что я клятвенно обещаю: будет первое - второе лично сварю.

Коллеги, прошу понять меня правильно - это лишь мои соображения.
Но я готов их обосновывать, не на пустом же месте они родились

А по мне так это одно и тоже! )) То, что ты подразумеваешь под программированием, я отношу это к проектированию! )

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

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






------------ Дoбавленo в 00.00:
Еще одно.
Говорил, уже, но повторюсь, ввиду важности этого факта.

Уважаемые коллеги, не рассчитывайте на быстрый результат. До какой-то степени любезный наш andrestudio прав - мы пытаемся объять "необъятное".
Но тут характер многое определяет. Кто-то считает, что компилятор - это магия и колдовство, поэтому даже браться не стоит за эту лженауку. А кто-то берет и осваивает эту теорию ((кстати говоря, уверяю Вас коллеги, сделать самопал на уровне FPC - не есть супер-задача, общепринятая (не моя) планка качества лежит довольно низко)).

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

Да, под "компилятором" я понимал графический Язык, плюс CodeGen, плюс некий Back-End. Back-End сегодня -- это Дельфи и FPC. Вполне может быть fasm. Или я для себя возьму Keil (для кортекса)... Да мало ли.
BTW: вообще-то, ansi-C иногда заслуженно называют межплатформенным ассемблером. Все, про компиляторы больше ни слова



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