Comments 55
А что вы думаете про графическое программирование и технологию RPA в частности?
Как эксперт по технологии RPA отнесётся к мнению, что программисты на текстовых языках программирования выскажут ему своё мнение?
P.S. Можете добавить опрос по выяснению мнений к статье по заданному вопросу.
А что вы думаете про графическое программирование
Думаю, что это очень плохо масштабируется — как на большие объемы кода, так и на совместную работу.
Естественно, писать большие программы, как это делают мастера на C#, Java, C++ итд - не совсем правильное решение. Но сделать вполне конкретную утилиту, которая решает поставленную задачу можно довольно качественно. Тем более, что если речь идет про клиент-серверную архитектуру, здесь не нужно самому изобретать велосипеды и искать разнообразные движки, так как сам сервер UiPath (оркестратор) дает очень многое.
Даже из моего личного опыта: Когда-то давно мы с моей командой вели разработку одного решения для крупного банка. Решение должно было строить очередь из миллионов транзакций и обрабатывать их на десятке нод. Все это разрабатывалось тогда, когда еще никаких RabbitMQ и подобных решений на рынке не было (а если и были - они являлись не сильно известными).
Так вот такое решение мы разрабатывали несколько месяцев (с учетом отладки и доведения до ума). А используя готовые механизмы очереди транзакций из оркестратора UiPath такое решение можно построить меньше чем за один рабочий день. И сегодня такие вещи делают специалисты, которых в "прошлой жизни" я бы не взял даже на позицию джуниора.
Естественно, писать большие программы, как это делают мастера на C#, Java, C++ итд — не совсем правильное решение. Но сделать вполне конкретную утилиту, которая решает поставленную задачу можно довольно качественно.
… сделать в одиночку и не иметь возможности поддерживать сообществом, да. Это тоже немаловажно.
Собственно, об этом и речь: насколько я знаю графическое программирование, разработка на нем — это lock-in, который не позволит развивать программу, достигшую определенного порога. Ее придется куда-то переносить, и эти усилия могут быть сопоставимыми с написанием программы с нуля.
А используя готовые механизмы очереди транзакций из оркестратора UiPath такое решение можно построить меньше чем за один рабочий день.
Это не вопрос визуального программирования. Это вопрос доступных технологий. Используя готовые механизмы из [нужное вписать], сейчас такое можно сделать за то же самое время, что и на UiPath, только потом еще и поддерживать будет проще.
И сегодня такие вещи делают специалисты, которых в "прошлой жизни" я бы не взял даже на позицию джуниора.
Делать "такие вещи" несложно. Сложно их потом развивать и поддерживать.
Удалось объяснить гуманитарию зачем нужны переменные и что такое функция? Или "это другое"? (c)
… а в чем, кстати, проблема объяснить гуманитарию, зачем нужны переменные?
(автор, если что, обучал не гуманитариев, по его же собственному признанию)
Ученики считали себя гуманитариями сами, так как учились в соответствующих учебных заведениях, но по факту имеющихся знаний и навыков их трудно таковыми назвать, поэтому я и делаю такую оговорку в статье
Проблема в понимании концепций переменных и функций и в категорическом нежелании плодить ненужные сущности. В результате код начинает быть похож на художественный текст (если обучался филолог или лингвист). Объяснить области видимости, модульность - это отдельный квест. Если классы/объекты не дай бог начинаются - вообще беда.
Проблема в понимании концепций переменных и функций.
Объяснить области видимости, модульность — это отдельный квест.
А в чем проблема-то?
У меня, кстати, под боком есть некоторое количество вполне себе программистов, которые не понимают области видимости, так что может дело не в "гуманитариях"?
в категорическом нежелании плодить ненужные сущности
… это ж вроде бы хорошо?
В результате код начинает быть похож на художественный текст (если обучался филолог или лингвист).
… вы никогда не слышали про Literate programming?
Я вот в среднем считаю, что если код можно читать как прозаический (это, кстати, важно, не художественный, а прозаический) текст — это его достоинство, а не недостаток.
С учетом того, что они могут объяснить каждое действие, которое применяют, а сам код роботов разбивают на части (отдельные файлы) с собственными входными и выходными аргументами (считай параметры и возвращаемое значение) - считаю, что удалось
Перефразирую известный анекдот:
Разговаривают два математика: - Я не понимаю, что такое функция. - Да не проблема, сейчас я тебе объясню. - Нет же, объяснить то я и сам могу, а вот понять...
Начали за здравие, закончили за упокой.
Программированию то удалось обучить?
Потому что пока выглядит как реклама визуальных сред.
Возможно, вы где-то в середине решили просто пролистать статью, но в блоке с примерами простых программ на UiPath я написал, что простота визуального программирования побудила в учениках интерес разбираться глубже. И уже благодаря ему в этой же самой среде они начали писать программный код, благо она позволяет это делать. Сначала 1-2 строчки, потом больше-больше, постепенно заменяя визуальные готовые блоки на свой код.
Визуальная среда здесь - не конечная точка "путешествия", а скорее как мостик между визуальным осознанием алгоритмов и сложным программированием. Если бы я, как и другие, пытался бы их научить сразу писать код - с высокой долей вероятности ничего не получилось бы. А здесь у меня все получилось и я делюсь опытом "Как еще можно учить людей". И это не фантазия, а подтвержденный мною факт.
Абсолютно верно. Цитирую (ссылку давать не буду, легко ищется):
ЧТО ТАКОЕ UIPATH?
При взаимодействии с другими пользовательскими приложениями платформа UiPath имитирует действия человека, и в этом ее состоит ее основное различие с иными программами, работающими по API или через интеграционную шину (Middleware).
Это позволяет применять UiPath в создании роботов, предназначенных для:
Дальше идет перечисление того, что он может автоматизировать в существующих программах типа Экселя и прочих, но я не нашел ничего о том, что эта штука может создать что-то новое с нуля.
Демо-версия только для залогиненных, как и цены. В топку такие проекты.
и единственное, что их объединяло – катастрофическая нелюбовь к техническим наукам (на самом деле и гуманитарии из них были так себе).
Программисты которых мы заслужили. (Знать бы ещё за какие именно грехи...)
Зачем так сложно? начали бы со скретча, раз уж в визуальное программирование пошли.
Смысл был не в том, чтобы научить визуальному программированию, а в том, чтобы пробудив более глубокий интерес научить делать правильно. Если бы я начал со скретча - я бы не смог прямо там же показать им как программировать классическим способом. Я не просто так в плюсах UiPath указал возможность полноценно программировать - именно этот мостик и сработал. Сначала ученики научились делать программы не написав ни строчки кода, а потом уже заменяли готовые визуальые блоки на свой код. Не все сразу, постепенно. И это заработало.
Сам применяю визуальное программирование для мелкой автоматизации (я инженер-проектировщик). Про минусы уже все написали, напишу про плюсы:
Как правило, уже всё есть для ввода/вывода "из коробки". Не надо писать для этого какие-то классы и т.д.
Я работаю с 3д моделями и удобно видеть на каждом шаге куда и что преобразуется. Не надо сочинять простыни кода, чтобы что-то вывести на экран.
Так что для скриптов отличная тема
No Code - это негибко. Зачастую, проще написать какую-нибудь библиотеку, покрыть её тестами. а потом реализовывать бизнес требования в пару строк кода. Бизнес пользователи генерирующие бизнес правила, должны четко ставить задачу. А программист быстро превращать это в код.
А ещё можно обучить непрограммистов формату json (некоторым конструкциям js, markdown в зависимости от задачи) и писать конфиги на нем. Можно даже написать инструмент который визуализирует эту json-конфигурацию (проще чем писать визуальный редактор). Главное, что бы ядром был исходный текст.
И вот когда все работают с исходным текстом, то нахаляву получается много возможностей: контроль версий и аудит (git), возможность совместной работы (любые совместные редукторы кода или библиотеки для организации этой работы, проще чем писать с нуля для своей UI-тулы).
Я скажу, что идея интересная. Про подход в обучении.
Не всегда понятно, где и как применять то, что ты изучаешь или тебе показывают на уроках.
Стандартное обучение выглядит так, вам наваливают кучу кирпичей и варианты их укладки. А после вам говорят - бери вот эту кучу кирпичей и строй дом.....
Более логичным выглядит подход, мы хотим построить дом... для этого нам нужно фундамент, стены и т.д. Для укладки стен лучше вот так, для переходов вот так и т.д.
Для старта очень даже хороший подход, хотелось бы узнать как после обучения у этих ребят складывается карьера?
О том, как складывается карьера - написано в начале и под конец. Один из них после плотного изучения визуального программирования смог освоить классическую разработку на C# и устроился джуниором в одну из IT-компаний. Двое других пока не выросли дальше визуального программирования, но тем не менее создают свои программки уже и без моей помощи, что я считаю очень хорошим прогрессом (тут даже скорее важно то, что они сами делают это с удовольствием и благодарят меня за то, что сдвинул их с мертвой точки).
Но вообще в целом, что касается карьеры - я себе не ставлю никогда цели "Устроить своего ученика в гугл-яндекс", а цель скорее - развить и дать более глубокое понимание, развить интерес к открытию новых границ. А как человек воспользуется этим для продвижения по карьере это уже его дело.
Ну кубики, пирамидки по цветам и отверстиям раскладывать, так же как и яблоки с апельсинами можно и обезъяну научить. А вот Мичуриным она не станет никогда.
Зачем это? Где пригодится? Как они будут всю жизнь работать без команды?
Что тут думать... А то, что среды графической разработки (графические языки программирования) пользуются своей нишевостью и от туда не вылезают уже очень давно
Вот статья на хабр https://habr.com/ru/company/edison/blog/432334/ (Визуальное программирование — почему это плохая идея)
По мне, это только первый этап в обучении программированию, не стоит делать большую ставку (но у вас там целый отдел), как самостоятельная практика написания возможна, но она упрется в фундаметальные ограничения
В первую очередь графический язык - некоторые штуки в нем тяжело выразить, например понятия:
рекурсия
лямбда / функтор (функциональный объект)
рефлексия и метапрограммирование
.... много оных
Вторая очередь: инструменты, есть ли в инструментах например intellisense, git, ...
Под капотом у выбранного инструмента (UiPath) - платформа .NET (при чем как старый .NET Framework 4.6.2, так и современный .NET по выбору) с возможностью писать выражения и блоки кода на языках VB NET и C#. Например, если вам нужно отправить письмо и составить его из разных блоков текста в зависимости от множества условий - вам не обязательно надо использовать только визуальное программирование, вы можете написать элегантный код. Преимущество именно в возможности выбора подхода. Что касается вопрсов:
Рекурсия - Есть, работает. Как в графическом варианте (вызывая другой/этот же файл с графическим кодом), так и в виде написания подфункций в блоке на языке из перечисленных выше
Лямбда-выражения - Используются большинством разработчиков для фильтрации, сортировки списков, таблиц
IntelliSence - присутствует при написании выражений и блоков кода на VB NET, C#
GIT (а так же TFS, SVN) - имеется встроенная интеграция с ними, в том числе с популярными GitHub, и GitLab.
... много оных - надо понимать о чем именно речь, но благодаря возможности использования VB NET и C# - скорее всего есть.
Мне кажется, для выполнения плана вам нужно еще несколько раз упомянуть UiPath. Могу вам помочь: UiPath, UiPath, UiPath
Я понимаю что вы на Net все написали, это конечно хорошо, еще бы Java/Rust/etc..., но дело же не в этом
Вы пишете:
Рекурсия - Есть, работает. Как в графическом варианте (вызывая другой/этот же файл с графическим кодом), так и в виде написания подфункций в блоке на языке из перечисленных выше
Мне интересно как именно графически будет выглядеть кусок кода ниже:
Вот смотрите, есть допустим у меня такой кусок кода:
Number fact( Number x ) {
if( x>1 )return x*fact(x-1);
return x;
}Данная функция вызвает сама себя, а как в вашем случае в графической нотации вызывает функция сама себя ?
Как вы определяете графически функцию ? есть ли у вас для аргментов функции какие-то графические блоки, для каждого аргумента функции как определить тип данных ?
Простые конструкции языка графически представить не сложно
цикл - две дуги, одна дуга ведущая к началу итерации, другая к выходу из цикла
ветвление (if) - пара дуг, одна в случае истенности условния, другая в случае ложности
При большом желании можно определить графически функцию исключительно, но вот куда засунуть рекурсивный вызов функции графически, так чтоб стрелочкой... вот это уже интереснее, а текстом я и сам знаю
У вас явно устаревшее представление о том "что такое графическое программирование". Принял ваш вызов и сделал в двух вариантах:
Последовательность
Блок-схема
Возможно и устарели представления, но в целом я ожидал этот ответ, что рекурсивной стрелки/дуги нет.
Хотя если бы язык был развитый, тогда из синего прямоугольника (invoke) могла быть дуга к пункту старт - это было бы значительно наглядней.
Из примеров я могу судить что у вас xaml файл = функция - так ?
А из-за того что у вас используются названия файлов при вызове - возникнет (я так предполагаю) очивидные мелкие проблемы - переименование файла может к чертям сломать функцию, которая вызывает код. Была бы рекурсивная стрелка - ничего бы не сломалось.
Как вы боритесь с согласованностью визуального кода и вызывемых функций ? т.е. что будет если файлы переименовать, когда узнаем о проблеме - в compile time или run time ?
Да, файл=функция.
Нет, при переименовании переменных, аргументов (входные - параметры функции, выходные - возвращаемое значение) и самих файлов ничего не летит, среда разработки сама все переименовывает везде (прямо как Visual Studio и IntelliJ IDEA, если пользоваться встроеннвм функционалом переименования).
Но если вы решите открыть исходный код в текстовом редакторе и поменять что-то ручками - конечно, поломается. Обо всех проблемах вы узнаете на этапе проектирования. Встроенный статический анализатор кода не даст просто запустить даже отладку. К слову, этот анализатор можно накрутить дополнительными условиями, которые будут запрещать запуск если ваши разработчики начнут именовать переменные от балды, отойдя от принятого в компании код-стайла.
В целом вы пишете очень разумные и правильные замечания, но все это (по крайней мере в этой платформе) уже несколько лет как "по-умолчанию" решено.
Собственно и изучаю, что может ваша платформа, чем она может быть полезна (и в ваших же интересах расказать о ней)
Например меня интересует на сколько силен ваш статический анализатор по сравнению с Rust
Переименование это только первая очивидная проблема
Я могу предположить, что у вас на платформе генерируется код, тот же C# и потом делается попытка его скомпилировать
Если так, тогда как пользователь платформы узнает о
опечатках в коде
не правильном использовании типов данных, например: "Иванов" + 5 сентября
Из менее очивидных проблем графического программирования:
как быть если хотим ООП (свои структуры данных + методы структур данных) - тут я ожидаю, что визуального языка нет, все придется описывать руками и текстом
как быть с много поточкой и блокировками
как быть с иммутабельностью
как быть с транзакциями, вложенными транзакциями
Как быть с унаследованным кодом, можно ли трансформировать исходный код на C# в диаграммы ?
Я не являюсь экспертом по Rust, поэтому не готов комментировать сравнение с ним.
Что касается вопрсов опечаток в коде и правильного использования типов данных - за это отвечают возможности анализаторов и компиляторов языков VB NET и C#, точно такие же, как используемые в Visual Studio от Microsoft.
ООП именно в виде графической разработки - никак. Но если очень хочется, и ведется командная разработка - то как правило старшие специалисты пишут нужные классы в виде классической dll-библиотеки, упаковывают ее в NuGet-пакет, публикуют в локальном NuGet-репозитории и дальше он используется в любых проектах, где нужно использовать собственные классы, структуры. С другой стороны - чаще всего разработчики на UiPath используют json-структуры для хранения и обмена информацией, что позволяет вообще не морочится с созданием собственных классов (в классическом понимании).
По поводу многопоточности - имеется вариант запуска других программ (процессов) на других машинах с ожиданием выполнения. Самый лучший способ - использовать встроенные в платформу очереди транзакций, которые гарантируют получение уникальной транзакции каждой отдельной машиной (то есть очередь из миллиона транзакций будет разбираться 2-3-4 итд машинами и нигде не будет путанницы).
С другой стороны - опускание в такие глубокие детали вызывает уже и встречный вопрос - а зачем все это нужно при решении несложных утилитарных задач? Усложнение не всегда действительно нужно. А часть вещей, которые вам хочется писать самому - уже есть в платформе, и их просто нужно научиться использовать. А чтобы научиться - есть бесплатная академия, где рассказано про все аспекты платформы: https://academy.uipath.com
С другой стороны - опускание в такие глубокие детали вызывает уже и встречный вопрос - а зачем все это нужно при решении несложных утилитарных задач?
Ну потому что это показывает предел графического программирования, дело не в сложности, а в возможностях языка
Перечисленные выше вопросы - это все о примитивах языка
Я могу задать сходный вопрос - а зачем нам графический язык, когда есть BrainFuck или ASM - это вопрос к тому что любой язык программирования может быть сведен к более простому языку (по Тюрингу)
Но мы как-то не используем простые языки (ASM, C), а используем именно выразительные языки (Scala/C#/Haskel/TypeScript/...)
По мне из известных графических языков, многие из них страдают одними и теме же проблемами:
Не выразительны в сложных абстракциях - это не доработка дизайнера языка
Все ориентированы на кликанье мыши - а это заведомый тупик и проигрышь по сравнению с клавиатурой, стилус почему то не используют
Большинство работают как с листом бумаги и схемами на ней, а должно быть более сложное пространство, например бесконечное увеличение частей схемы
У большинства нет возможности создавать свои графические обозначения, свой графический язык - а это нарушает сами принципы языков
Я могу задать сходный вопрос - а зачем нам графический язык, когда есть BrainFuck или ASM
Предлагаю вам снова перечитать статью и перепогрузится в проблематику.
Там есть пример программы, которая считывает excel-файл и отправляет письма всем людям из таблицы в файле. Она занимает всего три действия: "Прочитать файл", цикл "Для каждой строчки", и "Отправить письмо".
Когда людям нужно делать такие простые программы - они могут сделать их меньше, чем за 10 минут (для этой статьи я, как опытный разработчик, сделал эту программу за 2 минуты, но я делаю "скидку" для новичков).
А сколько они потратят времени, если будут пользоваться ASM? Хорошо, я понимаю, что вы утрировали, но давайте скажите мне сколько вы потратите времени, чтобы с нуля написать такую программу на RUST, только без использования Интернета (гугла).
Я хочу донести до вас мысль, что не нужно ножиком забивать гвозди. У каждого инструмента есть своя сфера применения, и никто не говорит, что "Давайте выбросим классическое программирование и будем рисовать". Я лишь говорю в этой статье, что можно начинать свой путь именно так, а дальше уже развиваться.
PS: Я совершенно не понимаю о чем вы говорите словами "все ориентированны на кликание мыши". Последний раз, когда я программировал без мышки - был первый курс университета, на котором мы писали под DOS на Borland C++ 3.1. Все остальное время во всех более современных средах разработки так или иначе можно (и даже нужно) применять мышку. Вы большой молодец, что выучили все сочетания клавиш и справляетесь со своей работой, выбросив мышку - но большинство современных разработчиков все же использует мышку, чтобы открывать файлы, вызывать контекстное меню, "рисовать" пользовательские интерфейсы итд.
Предлагаю вам снова перечитать статью и перепогрузится в проблематику.
Так у вас проблематика "научить программировать" или "научить делать простые программы"?
По вашей статье очень мало что можно вынести
"Как я учил гуманитариев программировать и что из этого вышло"
Что вышло - вопрос открытый (https://habr.com/ru/post/599329/#comment_23903797 - Удалось объяснить гуманитарию зачем нужны переменные и что такое функция? Или "это другое"? (c)
https://habr.com/ru/post/599329/#comment_23904673 - Начали за здравие, закончили за упокой. Программированию то удалось обучить? Потому что пока выглядит как реклама визуальных сред.
), и какую именно роль сыграло в этом визуальное прграммирование, очень большой вопрос
А сколько они потратят времени, если будут пользоваться ASM? Хорошо, я понимаю, что вы утрировали, но давайте скажите мне сколько вы потратите времени, чтобы с нуля написать такую программу на RUST, только без использования Интернета (гугла).
И опять видать фраза про выразительные языки как-то мимо вас прошла
Я хочу донести до вас мысль, что не нужно ножиком забивать гвозди. У каждого инструмента есть своя сфера применения, и никто не говорит, что "Давайте выбросим классическое программирование и будем рисовать". Я лишь говорю в этой статье, что можно начинать свой путь именно так, а дальше уже развиваться.
блин... кто ж спорит, а можно и по другому начать программирование и тем же гумманитарием
Я совершенно не понимаю о чем вы говорите словами "все ориентированны на кликание мыши"
я говорю о графическом вводе, когда рисуется диаграмма вы графически вводите объекты, перетаскиваете мышью на холст
потом дополняете объекты текстом - клавиатурой
когда обычное программирование это в первую очередь работа с текстом большого объема
но большинство современных разработчиков все же использует мышку, чтобы открывать файлы, вызывать контекстное меню, "рисовать" пользовательские интерфейсы итд.
ну вот именно, только с оговоркой, разработчик вообще к графическим интерфейсам из за отсуствия дизайнеров занимается этой штукой
ну а мушью я пользуюсь, в основном чтоб скорилить текст, да и то..., а большую часть действий я совершаю клавиаутрой
А что вы думаете про графическое программирование и технологию RPA в частности?
Кто вас за язык тянул ?
В целом по поводу графических языков программирования - есть простой критерий их (не)состоятельности:
Вот когда на графическом языке программирования можно будет создать еще один графический язык программирования - тогда будет о чем по говорить
Вот когда на графическом языке программирования можно будет создать еще один графический язык программирования — тогда будет о чем по говорить
А, почему, к примеру, это сложно сделать на HiAsm?
В пpимерах врoде даже есть сделанный и 3D просмотрщик HiAsm схем.
Конечно для генерации кода придётся использовать или штатный генератор или сделать свой по имеющимся в данной среде возможностям.
Если кратко... То это сложно
Во первых нужно определиться с типами данных языка и операциями над ними, в самом простом случае мы можем свести что у нас будут только биты или на крайний случай числа в языке, но и вот что будет в графическом языке.? Допустим тоже... Ок
Потом нужно определиться с операциями над ними, с битами там понятно and, or,... с числами тоже
Потом работу с памятью придумать надо (read /write variables)
А далее порядок исполнения (if, while, call)
Если мы вводим вызов функции (call) то нужно определить синтаксис для определения функции, рекурсию и стек вызова
С типами данных, если их больше одного, то сразу тяжелее... Проверка на совместимость, ковариантности и прочего...
И вот.. Тут начинается зоопарк, надо написать парсер, который умеет из плоских данных (исходного текста, а данном случае из картинок/диаграмм) создать абстрактное синтаксическое дерево
А это парсер написать уже не тривиальным программа по размеру, даже если очень пытаться
Есть два варианта уменьшать грамматику языка, чтобы уменьшить объем парсера
За счёт упрощения языка
За счёт усложнения статического анализа и сложной модели типизации
В любом случае необходимо в языке (на котором ведётся разработка) иметь возможность выражать средствами самого языка графовые, неоднородные структуры
А многие графические языки, включая hiasm этого не умеют (могу заблуждаться) hiasm может использовать другие языки, но сам он не умеет в сложные типы данных
Под сложными типами я понимаю наличие параметриеских типов данных, типизированных кортежей + pattern matching, лямбд/замыканий
По мне, многие графические языки останавливаются на уровне простого процедурного программирования
Это возможно, но сложно... объяснение почему https://habr.com/ru/post/599329/comments/#comment_23910815
P.S. Как пример одного такого целевого языка flprog.ru
Ну глупо было бы говорить, что это не возможно.
О понятиях, не уже ли вы хотите сказать что в графических языках отсуствуют понятия как цикл, переменная, ветвление ?
Я например не считаю что это понятия относятся текстовым языкам или графическим языкам, они вне этих языков...
Такая же история и со сложными структурами данных
А текстовый или графическияй язык программирования - это лишь способ представить программу
А вот на сколько это удобный способ удобен и выразителен, это отдельный разговор
Как такая трансформация возможна в графических языках, не понятнo как возможнo, если возможнo в принципе.
Да в принципе возможна, есть два видео, где показаны не стандартные модели визуальных языков
1) https://youtu.be/mdYfFDJCDHc
2) https://youtu.be/Ps3mBPcjySE
Но и не стоит отбрасывать пару фактов
Тот язык который, на основе блоков (if/while/...) - это по сути не визуальные языки, а тот же текст, сомнительно представленный.
Языки на основе потока данных более интересны, хотя они более нишевые (3D движки, например blender3D)
Со сложной семанитокой стоит вспомнить, что первые языки (вроде FORTRAN) не имели рекурсии в фнукциях, а потом они появились, что мешает завести это дело в графические языки... (думаю ничего не мешает)
Здесь же момент в синтаксисе, в буквенном кодировани понятий, в графическом языке то же большой потенциал кодирования.
Обычные блочные графические языки, они скудны по выразительнсоти, по факту редко используют цвет или толщину линии, или ... о боже падующую тень / визуальные образы
Хотя наш мозг визуально очень быстро работает, и работает точно не только с 2D представлением информации, но представление о визуальной стороне, визуальном языке ... в графических представлении оставляет желать лучшего.
Прекрасная, кстати, иллюстрация к вопросу "что я думаю про графическое программирование". Вот был исходный текст программы:
Number fact( Number x ) {
if( x>1 )return x*fact(x-1);
return x;
}(а на самом деле — и того меньше: let fact x = x > 1 ? x*fact(x-1) : x)
А чтобы его представить, вам понадобился экран картинок, и, что хуже всего, на этом экране не видно, какие же параметры передаются в следующий шаг рекурсии — то есть, самое важное (иначе нельзя сходимость оценить).
Вот за это и не любим.
А может, и не надо гуманитариев тащить а программирование?
еще есть codecombat.com где вы пишете игру, но не всамделешнюю, а просто, чтоб было понятно как оно вцелом работает. Я показал его брату геймеру, который ну никак не может в программирование (но усердно бьется, периодически, который год). Так он меньше чем за полчаса игры понял и циклы, и условия, и переменные, и, кажись, функции (если они там были), - то есть почти все, а вот на словах и примерах вообще никак не понимал (к тому же и я не ахти какой учитель).
Проблема только в том, что для программирования не достаточно знать циклы и переменные, как заметил автор, сначала нужно выработать мотивацию и понимание что с этим делать и куда двигаться дальше, а простой инструмент, имхо, может только снизить порог вхождения. Это очень важно, но не достаточно, чтоб "сделать программиста". Главным, все равно, остаётся личная мотивация и много практики.
А тема с unreal engine кажется особенно интересной еще и тем, что уже что-то предлагает для мотивации (этож настоящая игра!). Пойду гуглить о ней.
Отличный пример, к слову он не единственный. У Apple есть что-то похожее для обучения Swift. И для ряда своих учеников я применяю в том числе и эти инструменты.
Однако, с этими тремя учениками возникла проблема именно с освоением такого текстового формата. Наверное, если бы я, как типовой учитель, посидел бы с ними много занятий - смог вдолбить им это. Но благодаря использованному инструменту у меня получилось сделать именно для них обучение более быстрым и интересным.
чуток напутал. Когда писал коммент был уверен, что codecombat это визуальное программирование, давно его использовал. А так, сегодня много игр для андроид с использованием визуального программирования есть еще в плей маркете. В комментариях все довольны, и не скажешь, что это отзывы об игре где надо программировать.
Хороший успех зависит от хорошего преподавателя || хорошей мотивации ученика.
Вместо бубнения чего-то под нос и конспектирования, тут проявляется смекалка, и дела идут нормально, а не "по совковому"
Как я учил гуманитариев программировать и что из этого вышло