>>832099

>функциональной парадигме

Так она не сильно отличается от императивной, если я ничего не путаю. Вот декларативную парадигму было бы круто реализовать визуально, чтобы собирать из кубиков не решение задачи, а описание задачи, которую нужно решить компьютеру. Сравни, например, HTML код и WYSIWYG редакторы веб-страниц: вместо необходимости вручную описывать все теги и их свойства, ты просто мышкой "рисуешь" всё, что хочешь видеть на своём сайте, и компьютер сам находит способ сделать то, что ты хочешь, без необходимости ковыряться в коде. Вот это реально мощный инструмент, в отличие от перемещения мышкой команд императивного/функционального языка. Ты же не будешь говорить, что перемещение мышкой голых HTML тегов и их свойств было бы лучше (быстрее, удобнее, проще для новичков и т.д.) WYSIWYG редактора? Не спорю, иметь возможность править исходный код как он есть важно, но для конкретной задачи (сделать веб-сайт) и конкретных условий (ты нуб и тебе не важна оптимальность кода, важен только результат) WYSIWYG намного лучше ковыряния тегов, пусть даже мышкой с красивыми цветными прямоугольниками вокруг кусочков кода.

Другое дело, что декларативные языки и соответствующие им WYSIWYG редакторы могут быть только для конкретных узких задач, а не для всего, что угодно. Хм, в общем-то редакторы игровых сцен и являются WYSIWYG редакторами для какого-то внутреннего декларативного языка игрового движка, на котором вручную писать было бы слишком сложно (но обычно возможно). Так что визуальное программирование есть в любом редакторе сцен, от него никуда не денешься, пока двигаешь модельки мышкой.

>>832098

>Поэтому я перешёл со скретча на Snap! Смотри скока разных стилей.

А что, в скретче нет выбора тем? Лол, за столько лет не сделали такую базовую фичу, которая есть в любом текстовом редакторе с подсветкой синтаксиса...

>ПОТОМУ ЧТО ХОЧЕТСЯ.

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

>Snap! is a broadly inviting programming language for kids and adults that's also a platform for serious study of computer science.

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

>>832173

>С-блок

О, кстати, а там можно эти блоки сворачивать, то есть временно скрывать их содержимое? В современных редакторах текстового кода обычно есть возможность свернуть блоки кода в одну линию: редактор временно скрывает часть строк, отображая слева на линейке, какая часть строк скрыта. Это бывает удобно, хотя, если честно, хорошо написанный код скрывать не нужно. Можно даже последовательно скрывать разные вложенные уровни кода, например, если у тебя длинный каскад из if/for/while.

>>832175

>Ну создавай свои блоки, добавляй в них код, затем из своих блоков создавай код более высокого уровня.

Не понял, так можно объединять между собой пустышки или нельзя? В ООП возможен такой подход: описываем свойства и методы класса и сразу же вызываем их из другого класса, но пока класс пустой, он ничего не делает, это "пустышка". В последствии наполняем методы класса кодом и система начинает работать.

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

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

>Ты видишь то, что хочешь видеть.

Я вижу готовый низкоуровневый код.

>Как мне тебе это продемонстрировать на блоках?

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

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

>>832516

>Сможешь обеснить разницу?

Вот здесь у тебя >>832348 не просто кучка блоков, а композиция по определённым правилам, которые понять можно только уже зная принципы программирования. Вот у тебя вызов функции, в него вставляются не просто какие-то числа, а целые конструкции, которые ещё нужно найти на палитре блоков, выбрать и заполнить, да не абы как, а всё по правилам. Такой инструмент предоставляет неограниченные возможности, т.к. является полноценным языком программирования, но чтобы им научиться пользоваться, нужно научиться программировать, чего новички и яждизайнеры активно пытаются избежать. Поэтому скретч хорош для обучения детей программированию, но плох в качестве замены программированию.

