Долго же я изучал Ваши материалы (одна компьютерра чего стоит), но куда денешься-то, если это необходимо для взаимопонимания
Ну вот что получилось пока:
1) Различие представлений "структуры программы" в HiAsm и ДРАКОН.
1.1) Давайте рассмотрим простенькое мероприятие по превращению текста структурированной программы в схему HiAsm. Исходим из того, что, как сделать таковое в ДРАКОН-схему - Вы знаете (и чего я совершенно не понимал в самом начале топика). Тут-то мы основную разницу и увидим.
Превращаем структурный блок в иконку с нужным изображением на ней (FOR, например), выносим стрелочку из этой иконки вправо к текстовому блоку, в котором теперь помещается уже только текст "подструктуры". Получилась иконка с одной правой точкой, от которой проведена связь к текстовому блоку. С которым проводим ту же самую процедуру, коль скоро он тоже является структурой. А если не является, то это назовем неким "атомом", которому тоже назначим иконку с одной левой точкой и поместим ее в библиотеку элементов. Кстати, о левых точках - это просто "входы в структуру". Соответственно, раз уж IF и FOR могут быть вложенными (да хоть и в самих себя же), то они естественно имеют левую точку.
Далее, вспоминаем, что в структуре (например, IF-THEN-ELSE-END) возможна не одна (как в FOR), а две подструктуры: TRUE-блок, и FALSE-блок. Все то же самое, но теперь у нашего структурного элемента будут две правые точки, от которых проведены линии к соответствующим блокам.
Одно "атомарное" действие, затем второе, затем третье - это ведь тоже описание структуры. И этот элемент структурирования у нас называется HUB, имеющий какое хочешь (вообще-то, ограничено сотней) количество правых точек.
Вспомним, кстати говоря, что сворачивание структурного блока в иконку - одно из основных пожеланий в плане "рюшечек" к IDE. А ведь это я не придумал, а просто прочитал на Форуме. Имеющее, безусловно, простое и логичное объяснение - разработчик хочет абстрагироваться от содержания структуры, и обозревать код (думать над ним) на более "глобальном" уровне. Ничего военного...
И чего у нас получается, после вышеозначенного сворачивания структурных блоков в иконки ??? А получается в явно нарисованном виде дерево структуры программы.
Именно структуры, и ничего другого. Поэтому я и не понимал вопросы про отсутствие структуры в наших схемах... У нас этого не может быть, потому что этого не может быть никогда (если по научному - не может быть по определению). Этим наше визуальное представление алгоритма (а я говорил пока только про алгоритмическую часть) отличается от ДРАКОНовского.
Спрашивается, зачем нужна схема программисту ??? Для того чтобы он мог в уме моделировать происходящее исходя из нарисованного (да хоть и написанного - без разницы). И эта модель в исполнении HiAsm несколько отличается от ДРАКОНовской. Если на ДРАКОН-схеме достаточно передвигать "черепашку" (пытаюсь использовать термины, встречающиеся на Форуме) по схеме, то у нас - нет, недостаточно. Мы должны ее двигать "на веревочке", имея ввиду, что она обязана (в ДРАКОНе - никому она ничего не обязана) вернуться назад. Не в том смысле, что об этом должен позаботиться программист - нет, не должен, она вернется, даже если он этого не хочет. Просто, без понимания такового, в его голове будет сидеть не очень адекватная модель происходящего. Например, некий элемент активизировал (отправил черепашку) по одной из своих правых веток. И пока она не вернется – у элемента нет никакой возможности активизировать некую другую. Да чего там активизировать - элемент вообще "заморожен", процессорное время отдано другим элементам, тем которые сейчас в правой ветке и находятся.
Грубо говоря, если в ДРАКОНе цикл моделируется в уме хождением черепашки «по кругу», то у нас - НЕТ. Никаких кругов, черепашка всегда возвращается обратно только по тому «следу», который сама же и проложила. А куда она денется-то, если она "на веревочке".
1.2) Возможен и другой подход, демонстрирующий разницу визуальных представлений ДРАКОНа и HiAsm. Представим себе макроикону «цикл ПОКА», внутри которой одна икона ВСТАВКА. Ну и, конечно, некий примитив/силуэт, на который ссылается икона ВСТАВКА. Так вот, в HiAsm эта макроикона вся целиком упаковывается в один элемент, из которой выходит визуальная связь, приходящая к той визуальной конструкции, которая будет описывать вышеозначенный примитив/силуэт (а там ведь аналогично – макроикона-вставка-примитив, и т.д.).
Т.е., в HiAsm визуализировано как раз то, чего в ДРАКОНе связано только именами.
1.3) Более коротко, но для кого-то может быть и более понятно: у нас не может быть нарушения принципов структурирования алгоритма по Дейкстре, потому что наши линии связи – это вовсе не GOTO, а CALL (хотя фактическое решение call/inline – это задача кодогенерации, а не визуального UI).
1.4) Предварительные выводы
Да, это немного сложнее, чем просто "абсолютно свободная черепашка"... Но знание сие вполне доступно школьникам - это есть просто экспериментально проверенный (нами) факт.
И самое главное, компенсируется пониманием структуры целиком. Это есть главное отличие, и это все-таки - есть Сила. Да, да - именно та Сила, которая "улучшает работу ума". Небольшой психологический барьер с ограничением свободы черепашки - и мы получаем доступ к «неограниченному источнику интеллектуальной энергии». Да пребудет с нами Сила (шутка юмору, конечно же)
2) Некоторые не тривиальные "шаблоны" ДРАКОНа в HiAsm. Для демонстрации действия Силы
2.1) Помню обсуждение визуализации исключений для ДРАКОНа. И в чем там была основная заморочка ???. Да в том, что в режиме "абсолютно свободной черепашки" не видно глобальное дерево структурных вложенностей. Кстати говоря, я не совсем понял, на чем же там сердце успокоилось все-таки... Ну да ладно.
Как у нас это будет выглядеть ??? Да элементарно... Элементик (TRY), с одной левой точкой - вход в структуру. Правая точка - дерево вложенных в нашу ловушку структур. Это очень правильно и наглядно (и я готов отстаивать эту позицию), что начало и конец структуры сосредоточены в одном месте
((цикл FOR у нас это одна иконка, а не две, как в ДРАКОНе - начало цикла, и его конец))
Еще одна правая точка с названием onExcept. Если делать в стиле Forth, вполне этого и достаточно. К этой правой точке onExcept подключен некий алгоритм, который распознает «чужое» это, или «твое» исключение – по его "номеру". И, соответственно - либо просто скажет Raise (с тем же «номером» исключения, Raise - это элементик такой "атомарный", с одной левой точкой), либо только и совершит, что некую финализацию...
Все просто и очевидно: в штатном режиме, гуляя "на веревочке", черепашка вернулась бы, только обойдя все нужные ветки дерева. А при исключении - веревочку некий демон дернул так сильно, что черепашка сразу оказалась в элементе TRY, забывши все правила правильного поведения в элементах, являющимися узлами той ветви нашего дерева, по которым проходит ее веревочка. Откуда, уже по всем правилам, и попала на onExcept
Почему демон проснулся? Ну, либо мы "на ноль чего-то поделили", либо черепашка сама его "укусила", сказавши магическое слово Raise.
И все это видно на схеме глазами, а не посредством неких логических умозаключений: вот в этом месте стоит Raise, а вот именно в этом месте будет перехват – левее, ближе к корню дерева.
И попробуйте сказать, что я школьнику объяснил что-то неправильно
2.2) Параллельные процессы/потоки... Читал, читал - в аспекте ДРАКОНа. А теперь слухайте сюды
Синхронизация потоков, это ведь тоже некая простенькая структура, начинающаяся с WaitForSingleObject, и заканчивающаяся ReleaseMutex (ну или EnterCriticalSection/LeaveCriticalSection - если таковое будет угодно)
И у нас опять же - все просто и красиво: элемент с одной левой точкой doSafeWork и правой точкой onSafeEvent. Ну ладно, при более внимательном изучении вопроса, появятся еще и "аварийные" правые точки onWaitAbandoned, onWaitFailed, onWaitTimeOut. И все! Мне не надо рассказывать пользователю про необходимость освобождения мьютекса, после завершения критической к параллельному доступу работы с чем-то.
Просто алгоритмическую ветку, работающую с неким ресурсом, который допускает работу только по отдельности - пропускаем через такой элемент, и всего делов. Как бы даже и не придумаю сразу, чего тут еще обсуждать можно. Дешево и сердито, вроде.
3) Все вышесказанное относилось только к алгоритмической части творчества программиста. Но попробуем «скрестить ужа с ежом».
Потому что без такого «скрещивания» бывает крайне затруднительно. Ну, скажем - те же параллельные процессы... Есть два алгоритма, работающие в разных потоках, каждый использует с десяток каких-то переменных/данных (ресурсов, если по научному).
И тут на тебе – конфликт данных. Да, алгоритмы визуализированы, они схватываются глазом сразу, а вот обращение к общему ресурсу – сокрыто от глаз, и является, поэтому, миной замедленного действия. Зачем же мы тогда усиливали работу ума, если подрываемся на такой простой мине-ловушке.
Давайте, вместо написания в свойствах элемента некого магического имени переменной, просто покажем пальцем на некую иконку, символизирующую эту переменную. Примерно так у нас и сделано: есть некий элемент Memory (читай – ЗАПОМИНАТЕЛЬ), и к нему нарисована линия/линии (красным цветом, в отличие от алгоритмических связей) от всех других элементов, использующих нашу «переменную».
Чего мы этим достигаем ??? Пользователь нарисовал отдельно две алгоритмические ветки, работающие в разных потоках. И, в противовес чисто алгоритмическому стилю, обозначил дополнительно эти связи с «декларативными элементами». Каков результат – связей стало больше, они начинают пересекаться, и т.д.. А с другой стороны, ровно «шесть секунд» (симультанное восприятие) требуется пользователю, чтобы увидеть параллельное использование неких данных. Данных-то может быть много, а параллельное использование, например – только одно. И еще минута (уже сукцессивное восприятие), для более детального и профессионального анализа на критичность таковой ситуации (может оба алгоритма только чтением и занимаются)
Мины за пользователя никто, конечно же, не обезвредит, но каждая из них уже обозначена большим красным флагом.
Усилили мы работу ума программиста, расставивши «красные флажки» на схеме, или наоборот – только добавили «визуального мусора» ??? Мне представляется, что именно усилили. И призываю коллег поразмыслить именно над этим.
Что же у нас получилось с визуальным синтаксисом. Наряду с императивными элементами у нас в схеме стоит теперь и декларативный элемент. Декларативные связи мы пытаемся отделять от императивных - цветом, но и точки, к которым подключены эти связи – тоже не следует путать с императивными (которые мы обсуждали ранее). Так и возникла принятая у нас сегодня «схема»: точки, предназначенные для получения данных, мы располагаем сверху, а отдающие данные – снизу.
Вспомним еще, что элемент IF, кроме структурных единиц TRUE и FALSE занимается таки и сравнением, которое может быть тоже не самым тривиальным мероприятием. Да, теперь мы не сравниваем две именованные переменные, сказавши, что "это декларативная часть, и мы это не рисуем, потому что невозможно скрестить ежа с ужом". Возможно, теперь у нас на элементе IF есть две верхние точки для получения операндов для сравнения.
И что занимательно, именно после визуализации декларативных данных и связей с ними, в элементе IF не осталось чего писать, на неком языке программирования. Теряется свойство метаязыка, которому обязательно нужен некий язык для представления декларативных данных, и появляется магическая фраза «без единой строчки кода».
А разве не возникал такой вопрос при обсуждении ДРАКОНа ??? кажется а.к.а. Димыч за такое спрашивал... Так именно у нас и есть, что на это ответить. Например, что такое может получиться только после визуализации декларативных данных, и объединения «ежа с ужом». У нас это сделано таким образом... Может, есть более эргономичные варианты, например - расширением ДРАКОНа... Давайте смотреть. Но именно с этого надо начинать, видимо.
Однако может оказаться, что результат получения таковых данных для того же сравнения в элементе IF - тоже является неким нетривиальным алгоритмом.
Опять же, я не фантазирую, а просто вижу на форуме обсуждения ДРАКОНА предложения о превращении иконы ВОПРОС в аналог иконы ВСТАВКА - некий примитив с двумя выходами.
А вот, можете себе представить, есть у нас такая разновидность ЗАПОМИНАТЕЛЯ (с названием EventFromData), который перед тем как вернуть запрашиваемые у него данные, генерирует запрос ((сигнал, функциональный вызов, текст inline-алгоритма, отправляет черепашку: важны не слова, а соответствие сидящей в голове пользователя модели происходящего - реальной системе кодогенерации)) на свою правую точку. Возможно, что более понятным хинтом к этой правой точке было бы: «Ой, нас тут снизу спрашивают!».
Далее, пользователь рисует алгоритм (как бы, совершенно императивное действо), результатом которого является установка нужных значений в ЗАПОМИНАТЕЛЬ – что и будет возвращено в последствии как результат запроса. Т.е., у ЗАПОМИНАТЕЛЯ обязательно есть левая точка, предназначенная для установки (запоминания) в него новых значений.
Ну и каким элементом у нас тогда является ЗАПОМИНАТЕЛЬ: декларативным, или императивным ???
А никаким. Объявим таковые вопросы не имеющими смысла, по причине того, что акт «скрещения ужа с ежом» уже состоялся.
Наверное, настолько же бессмысленным, настолько в физике является вопрос: фотон (электрон, пи-мезон, и т.д. и т.п.), это волна или частица?
Кстати говоря, то же и про элемент FOR можно сказать. В алгоритмической ветке, которую этот элемент активизирует нужное количество раз, может потребоваться знание значения этого счетчика цикла. И чего теперь, по принципу разделения элементов на императивные и декларативные – заводить некий ЗАПОМИНАТЕЛЬ, непонятным образом связанный с элементом FOR ???
Да ни в коем случае
Выкидываем этот принцип разделения на помойку, и заводим в FOR нижнюю (отдающую данные) точку с именем Position (например).
4) Дальнейшее развитие топологии в HiAsm
4.1) Ну хорошо, пока мы говорили о визуальном представление структуры алгоритма в виде дерева. А как быть с «дублированием кода»?
Нарисовал пользователь одну алгоритмическую ветку. Рисует вторую. И обнаруживает, что все последующие, необходимые для него действия – уже им же и нарисованы. Как какая-то часть предыдущей алгоритмической ветки. Что характерно: обнаруживает моментально – все ж таки симультанное восприятие.
Ситуация аналогична ДРАКОНовской, когда две разные макроиконы имеют в своем составе элементы ВСТАВКА, ссылающиеся на один и тот же примитив/силуэт. А у нас ведь как раз эта «ссылка» и визуализирована как связь.
Не дать пользователю объединить эти две (уже существующую, и требуемую к рисованию) ветки – себе дороже. Это настолько просто и понятно, по сравнению с рисованием некого «функционального вызова по имени» с выделением ветки в отдельную «функцию», что критику пользователя выдержать крайне затруднительно. Особенно, если ты придерживаешься взглядов, что инструмент для пользователя, а не наоборот. Опять же, критерием истины является не мой (Ваш, наш – не важно) логический вывод из некого понимания эргономики, а «психологический эксперимент». Можно и про бритву Окамы вспомнить: «функциональный вызов», непонятно из чего выходящая алгоритмическая ветка – это новые сущности, в противовес очевидному «соединению проводов».
Вот и получается, что дерево у нас превращается в граф, а задачу call/inline мы перекладываем на кодогенерацию, как бы это не было противно окружающим.
Мимоходом отмечу, что адекватного (в смысле оптимальности кодов) решения этой задачи у нас пока еще нет. Да и ЯВУ, которые осмеливаются этим заниматься – как-то не вижу. Скажем для «вертикальных» связей в подавляющем числе случаев нужен inline (в этом подавляющем числе случаев просто читаются некие значения – и все), а для алгоритмических веток – call (но тоже, далеко не всегда).
А деваться некуда, Front-End - первичен. Получается, что если для реализации таковых идей придется делать свой компилятор, то его придется делать
4.2) Далее, посмотрим, что происходит, если у пользователя возникает неистребимое желание сделать такое объединение веток, что граф становится циклическим. Как я уже отмечал в предыдущих постах, это у нас является запрещенным (хотя и не всегда) приемом, семантической ошибкой языка, называемой на сленге «кольцеванием». Источник такого «желания» пользователя – непонимание им наличия «веревочки» у черепашки, и желание выполнять чего-то в цикле. Проходит быстро, с первого раза (клинические случаи пока рассматривать не будем), но встречается - относительно регулярно.
Возможно ли потенциально убрать и это «недружелюбие» среды ??? Думаю – да. Тут должно быть что-то похожее на замену SendMessage на PostMessage. Т.е., наткнувшись на занятый маршрут (свою же веревочку), черепашка должна просто оставить данные, которые она несет - да прямо на дороге, считая свою миссию при этом выполненной. А, возвращаясь обратно, и обнаруживши послание (которое она сама же и оставила) - развернуться на 180 градусов, и повторить уже выполненную миссию, но с новыми (которые лежат на дороге) данными. Таковое «прикрытие» не сделано сегодня по неким причинам, связанным с совместимостью...
4.3) Ну и последний пока фактор – инкапсуляция.
Противоположной стороной нашей Силы (в сравнении с ДРАКОНом), является то, что наша схема в меньшей степени делится на фрагменты. Это понятно: расшифровка иконы ВСТАВКА может оказаться на другом листе, и выполняться даже другим разработчиком. А у нас это прямая и неразрывная визуализированная связь. Ну вот, мы можем «перегрузить лист информацией» значительно быстрей, чем на ДРАКОНе.
Понятно, что на бумаге у нас никто схемы не печатает, все только в среде, какие мониторы есть, с такими и работаем. Опыта с multi-touch – пока не имеем. Практически получается, что схемы, большие чем 200 элементов – перестают «читаться». Если по научному – перестает работать симультанное восприятие, видимо.
Против этого у нас тоже есть метод, похожий, возможно, на использование иконы ВСТАВКА в ДРАКОНе. Выделяем некоторую «географическую» область на схеме, <контекстное меню – поместить в...> - и дело в шляпе. Кусок схемы поместился в некий MultiElement, у которого есть все четыре вида точек (коль скоро соответствующие связи подходили к выделенному фрагменту схемы), как и у вышеописанных атомарных элементов.
Можно ли это сравнить с примитивом/силуэтом, на который ссылается элемент ВСТАВКА ??? Сравнить-то можно, только это не очень одно и то же будет.
Примитив/силуэт – это один какой-то алгоритм, а содержимое мультика – это несколько (по количеству соответствующих точек) алгоритмов, которые и не очень отделишь друг от друга, потому что они могут работать с одними и теми же данными. Да, после визуализации декларативных связей, появились проблемы с разделением алгоритмов, если они «лапают» одни и те же данные. Надо ли с этим бороться ??? Мое глубокое убеждение – НЕТ.
Потому что именно так устроена жизнь, как мне представляется. И лучше ее видеть таковой, какая она есть, чем создавать мифы про нее.
4.4) Немного философии.
Конечно, я описал «тупой» метод создания объекта «разработкой снизу». Но достойный внимания, хотя бы потому, что практически все через это проходят. Далее, пользователи начинают понимать (без усилий с нашей стороны, между прочим), что наиболее рационально этот прием работает, если большая функциональность требует меньшего количества интерфейсных точек.
Начинает приходить понимание и об абстрактном интерфейсе – наплевать чего там нарисовано внутри мультика, если ты точно знаешь назначение точек мультика. ((Причем, как-то так получилось, что он у нас сложнее «классического» определения))
Осознание этого «наплевать» - база для разделения работы над неким Проектом между многими разработчиками.
Ну и верхний полет (на данном этапе развития HiAsm) – это множественное использование «объектов этого класса».
Специально взял в кавычки.
Является ли это ООП, или является чем-то другим, или для того, чтобы являлось, еще чего-то надо добавить - судите сами. У Паниковского, конечно же, есть и свое мнение... Но я Вам его пока рассказывать не буду, а просто примерчик приведу из жизни инженера, который стал таки «программировать без программистов». И задам контрольные вопросы для размышления.
Вводная: собрал таки я железо, управляющее координатным столом – три (по количеству координат) отдельных модуля (контроллера на базе Atmega8-16), которые замыкают обратную связь от датчиков перемещения (ЛИР350) до электродвигателей. Естественно, все это добро связывается с компьютером, который и задает траекторию движения. Штатный программист пишет софт для штатной же работы Оператора в технологическом процессе. А как я (в смысле - инженер) отлаживать свое железо должен?
Сам пример: ну вот, рисую себе тестовую программу. Прежде всего – для работы с одним контроллером.
Это элементы GUI типа надписей, трек-баров, полей ввода, и прочая мутота. Ну и алгоритмы, которые по событиям от этих элементов и таймеров, формируют реальные «команды общения с контроллером»
Контрольный вопрос: схема, все это изображающая, какие знания отражает – императивные, или декларативные?
Или это все-таки объект, у которого алгоритмы (если по научному - методы) неотделимы от данных?
Для одного контроллера все прекрасно. Все это удовольствие я размещаю на Панели (это у нас такая GUI-разновидность мультика) и создаю еще две связанные копии этого мультика. Получившиеся три Панели я «приаттачиваю» к табу, и получаю инструмент тестирования всех трех контроллеров: с каждой закладки таба – своим. Они только и отличаются-то, что slave-адресом, который в одном из полей ввода и установлен.
Второй вопрос: если эти три Панели, не три экземпляра одного класса, тогда что же это такое?
А если это все-таки Объекты, то каким программированием я занимался в процессе их создания?
5) Простенький пример для критики
Как я уже отмечал в других постах, Автор среды HiAsm ДРАКОН-теорию не читал, и является в значительно большей степени практиком, чем теоретиком. И некоторые визуальные принципы, заложенные в среду, противоречат принятым в ДРАКОНе безоговорочно. Рисую простейший пример вычисления факториала для рассмотрения и критики визуальных решений.
Естественно, принятые нами решения обладают разной степенью важности. Есть некие базовые, от которых отступать было бы совершенно не разумно с нашей стороны. Например, если для устранения неких пересечений потребуется отменить «скрещивание ежа с ужом» - вряд ли имеет смысл рассматривать такие варианты. А конструктивная критика была бы очень интересна. Типа такой: «А если сделать не так, а по-другому – вот эдак? А если делать это как в ДРАКОНе, получится понятнее!»
Очень была бы интересна...
Заодно, я не поленился, и провел хронометрирование нашего кодинга. Поскольку встречал (и на этом Форуме в разделе ДРАКОНа - ТОЖЕ) глубокую убежденность, что рисовать схему неизмеримо дольше, чем настучать эквивалентный текст.
Совершенно необоснованную убежденность. Вот, смотрите:
Вложение:
Комментарий к файлу: Вычисление факториала
Factorial.png [ 10.42 КБ | Просмотров: 14211 ]
От нажатия кнопы «Новый проект», до PrintScreen – 150 секунд. При этом большую часть времени расстановка контролов на форме занимает, да надписи всякие... А на выходе Вы видите работающее приложение, которое даже и «протестировали» (10! – посчитан) А ведь я не спортсмен, наоборот: люблю спешить не торопясь.
Грубо говоря, интерактивность среды – тоже может чего-то стоить. Т.е., я не только согласен в этом вопросе с Alexey_Donskoy, но и готов подтвердить его правоту экспериментальными результатами.
Да, если смотреть скрин, то понятно далеко не все. Все понятно - в среде, бумажный вариант даже и не рассматривается.
Хотя дополнительная (кроме скрина) информация, необходимая пользователю HiAsm (в смысле – узнающему базовые элементы по их иконке) выражается всего двумя строками:
Math_?.Default=1.0; For_?.Start=2; В среде он это увидит на панели свойств элементов.
В среде - много чего увидеть можно, в сравнении со скрином... На панели <Подсказка> постоянно отображается хинт на объект под курсором – на элементы, на точки элементов. Пользователь-то HiAsm все их, для приведенной схемы - наизусть и так знает. А свежему человеку – сложнее, наверное. Тут у меня глаз замыленный, и встать на позицию новичка - мне крайне трудно.
Вот пытаюсь, и не закачиваю «большую схему», скрин которой привел коллега Pirr. Но все равно – общий смысл проводимых там мероприятий, мне и по скрину понятен. Остались всякие подробности, типа конкретных значений конкретных свойств некоторых элементов. Закачаю, и через полчаса эта схема от своей будет неотличима...
А скринами мы, вообще-то - не обмениваемся.
Мы обмениваемся текстовыми скриптами, которые среда сразу же изображает как схему... В которых никто и разбираться не хочет (хотя там все прозрачно), их просто тупо копируют – <контекстное меню – Вставить>, и перед тобой схема. И наоборот: выделил кусок схемы - <контекстное меню – Копировать>, и в буфере винды скрипт для выделенного куска схемы.
Причем часто обмениваемся... Возникла мысль, в процессе беседы излагаешь ее в виде схемы – отдаешь коллеге. Он возражает, или делает какие-то добавления, путем некого исправления в схеме - и возвращает ее обратно... Не, ну совсем без слов не обходится, конечно же.
Ничего не напоминает
Мы обмениваемся знаниями, представленными в виде схемы (потому что это ТОЧНЕЕ, чем на великом и могучем) – мечта Владимира Даниеловича давно сбылась.
Вообще-то, получается почти по Мольеру: оказывается, мы всю жизнь «говорили Прозой», даже не подозревая этого
6) Каковы могут быть варианты дальнейшего развития
Как я отмечал ранее, при создании Проекта, математическим обоснованием никто особо не заморачивался. Можно даже сказать, что и создание супер-языка программирования – никто и в мыслях не имел. Делалось по принципу «давайте посмотрим, что получится». То, чего получилось, я могу рассказать со всеми подробностями, до мельчайших деталей.
Например, изложить все тонкие места в нашей технологии, и свое понимание о способах их преодоления. Что такое «без единой строчки кода», и возможно ли это в принципе. Можно ли в принципе, прекратить нескончаемый пока поток: «а сделайте мне это». Что сегодня невозможно сделать в HiAsm в принципе, и как это преодолеть. И наконец - конечен ли этот процесс усовершенствования.
Но излагать это логично при встречном конструктивном интересе
А вот то, чего будет с Проектом в будущем – тут возможны разные мнения. И все будут до какой-то степени обоснованы. Каково должно быть будущее, у того, что получилось сегодня – у меня есть свое мнение, но тут я могу ответственно говорить только о своем мнении. Если это будет интересно конечно.
Скажем, мне думается, что было бы логично, создать некую «стратегическую инициативу» по превращению HiAsm в будущий супер-язык программирования. Это конечно не преобразование системы познания человечества, но - все-таки…
Реально это или нет, об этом говорить пока рано, поскольку зависит от многих факторов. Например, от наличия математического обоснования проекта, сравнимого с аналогичным для Дракона. Но пока можно точно сказать, что математиков среди нашей команды нет.
И это далеко не единственный влияющий фактор, естественно. Но все эти вопросы открыты для конструктивного обсуждения. Точно могу сказать, что мне это - очень интересно