Привет, Хабр! Сегодня я тебе расскажу историю о том, как я взял на себя ответственность за обучение программированию трех разных человек, которые казались абсолютно безнадежными и никто (даже их самые близкие родственники) в них не верил. Важно то, что каждый из них уже проявлял интерес к программированию раньше, но ни один из доступных методов обучения не давал результата. Сегодня эти люди свободно делают программы без моей помощи (работают над «проектами мечты»), а один из них даже устроился в хорошую IT-компанию.
В чем заключались проблемы каждого из учеников, как я их преодолевал и что они теперь из себя представляют – рассказываю в этой статье.
Как я пришел к надобности учить гуманитариев программированию
Я не могу себя назвать супер-программистом, явно не дотягиваю до великих мастеров, но за свои 12+ лет карьеры прошел через многое. Когда я работал в одной из Российских IT-компаний, мне доверили проводить тренинги для заказчиков, благодаря чему я почувствовал в себе интерес к обучению других людей, что продолжил делать на своих следующих местах работы.
Довольно быстро я загорелся наставничеством и начал обучать программированию знакомых молодых ребят. Самым важным правилом для меня было: брать «под крыло» только тех, кто уже хоть что-то умеет и проявляет реальный интерес к разработке, а не тех, которые кричат «Крута, пограмисты много зарабатывают, хочу так же».
«Если хочешь рассмешить Бога, расскажи ему о своих планах»: 2020 внес много корректировок в планы каждого. Онлайн школы начали появляться с такой скоростью, что очень быстро количество моих падаванов сократилось. А так как я уже не мог представить свою жизнь без наставничества, мне пришлось начать соглашаться учить тех, кто ничего не умеет и хочет «только срубить бабла и быстрее переехать за бугор». Примечательно, что «первая тройка игроков» появилась в моей жизни почти одновременно, тем самым сделав мне вызов.
Статус-кво на начало обучения
Каждый из моих учеников имел свой бэкграунд, и единственное, что их объединяло – катастрофическая нелюбовь к техническим наукам (на самом деле и гуманитарии из них были так себе). При этом все они пришли ко мне не сразу, а попробовав начать свою карьеру в IT другими способами.
Я дорожу своими учениками и не хочу, чтобы кто-то из их знакомых понял о ком идет речь, поэтому назову их так, чтобы никто не догадался
Рамсес знал, что в Интернете есть всё, он даже смог найти несколько видеокурсов по программированию (на ютубе), нашел всякие полезные справочники, установил себе несколько IDE и принялся изучать программирование именно таким образом. Стоит похвалить Рамсеса – ведь среди всех моих учеников из этой статьи он продвинулся дальше всех в плане умения писать код, однако, не мог объяснить что и зачем он пишет (по сути просто отлично писал по памяти то, что уже видел).
Гильгамеш хорошо общался со школьным учителем Информатики, который был опытным программистом, отработавшим несколько лет в крупных компаниях. Заработав первые деньги работая барменом-официантом, Гильгамеш отдал их учителю для того, чтобы тот посидел с ним и «погонял» по программированию. Как оказалось, если человек мастер в программировании и умеет читать школьный материал – он далеко не всегда умеет действительно научить программировать.
Ахилл не имел навыков поиска в Интернете, да и в школе у него учитель был откровенно слаб, зато он видел классные рекламные ролики и читал красивейшие сайты одной популярной онлайн-школы, которая обещала за полгода сделать из него джуниора и устроить на работу. У Ахилла богатые родители, поэтому инвестировать пару сотен тысяч рублей в обучение сыночка для них не было проблемой… Вот только после прохождения обучения, как оказалось, Ахилл не мог даже объяснить мне «А что такое переменная?»
Как я нашел подход к каждому ученику
Дело в том, что почти все технические специалисты привыкли строить повествование по схеме «Что (О чем я говорю) -> Как (применять то, о чем я говорю) -> Зачем (вообще это нужно)». Но как оказалось - это не очень правильный подход, и гораздо продуктивнее идти от обратного: сначала ищем «Зачем» это ученику, после чего объясняем «Как» мы будем это делать и уже только потом начинаем «что-то» делать.
Если вам интересна эта тема - можете погуглить «Why How What»
Казалось бы, что может быть проще, чем определить «Зачем»… Однако, на практике это не быстрый процесс, требующий нескольких сессий совместного общения, а также времени на переваривание и осмысление собственных желаний учениками. С каждым падаваном нам потребовалось разное время на выявление своего «Зачем», но в итоге мы определились кому что интересно разрабатывать и придумали индивидуальные проекты, соответствующие желаниям. Дальше встал вопрос «Как» - и здесь мы встретились с камнем преткновения в виде языков программирования.
Визуальная несостоятельность языков программирования и визуальное решение проблемы
Мои ученики отлично всё схватывали в визуальном формате, то есть понимали схематичное представление (блок-схемы), но вот понять и принять текстовый вариант написания кода им было очень сложно.
И тут мне пришла в голову мысль: «А почему бы нам не попробовать визуальное программирование?».
После детально проведенного анализа мой взгляд упал на RPA-платформу UiPath, которая мне показалась интересной по следующим причинам:
Можно визуально программировать в виде последовательности действий
Можно визуально программировать в виде блок-схем
Есть машины состояний (ВАУ!), которые так же настраиваются визуально
Есть переменные с типами данных из .NET, что позволяет научить работе с разными типами данных
Можно использовать готовые блоки с действиями, которые позволяют не писать много строчек кода для выполнения понятного действия
Можно писать выражения с использованием операций, методов, функций, классов на языках программирования VB.NET и C#
Можно писать целые блоки кода на языках программирования VB.NET и C#
Можно использовать любые NuGet-пакеты и создавать свои собственные точно так же, как и в Visual Studio
Можно использовать готовые блоки действий для взаимодействия с различными веб-сервисами, которые можно настраивать даже без знания основ программирования (а при желании никто не мешает написать собственный блок кода взаимодействия с веб-сервисами на VB.NET или C#)
Есть серверные компоненты, благодаря которым можно научиться разрабатывать клиент-серверные приложения, обрабатывать большие очереди заданий и понимать тонкости работы с сетью
Как выбор повлиял на процесс обучения
Скорость обучения визуальному программированию с поверхностным изучением типов данных меня поразила – уже после первого занятия мои ученики сделали простенькие программы и могли объяснить в них каждое действие.
Еще через пару занятий они делали уже более сложные программы, разбивали код на разные файлы (благо платформа это позволяет), комбинировали блок-схемы с последовательностями, и могли «защитить» свое решение обосновав почему они сделали так, а не иначе. Само собой, в их программах были огрехи, это были очень слабые работы, подверженные различным ошибкам (о которых ученики еще не знали), но важно понимать, что они получили результат «здесь и сейчас», а это дало им мотивацию двигаться дальше.
После того, как я обращал внимание падаванов на неполноценность их разработок, они загорелись желанием улучшать их: разбираться в типах данных глубже, сокращать количество действий, обрабатывать ошибки, писать программный код самостоятельно вместо использования готовых блоков. Честно признаться - по началу я и сам не ожидал такого результата, но это не погрешность и не исключение, а реальный факт для всех трех учеников.
Какие перспективы у визуального программирования?
RPA-платформы только набирают обороты, а уже на сегодняшний день в России UiPath используется в более чем 150 ведущих компаний (это не считая почти 10 тысяч компаний по всему миру). На сайтах по поиску работы можно обнаружить, что количество вакансий с требованием знания именно этой платформы постоянно увеличивается, а это означает, что всё больше молодых специалистов, начавших путь именно с UiPath, могут войти в дело довольно легко. Кроме того, один из моих учеников благодаря освоению визуального программирования смог самостоятельно освоить и «классическое» программирование на языке C#, после чего устроился джуниором в одну из небольших IT-компаний.
Отдельно важно отметить то, что согласно публикациям Кто такие citizen developers, Роботы для каждого (ГазПромБанк) крупные организации используют именно UiPath для обучения своих специалистов из не-IT подразделений для разработки собственных роботов-помощников, а это означает, что навыки, которым я научил своих учеников, им точно пригодятся, даже если они не пойдут именно в программисты.
И тут можно было бы завершить мысли о будущем визуального программирования ограничившись корпоративным сектором, но лично мне очень интересно было узнать от одного из учеников о том, что оказывается в современном игровом движке Unreal Engine тоже присутствует возможность визуального программирования. Честно признаюсь – я не работал с этим движком, но судя по тому, что я увидел в разных статьях и видеороликах, это очень похоже на RPA.
А что вы думаете про графическое программирование и технологию RPA в частности?
Комментарии (51)
lair
04.01.2022 21:13+15А что вы думаете про графическое программирование
Думаю, что это очень плохо масштабируется — как на большие объемы кода, так и на совместную работу.
Drazd Автор
04.01.2022 21:49-1Естественно, писать большие программы, как это делают мастера на C#, Java, C++ итд - не совсем правильное решение. Но сделать вполне конкретную утилиту, которая решает поставленную задачу можно довольно качественно. Тем более, что если речь идет про клиент-серверную архитектуру, здесь не нужно самому изобретать велосипеды и искать разнообразные движки, так как сам сервер UiPath (оркестратор) дает очень многое.
Даже из моего личного опыта: Когда-то давно мы с моей командой вели разработку одного решения для крупного банка. Решение должно было строить очередь из миллионов транзакций и обрабатывать их на десятке нод. Все это разрабатывалось тогда, когда еще никаких RabbitMQ и подобных решений на рынке не было (а если и были - они являлись не сильно известными).
Так вот такое решение мы разрабатывали несколько месяцев (с учетом отладки и доведения до ума). А используя готовые механизмы очереди транзакций из оркестратора UiPath такое решение можно построить меньше чем за один рабочий день. И сегодня такие вещи делают специалисты, которых в "прошлой жизни" я бы не взял даже на позицию джуниора.
lair
04.01.2022 21:53+5Естественно, писать большие программы, как это делают мастера на C#, Java, C++ итд — не совсем правильное решение. Но сделать вполне конкретную утилиту, которая решает поставленную задачу можно довольно качественно.
… сделать в одиночку и не иметь возможности поддерживать сообществом, да. Это тоже немаловажно.
Собственно, об этом и речь: насколько я знаю графическое программирование, разработка на нем — это lock-in, который не позволит развивать программу, достигшую определенного порога. Ее придется куда-то переносить, и эти усилия могут быть сопоставимыми с написанием программы с нуля.
А используя готовые механизмы очереди транзакций из оркестратора UiPath такое решение можно построить меньше чем за один рабочий день.
Это не вопрос визуального программирования. Это вопрос доступных технологий. Используя готовые механизмы из [нужное вписать], сейчас такое можно сделать за то же самое время, что и на UiPath, только потом еще и поддерживать будет проще.
И сегодня такие вещи делают специалисты, которых в "прошлой жизни" я бы не взял даже на позицию джуниора.
Делать "такие вещи" несложно. Сложно их потом развивать и поддерживать.
mst_72
04.01.2022 21:15+3Удалось объяснить гуманитарию зачем нужны переменные и что такое функция? Или "это другое"? (c)
lair
04.01.2022 21:23+1… а в чем, кстати, проблема объяснить гуманитарию, зачем нужны переменные?
(автор, если что, обучал не гуманитариев, по его же собственному признанию)
Drazd Автор
04.01.2022 21:49Ученики считали себя гуманитариями сами, так как учились в соответствующих учебных заведениях, но по факту имеющихся знаний и навыков их трудно таковыми назвать, поэтому я и делаю такую оговорку в статье
lair
04.01.2022 21:54+3А, считать-то себя можно кем угодно. Можно и программистом себя называть ("я же курсы закончил, да?"), только это же ничего не значит без реальных навыков и знаний.
mst_72
04.01.2022 21:57+1Проблема в понимании концепций переменных и функций и в категорическом нежелании плодить ненужные сущности. В результате код начинает быть похож на художественный текст (если обучался филолог или лингвист). Объяснить области видимости, модульность - это отдельный квест. Если классы/объекты не дай бог начинаются - вообще беда.
lair
04.01.2022 22:01+3Проблема в понимании концепций переменных и функций.
Объяснить области видимости, модульность — это отдельный квест.А в чем проблема-то?
У меня, кстати, под боком есть некоторое количество вполне себе программистов, которые не понимают области видимости, так что может дело не в "гуманитариях"?
в категорическом нежелании плодить ненужные сущности
… это ж вроде бы хорошо?
В результате код начинает быть похож на художественный текст (если обучался филолог или лингвист).
… вы никогда не слышали про Literate programming?
Я вот в среднем считаю, что если код можно читать как прозаический (это, кстати, важно, не художественный, а прозаический) текст — это его достоинство, а не недостаток.
vkni
06.01.2022 00:08А в чем проблема-то?
+1 Оно же само если "не доходит через голову, дойдёт через попу". В смысле на мало-мальски большом проекте появятся ошибки, которые придётся искать отладкой и чертыханиями.
Drazd Автор
04.01.2022 21:44-1С учетом того, что они могут объяснить каждое действие, которое применяют, а сам код роботов разбивают на части (отдельные файлы) с собственными входными и выходными аргументами (считай параметры и возвращаемое значение) - считаю, что удалось
GospodinKolhoznik
05.01.2022 04:05+1Перефразирую известный анекдот:
Разговаривают два математика: - Я не понимаю, что такое функция. - Да не проблема, сейчас я тебе объясню. - Нет же, объяснить то я и сам могу, а вот понять...
SadOcean
05.01.2022 02:40+9Начали за здравие, закончили за упокой.
Программированию то удалось обучить?
Потому что пока выглядит как реклама визуальных сред.
Drazd Автор
05.01.2022 11:18Возможно, вы где-то в середине решили просто пролистать статью, но в блоке с примерами простых программ на UiPath я написал, что простота визуального программирования побудила в учениках интерес разбираться глубже. И уже благодаря ему в этой же самой среде они начали писать программный код, благо она позволяет это делать. Сначала 1-2 строчки, потом больше-больше, постепенно заменяя визуальные готовые блоки на свой код.
Визуальная среда здесь - не конечная точка "путешествия", а скорее как мостик между визуальным осознанием алгоритмов и сложным программированием. Если бы я, как и другие, пытался бы их научить сразу писать код - с высокой долей вероятности ничего не получилось бы. А здесь у меня все получилось и я делюсь опытом "Как еще можно учить людей". И это не фантазия, а подтвержденный мною факт.
unclegluk
07.01.2022 15:07Абсолютно верно. Цитирую (ссылку давать не буду, легко ищется):
ЧТО ТАКОЕ UIPATH?
При взаимодействии с другими пользовательскими приложениями платформа UiPath имитирует действия человека, и в этом ее состоит ее основное различие с иными программами, работающими по API или через интеграционную шину (Middleware).
Это позволяет применять UiPath в создании роботов, предназначенных для:
Дальше идет перечисление того, что он может автоматизировать в существующих программах типа Экселя и прочих, но я не нашел ничего о том, что эта штука может создать что-то новое с нуля.
Демо-версия только для залогиненных, как и цены. В топку такие проекты.
Shaz
05.01.2022 07:06+6и единственное, что их объединяло – катастрофическая нелюбовь к техническим наукам (на самом деле и гуманитарии из них были так себе).
Программисты которых мы заслужили. (Знать бы ещё за какие именно грехи...)
Conung_ViC
05.01.2022 10:30+3Зачем так сложно? начали бы со скретча, раз уж в визуальное программирование пошли.
Drazd Автор
05.01.2022 11:15Смысл был не в том, чтобы научить визуальному программированию, а в том, чтобы пробудив более глубокий интерес научить делать правильно. Если бы я начал со скретча - я бы не смог прямо там же показать им как программировать классическим способом. Я не просто так в плюсах UiPath указал возможность полноценно программировать - именно этот мостик и сработал. Сначала ученики научились делать программы не написав ни строчки кода, а потом уже заменяли готовые визуальые блоки на свой код. Не все сразу, постепенно. И это заработало.
Utrfm
05.01.2022 11:19+1Сам применяю визуальное программирование для мелкой автоматизации (я инженер-проектировщик). Про минусы уже все написали, напишу про плюсы:
Как правило, уже всё есть для ввода/вывода "из коробки". Не надо писать для этого какие-то классы и т.д.
Я работаю с 3д моделями и удобно видеть на каждом шаге куда и что преобразуется. Не надо сочинять простыни кода, чтобы что-то вывести на экран.
Так что для скриптов отличная тема
SWATOPLUS
05.01.2022 11:21No Code - это негибко. Зачастую, проще написать какую-нибудь библиотеку, покрыть её тестами. а потом реализовывать бизнес требования в пару строк кода. Бизнес пользователи генерирующие бизнес правила, должны четко ставить задачу. А программист быстро превращать это в код.
А ещё можно обучить непрограммистов формату json (некоторым конструкциям js, markdown в зависимости от задачи) и писать конфиги на нем. Можно даже написать инструмент который визуализирует эту json-конфигурацию (проще чем писать визуальный редактор). Главное, что бы ядром был исходный текст.
И вот когда все работают с исходным текстом, то нахаляву получается много возможностей: контроль версий и аудит (git), возможность совместной работы (любые совместные редукторы кода или библиотеки для организации этой работы, проще чем писать с нуля для своей UI-тулы).
Drazd Автор
05.01.2022 11:22А можете, пожалуйста, указать, где в статье указано про No-Code? Статья посвящена тому, как через мостик визуального программирования научится именно что писать полноценный "Много-Code".
Narewen
05.01.2022 14:00+2Я скажу, что идея интересная. Про подход в обучении.
Не всегда понятно, где и как применять то, что ты изучаешь или тебе показывают на уроках.
Стандартное обучение выглядит так, вам наваливают кучу кирпичей и варианты их укладки. А после вам говорят - бери вот эту кучу кирпичей и строй дом.....
Более логичным выглядит подход, мы хотим построить дом... для этого нам нужно фундамент, стены и т.д. Для укладки стен лучше вот так, для переходов вот так и т.д.
Для старта очень даже хороший подход, хотелось бы узнать как после обучения у этих ребят складывается карьера?
Drazd Автор
05.01.2022 14:04О том, как складывается карьера - написано в начале и под конец. Один из них после плотного изучения визуального программирования смог освоить классическую разработку на C# и устроился джуниором в одну из IT-компаний. Двое других пока не выросли дальше визуального программирования, но тем не менее создают свои программки уже и без моей помощи, что я считаю очень хорошим прогрессом (тут даже скорее важно то, что они сами делают это с удовольствием и благодарят меня за то, что сдвинул их с мертвой точки).
Но вообще в целом, что касается карьеры - я себе не ставлю никогда цели "Устроить своего ученика в гугл-яндекс", а цель скорее - развить и дать более глубокое понимание, развить интерес к открытию новых границ. А как человек воспользуется этим для продвижения по карьере это уже его дело.
souls_arch
05.01.2022 17:52+2Ну кубики, пирамидки по цветам и отверстиям раскладывать, так же как и яблоки с апельсинами можно и обезъяну научить. А вот Мичуриным она не станет никогда.
Зачем это? Где пригодится? Как они будут всю жизнь работать без команды?
gochaorg
05.01.2022 22:00+1Что тут думать... А то, что среды графической разработки (графические языки программирования) пользуются своей нишевостью и от туда не вылезают уже очень давно
Вот статья на хабр https://habr.com/ru/company/edison/blog/432334/ (Визуальное программирование — почему это плохая идея)
По мне, это только первый этап в обучении программированию, не стоит делать большую ставку (но у вас там целый отдел), как самостоятельная практика написания возможна, но она упрется в фундаметальные ограничения
В первую очередь графический язык - некоторые штуки в нем тяжело выразить, например понятия:
рекурсия
лямбда / функтор (функциональный объект)
рефлексия и метапрограммирование
.... много оных
Вторая очередь: инструменты, есть ли в инструментах например intellisense, git, ...
Drazd Автор
05.01.2022 22:12Под капотом у выбранного инструмента (UiPath) - платформа .NET (при чем как старый .NET Framework 4.6.2, так и современный .NET по выбору) с возможностью писать выражения и блоки кода на языках VB NET и C#. Например, если вам нужно отправить письмо и составить его из разных блоков текста в зависимости от множества условий - вам не обязательно надо использовать только визуальное программирование, вы можете написать элегантный код. Преимущество именно в возможности выбора подхода. Что касается вопрсов:
Рекурсия - Есть, работает. Как в графическом варианте (вызывая другой/этот же файл с графическим кодом), так и в виде написания подфункций в блоке на языке из перечисленных выше
Лямбда-выражения - Используются большинством разработчиков для фильтрации, сортировки списков, таблиц
IntelliSence - присутствует при написании выражений и блоков кода на VB NET, C#
GIT (а так же TFS, SVN) - имеется встроенная интеграция с ними, в том числе с популярными GitHub, и GitLab.
... много оных - надо понимать о чем именно речь, но благодаря возможности использования VB NET и C# - скорее всего есть.
omichkun
05.01.2022 23:36+2Мне кажется, для выполнения плана вам нужно еще несколько раз упомянуть UiPath. Могу вам помочь: UiPath, UiPath, UiPath
gochaorg
05.01.2022 23:47Я понимаю что вы на Net все написали, это конечно хорошо, еще бы Java/Rust/etc..., но дело же не в этом
Вы пишете:
Рекурсия - Есть, работает. Как в графическом варианте (вызывая другой/этот же файл с графическим кодом), так и в виде написания подфункций в блоке на языке из перечисленных выше
Мне интересно как именно графически будет выглядеть кусок кода ниже:
Вот смотрите, есть допустим у меня такой кусок кода:Number fact( Number x ) { if( x>1 )return x*fact(x-1); return x; }Данная функция вызвает сама себя, а как в вашем случае в графической нотации вызывает функция сама себя ?
Как вы определяете графически функцию ? есть ли у вас для аргментов функции какие-то графические блоки, для каждого аргумента функции как определить тип данных ?
Простые конструкции языка графически представить не сложно
цикл - две дуги, одна дуга ведущая к началу итерации, другая к выходу из цикла
ветвление (if) - пара дуг, одна в случае истенности условния, другая в случае ложности
При большом желании можно определить графически функцию исключительно, но вот куда засунуть рекурсивный вызов функции графически, так чтоб стрелочкой... вот это уже интереснее, а текстом я и сам знаю
Drazd Автор
06.01.2022 00:31У вас явно устаревшее представление о том "что такое графическое программирование". Принял ваш вызов и сделал в двух вариантах:
Последовательность
Блок-схема
gochaorg
06.01.2022 01:27Возможно и устарели представления, но в целом я ожидал этот ответ, что рекурсивной стрелки/дуги нет.
Хотя если бы язык был развитый, тогда из синего прямоугольника (invoke) могла быть дуга к пункту старт - это было бы значительно наглядней.
Из примеров я могу судить что у вас xaml файл = функция - так ?
А из-за того что у вас используются названия файлов при вызове - возникнет (я так предполагаю) очивидные мелкие проблемы - переименование файла может к чертям сломать функцию, которая вызывает код. Была бы рекурсивная стрелка - ничего бы не сломалось.
Как вы боритесь с согласованностью визуального кода и вызывемых функций ? т.е. что будет если файлы переименовать, когда узнаем о проблеме - в compile time или run time ?
Drazd Автор
06.01.2022 01:32Да, файл=функция.
Нет, при переименовании переменных, аргументов (входные - параметры функции, выходные - возвращаемое значение) и самих файлов ничего не летит, среда разработки сама все переименовывает везде (прямо как Visual Studio и IntelliJ IDEA, если пользоваться встроеннвм функционалом переименования).
Но если вы решите открыть исходный код в текстовом редакторе и поменять что-то ручками - конечно, поломается. Обо всех проблемах вы узнаете на этапе проектирования. Встроенный статический анализатор кода не даст просто запустить даже отладку. К слову, этот анализатор можно накрутить дополнительными условиями, которые будут запрещать запуск если ваши разработчики начнут именовать переменные от балды, отойдя от принятого в компании код-стайла.
В целом вы пишете очень разумные и правильные замечания, но все это (по крайней мере в этой платформе) уже несколько лет как "по-умолчанию" решено.
gochaorg
06.01.2022 01:52Собственно и изучаю, что может ваша платформа, чем она может быть полезна (и в ваших же интересах расказать о ней)
Например меня интересует на сколько силен ваш статический анализатор по сравнению с Rust
Переименование это только первая очивидная проблема
Я могу предположить, что у вас на платформе генерируется код, тот же C# и потом делается попытка его скомпилировать
Если так, тогда как пользователь платформы узнает о
опечатках в коде
не правильном использовании типов данных, например: "Иванов" + 5 сентября
Из менее очивидных проблем графического программирования:
как быть если хотим ООП (свои структуры данных + методы структур данных) - тут я ожидаю, что визуального языка нет, все придется описывать руками и текстом
как быть с много поточкой и блокировками
как быть с иммутабельностью
как быть с транзакциями, вложенными транзакциями
Как быть с унаследованным кодом, можно ли трансформировать исходный код на C# в диаграммы ?
Drazd Автор
06.01.2022 11:14-1Я не являюсь экспертом по Rust, поэтому не готов комментировать сравнение с ним.
Что касается вопрсов опечаток в коде и правильного использования типов данных - за это отвечают возможности анализаторов и компиляторов языков VB NET и C#, точно такие же, как используемые в Visual Studio от Microsoft.
ООП именно в виде графической разработки - никак. Но если очень хочется, и ведется командная разработка - то как правило старшие специалисты пишут нужные классы в виде классической dll-библиотеки, упаковывают ее в NuGet-пакет, публикуют в локальном NuGet-репозитории и дальше он используется в любых проектах, где нужно использовать собственные классы, структуры. С другой стороны - чаще всего разработчики на UiPath используют json-структуры для хранения и обмена информацией, что позволяет вообще не морочится с созданием собственных классов (в классическом понимании).
По поводу многопоточности - имеется вариант запуска других программ (процессов) на других машинах с ожиданием выполнения. Самый лучший способ - использовать встроенные в платформу очереди транзакций, которые гарантируют получение уникальной транзакции каждой отдельной машиной (то есть очередь из миллиона транзакций будет разбираться 2-3-4 итд машинами и нигде не будет путанницы).
С другой стороны - опускание в такие глубокие детали вызывает уже и встречный вопрос - а зачем все это нужно при решении несложных утилитарных задач? Усложнение не всегда действительно нужно. А часть вещей, которые вам хочется писать самому - уже есть в платформе, и их просто нужно научиться использовать. А чтобы научиться - есть бесплатная академия, где рассказано про все аспекты платформы: https://academy.uipath.com
gochaorg
06.01.2022 12:12С другой стороны - опускание в такие глубокие детали вызывает уже и встречный вопрос - а зачем все это нужно при решении несложных утилитарных задач?
Ну потому что это показывает предел графического программирования, дело не в сложности, а в возможностях языка
Перечисленные выше вопросы - это все о примитивах языка
Я могу задать сходный вопрос - а зачем нам графический язык, когда есть BrainFuck или ASM - это вопрос к тому что любой язык программирования может быть сведен к более простому языку (по Тюрингу)
Но мы как-то не используем простые языки (ASM, C), а используем именно выразительные языки (Scala/C#/Haskel/TypeScript/...)
По мне из известных графических языков, многие из них страдают одними и теме же проблемами:
Не выразительны в сложных абстракциях - это не доработка дизайнера языка
Все ориентированы на кликанье мыши - а это заведомый тупик и проигрышь по сравнению с клавиатурой, стилус почему то не используют
Большинство работают как с листом бумаги и схемами на ней, а должно быть более сложное пространство, например бесконечное увеличение частей схемы
У большинства нет возможности создавать свои графические обозначения, свой графический язык - а это нарушает сами принципы языков
Drazd Автор
06.01.2022 12:26Я могу задать сходный вопрос - а зачем нам графический язык, когда есть BrainFuck или ASM
Предлагаю вам снова перечитать статью и перепогрузится в проблематику.
Там есть пример программы, которая считывает excel-файл и отправляет письма всем людям из таблицы в файле. Она занимает всего три действия: "Прочитать файл", цикл "Для каждой строчки", и "Отправить письмо".
Когда людям нужно делать такие простые программы - они могут сделать их меньше, чем за 10 минут (для этой статьи я, как опытный разработчик, сделал эту программу за 2 минуты, но я делаю "скидку" для новичков).
А сколько они потратят времени, если будут пользоваться ASM? Хорошо, я понимаю, что вы утрировали, но давайте скажите мне сколько вы потратите времени, чтобы с нуля написать такую программу на RUST, только без использования Интернета (гугла).
Я хочу донести до вас мысль, что не нужно ножиком забивать гвозди. У каждого инструмента есть своя сфера применения, и никто не говорит, что "Давайте выбросим классическое программирование и будем рисовать". Я лишь говорю в этой статье, что можно начинать свой путь именно так, а дальше уже развиваться.
PS: Я совершенно не понимаю о чем вы говорите словами "все ориентированны на кликание мыши". Последний раз, когда я программировал без мышки - был первый курс университета, на котором мы писали под DOS на Borland C++ 3.1. Все остальное время во всех более современных средах разработки так или иначе можно (и даже нужно) применять мышку. Вы большой молодец, что выучили все сочетания клавиш и справляетесь со своей работой, выбросив мышку - но большинство современных разработчиков все же использует мышку, чтобы открывать файлы, вызывать контекстное меню, "рисовать" пользовательские интерфейсы итд.
lair
06.01.2022 12:33+1Предлагаю вам снова перечитать статью и перепогрузится в проблематику.
Так у вас проблематика "научить программировать" или "научить делать простые программы"?
gochaorg
06.01.2022 13:15По вашей статье очень мало что можно вынести
"Как я учил гуманитариев программировать и что из этого вышло"
Что вышло - вопрос открытый (https://habr.com/ru/post/599329/#comment_23903797 - Удалось объяснить гуманитарию зачем нужны переменные и что такое функция? Или "это другое"? (c)
https://habr.com/ru/post/599329/#comment_23904673 - Начали за здравие, закончили за упокой. Программированию то удалось обучить? Потому что пока выглядит как реклама визуальных сред.
), и какую именно роль сыграло в этом визуальное прграммирование, очень большой вопросА сколько они потратят времени, если будут пользоваться ASM? Хорошо, я понимаю, что вы утрировали, но давайте скажите мне сколько вы потратите времени, чтобы с нуля написать такую программу на RUST, только без использования Интернета (гугла).
И опять видать фраза про выразительные языки как-то мимо вас прошла
Я хочу донести до вас мысль, что не нужно ножиком забивать гвозди. У каждого инструмента есть своя сфера применения, и никто не говорит, что "Давайте выбросим классическое программирование и будем рисовать". Я лишь говорю в этой статье, что можно начинать свой путь именно так, а дальше уже развиваться.
блин... кто ж спорит, а можно и по другому начать программирование и тем же гумманитарием
Я совершенно не понимаю о чем вы говорите словами "все ориентированны на кликание мыши"
я говорю о графическом вводе, когда рисуется диаграмма вы графически вводите объекты, перетаскиваете мышью на холст
потом дополняете объекты текстом - клавиатурой
когда обычное программирование это в первую очередь работа с текстом большого объема
но большинство современных разработчиков все же использует мышку, чтобы открывать файлы, вызывать контекстное меню, "рисовать" пользовательские интерфейсы итд.
ну вот именно, только с оговоркой, разработчик вообще к графическим интерфейсам из за отсуствия дизайнеров занимается этой штукой
ну а мушью я пользуюсь, в основном чтоб скорилить текст, да и то..., а большую часть действий я совершаю клавиаутрой
А что вы думаете про графическое программирование и технологию RPA в частности?
Кто вас за язык тянул ?
gochaorg
06.01.2022 13:27В целом по поводу графических языков программирования - есть простой критерий их (не)состоятельности:
Вот когда на графическом языке программирования можно будет создать еще один графический язык программирования - тогда будет о чем по говорить
forthuser
06.01.2022 15:03Вот когда на графическом языке программирования можно будет создать еще один графический язык программирования — тогда будет о чем по говорить
А, почему, к примеру, это сложно сделать на HiAsm?
В пpимерах врoде даже есть сделанный и 3D просмотрщик HiAsm схем.
Конечно для генерации кода придётся использовать или штатный генератор или сделать свой по имеющимся в данной среде возможностям.
gochaorg
07.01.2022 02:32Если кратко... То это сложно
Во первых нужно определиться с типами данных языка и операциями над ними, в самом простом случае мы можем свести что у нас будут только биты или на крайний случай числа в языке, но и вот что будет в графическом языке.? Допустим тоже... Ок
Потом нужно определиться с операциями над ними, с битами там понятно and, or,... с числами тоже
Потом работу с памятью придумать надо (read /write variables)
А далее порядок исполнения (if, while, call)
Если мы вводим вызов функции (call) то нужно определить синтаксис для определения функции, рекурсию и стек вызова
С типами данных, если их больше одного, то сразу тяжелее... Проверка на совместимость, ковариантности и прочего...
И вот.. Тут начинается зоопарк, надо написать парсер, который умеет из плоских данных (исходного текста, а данном случае из картинок/диаграмм) создать абстрактное синтаксическое дерево
А это парсер написать уже не тривиальным программа по размеру, даже если очень пытаться
Есть два варианта уменьшать грамматику языка, чтобы уменьшить объем парсера
За счёт упрощения языка
За счёт усложнения статического анализа и сложной модели типизации
В любом случае необходимо в языке (на котором ведётся разработка) иметь возможность выражать средствами самого языка графовые, неоднородные структуры
А многие графические языки, включая hiasm этого не умеют (могу заблуждаться) hiasm может использовать другие языки, но сам он не умеет в сложные типы данных
Под сложными типами я понимаю наличие параметриеских типов данных, типизированных кортежей + pattern matching, лямбд/замыканий
По мне, многие графические языки останавливаются на уровне простого процедурного программирования
gochaorg
07.01.2022 02:35Это возможно, но сложно... объяснение почему https://habr.com/ru/post/599329/comments/#comment_23910815
forthuser
07.01.2022 03:34Вот видите, сами же и ответили на вопрос что возможно, но сложно с Вашей точки зрения и из-за того, что хотите затащить в язык привычные Вам понятия из текстового программирования в которых может быть и не такая потребность в графическом языке программирования как целевого средства решения каких то задач.
P.S. Как пример одного такого целевого языка flprog.ru
lair
06.01.2022 11:21+1Прекрасная, кстати, иллюстрация к вопросу "что я думаю про графическое программирование". Вот был исходный текст программы:
Number fact( Number x ) { if( x>1 )return x*fact(x-1); return x; }(а на самом деле — и того меньше:
let fact x = x > 1 ? x*fact(x-1) : x)А чтобы его представить, вам понадобился экран картинок, и, что хуже всего, на этом экране не видно, какие же параметры передаются в следующий шаг рекурсии — то есть, самое важное (иначе нельзя сходимость оценить).
Вот за это и не любим.
teke-teke
06.01.2022 12:28+1еще есть codecombat.com где вы пишете игру, но не всамделешнюю, а просто, чтоб было понятно как оно вцелом работает. Я показал его брату геймеру, который ну никак не может в программирование (но усердно бьется, периодически, который год). Так он меньше чем за полчаса игры понял и циклы, и условия, и переменные, и, кажись, функции (если они там были), - то есть почти все, а вот на словах и примерах вообще никак не понимал (к тому же и я не ахти какой учитель).
Проблема только в том, что для программирования не достаточно знать циклы и переменные, как заметил автор, сначала нужно выработать мотивацию и понимание что с этим делать и куда двигаться дальше, а простой инструмент, имхо, может только снизить порог вхождения. Это очень важно, но не достаточно, чтоб "сделать программиста". Главным, все равно, остаётся личная мотивация и много практики.
А тема с unreal engine кажется особенно интересной еще и тем, что уже что-то предлагает для мотивации (этож настоящая игра!). Пойду гуглить о ней.
Drazd Автор
06.01.2022 12:31Отличный пример, к слову он не единственный. У Apple есть что-то похожее для обучения Swift. И для ряда своих учеников я применяю в том числе и эти инструменты.
Однако, с этими тремя учениками возникла проблема именно с освоением такого текстового формата. Наверное, если бы я, как типовой учитель, посидел бы с ними много занятий - смог вдолбить им это. Но благодаря использованному инструменту у меня получилось сделать именно для них обучение более быстрым и интересным.
teke-teke
06.01.2022 12:59чуток напутал. Когда писал коммент был уверен, что codecombat это визуальное программирование, давно его использовал. А так, сегодня много игр для андроид с использованием визуального программирования есть еще в плей маркете. В комментариях все довольны, и не скажешь, что это отзывы об игре где надо программировать.
gameplayer55055
06.01.2022 17:54Хороший успех зависит от хорошего преподавателя || хорошей мотивации ученика.
Вместо бубнения чего-то под нос и конспектирования, тут проявляется смекалка, и дела идут нормально, а не "по совковому"
Borjomy
07.01.2022 10:18Нда... Обратите внимание на язык G, есть среда разработки LabView компании National Instruments. Система разработки для инженеров и математиков. Код самой LabView пишут в том числе и индусы. Графичнее некуда. Есть образовательные лицензии. Используется в том числе для начального обучения. Существует уже 30+ лет. По мощности и возможностям сравнима с C. И вполне самодостаточна. Очень много индусов пишут на LabView.
forthuser
Как эксперт по технологии RPA отнесётся к мнению, что программисты на текстовых языках программирования выскажут ему своё мнение?
P.S. Можете добавить опрос по выяснению мнений к статье по заданному вопросу.
Drazd Автор
Опрос - это как ЕГЭ, можно тыкнуть в квадратики (кружочки), но это лишь некая уравниловка. Поэтому скорее интересно послушать живые мнения, опыт использования, субъективные ощущения.