Здесь >>832450 я показал, что можно собрать целую игру совсем без программирования, только натягивая ниточки слева направо, выбрав сначала "сенсор" и "актуатор". С этим справится любой, даже не зная основ программирования, достаточно объяснить ему суть. Да, впрочем, и объяснять ничего не надо - из названий ясно, что сенсор реагирует на какие-то события, а актуатор совершает какое-то действие. Что мы хотим сделать? Сдвинуть кубик по оси Y в ответ на нажатие кнопки W. Выбираем сенсор "клавиатура" и актуатор "движение", в первом вводим букву W, а во втором вводим любое число в поле с буквой Y. Соединяем сенсор с актуатором ниточкой и готово - теперь кубик двигается куда мы сказали по нажатию указанной кнопки. Продолжаем путём повторения этих очевидных действий, постепенно изучая методом тыка свойства разных сенсоров и актуаторов. Даже логические блоки, "контроллеры" понять совсем не сложно, контроллер И ждёт срабатывания всех подключённых сенсоров (сенсор А и сенсор Б), контроллер ИЛИ ждёт срабатывания любого из сенсоров (сенсор А или сенсор Б), и т.д. Разве что про XOR придётся погуглить, т.к. это искусственное слово. Так вот в этом всём нет никакого кодерства, ты не пишешь код - ты просто создаёшь связи между двумя/тремя классами сущностей. Да, эта система имеет ограничения и будет неудобна для сложной логики, но она не ставит своей целью заменить программирование целиком и не ставит целью обучать программированию. Её цель - упростить описание логики для тех, кто не хочет разбираться в программировании.

>>832517

>любая визуальная не-код-система - это всё равно код

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

А в случае с логикой БГЕ нет никакого языка. Ты не составляешь выражения из кубиков, ты только создаёшь простые подключения между некими приборчиками. Вот если вставить провод в одну розетку, загорится красная лампочка, а если в другую - зелёная, ну и где тут язык? Ты не выражаешь свою мысль на каком-то языке собеседнику (компьютеру), ты только настраиваешь умные приборчики, чтобы они работали так, как ты хочешь. Если у тебя под рукой не окажется нужного приборчика - тебе придётся идти к папе-программисту с просьбой создать приборчик, потому что сам ты его никак не создашь. А папа-программист придёт и объяснит глупому компьютеру на его странном и непонятном тебе языке, как должен работать недостающий приборчик, компьютер подмигнёт и у тебя появится новый приборчик для создания связей с уже имеющимися.

Сразу предупреждаю, речь не идёт о создании связей между нодами визуальных языков в Godot/UE/Blender. Легко обмануться из-за внешнего подобия. Визуальные языки - это именно языки, ты создаёшь на них языковые конструкции, с помощью которых выражаешь свои мысли компьютеру. Ты можешь строить длинные многословные выражения, а можешь рубить короткие фразы, но это всё твоя речь на языке. В описанном выше случае нет никакой речи, есть только ограниченные подключения между фиксированными системами. На визуальном языке можно реализовать подобное (создав множество высокоуровневых конструкций и площадку для их подключения между собой), но не наоборот.

>не помешает поработать в ней "умнячку"

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

Попробую продемонстрировать наглядно.

Если ты почувствовал нажатие кнопки W, тогда возьми из свойств кубика его текущее смещение, извлеки из него Y-компоненту, прибавь к ней число 0.05, затем верни полученное значение обратно в Y-компоненту смещения, а само смещение верни в свойства кубика, чтобы он обновил своё положение на экране на новое.

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

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

