Тем не менее (1), угореть по скретчу можно и под сраку лет.
Тем не менее (2), есть офлайн-клиент, есть возможность конвертнуть проект в HTML5, а затем через ноду.жс конвертнуть в екзе. Что делает скретч совместимым с классическими условиями ТВГ (запускаемые без интернетов файлы). А значит, можно со скретчем на ТВГ вкотиться.
Собсна, сам виновник торжества доступен онлайн без СМС и регистрации https://scratch.mit.edu/ (но регистрация даёт возможность хранить свои поделия в облаке и автоматически расшаривать там же)
Документация https://ru.scratch-wiki.info/wiki/Блок
Конвертер проектов в ХТМЛ5 https://sheeptester.github.io/htmlifier/
Туториал по превращению веб-приложения в отдельное экзэ https://code.tutsplus.com/tutorials/introduction-to-html5-desktop-apps-with-node-webkit--net-36296
Вот примеры, что вообще там можно сваять https://www.youtube.com/watch?v=_fLhibzK5Cw
Опу чая, тему подкинул.
Очень классная штука чтобы детей приучивать к гейм деву, для обычно анона слишком уж примитивно.
> слишком уж примитивно
И ЧСХ, раньше было больше функционала. Но в трёшке многое убрали. Штука примитивная, но для многих это может быть вызовом (могу ли я сделать сложное на примитивном?)
>могу ли я сделать сложное на примитивном?
я так игру про башню делать начал
Согласен, к примеру на твг сделать игрульку на этом конструкторе хорошая идея.
Что интересно чекнул форум, вроде куча сообщений, и есть ощущение что всё развивается, что огромный плюс, ведь на твои грабли уже наступили и быстрее решать поступающие баги, и больше времени уделять контенту.
>>740224
Особенно интригует, что там искаропки редактор векторной графики. Что роднит это всё с флешем и делает ещё быстрее быструю двухнедельную разработку игор.
Ну хз, я даже в констракте когда кубики расставляю уже чувствую себя дебилом, а тут уж совсем для детишек программирование какое то. Обучатся наверно круто, но что то серьезное делать, увольте
Удивительно, даже у никому не нужного скретча есть клоны.
Ты уж меня извини, но у меня моментально глаза вытекли от такого цветового оформления.
Не извиню. Косарь отдай.
Скорей бы уже сделали движок на нейросетях, шоб кнопка ЗДЕЛОТЬ ЗОЕБИСЬ посередине зеленая.
Оказалось, что в Беркли запилили Snap! -продвинутый форк масачусетского скретча с объектами первого класса и метапрограммированием. Кароч, если и делать игоры то в снэпе.
https://snap.berkeley.edu/snap/snap.html
Скрэтч это база.
Помню, что недолго пользовавшаяся здесь популярностью разработчица и мыслительница под псевдонимом Штумоз тоже восхищалась этим продуктом и требовала у правительства Украины выделить ей гранты на развитие специальной версии Скрэтча для украинских школьников. Но поскольку она пишет на русском и считает США врагом человечества, правительство Украины предпочло финансировать убийства мирных жителей, а не образовательные проекты...
>никому не нужного
Скретч используют в школах (где-то).
>у скретча есть клоны
Не путай клоны и проекты на одном движке.
https://en.wikipedia.org/wiki/Blockly
>Blockly is used in several notable projects, including:
>MIT's Scratch, visual programming environment for education
https://developers.google.com/blockly
https://github.com/google/blockly
>>831981
>первые шаги в программировании
Чисто по приколу, почему бы не попробовать? Для саморазвития программисту нужно пробовать новые инструменты, даже если они кажутся детскими, лишними или устаревшими. Тем более что в данном конкретном случае это просто, язык-то императивный.
Какая же гадость. Фу. Отвратительно. И ведь фактически это та же самая строка императивного кода, только ты не можешь изменить его как строку, ты вынужден мышкой таскать блоки и глазами искать нужные тебе блоки, а не прямо из головы писать что захочешь.
Нет, если хочешь делать программы графически - нужна какая-то другая парадигма. Точно не императивная. Если от императивной парадигмы не избавиться (машинные коды в любом случае императивны), то императивный код нужно писать как текст. А графически перемещать блоки следуя другой парадигме...
Тебя серьёзно устраивает такой дизайн? Тут 5 (ПЯТЬ!) уровней вложенности, две пары которых имеют одинаковый цвет, а нарисованы они двухпиксельной (ДВУХ! ПИКСЕЛЬНОЙ!) рамкой с мерзким размытием, ещё больше портящей и без того плохие цвета, смешивая всё в кашу.
А теперь главный вопрос: ЗАЧЕМ нужно было делать эту кислотную гирлянду из 5-уровневой башни прямоугольников, если текст на этой картинке можно напечатать за считанные секунды, если ты уже умеешь печатать хотя бы двумя пальцами не глядя на клавиатуру?
Если ты инвалид с проблемами рук - извини. Но если тебе просто лень печатать, то я советую взять себя в руки и обучиться слепой печати. Хотя бы как-то. Сперва будет тяжело, но потом поймёшь, что печатать код куда проще и быстрее, чем составлять комбинации фишечек-прямоугольничков мышкой.
Я не говорю, что "визуальное программирование" вообще не нужно, нет, у него есть свои области применения. Также, я думаю, возможно придумать или использовать другую парадигму, в которой визуальность будет иметь куда больше смысла, чем в императивной парадигме (т.е. вместо "if ... then ... else ..." будет что-то другое).
А в данном конкретном случае, я надеюсь, можно пофиксить косяки Скретча изменением стандартной цветовой темы и увеличением полей (margin) блоков (сверху и снизу как минимум). Можно ведь? Можно?..
На картинке ошибка, я перепутал блоки 4-го уровня с блоками 5-го уровня, т.к. торопился. Но это только наглядно показывает, как легко запутаться в этом представлении кода.
Также я знаю, что цвета в Скретче не обозначают уровень вложенности - цвета обозначают только тип блока. Вот конструкция "if then else" - жёлтенькая, а условное выражение "key = w" - зелёненький шестиугольник. Проблема в том, что это кислотные цвета и они никак не помогают прочитать код и понять его смысл, а только мешают (в таком исполнении).
Может быть, такие цвета выбраны с учётом людей с проблемами зрения, в чём я очень сомневаюсь - тут и зрячий легко запутается, но человеку с нормальным восприятием цветов эта цветная каша неприятна.
И это я на обычном старом LCD мониторе. На OLED будет в разы хуже, т.к. у OLED выше насыщенность цветов.
> Какая же гадость. Фу. Отвратительно.
Это всё рефакторится. Главное - уметь.
>>832019
> Чисто по приколу, почему бы не попробовать?
Именно так.
>>831991
> Скрэтч это база.
А Snap! - это надстройка над базой. Причём неплохая. Теперь это Снэп-тред.
>>832083
> Тебя серьёзно устраивает такой дизайн?
Не устроил. Поэтому я перешёл со скретча на Snap! Смотри скока разных стилей.
> А теперь главный вопрос: ЗАЧЕМ
ПОТОМУ ЧТО ХОЧЕТСЯ. НУ ВОТ ХОЧЕТСЯ И НИЧЕГО С ЭТИМ НЕ ПОДЕЛАЕШЬ.
> нужна какая-то другая парадигма. Точно не императивная.
> А графически перемещать блоки следуя другой парадигме
В снэпе можно складывать блоки в функциональной парадигме: шапка, хвост, каррирование, все дела. Просто я сам императивщик, в функционалку не умею. Это не минус языка. Это мой минус.
>функциональной парадигме
Так она не сильно отличается от императивной, если я ничего не путаю. Вот декларативную парадигму было бы круто реализовать визуально, чтобы собирать из кубиков не решение задачи, а описание задачи, которую нужно решить компьютеру. Сравни, например, 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.
По официальному сайту не ясно, можно ли компилировать код во что-то серьёзное или это такая же веб-платформа для создания детьми примитивных игрушек и "проведения серьёзных научных исследований" (каких?)...
> Хм, в общем-то редакторы игровых сцен и являются WYSIWYG редакторами для какого-то внутреннего декларативного языка
Правильно заданный вопрос имеет в себе ответ. Молодец, ты сам догадался до ответа. Не нужно требовать декларативности там, где она не нужна. Декларативность поставляется именно инструментами редактирования объектных иерархий (сцен, окон, страниц, уровней и т.п.)
Я надеюсь с этим вопросом мы разобрались и не будем в дальнейшем жаловаться на слабую декларативность визуальных языков?
>serious study of computer science.
>проведения серьёзных научных исследований
Блин, перепутал, там говорится "серьёзное ИЗУЧЕНИЕ компьютерных наук (а.к.а. информатика)", т.е. это просто инструмент для обучения программированию.
>можно ли компилировать код во что-то серьёзное
Похоже, что можно:
>codification of Snap! programs to text languages such as Python, JavaScript, C, etc.
>>832169
>не будем в дальнейшем жаловаться на слабую декларативность визуальных языков?
Нет, будем. От идеального визуального языка я бы хотел удобной комбинации высокоуровневых систем и возможности разработки сверху вниз, начиная с пустышек. Типа чтобы можно было бы сказать: "вот есть такая-то штука и вот такая-то, как они работают я пока понятия не имею, но они должны иметь такие-то свойства и так-то друг с другом взаимодействовать". В ООП это возможно, но выглядит не слишком наглядно (куча текста в куче отдельных файлов), хотелось бы видеть визуальную репрезентацию своих классов...
А то пока что всё, что я вижу - это примитивные низкоуровневые конструкции "если А, тогда Б+В", которые разрабатываются снизу вверх и поэтому удобнее пишутся вручную, чем собираются из блоков.
А ещё, кстати, декларативность в скретче/снэпе обеспечивается С-формой С-блоков, они как бы охватывают группу блоков, содержащуюся внутри, как круги Эйлера вышеупомянутые. И снэп дополнительно подкрашивает цепочки С-блоков двумя оттенками их базового цвета. Всё наглядно, всё видно, что откуда и куда идёт в императивной цепочке задекларированных блоков.
> я бы хотел удобной комбинации высокоуровневых систем
> возможности разработки сверху вниз, начиная с пустышек
Ну создавай свои блоки, добавляй в них код, затем из своих блоков создавай код более высокого уровня. Всё есть. (В снэпе).
> вот есть такая-то штука и вот такая-то, как они работают я пока понятия не имею, но они должны иметь такие-то свойства и так-то друг с другом взаимодействовать
Именно в таком ключе.
> хотелось бы видеть визуальную репрезентацию своих классов
Ну блоки же.
> А то пока что всё, что я вижу - это примитивные низкоуровневые конструкции
Ты видишь то, что хочешь видеть. Хорошо. Как мне тебе это продемонстрировать на блоках? Давай ТЗ.
>С-блок
О, кстати, а там можно эти блоки сворачивать, то есть временно скрывать их содержимое? В современных редакторах текстового кода обычно есть возможность свернуть блоки кода в одну линию: редактор временно скрывает часть строк, отображая слева на линейке, какая часть строк скрыта. Это бывает удобно, хотя, если честно, хорошо написанный код скрывать не нужно. Можно даже последовательно скрывать разные вложенные уровни кода, например, если у тебя длинный каскад из if/for/while.
>>832175
>Ну создавай свои блоки, добавляй в них код, затем из своих блоков создавай код более высокого уровня.
Не понял, так можно объединять между собой пустышки или нельзя? В ООП возможен такой подход: описываем свойства и методы класса и сразу же вызываем их из другого класса, но пока класс пустой, он ничего не делает, это "пустышка". В последствии наполняем методы класса кодом и система начинает работать.
Можно сравнить с рисованием. Разработка снизу вверх - это когда художник рисует каждую травинку и каждый листик, имея слабое представление о том, что получится в итоге. Разработка сверху вниз - это когда художник большими пятнами цвета отмечает расположение деревьев, травы, неба, облаков, людей и т.д., а потом постепенно добавляет детали на всех частях картины равномерно, пока объекты не станут достаточно узнаваемы.
Вот снизу вверх рисовать сложно (также это считается ошибкой новичка), а печатать код - легко. А вот сверху вниз рисовать легко, но печатать код сложно, потому что в отличие от картины код не лежит перед тобой в общем и целом как на одном холсте, он разбросан то тут, то там. Исправить это можно было бы визуальным программированием, совместив его с классическим текстовым кодом, но я пока не видел годных реализаций и Snap! не выглядит как такая реализация.
>Ты видишь то, что хочешь видеть.
Я вижу готовый низкоуровневый код.
>Как мне тебе это продемонстрировать на блоках?
Если так хочется, запиши видео, как ты составляешь программу из блоков сверху вниз. Или хотя бы серию скриншотов "пустышка", "композиция пустышек", "наполнение кодом", "рабочий результат". Это будет нагляднее скриншота одного только результата.
Опять же, сравни с рисованием. Когда ты видишь чужой рисунок, ты понятия не имеешь, как его рисовали. Но некоторые художники записывают и выкладывают процесс рисования, и ты можешь изучить его и понять пайплайн и некоторые базовые трюки. Так и здесь, только вместо частей рисунка - "рисуются" части программы.
> А вот сверху вниз рисовать легко, но печатать код сложно, потому что в отличие от картины код не лежит перед тобой в общем и целом как на одном холсте, он разбросан то тут, то там. Исправить это можно было бы визуальным программированием, совместив его с классическим текстовым кодом, но я пока не видел годных реализаций и Snap! не выглядит как такая реализация.
Теперь я понял. Годная реализация должна выглядеть так:
1. Код состоит из стыкуемых элементов, стыкующихся в нескольких направлениях (далее блоки), подобно кругам Эйлера.
2. Код начинается в центре и заканчивается по краям готовой фигуры, образованной блоками кода (назовём её - модуль).
3. Свёртка вида: Каждый модуль может быть свёрнут в одну фигуру или развёрнут на отдельный холст, для изменения кода в нём.
4. В развёрнутых модулях входы и выходы для данных находятся в соответствующих блоках, а у свёрнутого модуля входы и выходы на границе его блока-представления.
5. Входы - кружочки. Выходы - точечки.
6. Работа с кодом должна вестись с клавиатуры:
- Таб/шифт+таб - циклически переключаться между входами выбранного блока.
- Пробел: на присоединенной паре вход-выход - переход к следующему (выходному) блоку ( с шифтом переход ко входному блоку); на неприсоединённом блоке - выпадающее меню вставки блока.
> запиши видео, как ты составляешь программу из блоков сверху вниз
Видео хлопотно. Вот серия скринов. Я обнаружил, что нет очевидных функций минимума и максимума. Окей, я запилил свои. Создание своего блока - это по сути создание метода.
Command - это императивный метод, то есть команда, то есть вызываемая в потоке команд. подразумевается, что это аналог void-метода, но в параметрах можно указать выходные данные "out" или в терминологии снэпа - upvar.
Reporter - это как бы геттер поля, но у него нет поля, он просто сообщает некое значение, в этом смысле он как бы типизированный метод (в смысле, не void) но он не может по умолчанию встроиться в поток вызова команд. Однако в снэпе есть делегаты (ринги) и репортера можно обделегировать, для этого есть команды run (синхронная) и launch (асинхронная).
Predicate - это по сути репортёр, но для логических значений.
Вполне себе гибкая система, ИМХО. Держим в уме, что система не для полноценного продакшона, а для обучения ньюфагов, и для прокрастинации олдфагов.
>vec2 0 0
>vec2 0 0
>vec2 0 0
Изобрети уже константу Vector2.ZERO, лол.
Кстати, да.
Спасибо за разбор.
>Command
>Reporter
>Predicate
Их роли легко понять по названиям и скриншотам кода, так что можно было не объяснять.
>>832230
>1. Код состоит из стыкуемых элементов, стыкующихся в нескольких направлениях (далее блоки), подобно кругам Эйлера.
>2. Код начинается в центре и заканчивается по краям готовой фигуры, образованной блоками кода (назовём её - модуль).
Я честно пытался, но так и не понял, зачем именно так делать. То, что ты предлагаешь, можно было бы и на GraphNode в Godot сделать...
>Входы - кружочки. Выходы - точечки.
Неинтуитивно. Было бы лучше обозначать выходы как стрелочку/галочку, направленную наружу фигуры, а входы - как стрелочку/галочку, направленную внутрь фигуры. Ну или нарисовать пупырышки и вмятинки как в Scratch/Snap блоках, а-ля паззлы: пупырышек - выход, вмятинка - вход. Но я бы всё же оставил натягивание ниток как у GraphNode, чтобы сами ноды можно было размещать как угодно.
Итак, откиньтесь на спинку кресла, и представьте, что в годоте вместо вот этих вот граф-нод (пик1) в качестве визуального скрипта скретч-лайк модулярный композит (пик2).
Как тебе такое, Хуан Линецкий?
>представьте, что в годоте вместо вот этих вот граф-нод (пик1) в качестве визуального скрипта скретч-лайк модулярный композит (пик2)
Во-первых, принципиальной разницы в коде нет, это всё та же императивщина, которую яждизайнеру не понять, у него мозг на это не натренирован.
Во-вторых, у нод с ниточками куда больше гибкость и потенциал, который, увы, в Годо так и не раскрыт. Нужны ноды более высокого уровня, принимающие на вход сущности высокого уровня, а не вещественные числа и даже не векторы. Если я не ошибаюсь, в этом суть блупринтов УЕ и процедурных нод Блендера.
В-третьих, блоки скретча в самой своей сути - это просто подсветка синтаксиса и немного другие ключевые слова обычного текстового кода. Если убрать блоки (которые мне, кстати, не нравятся с эстетической точки зрения), из твоего кода на скретче получится обычный текстовый код. Суть скретча в том, чтобы детям не приходилось бороться с синтаксическими ошибками в коде, когда они случайно забывают поставить точку с запятой, закрыть скобку или сделать отступ в нужном месте. Код в стиле скретча не решает проблему яждизайнера, которому не хочется разбираться в кодинге, но хочется, например, заставить персонажа двигаться.
Вот ты на своих скриншотах решил задачу движения персонажа как программист. Разница только в том, как изображён код, но код одинаковый. Ты применил свои программистские знания к разным инструментам, которые отличаются только внешним видом.
Яждизайнер же не справится с твоим кодом, каким бы внешним видом он ни был бы представлен. Он понятия не имеет о векторах, вещественных числах и всём таком нашем кодомартышечном. Он знает только, что нажатие клавиш должно перемещать фигурку по экрану и ему нужно описать это каким-то образом, не вдаваясь в детали реализации. Ни ноды Годо, ни блоки Скретча не позволяют ему этого сделать, заставляя учить коды и матан.
> Если я не ошибаюсь, в этом суть блупринтов УЕ
Ошибаешься. Завтра то же самое в блупринтах выложу.
> и процедурных нод Блендера
Тоже ошибаешься. Блендер открой. Всё на тамошних нодах так же: входы, выходы, типы данных.
> Суть скретча в том, чтобы детям не приходилось бороться с синтаксическими ошибками в коде
Нам нужны новые годотеры. Отлично!
> Код в стиле скретча не решает проблему яждизайнера, которому не хочется разбираться в кодинге, но хочется, например, заставить персонажа двигаться.
Посочувствуем нашему вымышленному яждизайнеру. И не перезвоним ему.
> Ошибаешься. Завтра то же самое в блупринтах выложу.
А пока что просто скажу. УЕ парадоксальным образом ещё больше программистских правил нарушает, там куча синглтонов, синглтонов, блять, за которые с собеса на галеру выгоняют! На каждый чих - синглтон.
> ноды более высокого уровня, принимающие на вход сущности высокого уровня, а не вещественные числа и даже не векторы
Высокий уровень пиздабольства на входе.
>Нам нужны новые годотеры. Отлично!
Ты имеешь в виду пятилетних детей? Потому что визуальные скрипты из Годо убрали по той простой причине, что новичкам, которые попробовали GDScript, уже не нужны были никакие визуальные языки. А пятилетние дети пусть продолжают сидеть на скретче, Годо им не нужен и Годо они не нужны, пока не подрастут. Годо за лёгкость освоения новичками, но не для совсем маленьких детей. Совсем маленькие пусть вон, в Роблокс свой играют.
Или тебе настолько в кайф двигать блоки, что теперь уже не хочется печатать код? Об этом я уже говорил, научись печатать вслепую и двигать мышь станет лень...
>>832408
Я УЕ никогда не ставил, но по скриншотам видел там какие-то высокоуровневые ноды. Алсо лапшиз что-то здесь упоминал про них. Не спорю, что и там можно векторы пересобирать, но зачем? Это как микроскопом гвозди забивать. Лучше создать высокоуровневые сущности и менять отношения между ними кликами мыши.
Вот как в Годо такие сущности создавать я не понял. То есть да, я могу создать свою ноду для дерева сцены, у которой будут поля для кастомных ресурсов и куча параметров. Но это не имеет отношения к визуальному языку. Визуальные скрипты живут в каком-то своём мирке, не связанном с деревом сцены и нормальными скриптами. Как я их использовать вообще должен, если они занимают ячейку нормального скрипта в ноде?
Вот в Blender Game Engine было какое-то отдельное окошко (Game Logic?) со связями ниточками: "событие - условие - действие", и это самостоятельный от скриптов на питоне инструмент, а не попытка изобразить питоновые скрипты в виде лапши. Почему-то в Годо его нет, хотя логично было бы иметь, вместо этого пытались полностью заменить скрипты визуальной лапшой и закономерно провалились...
>Blender Game Engine
>событие - условие - действие
Таки да, я был прав, до сих пор есть.
>>832348
>Как тебе такое, Хуан Линецкий?
Сделал играбельную мини-игру на UPBGE вообще без программирования, даже "визуального". И таким способом можно реализовать множество игровых механик, а для остального есть полноценный Python: программист, если нужно, пишет сложные системы/модули на Python, а геймдизайнер настраивает логику и вводит циферки в понятные даже гуманитарию менюшки.
Как тебе такое, Блочный Код Скретчевич?
И таки возвращаясь к Годо, потому что ты сам затронул эту тему здесь: Годо заставляет прописывать всю базовую логику кодом на GDScript, но зачем? Что дадут эти бесконечные бездумно копипастные if event.is_action_pressed("bla_bla_bla"): just_do_that_damn_thing_already(you_stupid_bastard) или ещё хуже, каскады из if colider... а-а-а, блин, я даже не могу навскидку сказать, какой там код для проверки столкновений, хотя я минимум джва года ковыряюсь в Годо, пытаясь сделать игру. То есть да, там много способов проверить столкновения, но просто взять и проверить нельзя, нужно сделать кучу действий в редакторе и потом ещё обязательно написать несколько строк по сути бойлерплейт кода. Не говоря уж о том, что соединения между событиями (сигналами) и обработчиками не визуальные, они "где-то там" - либо в инспекторе ноды, либо в самом коде (на практике - где угодно, то есть вообще где угодно, ищи давай, вилкой ищи, вот тебе 9000 файлов с отборным кодом, ищи давай connect-ы).
Короче говоря, BGE и его Logic Bricks незаслуженно забыты, хотя конкретная реализация менюшек не такая уж удобная, если честно. Интересно, можно ли реализовать аналог в Godot, особенно после выпиливания визуальных скриптов? Через тул скрипты можно сделать менюшку, но может ли аддон в рантайме реализовать то поведение, которое юзер нащёлкал в этой кастомной менюшке? Чтобы всю тривиальную логику (обработчики клавиш, столкновений, таймеров и т.п.) совсем без кода делать. А если ещё и обработчики сигналов визуально ниточками связывать на некой глобальной карте проекта (процедурной, Код Блочный, процедурной карте проекта!), вообще кайф был бы, я бы ловил оргазм от созерцания архитектуры своего проекта (после того, как проблевался бы с неё и отрефакторил, ведь я сейчас даже не знаю её толком - проекты мои умом не понять, в байтах не измерить)...
Как же хочется аддончик написать, ну почему я такой прокрастинатор, разве я многого хочу...
> Вот как в Годо такие сущности создавать я не понял.
Я понял, но это неважно, потому что визуальный скрипт будет удалён, ставить его аддоном никто не будет, он мертворожден.
> То есть да, я могу создать свою ноду для дерева сцены, у которой будут поля для кастомных ресурсов и куча параметров. Но это не имеет отношения к визуальному языку.
Имеет. Всё тоже самое ты можешь сделать и там. Ну, как сказать? Нет ,не всё. Если бы над модулем работали, то мог бы всё, а на данный момент можешь базовые типы экспортами подключить. И всё это коряво и неочевидно организовано, что я сам наверное единственный, кто случайно нашёл этот функционал.
> Визуальные скрипты живут в каком-то своём мирке, не связанном с деревом сцены и нормальными скриптами.
Неверно. Они в том же мирке живут и прекрасно взаимодействуют со всеми остальными компонентами.> Как я их использовать вообще должен
Возвращаемся к п.1. Если бы их не дропнули, я бы ответил read the docs, однако теперь да, ответ - никак.
> хотя конкретная реализация менюшек не такая уж удобная, если честно
Кстати да. Юзабилити очень важна. Даже если на блоках кодить, не таская их мышкой, а например, переключаясь стрелками между блоками в цепочке и нажимая хоткеи для вставки блоков (press F to add Respect block) - то уже будет ощущение удобства.
> эти бесконечные бездумно копипастные if event.is_action_pressed("bla_bla_bla"): just_do_that_damn_thing_already(you_stupid_bastard) или ещё хуже, каскады из if colider...
Рано или поздно на любом уровне абстракции ты упрёшься, переходя от абстракций к реализации, с голым машинным нутром, которое сугубо императивно. И тебе придется именно длинными цепочками ифов проверять все свои нажатые клавиши.
Либо один раз сделать общую функцию, в которой это всё делается мерзким копипастом и спрятано от твоих высокоуровневых абстракций
>И тебе придется именно длинными цепочками ифов проверять все свои нажатые клавиши.
Ты видео не смотрел, верно? Где там "длинные цепочки ифов"? Где там хотя бы строчка кода? Там только логические связи "если W - двигай вперёд". Вот почему нельзя везде так делать? Это же удобно.
>переключаясь стрелками между блоками в цепочке и нажимая хоткеи для вставки блоков - то уже будет ощущение удобства.
Ага, а если вместо стрелочек набирать названия блоков и нажимать enter, то будет уже не просто ощущение удобства, а самое настоящее удобство. Ой, только это будет уже обычный текстовый редактор с автодополнением, вот ведь какое неожиданное совпадение.
> Где там "длинные цепочки ифов"?
Под капотом твоей связки "если W - двигай вперёд". Об этом речь.
> просто ощущение удобства, а самое настоящее удобство
Вкусовщина.
Блять, макаба, что ты творишь!?
Извините, это пикча из ньюсача.
>>832498
Да у тебя не только пикча из ньюсача...
>Под капотом твоей связки "если W - двигай вперёд". Об этом речь.
facepalm.jpg
Мы, кажется, обсуждали, с помощью какого инструмента лучше делать игры для непрограммиста? В чём смысл твоего "под капотом всё равно код", если с точки зрения пользователя он код не пишет?
Вот скретч - это написание кода мышкой. Да, код обёрнут в кислотные коробочки, но это код, портянка из инструкций воображаемому дурачку.
А в БГЕ ты именно логику навешиваешь, а не код.
> Вот БГЕ- это написание кода мышкой. Да, код обёрнут в серые коробочки с линиями, но это код, портянка из инструкций воображаемому дурачку.
> А в скретч ты именно логику навешиваешь, а не код.
Сможешь обеснить разницу? Я - не вижу.
Покуда меня не зачислили в тролли, всё же разверну свою мысль: ящитаю, что любая визуальная не-код-система - это всё равно код.
Основной смысл не-код-системы - быть понятной дурачку. Однако это не помешает поработать в ней "умнячку".
>Сможешь обеснить разницу?
Вот здесь у тебя >>832348 не просто кучка блоков, а композиция по определённым правилам, которые понять можно только уже зная принципы программирования. Вот у тебя вызов функции, в него вставляются не просто какие-то числа, а целые конструкции, которые ещё нужно найти на палитре блоков, выбрать и заполнить, да не абы как, а всё по правилам. Такой инструмент предоставляет неограниченные возможности, т.к. является полноценным языком программирования, но чтобы им научиться пользоваться, нужно научиться программировать, чего новички и яждизайнеры активно пытаются избежать. Поэтому скретч хорош для обучения детей программированию, но плох в качестве замены программированию.
Здесь >>832450 я показал, что можно собрать целую игру совсем без программирования, только натягивая ниточки слева направо, выбрав сначала "сенсор" и "актуатор". С этим справится любой, даже не зная основ программирования, достаточно объяснить ему суть. Да, впрочем, и объяснять ничего не надо - из названий ясно, что сенсор реагирует на какие-то события, а актуатор совершает какое-то действие. Что мы хотим сделать? Сдвинуть кубик по оси Y в ответ на нажатие кнопки W. Выбираем сенсор "клавиатура" и актуатор "движение", в первом вводим букву W, а во втором вводим любое число в поле с буквой Y. Соединяем сенсор с актуатором ниточкой и готово - теперь кубик двигается куда мы сказали по нажатию указанной кнопки. Продолжаем путём повторения этих очевидных действий, постепенно изучая методом тыка свойства разных сенсоров и актуаторов. Даже логические блоки, "контроллеры" понять совсем не сложно, контроллер И ждёт срабатывания всех подключённых сенсоров (сенсор А и сенсор Б), контроллер ИЛИ ждёт срабатывания любого из сенсоров (сенсор А или сенсор Б), и т.д. Разве что про XOR придётся погуглить, т.к. это искусственное слово. Так вот в этом всём нет никакого кодерства, ты не пишешь код - ты просто создаёшь связи между двумя/тремя классами сущностей. Да, эта система имеет ограничения и будет неудобна для сложной логики, но она не ставит своей целью заменить программирование целиком и не ставит целью обучать программированию. Её цель - упростить описание логики для тех, кто не хочет разбираться в программировании.
>>832517
>любая визуальная не-код-система - это всё равно код
Тут лингвистическая проблема. Программирование в самом широком смысле - это создание программ, а не написание кода. Так что замена картинок в готовой программе тоже своего рода программирование, ведь возникает новый программный продукт (производный от существующего, но всё равно новый). Но в наиболее узком смысле программированием называют кодинг, то есть буквально написание кодов (слов) на каком-то языке, а не нажатие кнопок в умных менюшках. Коды можно изобразить визуально и заставить таскать их мышкой - они останутся кодами и процесс таскания будет идентичен написанию. Детские кубики с буквами тоже позволяют составлять слова и ими при желании можно что-то сказать, вот в случае с визуальными языками программирования та же ситуация, только вместо букв на кубиках - слова и выражения. При желании можно заменить слова на пиктограммы, смайлики, эмодзи - суть кодинга останется неизменной, ты пишешь текст на языке.
А в случае с логикой БГЕ нет никакого языка. Ты не составляешь выражения из кубиков, ты только создаёшь простые подключения между некими приборчиками. Вот если вставить провод в одну розетку, загорится красная лампочка, а если в другую - зелёная, ну и где тут язык? Ты не выражаешь свою мысль на каком-то языке собеседнику (компьютеру), ты только настраиваешь умные приборчики, чтобы они работали так, как ты хочешь. Если у тебя под рукой не окажется нужного приборчика - тебе придётся идти к папе-программисту с просьбой создать приборчик, потому что сам ты его никак не создашь. А папа-программист придёт и объяснит глупому компьютеру на его странном и непонятном тебе языке, как должен работать недостающий приборчик, компьютер подмигнёт и у тебя появится новый приборчик для создания связей с уже имеющимися.
Сразу предупреждаю, речь не идёт о создании связей между нодами визуальных языков в Godot/UE/Blender. Легко обмануться из-за внешнего подобия. Визуальные языки - это именно языки, ты создаёшь на них языковые конструкции, с помощью которых выражаешь свои мысли компьютеру. Ты можешь строить длинные многословные выражения, а можешь рубить короткие фразы, но это всё твоя речь на языке. В описанном выше случае нет никакой речи, есть только ограниченные подключения между фиксированными системами. На визуальном языке можно реализовать подобное (создав множество высокоуровневых конструкций и площадку для их подключения между собой), но не наоборот.
>не помешает поработать в ней "умнячку"
А это ничего не значит. Взрослый может выкладывать длинные осмысленные тексты детскими кубиками - это язык. Но если взрослый будет соединять между собой лампочки и розетки, он не сможет связать и двух слов, потому что в лампочках и розетках нет языка, они не выражают никаких слов, из них не создать осмысленных языковых конструкций. Т.е. от ума пользователя суть инструмента не меняется.
Если ты почувствовал нажатие кнопки W, тогда возьми из свойств кубика его текущее смещение, извлеки из него Y-компоненту, прибавь к ней число 0.05, затем верни полученное значение обратно в Y-компоненту смещения, а само смещение верни в свойства кубика, чтобы он обновил своё положение на экране на новое.
Сказанное выше является полноценной компьютерной программой на каком-то вымышленном языке программирования, я гарантирую это. Мы не создаём и не используем таких языков из-за их избыточной сложности и многословности - тот же смысл можно объяснить компьютеру намного короче. Однако попытки создать такой язык были и продолжаются, только сейчас фокус сместился с ручного создания компиляторов на тренировку нейронок на примерах кода с описанием на естественном языке, но суть не меняется, нейронка играет роль транспилятора - переводит с одного языка на другой.
Но главное, что нужно понять - для написания данной программы писатель должен владеть определённой системой языковых правил, достаточно сложной, поскольку язык позволяет составлять самые разнообразные выражения, многие из которых в зависимости от контекста ошибочны или не несут в себе смысла. Нужно быть, так сказать, мастером слова, чтобы составлять такие выражения, пусть и на искусственном языке.
А теперь сравним с этим:
[кнопка] W => [движение.y] 0.05
Что это? Может показаться, что это тоже какой-то язык (потому что я записал это буквами языка), но нужно заметить, что это единственная возможная фраза, её нельзя построить как-то иначе, нельзя вставить внутрь неё что-то ещё и ничего из неё изъять. Это просто натянутый провод между устройством "кнопка" и устройством "движение.y", у которых выставлены ручки в положение "W" и "0.05" соответственно. Как бы ты ни дёргал за провод и как бы ни крутил ручки, ничего другого ты не сделаешь. Ты не составляешь выражения, не пишешь текст, даже не выкладываешь кубики - ты просто настроил два прибора, между которыми есть соединение одним проводом. Всё. С этим даже обезьяна справится, если сможет удержать в своих лапах провод и попасть в отверстие разъёма, а значения на ручках можно и по умолчанию оставить вообще. А вот если посадить ту же обезьяну за печатную машинку или даже выдать ей в лапы кубики с буквами - осмысленного она ничего не напечатает, ведь в её мозгах нет языка с его правилами. Мы можем попытаться обучить обезьяну правилам языка и она даже что-то запомнит, но зачем нам это делать, если для решения бытовых задач обезьяны достаточно двух приборов и одного провода? Справится и без обучения языку...
Понятно, какую мысль ты пытался донести, но с формальной точки зрения все может быть не так.
Может оказаться, что язык А можно писать только такими конструкциями (тогда возьми из свойств кубика его текущее состояние), а все остальные попытки будут заканчиваться синтаксической ошибкой компиляции.
С другой стороны, обилие спецсимволов в языке B не гарантирует, что их нельзя сочетать ебанутым образом, как в каком нибудь J, а это вполне реальный у ученых, не эзотерический/шуточный язык.
>язык А можно писать только такими конструкциями
>не гарантирует, что их нельзя сочетать ебанутым образом
При чём тут это? Речь шла о том, что является языком, а что - нет.
Среди естественных языков тоже есть более жёсткие и более гибкие языки. На английском есть много правил построения предложений, нарушая которые ты совершаешь ошибку и даже можешь быть неправильно понят. А вот в русском языке положение слов почти не влияет на смысл сказанного - да, есть какие-то устоявшиеся нормы, но если построить предложение по-другому, тебя смогут понять и это не будет ошибкой с точки зрения языка. Но, несмотря на такие отличия в правилах, английский и русский являются языками, позволяя передать собеседнику одни и те же мысли.
С языками программирования аналогично, есть языки с максимальной свободой и есть языки с минимальной свободой, но они являются языками, потому что на них можно написать любую программу, которую может выполнить компьютер.
Но я тут подумал ещё, и всё не так просто, как кажется. Есть такая тема - полнота по Тьюрингу. Если система полна по Тьюрингу - она может выполнить любую задачу, которую способен выполнить компьютер. Так вот полнота по Тьюрингу обнаруживается в самых необычных местах - даже игра "Жизнь" с её примитивными правилами является полной по Тьюрингу, т.е. в ней возможно собрать эмулятор компьютера, записать в него программу и получить результат (и вроде бы даже уже делали простые компьютеры в игре "Жизнь"). Вполне возможно, что "logic bricks" в BGE тоже полны по Тьюрингу (без использования скриптов на Питоне) и из них можно собрать любую программу, включая эмулятор компьютера. Тогда утверждение, что logic bricks не являются языком программирования, будет звучать довольно странно...
С другой стороны, мы же говорим о языках. Вот HTML является языком программирования (декларативным), хотя не обладает полнотой по Тьюрингу. Многие другие языки программирования тоже не обладают полной по Тьюрингу, т.к. не нуждаются в ней для решения задач, ради которых они были созданы. В то же время игру "Жизнь" нельзя назвать языком программирования, хотя она и решает любые задачи, точно так же, как нельзя назвать языком программирования горсть транзисторов или красную пыль в Minecraft (тоже полна по Тьюрингу). Т.е. нужно смотреть в определение "языка" и ориентироваться на него, а не на выполнимость задачи каким-то инструментом. Даже если logic bricks позволяют решить любую задачу, это не язык программирования, даже не визуальный язык.
Ну так оба примера являются языком.
>[кнопка] W => [движение.y] 0.05
>Что это? Может показаться, что это тоже какой-то язык (потому что я записал это буквами языка), но нужно заметить, что это единственная возможная фраза
Это язык, в котором возможна единственная фраза. А еще бывает алфавит, состоящий из одной буквы.
>Это язык, в котором возможна единственная фраза
Абсурд. Лень аргументировать...
>алфавит, состоящий из одной буквы
Ты про азбуку Морзе? Это просто форма записи обычной латиницы или кириллицы точками и тире. Наш текст здесь на форуме тоже хранится как нули и единицы, но читаем мы буквы алфавита из 33 букв, а не из двух.
>Абсурд
Наука. Тоже лень аргументировать. Читай https://ru.wikipedia.org/wiki/Формальная_грамматика
В принципе это несильно отличается от комбинаторики и множеств. Множество может быть пустым, с одним элементом, со счетным кол-вом элементов, с бесконечным кол-вом. Так что ничто не мешает существовать языку с одной-единственной допустимой фразой.
>Ты про...
Нет, я про алфавит из одной буквы {A}. Из него можно составлять слова А, АА, ААА...
Также могут быть алфавиты, где составляющими элементами будут слова. Например, Ту, Ту Ты, Ты Ту Ты и т.д.
Поэтому я сделаю свой графический язык. Вот какие вводные я разработал на данный момент:
1. Блоки монохромны. Любые цвета расцениваются как синтаксический сахар. Блочная программа должна без потери смысла распечатываться на монохромном принтере или вывестись на монохромном дисплее.
2. Главный атрибут блока которым он отличается от других - его форма. На форму в моей концепции завязано всё.
3. Поток выполнения прописывается сверху вниз.
4. Поток вычисления выражений прописывается слева направо.
5. За поток выполнения отвечают блоки команд: Заголовки, концевики (терминаторы), возвраты (репортеры в терминологии скретча), сегменты (С-блоки в треминологии скретча).
6. За поток вычисления отвечают блоки выражений: типы, операторы.
7. Блоки типов символизируют в первую очередь типы данных. Фундаментальные (bool, byte, char, int, real (single, double, decimal). Производные, например string является производным от char и олицетворяет массив символов. Составные: object - первый и главный составной тип, олицетворяющий ООП и являющийся предком любых объектов. Его форма - прямоугольник (box) и своей формой он олицетворяет очевидно боксинг, возможность упаковать в object любой другой тип данных.
7.2. Во вторую очередь блоки типов это функции, возвращающие значение.
8. У каждого блока в середине есть как минимум одно гнездо для вставки либо текста, либо другого блока. Гнёзда символизируют значение для фундаментальных типов, либо параметры инициализации для составных типов. Вместо блоков-сеттеров скретча, я объединяю концепцию сеттера с этими гнёздами внутри. В скретче нужно поставить специальный блок-сеттер, выбрать в выпадающем списке требуемое имя переменной, и затем в гнездо вставить устанавливаемое значение. У меня же будет так: создаваемый на холсте блок типа это уже геттер с сеттером внутри себя. Внутри блока мы вписываем (или вставляем блок-)-значение. Сам же блок снаружи себя возвращает хранящееся в нём значение. концепция переменных здесь тоже применима (и есть), но об этом ниже.
9. Блоки стыкуются с операторами справа налево, как сказано в п. 4. Соответственно, у блоков и операторов есть важное графическое качество, которыми они отличаются между типами, но схожи между блоком типа и блоком оператора. У блоков типа уникальная для их типа форма, имеющая вертикальную симметрию. У блоков бинарных операторов вертикальная но инверсная симметрия так, что справа и слева стыкуются без зазоров два однотипных блока. У операторов унарных соответственно симметрия нарушена так, что с одной стороны форма для стыковки с блоком, а с другой стороны форма для стыковки либо со следующим оператором, либо с гнездом во внешнем блоке. Это лучше показать на примере. На пикрелейтеде 1 показано выражение ( 2 + 3 ) * 5 возвращаемое значение типа int. На втором пике изображена ложь, тип bool.
И кстати!
10. Но лучше этот пункт повыше закинуть в концепте: Форма фундаментальных блоков исключительно из прямых линий, без кривых. Для лучшей начертаемости от руки. Производные блоки программист может уже нарисовать какие хочет, но для хорошего стиля кодинга рекомендуется тоже рисовать формы из прямых отрезков.
11. Тернарных операторов в моей концепции нет. Взамен них существует другой механизм. Каждый типовой блок можно объявить как функцию. Блоку выдаётся свой холст, на котором можно задать точку входа, аргументы, и возвращаемый результат. Этот механизм позволит описывать как функции не только тернарные операторы, но вообще, фундаментальные языковые конструкции, типа циклов можно будет описать как сегментом (C-блоком) так и функцией.
Например, на пикче 1 в псевдоскретче некий сегмент, из трёх блоков, первый задаёт список (массив) int, второй задаёт цикл, который этот массив с помощью третьего блока заполняет значениями от 0 до 9. Этот же псевдокод можно изобразить блоком на пикче 2. Тут показан блок с двумя гнёздами-входами и названием. Это функция, которая делает то же самое, создаёт массив с заданными границами и возвращает его.
Аналогично, функцией мы можем описать тернарную операцию, пик 3. Блок возвращает int, о чём говорит его форма, имеет три входа, bool и два int на правду и ложь соответственно.
Аналогично можно описать любую требующуюся конструкцию.
12. Как сказано в п. 8, у блоков есть только гнёзда для вставки. Нет гнёзд так сказать "выпуклых", как в скретче. Соответственно, возникает вопрос, как на предыдущей пикче блок add знает что есть x и что есть i? Ответ в том, что у холста, на котором мы рисуем блоки, будет легенда. В ней мы перечисляем используемые на холсте переменные. Когда будет написан редактор, составление легенды будет автоматизированным. Ты бросаешь на холст блок if, и в легенде генерируется переменная i в формате:
> модификатор_доступа тип имя_блока.имя_переменной [= значение_по_умолчанию]
Поскольку у нас на дворе 21 век, в моей концепции я отталкиваюсь от ООП-парадигмы, а хначит холст - это неймспейс или фрагмент неймспейса, и холст содержит классы. Каждый блок-начало на холсте - это описатель создаваемого в неймспейсе класса, поэтому переменные в легенде принадлежат конкретным классам. И опять же, не переменные это, а члены класса. Но для простоты, по заветам инфоцыган я обесняю "для новичков", хех. Допустим, наш вышенарисованный for расположен в методе CreateList класса MyClass, тогда переменные x, i из пикчи сверху будут созданы в легенде следующим образом:
> private list<int> MyClass.CreateList.x
> local MyClass.CreateList.for1.i = 0
Переменная x как видим объявлена приватной в области видимости класса, а вот переменная i объявлена локальной в области видимости блока for которому автоматически выдано имя for1, имена блоков можно менять для читаемости программы, но следует помнить, что это не имена переменных и язык не будет иметь инструментов чтобы ссылаться на эти имена. А может быть будет. Как пойдёт.
> Ты бросаешь на холст блок for
Ну это прямо надо пофиксить. Сорян, аноны, хуярю текст на энтузиазме, вычитываю диагонально. За ашыпки извените.
На данный момент я пытаюсь вывести различимые и достаточно простые в рисовании блоки типов. Формы должны хотя бы немного отражать суть типа. Хотя, конечно, отталкиваюсь всё равно от скретча. Bool - шестиугольник, или иначе говоря блок с двумя треугольными краями и прямоугольной серединой.
Числовые типы отталкиваются от скретчевого кружочка, но поскольку кружочки запрещены в моём концепте, то целочисленный тип, int - это блок с одним плоским зубцом, далее real, single - в зубце одна дырка, double - в зубце две дырки, decimal - внутри острый зубец, образующий символ сигмы, а если смотреть сбоку, то напоминает букву М - money.
И тут очень органично решился вопрос с приведением типов. На пикче 1 мы берём целое 10 и прибавляем дробное 0.5 с одиночной точностью, используем оператор + целого типа, что неверно, и действительно, мы видим, что в состыковке образовался зазор, значит, что-то мы делаем неправильно. При сложении int и single результатом будет single, значит нам нужно взять сингловый +, но там зазоры будут ещё толще при попытке впихнуть в него int.
Что делать в таком случае? Решение очевидно. Операторы можно и нужно динамически подстраивать под входные типы и каждая получившаяся форма будет символизировать приведение типов. На входе int и single? чтож, мы приводим int к single и возвращаем single. Как показано на пикче 2.
Ну и конечно же, любое выражение можно свернуть в блок, как на пикче здесь >>832952 или вынести на отдельный холст в виде функции, что улучшит читаемость.
Пока что вырисовывается что-то типа такого:
>Так что ничто не мешает существовать языку с одной-единственной допустимой фразой.
Допустим, ты прав. Тогда почему распространено мнение, что животные не обладают способностями к речи? Даже обучение обезьян языку жестов было поставлено под сомнение, хотя обученные обезьяны умели правильно использовать до сотни слов и даже объединять слова в простые осмысленные выражения. У многих животных есть сигнальная система, в которой есть множество сигналов, несущих вполне конкретный смысл, животные могут передавать информацию этими сигналами. Даже у растений, у которых нет нервной системы (но есть гормоны, рецепторы, актуаторы, передача сигналов), есть способы общения между отдельными индивидуумами как одного вида, так и разных, и даже способы взаимодействия с насекомыми-опылителями. По твоим словам, это всё - языки, и почти всё живое владеет каким-либо своим языком, принятым у конкретного вида или в конкретной популяции. Почему тогда мы не воспринимаем это как языки и даже подвергаем сомнению обучаемость обезьян языку жестов?
> почему
> животные не обладают способностями к речи?
У них нет отвечающей за речь нейросети в мозгу.
Можете скринить, вангую, когда учёные наконец изобретут нейроинтерфейсы, они смогут присоединить к обезьянам внешний речевой центр, скопированный у человека - и обезьяны заговорят.
>отвечающей за речь нейросети
>присоединить к обезьянам внешний речевой центр, скопированный у человека
Надеюсь, ты так шутишь.
Речевой центр человека по структуре идентичен остальным зонам новой коры больших полушарий мозга. Его конкретное расположение обусловлено, скорее всего, удобством такого расположения. Для примера, зрительная зона коры находится на затылке только потому, что зрительные нервы огибают мозг и присоединяются к нему сзади. Лобные доли отвечают за высшие функции (долгосрочное планирование и всё такое), потому что они расположены дальше всех остальных от внешних нервов, то есть источников информации. В остальном кора устроена одинаково на всей своей площади и представляет собой универсальную ассоциативную память - чему обучишь, то и будет хранить и использовать. В частности, речевой центр у нас обычно в левом полушарии - правое по умолчанию не способно говорить, но если человеку вырезать левое полушарие, спустя несколько месяцев правое обучится нормальной речи просто от безысходности. Т.е. речевые функции не привязаны к какой-то конкретной нейронке, и эксперименты с виртуальными нейронками и прочими чат-ботами, ящитаю, это доказывают (у них нет высших функций, они слепы и глухи, но сочиняют фразы достойно, на уровне человека).
У обезьян тоже есть новая кора, но она слабее, то есть у неё меньше слоёв - а, значит, меньше ёмкость памяти, меньше глубина связей-ассоциаций. Но главная проблема обезьян не в слабой коре, а в том, что артикуляционный аппарат у них по какой-то причине не связан с корой мозга. Т.е. они тупо не управляют своими криками, их звуки не кора воспроизводит, а какой-то более древний отдел. Но зато с корой у них связаны конечности, поэтому они могут обучиться разным трюкам и в том числе языку жестов - показывать руками осмысленные сигналы.
Собственно, поэтому обезьян и учили языку жестов. И обучение даже давало какие-то результаты. Но эти результаты ставят под сомнение. Сомнение основано на вопросе, как отличить обучение от дрессировки? Откуда нам знать, что обезьяна реально понимает, что она показывает жестами, а не делает это исключительно ради награды, как дрессированная собака? Насколько я понял эту тему, так и не удалось найти научное доказательство, говорят ли обезьяны языком жестов осмысленно или это всего лишь результат дрессировки.
В общем-то, в теории можно было бы соединить их артикуляционный аппарат с корой и научить говорить слова голосом. Да, они бы не смогли выучить много слов и строить слишком сложные предложения из-за низкой ёмкости коры, но они бы говорили. Вот только это снова ничего бы не доказало - откуда нам знать, говорят ли они как люди, или это просто подражание, подобно тому, как некоторые птицы воспроизводят услышанные звуки, или тому, как некоторые программы выводят информационные сообщения, не понимая их содержимого? Т.е. это ничем бы не отличалось от обучения языку жестов, кроме дорогостоящей операции на мозг.
>учёные наконец изобретут нейроинтерфейсы
Нейроинтерфейсы давно существуют. Втыкаешь электроды в мозг и обучаешь человека ими пользоваться, чтобы нейроны перестроились (на это уйдут месяцы). Если воткнёшь достаточно прицельно, то обучаться придётся меньше. А если нужно управлять дистанционно (сделать биодрон), то задача проще, если сможешь воткнуть электрод в подходящую структуру - организм будет воспринимать импульсы с электрода как собственные желания и выполнять их. Только вот никаких универсальных интерфейсов вроде USB не будет, архитектура не та - нужно обучение, никакого тебе plug and play в мозге не предусмотрено. Т.е. разъём на башке сделать можно, но обучаться придётся для каждого девайса независимо, а это минус несколько месяцев жизни. Так что в случае обезьян единственный рациональный способ - протянуть их собственные нервы к коре, авось сама как-нибудь обучится управлять. А все эти сказки про импланты в мозг, не требующие адаптации (вставил и сразу пользуешься), возможны только с каким-то искусственным мозгом, специально разработанным для поддержки plug and play устройств. Биологический мозг, если тебе так понятнее, захардкожен под конкретную задачу.
Но это всё не относится к нашей теме - можно ли считать языком систему, которая допускает всего одно действие? Может, с формальной точки зрения и можно, но с бытовой это не может считаться языком. Иначе нажатие кнопки на выключателе света - это тоже язык с единственной возможной фразой "измени своё состояние на противоположное", так что ли? Тогда все люди поголовно являются программистами, а ещё и куча животных (да и растение может нажать на выключатель, только очень медленно). Давай не доводить до абсурда, а то так можно бесконечно спорить.
То что раньше делал циклами начинаю уметь делать на маппинге списков. Так же в снэпе искаропки имеются блоки для отрезания головы и хвоста у списка, для пришивания головы к списку. Функциональщина!
> Надеюсь, ты так шутишь.
Надейся. Но вангование заскринь. Ну всё, я ушол, у меня там снэп на созвоне. Обнял.
>всё равно никто это не читает
Я прочитал его графоманию. Мне тоже нравится идея изобретения нового языка программирования и я тоже когда-то подумывал сделать свой собственный визуальный язык программирования, но потом забросил эту идею из-за её практической бесполезности (по крайней мере для меня самого, ведь я могу писать на готовых языках, а визуальные мне неудобны из-за связанного с ними дрочения мышки; вот на смартфоне могло бы быть удобно).
>>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кк/наносек кодомакаки на попсовых языках, которых волнует только работа на галеру. Будет ли его велосипед полезен галере? Нет, не будет. Значит, ему не место в /пр/. А здесь он может пилить свой велосипед в контексте какого-нибудь игрового движка, или сделать свой игровой движок на основе своего велосипеда. Мы посмотрим и посмеёмся над его попытками, но не так жестоко, как в /пр/, все ж свои.
> Надеюсь, ты сделаешь его для готового движка типа Godot или хотя бы для компиляции в существующий язык типа C
Именно так и хочу сделать. Транслятор в существующий язык. На большее меня не хватит, увы.
Все советы и претензии принял к сведению. Щас буду думоть.
> Щас буду думоть.
Итак, вот что выдумолось на данный момент. Оказывается в Snap! имеется встроенная функция кодификации. Свою реализацию блочного языка пилить не нужно. Ты прописываешь текст для каждого блока, в том числе для самодельных блоков, и из этого текста генерируется код! Который можно сохранить!
Искаропки там есть проект-образец, выдающий программы на джаваскрипте, питоне, сях. И я такой думаю, опачки! Щас быстро накидаю гдскрипт по образу и подобию питона. Но оказывается, что игровые движки, хоть годот, хоть юнити, хоть уе, хоть гамак, это в первую очередь АПИ, а уже во вторую - язык.
То есть, примитивные конструкции типа фор, иф, объявления переменных, операторы - всё это запиливается легко за полчаса. Но потом в полный рост встаёт необходимость вручную, кропотливо, строка за строкой, переносить в блоки сторонний АПИ. Классы, типы, утилиты, тысячи их! И если эту работу произвести, Snap! будет генерировать файлы кода для твоего движка и ты сможешь делать игоры, собирая их из блоков, как конструктор лего! YAY!
На пикрелейтеде блоки-пустышки, которые в снэпе ничего не делают, единственная их задача - предоставлять текст для генерации кода. Черновой вариант. Во многом не нравится. Особенно объявление энума смотри как сделано. Это же пиздец!
Продолжаю пробовать разные подходы. Щас уже вырисовывается в голове подход при котором я сделаю блоки-репортеры с выпадающим списком методов, по репортеру на каждый класс годота.
В кодификации есть возможность описывать заголовочную функцию для каждого блока. Например здесь блок умножения описан мной как вспомогательная функция product принимающая на входе массив, которым в снэпе блок умножения и является. Эти функции в сишном стиле названы заголовками и при парсинге лезут вперёд. Поэтому не проблема разнести фрагменты кода по разным генераторам, а потом склеить, чтобы extends шёл первой строкой, а потом всё остальное. Так даже визуально лучше, когда разные методы разложены отдельно.
Занимаюсь вопросом.
А потом можно будет сгенерировать XML snap-проекта на основе файлов гдскрипта.
А потооом! Можно будет дописать блоки переключения на язык по образцу таких блоков в сэмпл-проекте и ты прикинь? Можно будет легко переключать готовый код с гдскрипта на сишарп! Не ты прикинь? Можно даже на кресты перекидывать, чтобы потом оптимизировать и скомпилировать. Девелопишь проект на удобном, но медленном гдскрипте, а перед релизом переливаешь всё в кресты, собираешь и получаешь быстрый код на крестах!
>Черновой вариант. Во многом не нравится.
Прикольно. Но всё равно это не лучше подсветки синтаксиса.
>делать игоры, собирая их из блоков, как конструктор лего
Слишком мелкие блоки-то. Вот ноды в дереве сцены и ресурсы в инспекторе - норм. Особенно это заметно по нодам-потомкам Control, у них уже готовое сложное поведение, и неплохой сложный GUI собирается на одних только нодах, без кода, только изменить значения по-умолчанию.
>>833827
>Первый работающий скрипт. Вот прям запускается и работает.
Молодец. А я только планирую, планирую... и ничего не начинаю...
>Учитывая пожелания анона из треда, делаю высокоуровневые блоки.
Во-во, вот это оно, круто.
>>833838
>Можно будет легко переключать готовый код с гдскрипта на сишарп!
https://en.wikipedia.org/wiki/Source-to-source_compiler
> Слишком мелкие блоки-то.
Настраивается в настройках.
Ты не понял, я не про размер кнопки. Я про сложность системы, лежащей за этой кнопкой. Сейчас ты буквально отдельные слова выбираешь и вставляешь. Смысл в этом? Ты бы хотел писать на русском языке, выбирая слова из огромного словаря на десять тысяч слов, вместо того, чтобы печатать на клавиатуре? Что проще - напечатать "и" или листать мышкой список на десять тысяч слов в поисках слова "и"? А если сделать текстовый поиск по списку, ты так и будешь печатать, только не сразу в тексте, а в поиске, чтобы найти слово для текста.
Тысячу раз повторяли уже - визуальное программирование может быть оправдано только если визуальные блоки несут в себе очень сложные системы, которые ты соединяешь между собой высокоуровневыми связями. Как главы в книге перемещать, или, как минимум, абзацы текста. Для низкоуровневого кода визуальное программирование категорически не подходит, низкоуровневый код намного лучше печатать как обычный текст (с автодополнением, которое и в обычном тексте успешно используется).
Эх, жаль, концепт хорош, но не для продакшона.
>наконец запустил свою технодемку, всё люто затормозило и заглючило.
А мог для начала зайти на официальный сайт скретча и поиграть в игрушки от школоты, которых там много. Есть даже клон майнкрафта в 2D, с оригинальными текстурами из майна. Делаем скидку на то, что это всё работает в браузере, но игры на тех же Godot/Unity не так уж сильно теряют производительность в браузере.
Без обид, концептуально скретч довольно неплох.
Тут ещё дело в том ,что я в снэпе пилил. Того функционала, что мне нужен в скретче нет. В скретче, чтобы мои задумки реализовать, придётся еще больше куч из блоков нагородить.
Ясен хуй, это вообще не геймдев, и нерелейтед, но вдруг кому заинтересует.
Во! Нашёл трек крутой для первого уровня своей игры.