На протяжении всего существования программирования, считалось, что оно тяжело для освоения, и что на то чтобы овладеть им, нужно потратить много времени и сил на обучение, вплоть до нескольких лет обучения в ВУЗе. Но на самом деле сложность программирования обусловлена одной проблемой, которую не решило ни появление интернета с доступом к информации, ни Stackoverflow, где можно задавать вопросы, ни появление сред разработки (IDE) с их различными фичами, ни курсы "войти в айти за 9 месяцев", ни даже появление ChatGPT в 2022 году, которому можно задавать вопросы, и который и вовсе может "писать код за нас". Последнее создало у всех иллюзию революции, будто бы теперь любой желающий может создавать программы без знаний программирования, хотя в действительности их стало можно создавать без бюджета на программиста на начальном этапе. Если вы не знаете программирование, и программу для вас пишет ИИ, то вы заказчик, а не программист, и программу создаете не вы. А иначе бы и про заказчиков на фрилансе можно было бы сказать, что они они создают программы без знаний программирования при помощи исполнителей. А одного того, что нейросетям можно задавать вопросы, недостаточно, чтобы называть это образовательной революцией - это скорее эволюция того, что было раньше (гуглинг, Stackoverflow и т.д). Если какую революцию ИИ и совершил - так это производственную революцию. Но причину, мешающую быстрому освоению программирования, он так и не устранил.
А в чем состоит эта причина и как она будет решена, пойдет речь в данной статье.
P.S ранее я уже писал статью про 9 фич будущего, благодаря которым можно будет освоить программирование за день... ту самую, что раскритиковали в коментах и заминусовали. Ошибка той статьи была в том, что там главная проблема программирования так и не была описана на пальцах. Был лишь продемонстрирован инструмент, ее решающий, но даже на него не был сделан акцент, и он затерялся среди остальных фич, в совокупности решающих другую проблему. В этой статье это будет исправлено. Если вы прошлую статью не читали, то рекомендую прочитать сначала текущую статью.
В общем, поехали.
Содержание:
1. Ускорение практики, проблема двигателя и машины, смарт-консоль
Представьте, насколько была бы дорогой и сложной была бы разработка автомобиля, если бы его при разработке его узлов (двигателя, трансмиссии и т.д) и компонентов их можно было бы тестировать исключительно во время тест-драйва автомобиля, а не отдельно на тестовом стенде?
Что было бы (рассказывает ChatGPT)
Если бы двигатели и другие компоненты можно было бы тестировать только при тест-драйве всего автомобиля, а не отдельно на стенде или в лаборатории, это кардинально замедлило бы весь процесс разработки и производства. Вот к чему это бы привело:
1. Резкое удорожание НИОКР
Каждый тест нового двигателя потребовал бы сборки целого автомобиля (даже если это прототип).
Значит, на каждый этап нужно строить кузов, устанавливать подвеску, рулевое, салон и т.д., только чтобы проверить, работает ли двигатель.
2. Огромные временные затраты
Времени на интеграцию, сборку, разборку и устранение ошибок ушло бы в разы больше.
Исправить мелкий косяк в работе двигателя? Собери машину заново и проверь на треке.
3. Сложность с безопасностью
Нельзя выявить проблему в управлении топливом, температурой или вибрациями на безопасном стенде — всё проверяется «на ходу».
Это увеличивает риск разрушения узла прямо во время езды.
4. Отсутствие точности
Стендовые испытания позволяют изолировать конкретные параметры (например, температуру поршней, вибрации коленвала, нагар на свечах).
В автомобиле эти параметры мешаются другими системами, сложно понять, в чём проблема.
5. Проблемы с масштабированием
Массовое производство и контроль качества стали бы неэффективными — нельзя запустить двигатель на стенде для проверки, придётся катать каждую машину.
А вот программистам и представлять не надо, в здесь все ровно так и происходит - программу вы можете запустить только целиком. И если тест-драйв нашего автомобиля прошел успешно, то тогда никто и не заморачивается. Но если нет, то в на двигатель, трансмиссию, и другие узлы, вплоть до шестеренок, ставят... принтеры, которые печатают результаты их работы, по которым уже определяют, где что-то пошло не так. Да-да, именно так и выглядит обычная работа программиста - в различные места программы они вставляют такие команды, как echo, print, console.log, console.writeln и т.д в зависимости от языка. Более продвинутые программисты вместо "принтеров" используют пошаговую отладку - буквально "останавливают время" прямо по ходу проведения тест-драйва, и смотрят на показания электронных датчиков (просмотр значений переменных).
Думаю понятно, насколько "надежен" автомобиль в таком случае - ведь надежность любой техники определяется надежностью всех ее компонентов, а далеко не все сценарии каждого отдельно взятого узла можно проверить тест-драйвами всей машины. Некоторые программисты все же стараются тестировать компоненты отдельно - но для этого они в качестве испытательного стенда берут отдельный полуразобранный автомобиль, куда и могут поставить двигатель или что-нибудь еще чисто для проведения испытаний - это аналогия созданием отдельного файла и с выносом фрагментов кода и выражений туда, точно также прописывая print для получения результата. Делать так каждый раз - избыточно, долго и неудобно.
Однако надежность - это еще пол беды. Главная проблема - у вас нет гарантии, что вы действительно правильно понимаете, как все работает. Представьте - прилетели марсиане со своим марсианским автомобилем, и вы пытаетесь разобраться в его конструкции. Открываете капот, видите что-то похожее на двигатель. А где гарантия что это именно двигатель, а не топливный бак, трансмиссия, или еще что-нибудь? Кто их знает, этих марсиан? Надо бы достать двигатель и запустить его на стенде, чтобы убедится, что это действительно он (или например, что он работает так, как вы предполагаете), но для этого ведь нужно танцевать с бубнами... Проще поверить на слово своим догадкам (а потом однажды обнаружить, что машина ездит с выключенным двигателем).
Вот и в программировании любая программа - все равно что тот самый марсианский автомобиль, во всяком случае для новичков. А то и черный ящик, в котором вообще непонятно что происходит. А с появлением волшебника в голубом вертолете (ChatGPT), который создает готовый автомобиль по одному запросу, количество вот таких вот марсианских автомобилей может вырасти даже для опытных программистов. Думаю теперь понятно, почему говорят, что на каждого вайб-кодера найдется свой вайб-хакер.
Но проблема двигателя и машины могла быть решена, если бы был волшебный инструмент, который мгновенно клонирует двигатель на тестовый стенд и запускает его, едва вы показали на него пальцем, и позволяя ставить над ним опыты. То есть если бы в коде если бы можно было бы сразу выполнить интересующий фрагмент - просто навести курсор на любое выражение (или конструкцию) в коде и тут же его выполнить по клику, либо скопировать в отдельное окно, где его можно отредактировать перед выполнением.
Теперь у вас будет возможность гораздо быстрее и легче пройтись по всем выражениям и фрагментам в коде и выполнить их, либо быстро выполнить выражения при разных входных параметрах. Для новичка, который ничего не знает, каждое выполнение выражения уже является полноценным экспериментом, потому что таким образом проверяется предположение, что данное выражение действительно работает так, а не иначе, и возвращает такой-то результат, а не какой-то другой. А программирование как раз и изучается опытным путем, путем экспериментов, и если есть способ проводить опыты в сто раз быстрее, то и программирование будет освоено в сто раз быстрее. Теперь вам будет гораздо проще разобраться во всем самостоятельно.
У некоторых языков есть REPL-консоли, и казалось бы, вот он, тестовый стенд для запуска двигателя, вот только...
Стенд есть, а волшебного клонировщика нет, и двигатель нужно вручную ставить на стенд. То есть нужно каждый раз вручную выделять нужный кусок кода, копировать его и вставлять в консоль. И если вы думаете, что выделить-копировать-вставить достаточно, чтобы считать это быстрым клонировщиком, то это не так. Эти действия точно так же являются рутиной (особенно первое), которая особенно ощутима при многократном их повторении, но многих может и с первого раза отпугнуть.
Не у всех языков консоли подходят под определение REPL. Какие-то (например стандартная консоль php) не позволяют выполнять выражения напрямую, и результат тоже нужно выводить через
print. То есть в данном случае реальный стенд мало чем отличается от полуразобранного автомобиля, тоже используемого как стенд - и там и там к двигателю нужно цеплять принтер, чтобы получить результат.После запуска код оттуда пропадает, и вам его нужно туда снова вставлять, либо листать историю команд. Для консолей это базовое поведение со времен их появления, но если сравнивать со стендом, то это как если бы после запуска двигателя на нем он каждый раз был бы на полу.
Хотите выполнить часть куска кода, который в консоли? Вам придется заменить им первоначальный код. То есть если допустим на стенде был двигатель, но теперь вы хотите проверить на прочность отдельную шестеренку этого двигателя, то достаете ручками эту шестеренку, и ставите на стенд вместо него.
Не у каждой консоли есть интеграция с IDE. IDE имеет такие полезные и важные фичи, такие как подсветка и проверка синтаксиса, быстрая документация, автодополнение и т.д. Это как если бы у вас были бы очки дополненной реальности, в которых вы смотрите на только что собранный автомобиль, а они вам выводят потенциальные ошибки при сборке, быструю документацию по таким-то запчастям и их характеристики и т.д. Или робот-помощник, который предложит вам различные детали машины, и сам моментально поставит то, что вы выбрали, тем самым значительно ускоряя ее сборку. Но при работе с тестовым стендом все это перестает работать.
То есть стенд то есть, но тестировать двигатель отдельно все еще дорого. Поэтому консоли так и не набрали широкую популярность - ограничения классического интерфейса консолей, CLI, дают о себе знать. Описываемый же в данной статье инструмент в сравнении с обычными консолями - это как смартфон в сравнении с кнопочным телефоном, поэтому его логичное название для него - смарт-консоль. И да, просто наличие интеграции с IDE (пункт 5), еще не делает консоль смарт-консолью, а если и делает, то ее можно сравнить со смартфонами, которые были до появления айфона. Ведь главного - моментального теста любого вложенного компонента, будь то двигателя без машины, или шестеренки без двигателя, тут по прежнему нет.
Неофициально данный инструмент уже существует
Показанные в гифках фичи являются частью режима отладки - это Quick Evaluate Expression, и Evaluate Expression (в окне с возможностью предварительного редактирования). Но там у них другое предназначение - они предназначены для выполнения кода в месте точки останова, а не в любом месте проекта. Смарт-консоль тоже будет основана на данных фичах, но вместо отладки они скорее всего будут прикручены к тем же REPL-консолям, которые и будут ядром смарт-консоли. Получается, что REPL перейдет от CLI к GUI, но не потому что переход к графическому интерфейсу является самоцелью, а потому что это решает конкретные проблемы.
Но пока смарт-консоль не появилась, то другого способа получить доступ к данным фичам нету, поэтому для доступа к ним придется запускать отладку. Чтобы каждый раз не думать, куда поставить точку останова и как ее достичь, можно запускать так называемую фейковую отладку - использовать отдельный выделенный минимальный файл, где есть только точка останова и подключение библиотек, либо подключение всего приложения одной строчкой. То есть по сути для опытов над двигателем с одного автомобиля вы будете в качестве стенда использовать другой полуразобранный автомобиль, для которого будете "останавливать время", но в данном случае это удобно, потому что любой интересующий вас компонент моментально будет оказываться на этом "стенде". Ведь настоящий стенд (REPL-консоль) не имеет "быстрого клонировщика", а "заморозчик времени" (отладчик), как ни странно, им уже обладает.
Контекст пока что придется воспроизводить самостоятельно
Если выполняемое выражение содержит переменные, то вам нужно будет для начала их заполнить, если содержит this, то придется будет отредактировать выражение и заменить this на переменную, содержащую экземпляр класса. Когда появится официальная смарт-консоль, то наверняка все это автоматизируют. Например будут или генерировать и выполнять код для автоматического заполнения переменной (в строго типизированных языках для этого даже ИИ не понадобится), либо собирать их значения, делая снапшот программы трассировщиком (один из режимов работы отладчика) во время ее работы
Одной из наилучших реализаций данных фич обладает интерфейс отладки xdebug языка php в IDE Phpstorm - вот отдельная статья про это, а заодно и про запуск xdebug без настройки. Реализация этих фич в режимах отладки других языков мне понравилась меньше - например в Javascript debug нет автовыделения выражений (но зато там можно выполнять языковые конструкции, а не только выражения), а в отладке Java оно есть, но не захватывает присвоения переменных.
2. Теорию знать не придется?
Изучение программирования опытным путем это конечно хорошо и правильно, но все же нужно сверятся с теорией, чтобы убедится, что выводы из опытов сделаны правильные. И если вы не знаете теорию, то придется будет каждый раз изучать документацию, чтобы убедится в том, что вы правильно понимаете то, что видите. Либо и вовсе чтобы было что проверять опытным путем.
Но современные IDE уже частично избавляют от необходимости и знать базовую теорию, и гуглить ее, и даже спрашивать у нейронок - она зашита в их UI. Это такие фичи, как:
Проверка и подсветка синтаксиса. Больше не нужно знать синтаксис наизусть, и из-за одной пропущенной точкой с запятой полчаса выяснять, почему не работает код: IDE тут же подсветит этот момент. А статический анализатор подсветит вызовы несуществующих функций, передачу неверных параметров в функции и т.д. То есть если вы до этого не знали, что нельзя вызывать несуществующую функцию (либо знали, но допустили ошибку в имени существующей), то теперь это не будет проблемой.
Быстрая документация. Не нужно знать или запоминать наизусть, что делает та, или иная функция - можно навести курсор и получить окошко с описанием, что она делает, что принимает на входе и выдает на выходе.
Автокомлит (не путать нейрокомплитом). Вам не обязательно запоминать все функции и классы - достаточно написать первые несколько букв, и появится выпадающий список функций/классов, которые начинаются на эти буквы, из которого вы можете выбрать нужную, и ее вызов сразу будет вставлен в редактор по клику, без необходимости писать его целиком.
Переход к определению метода, и навигация по проекту в целом. Можно нажать на вызов функции/метода/класса (Ctrl+B или Ctrl+Click), и "провалится" в него - то есть перейти к его определению (исходному коду), что визуально выглядит как переход по ссылкам в интернете. Без этого функционала нужно было бы иметь знания того, как найти это самое определение (и вообще понимать, что оно есть).
То есть как я уже и писал выше, эти фичи IDE можно сравнить с очками дополненной реальности, выводящие информацию об автомобиле и его компонентах (пункты 1-2) а автокомплит (пункт 3) - с роботом-помощником. Однако сейчас функционал IDE покрывают далеко не все ситуации, и вот примеры "белых пятен", до которых UI пока не достает. Они уже описывались в прошлой статье вместе с фичами, которые должны их решить, поэтому тут кратко по ним пройдемся:
Нужно изначально знать о существовании базовых сущностей языка - функций, языковых конструкций, операторов и т.д. Если вы о них не знаете, то тогда вы вообще не знаете, что есть в данном языке, и без готового куска кода вам будет не с чем поиграться в смарт-консоли. А то и вообще непонятно, что делать в IDE, если только вы не вайб-кодер, который пришел попросить ИИ сделать что-то конкретное. Решить эту проблему должен единый структурированный список сущностей, откуда вы и сможете их взять. Автокомплит тут не подойдет - он предназначен для поиска и фильтрации по первым буквам, а не для обзора того, что есть в языке.
То, что написано в прошлой статье про Drag-n-Drop, больше не актуально
Первоначальное описание списка, представленное в прошлой статье, состоит в том, что вы можете взять из списка любую сущность, и Drag-n-Drop-ом перетащить ее сразу в код. Этот момент стал основным объектом критики в комментариях, и он действительно ошибочный. Брать сущность из списка и перетаскивать ее сразу в редактор - все равно что брать двигатель с витрины автозапчатей, и сразу ставить его в машину, не протестировав его отдельно, не поставив над ним опыты. Нарушение самого главного принципа, которому посвящена текущая статья. Вместо Drag-n-Drop нужно открытие напрямую в окне Evaluate Code. Перетаскивать напрямую, минуя тестирование, могло бы пригодится для уже знакомых функций, которыми пользовался не раз, но их вряд ли будут искать в списке - для этого есть автокомплит.
И все же однозначно пока нельзя сказать, будет ли Drag-n-Drop не нужен вообще, или будет нужен как второстепенная фича. Наверняка он будет полезен, но не в привязке к только списку, а как самостоятельная фича IDE, ускоряющая редактирование кода.
Отсутствие быстрой документации для языковых конструкций и операторов. Точнее, возможно это реализовано для отдельных языков, но в целом как единого стандарта, такого на платформе Intellij нет, и насколько известно, в других IDE тоже.
Навигация по коду не всегда интуитивно понятна, и в ряде случаев требует понимания ООП (наследование и полиморфизм) - если вы перешли из дочернего класса в родительский класс через "переход к определению", то автоматически вернуться обратно уже не сможете, если дочерних классов несколько.
Второстепенный на первый взгляд кейс - встроенные функции языка помечаются тем же цветом что и пользовательские, что может вводить новичков в заблуждение. Казалось бы, мелочь, но такие мелочи могут иметь отложенный негативный эффект - вы что-то поняли неправильно, но узнаете об этом не сейчас, а однажды в будущем, возможно в самый неподходящий момент.
Это не все кейсы, а лишь бросающиеся в глаза - заранее все предусмотреть невозможно, да и нецелесообразно (этим будут заниматься разработчики IDE, когда дело дойдет до дела). Когда UI закроет пробелы, то это будет означать, что вы, зайдя в IDE, сможете и разобраться во всем самостоятельно, и гарантированно понять все правильно. Действительно хороший UI не потребует знания базовой теории - он либо делает ее интуитивно понятной, либо ускоряет и упрощает к ней доступ в 100 раз. Что в сочетании с практикой, так же ускоренной и упрощенной в сто раз, делает само обучение программированию интуитивно понятным. Практика гарантирует, что теория понята правильно, теория гарантирует, что практика понята правильно.
Заключение
Освоить программирование за день - это кликбейт! Как мне писали под прошлой статьей. Может быть и кликбейт, вот только Илон Маск в 10-летнем возрасте освоил за 3 дня BASIC, хотя курс был рассчитан на полгода. И это при том, что тогда ни AI, ни интернета со Stackoverflow, ни IDE, и даже графического интерфейса еще не было тогда. Не было у Илона Маска ни возможности быстро «запустить двигатель без машины», ни «витрин с автозапчастями», ни «очков дополненной реальности». И ведь ему это не помешало. Просто теперь схватывать на лету сможет уже не только Илон Маск, но и вы тоже, если у вас не получалось это раньше.
Да и вообще, хоть об этом почти не говорят, но умение программировать и раньше осваивалось за день, и не только Маском. Да, раньше собрать работающий автомобиль без возможности быстро и легко протестировать двигатель было невероятно сложно, но если уж у вас получилось написать программу, и она работает (самостоятельно, без копипаста со StackOverflow и прочей помощи), то значит вы прошли «обряд посвящения в программисты», и одного этого было достаточно, чтобы считаться человеком, умеющим программировать. Ни годы института по профилю, ни месяцы курсов, а именно это (к тому же универ или курсы вовсе не гарантируют прохождение «обряда»). Даже если после этого вы все еще не знали какие‑то базовые основы языка, это становилось неважным, потому что пройденное испытание гарантировало, что вы можете во всем разобраться по ходу дела. Теперь же таким гарантом будет интуитивная понятность, обеспечиваемая смарт-консолью в сочетании с IDE UI следующего поколения. И когда это произойдёт, IDE может стать тем же, чем сейчас является Minecraft для школьников.