А теперь сравним с этим:
[кнопка] W => [движение.y] 0.05
Что это? Может показаться, что это тоже какой-то язык (потому что я записал это буквами языка), но нужно заметить, что это единственная возможная фраза, её нельзя построить как-то иначе, нельзя вставить внутрь неё что-то ещё и ничего из неё изъять. Это просто натянутый провод между устройством "кнопка" и устройством "движение.y", у которых выставлены ручки в положение "W" и "0.05" соответственно. Как бы ты ни дёргал за провод и как бы ни крутил ручки, ничего другого ты не сделаешь. Ты не составляешь выражения, не пишешь текст, даже не выкладываешь кубики - ты просто настроил два прибора, между которыми есть соединение одним проводом. Всё. С этим даже обезьяна справится, если сможет удержать в своих лапах провод и попасть в отверстие разъёма, а значения на ручках можно и по умолчанию оставить вообще. А вот если посадить ту же обезьяну за печатную машинку или даже выдать ей в лапы кубики с буквами - осмысленного она ничего не напечатает, ведь в её мозгах нет языка с его правилами. Мы можем попытаться обучить обезьяну правилам языка и она даже что-то запомнит, но зачем нам это делать, если для решения бытовых задач обезьяны достаточно двух приборов и одного провода? Справится и без обучения языку...

>>832617

>язык А можно писать только такими конструкциями

>не гарантирует, что их нельзя сочетать ебанутым образом

При чём тут это? Речь шла о том, что является языком, а что - нет.

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

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

Но я тут подумал ещё, и всё не так просто, как кажется. Есть такая тема - полнота по Тьюрингу. Если система полна по Тьюрингу - она может выполнить любую задачу, которую способен выполнить компьютер. Так вот полнота по Тьюрингу обнаруживается в самых необычных местах - даже игра "Жизнь" с её примитивными правилами является полной по Тьюрингу, т.е. в ней возможно собрать эмулятор компьютера, записать в него программу и получить результат (и вроде бы даже уже делали простые компьютеры в игре "Жизнь"). Вполне возможно, что "logic bricks" в BGE тоже полны по Тьюрингу (без использования скриптов на Питоне) и из них можно собрать любую программу, включая эмулятор компьютера. Тогда утверждение, что logic bricks не являются языком программирования, будет звучать довольно странно...

С другой стороны, мы же говорим о языках. Вот HTML является языком программирования (декларативным), хотя не обладает полнотой по Тьюрингу. Многие другие языки программирования тоже не обладают полной по Тьюрингу, т.к. не нуждаются в ней для решения задач, ради которых они были созданы. В то же время игру "Жизнь" нельзя назвать языком программирования, хотя она и решает любые задачи, точно так же, как нельзя назвать языком программирования горсть транзисторов или красную пыль в Minecraft (тоже полна по Тьюрингу). Т.е. нужно смотреть в определение "языка" и ориентироваться на него, а не на выполнимость задачи каким-то инструментом. Даже если logic bricks позволяют решить любую задачу, это не язык программирования, даже не визуальный язык.

>>833002

>отвечающей за речь нейросети

>присоединить к обезьянам внешний речевой центр, скопированный у человека

Надеюсь, ты так шутишь.

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

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

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

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

>учёные наконец изобретут нейроинтерфейсы

Нейроинтерфейсы давно существуют. Втыкаешь электроды в мозг и обучаешь человека ими пользоваться, чтобы нейроны перестроились (на это уйдут месяцы). Если воткнёшь достаточно прицельно, то обучаться придётся меньше. А если нужно управлять дистанционно (сделать биодрон), то задача проще, если сможешь воткнуть электрод в подходящую структуру - организм будет воспринимать импульсы с электрода как собственные желания и выполнять их. Только вот никаких универсальных интерфейсов вроде USB не будет, архитектура не та - нужно обучение, никакого тебе plug and play в мозге не предусмотрено. Т.е. разъём на башке сделать можно, но обучаться придётся для каждого девайса независимо, а это минус несколько месяцев жизни. Так что в случае обезьян единственный рациональный способ - протянуть их собственные нервы к коре, авось сама как-нибудь обучится управлять. А все эти сказки про импланты в мозг, не требующие адаптации (вставил и сразу пользуешься), возможны только с каким-то искусственным мозгом, специально разработанным для поддержки plug and play устройств. Биологический мозг, если тебе так понятнее, захардкожен под конкретную задачу.

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

