Это никогда не будет возможно, если об этом только говорить. А не думать над преодолением.
Парни, второй десяток лет идет: может и повзрослеть пора

Что является главным контр-аргументом на "профессиональных форумах" против нашего графического программирования.
Зайдите, и узнайте.
Впрочем не надо, я Вам и так скажу: мы должны все время писать на скриптовых языках все новые и новые элементы. Потому что задач в программировании - неизмеримое множество.
Как мы (Dilma, например) им возражали: нам достаточно конечного числа базовых элементов, написанных один раз и на всю оставшуюся жизнь.
Наша беда в том, что это не есть полная правда.
Посмотрите на любой язык программирования - там конечное число базовых элементов (на разных языках это количество разное), о бинарном представлении которых программисты имеют очень слабое представление (IF, FOR, WHILE, и т.д., и т.п.).
И, можете себе представить, живут счастливо (по крайней мере, они так думают).

Так что делать будем: посыпать еще десять лет голову пеплом по поводу "невозможности"? Или - думать как превратить эту "неполную правду" в настоящую правду?
BTW: Как то мы с nesco уже беседовали о буквах в алфавите, и иероглифах. И почему первых мало, а вторых - несть числа


------------ Дoбавленo в 11.53:
Уточнение, вот здесь: http://forum.hiasm.com/forum.html?q=3&p=252633#p252633

Galkov, не согласен, объём работы просто колоссальный
- сама среда 100к строк кода, и это реально мелочи т.к. компоненты одного пакета будет исчисляться уже в 500к строк кода и больше.

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

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

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

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

Ещё конечно придётся найти решение наследования версий элементов, точнее это и есть возможное решение
Т.е. в пакете придётся хранить все версии элементов, с возможностью выбора версии элемента в HiAsm.
Как минимум данное решение даёт стабильность проекту от внезапных проблем после обновлений...

В общем, идей очень много, но времени и сил на реализацию всего задуманного нужно гораздо больше, эх

Редактировалось 2 раз(а), последний 2017-06-14 22:24:06

Редактировалось 2 раз(а), последний 2017-06-14 22:24:06

Встречный вопрос: сколько лет (или десятилетий?) надо, чтобы согласиться
Очень желательно БЫЛО БЫ ответ услышать.
Обычно, на неудобные вопросы не отвечают. Как будто это я виноват, что вопрос не очень приятный

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

Они потому и страшны, потому что это месиво слабо структурировано. И ничего лучше для структуризации, чем схемы HiAsm - как то не очень просматривается.


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

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

---

Поймите меня правильно: я ни на чем не настаиваю. Просто делаю типа прогноз.
Один раз (много лет назад) уже делал. Dilma почему-то обиделся, и объявил меня врагом проекта

Вот читаю я вас тут и окромя бла-бла-бла в N-ой степени ничерта не вычитал. Идея, конечно, класс -- сделать HiAsm на HiAsm-e, но вопрос остается открытым -- "как" Что-то же должно быть в начале, что могло бы позволять работать с графическими примитивами на начальном уровне проектирования того же HiAsm-а, к примеру. И вот это стартовая IDE должна работать на всем, что только можно себе представить. Не проще ли тогда будет свою ОСь замутить?
Или есть более простой путь, который от меня ускользнул

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

Гораздо -- не то слово
Но -- спешить надо не торопясь. Выделить не самую большую подзадачу, но -- сделать ее на 102%.
Например, "главный разработчик" рисует схему верхнего уровня. Не более 30 элементов (или супер элементов). Пусть эти "супер-элементы" будут даже пустыми.
И не просто схему, а сверх-продуманную схему. Которая устояла против самой беспощадной критики. Например, на форуме. Пусть даже внутри "супер-элемента" будет для начала просто текст - семантика входных/выходных точек. Ну или - техническое задание на разработку.

Обратите внимание - теперь уже могут работать несколько человек независимо. Необязательно, но -- МОГУТ.
И не скриптокодеров, а программистов на HiAsm.

Это и есть - главная идея.
Поддержка средой технологии программирования "сверху".

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

nesco, вот ты же умный человек.
А чего бы тебе не включить голову, не НАПИСАТЬ нечто отличное от "бла-бла-бла в N-ой степени".
Вот я бы почитал твои соображения с великим интересом. Ты ведь все понимаешь. Может даже лучше всех остальных

И опять эта идея будет привязана к конкретному ЯВУ. Один работает в одном пакете, а другой в другом, а мосты где, они у нас есть

За один день не получится. Ну, ПРЕДПОЛОЖИМ - напишу (скажем, к понедельнику).
А читать-то будете
Или это повиснет постом/темой без ответа

P.S. "писать" то у меня опыт есть. Потому и вопрос задаю


------------ Дoбавленo в 17.03:
Неправда Ваша дяденька.
Мне так кажется, что это необоснованное утверждение.
Или обоснуешь

Это бла-бла-бла и мое там есть, толку-то от него. Я пока не вижу стартовой точки, никак не вижу. Концепция блочно-графического программирования весьма интересна, но не от чего пока отталкиваться. Текущая среда не совсем для этого подходит в том виде, в каком она есть
------------ Дoбавленo в 17.06:

Уже писал про это, в прошлом топике, и сейчас ответил

Вот как ты себе представляешь контейнер, написанный на пакете Windows, стыкованным с пакетом CNET, они еще и на разных технологиях сделаны и имеют разные интерфейсы

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