На протяжении всего существования программирования, считалось, что оно тяжело для освоения, и что на то чтобы овладеть им, нужно потратить много времени и сил на обучение, вплоть до нескольких лет обучения в ВУЗе. Но на самом деле сложность программирования обусловлена одной проблемой, которую не решило ни появление интернета с доступом к информации, ни 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 для школьников.
Комментарии (61)
Dhwtj
13.01.2026 16:36Программирование можно будет освоить за день без курсов, когда решат эту проблему
Когда люди научатся формулировать свои мысли понятно для других. Эта статья отличный пример.
vyatkh1
13.01.2026 16:36Тогда программисты будут не нужны. Будут повсеместные вайбкодеры (я, правда, не очень понимаю слово программист в современной интерпретации. Вот инженер - понимаю). А так, для четкости формулировок, нужно сокращать выбор слов. Эллочка-людоедка обходилась 33 словами. Так и появился прототип Си, видимо))).
hochbar
13.01.2026 16:36Программирование можно будет освоить за 30 секунд, когда придумают нейросетевой интерфейс для загрузки информации/знаний в мозг (помните в Матрице)
Belarus
13.01.2026 16:36И то это будет чужой опыт, а не твой, отчево в будущем всплывут несоответствия. Например, тот другой предпочитал табы, а не пробелы.
SensDj
13.01.2026 16:36у Маска эйдетическая память, с такой памятью я бы даже ассемблер мог бы за три дня освоить с нуля
hochbar
13.01.2026 16:36Просто чел не понимает, что все с люди с рождения НЕ РАВНЫ. Не равны по физическим способностям, не равны по интеллектуальным. Просто как данность. В современной политкорректной культуре все это конечно отвергается, но факт есть факт.
Мне рассказывали про чувака, который до 41 года был лингвистом. Решил переключиться на программирование, довольно быстро дорос до уровня который позволил устроиться в Твиттер, да да тот еще старый твитор. Через неполных три года уже тимлид. И это после 40 Карл! В 40 многие программисты уходят на пенсию
a43mx Автор
13.01.2026 16:36Просто чел не понимает, что все с люди с рождения НЕ РАВНЫ
Как раз таки понимаю, но считаю что в будущем будут изобретены способы помочь отстающим догнать тех, кто впереди
vyatkh1
13.01.2026 16:36Ассемблер за 3 дня с нуля - вообще не проблема (там команд то до 500, и фреймворков нету), берешь pic1684, например и через час ты уже ассемблерист. Ассемблер в применении к конкретной архитектуре железяки - и за месяц можно замумукаться.
dzhiharev
13.01.2026 16:36запомнить все команды != освоить язык
Словарный запас пятилетнего китайского ребенка - от 500 слов.
Возьметесь за три дня выучить китайский на уровне пятилетнего ребенка?SensDj
13.01.2026 16:36вы знаете что такое "эйдетическая память" ? с такой памятью - да, можно и 500 китайских слов за три дня выучить
dzhiharev
13.01.2026 16:36причем здесь какая-то память? Выучив 500 китайских слов вы не заговорите на китайском и не станете понимать других китайцев на уровне пятилетнего ребенка. Просто выучив 500 команд ассемблера вы не напишите простейшую сортировку.
Нельзя научиться читать просто выучив буквы алфавита. Нельзя научиться писать художественные рассказы, просто выучив все слова языка.
Нельзя научится программировать просто выучив команды какого-то ЯП.SensDj
13.01.2026 16:36как причём ? в данной ветке это ключевая вещь! ветка началась с фразы "у Маска эйдетическая память, с такой памятью я бы даже ассемблер мог бы за три дня освоить с нуля". Такую память ещё называют "фотографической". Т.е. за три дня читаем все учебники по программированию на асме, со всеми примерами, даже не сильно вникая в написанное. Далее можно начинать писать программы, мысленно "перечитывая" нужный абзац или пример.
dzhiharev
13.01.2026 16:36гугл говорит, что учебников по программированию на ассемблере существуют тысячи. За всю свою жизнь американец с феноменальной памятью Ким Пик запомнил более 9000 книг. О каких трех днях речь?
SensDj
13.01.2026 16:36в статье есть фраза "Илон Маск в 10-летнем возрасте освоил за 3 дня BASIC, хотя курс был рассчитан на полгода". Какой в те годы был BASIC ? типа Спектрумовского ? По ассемблеру Z80 у меня была одна толстая книга, её можно прочитать за три дня, больше у меня ничего не было, но этого хватило освоить тогдашний асм до уровня написания демок, в т.ч. с векторной графикой.
Само собой книгой я пользовался постоянно, а с эйдетической памятью можно было бы просто прочитать её и подарить кому-нибудь.
dzhiharev
13.01.2026 16:36Какие в те годы были курсы (да впрочем и сейчас). Полугодовой курс, преподающийся два часа в неделю? Это примерно 50 часов (как большинство курсов по программированию на онлайн площадках). Любой достаточно мотивированный человек может потратить по 16 часов в течение трех дней и пройти такой курс. Для этого не нужна феноменальная память. Правда, к сожалению, прохождение курса не делает его программистом автоматически. Как нас учили на педагогике: знания, умения и навыки - три компонента профессиональной компетентности. Полученными знаниями нужно еще научиться пользоваться, а потом достаточно длительно практиковать, чтобы умения переросли в навык.
furvionx
13.01.2026 16:36американец с феноменальной памятью Ким Пик запомнил более 9000 книг
и это только их обложки
venanen
13.01.2026 16:36Что мы вкладываем в понятие "программировать"? Простейший ассемблер можно выучить реально быстро, и писать простейшие прошивки "если тут ноль - тут единица", иными словами, если нажали кнопку - тут зажгли лампочку, что покроет очень большую часть embedded. Это программирование? Вроде как да.
Конечно, родить БПФ на ассемблере без знания самого БПФ, вероятно, сможет один из миллиона - но это же не про программирование вроде.furvionx
13.01.2026 16:36а что на это говорит ИИссусь:
Понятие «программировать» (программирование) означает процесс создания и разработки программного обеспечения для компьютеров и других устройств. Это искусство перевода концепций и идей в наборы инструкций, которые компьютер может понять и выполнить.
Программирование включает написание кода на различных языках программирования, использование инструментов для разработки программ и работу в разных сферах.Для программирования используются языки программирования — формальные языки, которые служат средством коммуникации между программистом и компьютером. Существуют языки общего назначения (Python, Java, C++) и узкоспециализированные (R — для статистики, SQL — для работы с базами данных).
Выбор языка зависит от задачи:Изучение ассемблера не является достаточным для полноценного программирования, так как для решения различных задач используются и другие языки.
Да, изучение Python может быть достаточным для полноценного программирования, так как этот язык универсален и востребован в разных сферах.
Таким образом, для широкого спектра задач в программировании необходимы знания и других языков, и ассемблер может использоваться в качестве дополнительного инструмента, а не основного.
Да, знание SQL может быть достаточным для работы программистом, в частности SQL-разработчиком
Нет однозначного мнения о том, достаточно ли знания Basic для работы программистом.
Некоторые эксперты считают, что Basic не имеет преимуществ и не позволяет решать реальные задачи, зная только этот язык.Да, машинный код можно рассматривать как примитивный язык программирования или как самый низкий уровень представления скомпилированных или ассемблированных компьютерных программ.
Нет, знания машинного кода в общем случае недостаточно для того, чтобы быть программистом.
Обычно программирование абстрагировано от команд процессора. Для работы используют языки высокого уровня, а для использования специфических команд процессора применяют короткие ассемблерные и/или бинарные вставки.короче asm в sql вполне себе программист(ирование) - учится пол дня
вторую половину дня на осознание что программирование это форма самообмана
dzhiharev
13.01.2026 16:36в понятие программирование я вкладываю умение решить задачу, с решением которой ты ранее не сталкивался. Например, ты знаешь синтаксис циклов, оператор присвоения, знаешь как заполнить и вывести массив, но не видел ни одной сортировки ранее. Если при этом ты сможешь написать программу, которая выведет отсортированный массив, я буду считать это умением программировать. Значит ты освоил понятие, не просто выучил синтаксис.
Из собственных воспоминаний: я внезапно осознал, что понимаю что такое матрицы и как работают циклы, когда на курсах написал программу, заполняющую квадратную матрицу змейкой. С этого момента решение задач связанных массивами не представляло для меня проблем...
OlegZH
13.01.2026 16:36В статье имеется значительный смысловой разрыв между изначальным посылом (о программировании как таковом) и возможным подходом к освоению (программирование на конкретном языке программирования при помощи особых "продвинутых" средств).
Прежде чем садится за код, нужно решить много вопросов. Самое трудное, это понять, что нужно сделать, что нужно получить на выходе. Чаще всего, никто не знает, что получится на выходе. Программирование оказывается искусством. Искусством возможного. Нельзя иметь структуру, которая одновременно даёт малое время доступа и малое время для перестройки (этой самой структуры). А на самом верхнем уровне? Что делает система? Нет теории. Всё зиждется на неких подходах, технологиях и библиотеках.
Если, уж, очень интересно поговорить именно о программировании, как таковом, то следует взять какую-нибудь крупную задачу: склад, интернет-магазин, бухгалтерия. Интуиция подсказывает, что задачи, реализуемые в каждом случае будут всегда определёнными и ограниченными некоторым, может быть и широким, кругом вопросов. Что мешает реализовать ПО для каждого случая? Почему разные конторы реализуют свои собственные решения для этих задач? Почему, вообще, мы постоянно занимаемся решением одних и тех же задач? Вот краеугольный вопрос программирования!
Хотелось бы иметь готовый набор компонентов и собирать нужные приложения на лету. Почему не получается?
Эффективное программирование невозможно без теории. А она есть? Строго говоря, всё программирование можно рассматривать как работу с автоматами: есть состояния, входные воздействия, выходные воздействия, переходы из состояния в состояние. Марковские модели со скрытыми состояниями. Программирование — это процесс идентификации такой системы, то есть — восстановление скрытых слоёв. (В этом смысле, языковые модели ближе всего к такой концепции.) Вопрос архитектуры: какие автоматы, какие переходы, сколько слоёв. А ещё: грамматика. Только теория предписывает совершенно другое: на практике, мы используем существующий язык программирования (существующую грамматику), а в теории, мы должны создавать новую грамматику, специальным образом подходящую под решение задачи.
SensDj
13.01.2026 16:36Я себе программирование представляю как проектирование роботизированного завода. На входе сырьё или запчасти, на выходе "товары" (изображения, файлы и т.п.). Проектировать можно каждый "станок" с нуля, а можно брать готовые станки (компоненты и библиотеки) и соединять их между собой конвеерной лентой. В последнее время почти все виды "станков" уже существуют и остаётся только поставить их в нужном порядке с нужными настройками. Т.е. раньше нужно было быть инженером, способным разработать каждый станок вручную, а сейчас бывает достаточно умения компоновать их в нужном порядке, не вникая как там внутри станка всё устроено.
a43mx Автор
13.01.2026 16:36Кстати аналогия с заводом даже лучше будет чем с автомобилем. Но суть остается та же. Даже если брать готовые станки, то попробовать изготовить на них нужную деталь лучше до того, как его поставили на завод. Чтобы не столкнуться с тем, что прочитал описание станка, сделал вывод что он может изготовить то что необходимо, а уже в процессе запуска всей линии оказалось, что не может. При этом внутреннее устройство станка знать действительно не обязательно
stranger_shaman
13.01.2026 16:36Вся эта демагогия про тестирование двигателя автомобиля нивелируется успехами SpaceX и итеративной разработкой Старшип (и его двигателей) в частности.
a43mx Автор
13.01.2026 16:36
stranger_shaman
13.01.2026 16:36нейросетка это хорошо, скриншоты текста это тоже хорошо, круче только голосовухи в мессенжерах, очень жаль что своими словами уже мало кто умеет. Но в сборе например НАСА тестирует свою SLS уже второй десяток лет. Сравните со Старшип. Они не доводят свой продукт до идеала на стенде, вместо этого пачка неконтролируемых бабахов в реальных полетах, и переделка после каждого. Причем часто переделка глобальная, архитектурная, чего НАСА позволить себе не может. Слишком дорого переписывать все тесты. Чистый аджайл в том виде, как он и должен был быть. А не у коучей и ангелов.
По сути тут TDD против итеративной разработки с интеграционным тестированием. И выиграло второе.
ihouser
13.01.2026 16:36И это потому, что интеграционные тесты тоже важны. И тесты в реальной среде тоже. Без них, компоненты создаются и тестируются исходя из ложных представлениях о будущих рисках. Все переусложняется, к тому в ненужных местах. Тестируется с огромной перестраховкой.
NASA очень хорошо это проиллюстрировала. За дорого.
stranger_shaman
13.01.2026 16:36соглашусь, особенно про переусложнение. Ультра-дорогая водородная ракета, на 100% покрытая тестами, и стальная непокрашенная труба, собранная как будто на коленке, но превосходящая все, что было до нее.
P. S. NASA вполне это осознавала, потому и вырастили частников, с другими подходами к разработке.
alan008
13.01.2026 16:36Описание про возможность выполнить фрагмент кода - какое-то бредовое, т.к. чтобы в сложной системе что-то выполнять, система сначала должна построить с памяти сложный набор структур данных (композицию классов и т.п.) и вся эта сложная структура уже потом позволяет выполнять определенные "расчеты" над некоторыми данными. А если вызвать только "середину кода" без сотен тысяч строк подготовки, о чем может идти речь, о каком понимании, как эта середина должна сработать. Автор либо совсем новичок (не имел дела со сложными системами), либо просто фантазер в розовых очках.
a43mx Автор
13.01.2026 16:36Я ее сам не раз вызывал, и там от случая к случаю, сколько кода нужно подготовить. Когда реально много, тогда проще было отладку запустить, но это 30% от всего. А так бывают например функции, которые не принимают параметров, или принимают не сложные. Там я вручную заполнял переменные, которые потом использовал в вызове. И как я писал в спойлере, этот код может быть подготовлен автоматически, и не всегда для этого нужен будет ИИ (он как один из вариантов)
Cordekk
13.01.2026 16:36Такой инструмент облегчит работу с кодом, но не понятно, как он облегчит обучение программированию.
В целом средства разработки и так развиваются от написания кода на бумажке с последующим переносом на перфокарту к абсолютно интерактивному запуску кода без компиляции, но это не облегчает обучение программированию.
Android1983
13.01.2026 16:36Я бы сказал что статья очень сложная. Ну да ладно опустим подробности. Я конечно не полноценный тестировщик, но на сколько я изучал java qa я видел что отдельные функции и классы можно тестировать отдельно от всей программы. Ну а изучение программирования это не такая сложность и изучить можно достаточно быстро 1-3 месяца + практика ~1 месяц. Это если 5 дней в неделю заниматься только изучением и практикой не менее 2-3 часов в день. Тут ещё одна штука что выучить всё нельзя а требования у всех разные, да доучить другое дело если уже много основы освоить на достаточном уровне. А вообще такие статьи тают пищу для размышлений. Да и вообще куда мы катимся со своими ИИ. Люди не знают как что работает, а уже с помощью ИИ что-то пытаются строить.
gscdlr
13.01.2026 16:36Впустую потраченное время на статью.
Освоить программирование можно за день. Под конец этого дня будешь писать программы расчета чего-либо. Ввод, обработка данных, вывод. Программируешь, есть рабочий результат. Цель выполнена?
Понятия не имею, сколько часов, дней, месяцев я потратил на программирование. В т.ч. с бесплатными курсами и с использованием LLM — не для вайб-кодинга, но в качестве инструмента. На каждом этапе, после завершения каждого крупного учебного проекта или интересной и сложной задачи, можно почувствовать, что ты что-то умеешь, что-то знаешь, многое понимаешь... Но впереди всегда остаётся непознанная бездна, перед которой ты — юный падаван, сделавший лишь совсем незначительный шажок.
Уверенности тех, кто заявляет, что программирование или хотя бы небольшой язык уровня Си можно выучить за 1/3/7/10/etc дней я могу лишь позавидовать. Блажен ум, что слишком мал для сомнений.
P.s. для какого-нибудь ЕГЭ за пару недель, думаю, освоить питон можно, чтобы полностью выполнить часть С.
furvionx
13.01.2026 16:36Освоить программирование можно за день. Под конец этого дня будешь писать программы расчета чего-либо. Ввод, обработка данных, вывод. Программируешь, есть рабочий результат. Цель выполнена?
если оплату за код получил то да
aamonster
13.01.2026 16:36Это всё полезно (и подкину в копилочку инструментов для реализации подхода: TTD – Time Travel Debugging в WinDbg, Reverse Debugging в GDB), но даже не близко к освоению программирования за один день – просто позволяет не тратить время на то, что вообще не помогает.
Upd: А ещё при наличии/использовании таких инструментов полезность курсов (или обучения с наставником) кратно возрастает. Человека можно не просто прогнать через быстрое решение типовых задач (чтобы он освоил все темы, которые ему понадобятся в первое время, и имел подходы к остальным), но и нащупать, где у него затыки, и откорректировать обучение на лету.
ExoticHadron
13.01.2026 16:36Смотря что называть программированием. А то ведь как в бородатом анекдоте:
— Я за полгода выучил русский язык. Пять тысяч слов.
И все они у меня тут — в з%пе!
KartaloSt
13.01.2026 16:36Может для начала отсекатор лишних "бы" и предлогов написать для текстового редактора. Хотя, постойте, есть же проверка грамматики или простой промпт для бям - отредактируй мои сослагательные наклонения так, чтобы было понятно, что я уважаю время читателя. Но нет, жупел так жупел, - будем нарочито неряшливо писать, чтобы в чатджипитижении не заподозрили.
a43mx Автор
13.01.2026 16:36Брать статью целиком и прогонять через ChatGPT неудобно, поскольку у Хабра свое кастомное форматирование, которое слетит после прогона. Был бы встроенный ассистент я может и попросил бы отредачить. При условии что мне Хабр показал diff до и после
Belarus
13.01.2026 16:36Похоже, автор новичок в програмировании как и я, и в плане неудобства тэстирования отдельных частей програмы я согласен. Но не понял, што понимаетса под "освоением програмирования". Ведь выучить синтаксис и понять основы можно за день. А штобы стать мидлом, надо решыть довольно много задач и набрать много опыта - если даже задачи будут идти подряд, то вряд ли это выдержыт мозг и хватит одново дня.
А вот то, што облегчило бы разработку в Visual Studio мне:
-шаг назад в отладке - удивительно, што это не стандарт. Сделал шаг вперёд - и всё, увидел изменение чево-то, но не других частей, шага назад штобы повторить нет. Соизволь перезапустить програму и доводить процес до этово места.
-принудительная компиляцыя: когда алгоритм на этапе разработки, не хочетса отвлекатса на стороннее. А именно - изменил што-то и теперь надо пройтись менять в других местах програмы. Пусть это будет добавление доп. параметра у функцыы. Или ошыбка несовпадения типа, потому што её изменил.
С принудительной компиляцыей можно было бы выполнить програму до нужново места. А если исполнение таки дошло до мест с ошыбкой, то там компилятор оставил бы прерывание процеса.
-запись ввода. При перезапуске програмы (т.к. шага назад нет, или сделал какое-то изменение) надо заново доводить процес до нужново места. Это не только ожыдание уже не раз произведённых вычислений и чтений из файла (достаточно подождать), но и ввод вручную, движения мышкой и нажатия. Лень для этово писать код воспроизведения в самой програме или использовать сторонние програмы записи и воспроизведения действий.
-паралельная версия кода: нередко бывает, што задачу можно выполнить разными способами и не ясно, какой будет производительнее и удобнее для глаз. Например, заранее выделить массив и сохранить в нём результат вычислений или же лучше вычисления делать лениво, по мере необходимости? Я бы писал и выполнял оба вариант одновременно, штобы легко сравнивать. Сделать один вариант, а потом переделывать ево под второй вариант - напряжно.
Отделять варианты с define - напряжно для чтения, код визуально усложняетса.
Радует, што в VS появились:
-внесений изменений в програму без компиляцыы, прямо во время отладки. Хоть работает и не всегда, но помогает в простых случаях.
-отладка частей кода, которые были выкинуты оптимизатором компилятора - совсем свежая штука. А то раньше с этим был "пук-среньк, ой извините"
-строка передающихся параметров програме прямо рядом с кнопкой запуска, т.е. не надо постоянно лезть в настройки проекта. Тоже новая фича, VS2026.
Вот бы ещё при отладке при просмотре внутренностей контэйнеров можно было сразу прыгнуть в ево конец клавишей End, а не держать PageDown.
А ещё штобы автозавершение кода и Ctrl+Z работали в строке поиска/замены... Мечты.
ilya_kochetov
Вторая статья с кликбейтным заголовком... или может, просто с автором, не очень понимающим, о чем говорит? Бейсик освоить за 3 дня можно, можно даже код рабочий за час написать с помощью чатгпт, но только к программированию это отношение имеет примерно такое же, как умение аутиста на память воспроизводить огромные тексты - к умению разговаривать.
furvionx
так и ассемблер можно за день освоить да аутокад за ящик водки - главное когда телевизионую программу составляешь не поломать привычки миллионов
a43mx Автор
Ну так я еще в начале статьи написал что вайб-кодинг не имеет отношения к умению программировать. И речь тут о любом языке шла
Но статья то не про вайб-кодинг
ilya_kochetov
вот именно, статья про то что каким-то, несомненно волшебным, способом умение создавать исполняющийся код связано с тем, что этот код будет иметь ценность. А потом к этому как-то (логика не очень прослеживается) приплетен REPL. И все это с густой пеной хайпа.
a43mx Автор
Ну как-бы он решает проблему двигателя и машины, но мне ее тут слово в слово пересказать? Это и есть объяснение зачем он. А если оно непонятное, то давайте уже конкретику тогда
ilya_kochetov
Взяв ваш пример с марсианским кораблем, вы (почему-то) предполагаете, что на него смотрит механик, а то и инженер, и его основная проблема - понять то что он видит и сопоставить со своими знаниями. Вы даете ему замечательный инструмент, он счастлив, все работает.
А теперь та же самая ситуация, только этот же механик увидел марсианский корабль в возрасте 7 лет (т.е. отнимем у него знания, умения и опыт с земными механизмах). Ему ваш инструмент будет абсолютно бесполезен. Даже если этот инструмент сам сделает 90% работы, у мальчика совсем другие интересы и уровень зрелости.
Возвращаясь к нашим баранам, проблема создания ПО сейчас не в IDE и не в отладчиках, никогда, собственно, в них проблемы не было (почитайте статью про Криса Хинсли https://habr.com/ru/companies/yandex/articles/978600/ который в 10 лабал игры на машинном коде, я сам этим занимался в 14, могу подтвердить это реально).
Проблема была и остается в целепологании, уровне зрелости и понимании домена.
a43mx Автор
Он может не осознавать необходимость если привык верить на слово своим догадкам и еще не сталкивался с последствиями такого подхода. У детей такое бывает, но даже тут ребенок ребенку рознь, и если у одного это есть, другой предпочел бы проверить свои размышления на практике
А разве не в умении решать задачи? Ниже про это комент оставляли