>>832960

>всё равно никто это не читает

Я прочитал его графоманию. Мне тоже нравится идея изобретения нового языка программирования и я тоже когда-то подумывал сделать свой собственный визуальный язык программирования, но потом забросил эту идею из-за её практической бесполезности (по крайней мере для меня самого, ведь я могу писать на готовых языках, а визуальные мне неудобны из-за связанного с ними дрочения мышки; вот на смартфоне могло бы быть удобно).

>>832947

>Поэтому я сделаю свой графический язык.

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

>Блоки монохромны. Любые цвета расцениваются как синтаксический сахар.

Ты разве не понимаешь, почему изобрели подсветку синтаксиса в текстовых редакторах? Мозгу проще ориентироваться по цвету, чем по форме. Форма тоже имеет значение, например, слова мы распознаём в первую очередь по их внешнему контуру, однако, по цвету ориентироваться куда проще.

>распечатываться на монохромном принтере или вывестись на монохромном дисплее

Зачем тебе печатать код на бумаге или читать/писать его на e-ink дисплее? Ты извращенец или просто хочешь изобрести язык "для всего и для всех"? Сделай лучше хороший язык для конкретной задачи, чем плохой - для любой. Кроме того, обозначение цветом - это, обычно, подсказка, без которой код остаётся читабельным; если твоё устройство не поддерживает цвет, тебе будет не очень удобно, но ты всё же сможешь читать и писать код. Совсем другое дело, когда цвет несёт в себе уникальную информацию (которую другим способом узнать нельзя) - вот это плохо, в первую очередь из-за существования дальтоников, людей с плохим или неправильным восприятием цветов.

>Главный атрибут блока которым он отличается от других - его форма.

У тебя быстро кончатся формы или различия между формами будут слишком незначительны для лёгкого восприятия разницы. Тогда придётся дублировать информацию текстом.

