Evgeniy_M
Вообще тема три кружочка - очень сложная!
Получение белого цвета из трех уже здесь рассматривались!
И получались только при использовании растра -по точкам!
В стриме как раз новый способ получения смешивания цвета, который раньше не рассматривался!
  Во вторых создание какого то языка программирования - "графического"!
Ну это не для интерпритатора RFO-Basic!
Слишком толстая матрешка получится!
ОС - java - RFO-Basic - и ваша фигня!
Скорость будет убийственно мала.
По этому - этот запрос не сюда!
   Да и на сколько я помню Вы наверно Evgeniy на официальном форуме.
Требовать от языка программирования - который существует то, что вообще не существует в природе? Перебор!
   Ну если Вы желаете типа по "щучьему велению" - то на сегодня я не знаю подобных языков!
А было бы очень удобно!
А так ( аналогично) :
- на уровне машинного языка - равносильно буквам
- на языке высокого уровня - словам
- на Вашем - предложения
Это по аналогии с языками людей.
В результате :
- на ассемблере под сотню команд
- на RFO-Basic под семьсот
- на Вашем - можно сравнить с Китайским языком - более 50000 значков ( иероглифов ) , из которых самый просвященный знает более 1000.
   И что в этом хорошего !
Это сколько кубиков ( иероглифов ) надо, чтобы написать простой алгоритм!
А сложный ?
   Все программисты будут в психушке!

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

Например, рисуем блок-схему, а из нее генерируется код на рфо. Я это так понимаю

Витаминыч
На все случаи жизни столько кубиков не заготовишь!
По этому и существуют языки разных уровней!
Но самый универсальный ( и старый ) - ассемблер - и самый быстрый!
И это уровень "букв" - то есть можно написать любое "слово".
А уже на языках высокого уровня приходится писать готовыми словами!

1961uvg, Так и не надо готовить мы программисты или где
Базовые какие-то основы, комбинируя которые получаем новые. Как с теми же цветами: красный, зеленый, синий.

Даже тупо ключевые слова и конструкции..
Но все же, лучше подождать разъяснений, что имел ввиду тот парень

Согласен!
Подождем!
А как тебе стрим?

1961uvg, Примеры стримить глупо, лучше полноценные ролики делать и писать статьи. Последние, кстати, давно просил..

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

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

1961uvg, добрый вечер всем присутствующим

Да, Evgeniy на том форуме - эт я
Я тут как-раз по Вашей "наводке"

А на счёт остального... Так я ж не зря указал конкретно - HiAsm
Это - реальный, проверенный временем пример Графической системы программирования, благодарность за создание которого многократно выражена разработчикам пользователями, далёкими от классических способов кодирования.

И смысл моих слов в том, что реально не справедливо, что RFO Basic!-ом могут пользоваться только те, кому удаётся осилить "китайскую грамоту" языка.
А я - лишь "проливаю на проблему свет"

Цитата 1961uvg:

---

Витаминыч На все случаи жизни столько кубиков не заготовишь!..А на этот случай,.. специально,.. сделали "кубик" "ИнлайнКод",.. в который, букивками, желающий может вписать недостающую функциональность

Цитата Evgeniy_M:

---

Поэтому, я убеждён, что RFO Basic! должен иметь
инструмент графического программирования,
похожий на HiAsmЗдравая мысль, полностью поддерживаю)
Я в свое время тоже предлагал подобный подход, правда в масштабах java.
Тем более, писать программы на андроиде, гораздо удобнее в виде соединения нужных модулей,
Приведу простой тезис, почему программирование должно быть модульным?
На мой взгляд, это следствие эволюционного процесса развития языков программирования.
Если вспомнить, на первых порах, люди писали программы на ассемблере, в дальнейшем стали появляться языки более высокого уровня, каждая из таких комманд высоко уровня, заменяля десятки комманд низкого, а дальше к чему пришли?
Языки высокого уровня стали появляться как грибы, но их дальнейшая эволюция затормозилась, а если исходить логически, дальнейший виток эволюции языка, это переход к модульному программированию, где модуль как команда, будет включать в себя десятки комманд языка высокого уровня, как в свое время десятки комманд асма, стали заменяться одной коммандой высокого уровня.
И не важно, какой язык, будь то RFO или какой еще, станет основой языка визуального(модульного) программирования.

Цитата 19Ram84:

---

Языки высокого уровня стали появляться как грибы, но их дальнейшая эволюция затормозилась, а если исходить логически, дальнейший виток эволюции языка, это переход к модульному программированию, где модуль как команда, будет включать в себя десятки комманд языка высокого уровня, как в свое время десятки комманд асма, стали заменяться одной коммандой высокого уровня.
Поздравляю, ты изобрёл велосипед. Есть функции (методы), группирующие несколько «команд» в одну. Есть классы, группирующие функции и данные в один модуль. Есть библиотеки, группирующие классы и функции в модуль ещё большего размера.

А графические языки программирования общего назначения, ровно как и генерация кода по моделям, не более чем фантазии теоретиков от мира программирования. Мне не посчастливилось заниматься подобными задачами, как использовать графические языки и модели, так и разрабатывать. Из всего этого я сделал выводы: либо язык имеет узкую направленность (например, пакет имитационного моделирования Simulink для Matlab, редактор состояний в Unity), либо он абсолютно неюзабелен (здравствуй, генератор кода из диаграмм деятельностей из Enterprise Architect) или близок к тому (например, Blueprint из Unreal Engine, на котором реализация (линк) алгоритма поиска путей A* даже на простейшей сетке превращается в огромную схему).