>сегменты (С-блоки

В нормальных языках это называется блоком:
https://ru.wikipedia.org/wiki/Блок_(программирование)
https://en.wikipedia.org/wiki/Block_(programming)
Но если ты называешь инструкции блоками, тогда логично было бы называть блоки кода группами, потому что их основная задача - группировка множества инструкций таким образом, что снаружи эта группа воспринимается как одна инструкция. А вообще, лучше б не выдумывал свои собственные термины... Ты же язык программирования хочешь сделать, а не новую терминологию.

>Фундаментальные

>Производные

>Составные

Опять же, по-моему, ты напутал.
https://ru.wikipedia.org/wiki/Примитивный_тип
https://ru.wikipedia.org/wiki/Тип_данных

Алсо, не забывай, что кроме классов (данные + функции), существуют ещё и записи (агрегатный тип данных):
https://ru.wikipedia.org/wiki/Запись_(тип_данных)

>>832951

>У каждого блока в середине есть как минимум одно гнездо

А как же процедуры и функции без аргументов? Особенно если ты замахиваешься на ООП, в котором метод без аргументов достаточно часто используется, чтобы объект выполнил какую-то работу сам с собой.

>>832952

>У блоков типа уникальная для их типа форма

Понятно, создавать новые типы в твоём языке будет нельзя - ведь уникальных форм на всех не хватит.

>У блоков бинарных операторов вертикальная но инверсная симметрия так, что справа и слева стыкуются без зазоров два однотипных блока.

Ты же в курсе, что могут быть операторы, принимающие на вход данные разных типов? Примеры: умножение вектора на скалярную величину и сложение целого типа с вещественным типом. Или у тебя даже такие простые операции потребуют явное приведение типов?

А что на счёт несимметричных операторов? Для примера, вектор можно разделить на скаляр, но скаляр нельзя разделить на вектор. Языки с поддержкой перегрузки операторов (будет у тебя такая поддержка?) позволяют создавать новые несимметричные операторы. Для примера, можно создать оператор "+", складывающий строку с числом и возвращающий строку, к которой дописано число (в некоторых языках такое в стандартной библиотеке).

>Для лучшей начертаемости от руки.

Совсем с ума сошёл, ты хочешь писать свой велосипедный код на салфетках в кафе? Или ты мечтаешь о том, как будут учить твоему языку в школах?

>>832955

>на пикче 1

>двумя гнёздами-входами

Уже видно изъяны твоей концепции. Во-первых, по факту это обычный императивный текстовый язык со смешной обводкой вокруг текста. Вместо этого было бы куда лучше визуально отображать операции с тем же list x так, чтобы вместо унылых буковок были только весёлые стрелочки и квадратики. Ну серьёзно, вместо x.add(i) должно быть что-то вроде стрелочки от i к x, но не в виде портянки, а графически. Ты же сделал обычный текстовый код без подсветки синтаксиса, но с обводочкой.

Во-вторых, ты уже упёрся в ограничение "у каждого типа свои гнёзда из прямых линий". Предлагаешь нам вручную считать количество уголков на твоих разъёмах, а потом вспоминать (или искать в длинном списке дурацких коробочек), у какого типа столько уголков?

>мы можем описать тернарную операцию

>Блок возвращает int, о чём говорит его форма, имеет три входа, bool и два int на правду и ложь соответственно.

Ты разве не понимаешь, что тебе придётся создавать новую операцию под каждую комбинацию типов? Вот поэтому так популярны языки с динамической типизацией - они позволяют использовать любой тип почти в любом месте, без необходимости создавать новую функцию. Добавил пользователю мышкодроча на больную руку...

>>832956

>не переменные это, а члены класса

Поля класса, по сути, и есть переменные.

>>832966

>мы приводим int к single и возвращаем single. Как показано на пикче 2.

Лол, на пикче ты возвращаешь int. Сам запутался в собственном велосипеде и не заметил этого.

>читаемость

Выскажу своё мнение: текущий дизайн твоего кода имеет низкую читаемость. Подсветка цветом int/float в обычном текстовом коде лучше твоих рамочек. Да и то, эта подсветка делается только для констант, а переменные не нужно подсвечивать - они должны говорить о своём содержимом самим своим названием, а также быть объявлены близко к месту своего использования. Короче, ты изобрёл какую-то бесполезную фигню, пятое колесо велосипеда. Без обид, не хочу тебя демотивировать, но это реально не нужно.

Особенно в целях обучения - нужно не подсказывать то, что должно быть очевидным, а ставить в условия, близкие к реальным. Вот твои рамочки склоняют к созданию однобуквенных переменных, т.к. волшебным образом указывают на тип независимо от его названия. Но на практике названия должны быть длинными, иначе ты запутаешься в коде. Следовательно, твой язык склоняет к дурной, неправильной практике программирования, к использованию антипаттернов.

>>832975
Не понимаю, чем твоя картинка лучше текста. Если набрать те же слова простым текстом, получится реальная программа на языке с минимальным использованием скобок. Исчезнет только бесполезное указание на типы, которое только мешает. Плюс, текст набирать проще, чем искать и двигать мышкой блоки; если добавить текстовый поиск блоков, то это ещё меньше будет отличаться от обычного набора исходного кода.

>>832976

>пора из гд в пр перекатываться

Там его сожрут успешные 300кк/наносек кодомакаки на попсовых языках, которых волнует только работа на галеру. Будет ли его велосипед полезен галере? Нет, не будет. Значит, ему не место в /пр/. А здесь он может пилить свой велосипед в контексте какого-нибудь игрового движка, или сделать свой игровой движок на основе своего велосипеда. Мы посмотрим и посмеёмся над его попытками, но не так жестоко, как в /пр/, все ж свои.