Comments 163
Вторая статья с кликбейтным заголовком... или может, просто с автором, не очень понимающим, о чем говорит? Бейсик освоить за 3 дня можно, можно даже код рабочий за час написать с помощью чатгпт, но только к программированию это отношение имеет примерно такое же, как умение аутиста на память воспроизводить огромные тексты - к умению разговаривать.
можно даже код рабочий за час написать с помощью чатгпт, но только к программированию это отношение имеет примерно такое же, как умение аутиста на память воспроизводить огромные тексты - к умению разговаривать.
Ну так я еще в начале статьи написал что вайб-кодинг не имеет отношения к умению программировать. И речь тут о любом языке шла
Но статья то не про вайб-кодинг
вот именно, статья про то что каким-то, несомненно волшебным, способом умение создавать исполняющийся код связано с тем, что этот код будет иметь ценность. А потом к этому как-то (логика не очень прослеживается) приплетен REPL. И все это с густой пеной хайпа.
А потом к этому как-то (логика не очень прослеживается) приплетен REPL
Ну как-бы он решает проблему двигателя и машины, но мне ее тут слово в слово пересказать? Это и есть объяснение зачем он. А если оно непонятное, то давайте уже конкретику тогда
Взяв ваш пример с марсианским кораблем, вы (почему-то) предполагаете, что на него смотрит механик, а то и инженер, и его основная проблема - понять то что он видит и сопоставить со своими знаниями. Вы даете ему замечательный инструмент, он счастлив, все работает.
А теперь та же самая ситуация, только этот же механик увидел марсианский корабль в возрасте 7 лет (т.е. отнимем у него знания, умения и опыт с земными механизмах). Ему ваш инструмент будет абсолютно бесполезен. Даже если этот инструмент сам сделает 90% работы, у мальчика совсем другие интересы и уровень зрелости.
Возвращаясь к нашим баранам, проблема создания ПО сейчас не в IDE и не в отладчиках, никогда, собственно, в них проблемы не было (почитайте статью про Криса Хинсли https://habr.com/ru/companies/yandex/articles/978600/ который в 10 лабал игры на машинном коде, я сам этим занимался в 14, могу подтвердить это реально).
Проблема была и остается в целепологании, уровне зрелости и понимании домена.
А теперь та же самая ситуация, только этот же механик увидел марсианский корабль в возрасте 7 лет (т.е. отнимем у него знания, умения и опыт с земными механизмах). Ему ваш инструмент будет абсолютно бесполезен.
Он может не осознавать необходимость если привык верить на слово своим догадкам и еще не сталкивался с последствиями такого подхода. У детей такое бывает, но даже тут ребенок ребенку рознь, и если у одного это есть, другой предпочел бы проверить свои размышления на практике
Проблема была и остается в целепологании, уровне зрелости и понимании домена.
А разве не в умении решать задачи? Ниже про это комент оставляли
Программирование можно будет освоить за день без курсов, когда решат эту проблему
Когда люди научатся формулировать свои мысли понятно для других. Эта статья отличный пример.
Тогда программисты будут не нужны. Будут повсеместные вайбкодеры (я, правда, не очень понимаю слово программист в современной интерпретации. Вот инженер - понимаю). А так, для четкости формулировок, нужно сокращать выбор слов. Эллочка-людоедка обходилась 33 словами. Так и появился прототип Си, видимо))).
Ну так спрашивайте, что конкретно непонятно в статье
А вот программистам и представлять не надо, в здесь все ровно так и происходит - программу вы можете запустить только целиком.
Совсем нет. Тестирование появилось одновременно с программированием, а сейчас тестирование очень развито, все части программы можно протестировать до запуска целиком.
Главная проблема - у вас нет гарантии, что вы действительно правильно понимаете, как все работает
Это скорее про заказчика, а не про исполнителя в классическом программировании для бизнеса: исполнитель понимает, а заказчик - не факт. А в вайбкодинге исполнитель - ЛЛМ, ЛЛМ - "понимает", а вот вайбкодер - не факт.
а из непонятного - почему вы не поменяете свой арсенал знаний и инструментов, которые держат вас в таких рамках, если видите эти рамки?
Совсем нет. Тестирование появилось одновременно с программированием, а сейчас тестирование очень развито, все части программы можно протестировать до запуска целиком.
Ну я конкретно про возможность ставить опыты над частями программы, а не просто про тесты. Если вы про юнит-тесты, то вот в другом комментарии писал, что это не то.
Это скорее про заказчика, а не про исполнителя в классическом программировании для бизнеса: исполнитель понимает, а заказчик - не факт. А в вайбкодинге исполнитель - ЛЛМ, ЛЛМ - "понимает", а вот вайбкодер - не факт.
Ну я и писал в начале статьи, что вайбкодер это заказчик. Но и действующим программистам ведь тоже довольно часто приходится изучать готовый код, и им нужно правильно понимать, как он работает. Да и свой код можно забыть
а из непонятного - почему вы не поменяете свой арсенал знаний и инструментов, которые держат вас в таких рамках, если видите эти рамки?
Применяю, я ж писал, что описанный в статье инструмент я использую на базе фейковой отладки
К сожалению, никакой REPL не поможет понять как работает готовый код в готовой системе сложнее здравствуй мира. Т.к. часто все построено не линейно. Т.е. понять как работает какой то кусок проблем нет, гораздо сложнее понять зачем он так работает и для кого.
Но и действующим программистам ведь тоже довольно часто приходится изучать готовый код, и им нужно правильно понимать, как он работает.
Не примите за хвастовство, но сильным программистам не нужно правильно понимать как работает код, для нас код работает однозначно + обычно код не пишут так, чтобы он содержал несколько смыслов. Те, кому приходится домозговывать код - либо только вступили на путь программиста, либо не являются таковыми. Лично мне, читать код без комментариев легче, чем с комментариями некоторых челов, которые не шарят в терминологии или пользуются айтишным жаргоном, чтобы выглядеть круто.
Те, кому приходится домозговывать код — либо только вступили на путь программиста, либо не являются таковыми
..либо они читают чужой код, написанный дебилом хз кем. На протяжении моих лет несметное число раз я думал «а вот там у них должно быть вот так — ну ведь не идиоты же они?!!» — но оказывалось, что таки идиоты.
(Сборка CSV-файла тупой конкатенацией строк, ломающаяся, когда внутри поля оказывается запятая — например, MyCompany, LLC — приветливо машет ложноножкой.)
Программирование можно будет освоить за 30 секунд, когда придумают нейросетевой интерфейс для загрузки информации/знаний в мозг (помните в Матрице)
у Маска эйдетическая память, с такой памятью я бы даже ассемблер мог бы за три дня освоить с нуля
Просто чел не понимает, что все с люди с рождения НЕ РАВНЫ. Не равны по физическим способностям, не равны по интеллектуальным. Просто как данность. В современной политкорректной культуре все это конечно отвергается, но факт есть факт.
Мне рассказывали про чувака, который до 41 года был лингвистом. Решил переключиться на программирование, довольно быстро дорос до уровня который позволил устроиться в Твиттер, да да тот еще старый твитор. Через неполных три года уже тимлид. И это после 40 Карл! В 40 многие программисты уходят на пенсию
Просто чел не понимает, что все с люди с рождения НЕ РАВНЫ
Как раз таки понимаю, но считаю что в будущем будут изобретены способы помочь отстающим догнать тех, кто впереди
способы помочь отстающим догнать тех, кто впереди
Зачем? Почему вы уверены, что этот "способ" не будет применяться наоборот, чтобы усилить тех, кто и так впереди, вместо того чтобы тянуть бесполезных отстающих?
в будущем будут
Скрытый текст
Скорее придумают, как тормознуть тех, кто умнее. Чтобы не оскорблять тупых.
А не к 65?
Ассемблер за 3 дня с нуля - вообще не проблема (там команд то до 500, и фреймворков нету), берешь pic1684, например и через час ты уже ассемблерист. Ассемблер в применении к конкретной архитектуре железяки - и за месяц можно замумукаться.
запомнить все команды != освоить язык
Словарный запас пятилетнего китайского ребенка - от 500 слов.
Возьметесь за три дня выучить китайский на уровне пятилетнего ребенка?
вы знаете что такое "эйдетическая память" ? с такой памятью - да, можно и 500 китайских слов за три дня выучить
причем здесь какая-то память? Выучив 500 китайских слов вы не заговорите на китайском и не станете понимать других китайцев на уровне пятилетнего ребенка. Просто выучив 500 команд ассемблера вы не напишите простейшую сортировку.
Нельзя научиться читать просто выучив буквы алфавита. Нельзя научиться писать художественные рассказы, просто выучив все слова языка.
Нельзя научится программировать просто выучив команды какого-то ЯП.
как причём ? в данной ветке это ключевая вещь! ветка началась с фразы "у Маска эйдетическая память, с такой памятью я бы даже ассемблер мог бы за три дня освоить с нуля". Такую память ещё называют "фотографической". Т.е. за три дня читаем все учебники по программированию на асме, со всеми примерами, даже не сильно вникая в написанное. Далее можно начинать писать программы, мысленно "перечитывая" нужный абзац или пример.
гугл говорит, что учебников по программированию на ассемблере существуют тысячи. За всю свою жизнь американец с феноменальной памятью Ким Пик запомнил более 9000 книг. О каких трех днях речь?
в статье есть фраза "Илон Маск в 10-летнем возрасте освоил за 3 дня BASIC, хотя курс был рассчитан на полгода". Какой в те годы был BASIC ? типа Спектрумовского ? По ассемблеру Z80 у меня была одна толстая книга, её можно прочитать за три дня, больше у меня ничего не было, но этого хватило освоить тогдашний асм до уровня написания демок, в т.ч. с векторной графикой.
Само собой книгой я пользовался постоянно, а с эйдетической памятью можно было бы просто прочитать её и подарить кому-нибудь.
Какие в те годы были курсы (да впрочем и сейчас). Полугодовой курс, преподающийся два часа в неделю? Это примерно 50 часов (как большинство курсов по программированию на онлайн площадках). Любой достаточно мотивированный человек может потратить по 16 часов в течение трех дней и пройти такой курс. Для этого не нужна феноменальная память. Правда, к сожалению, прохождение курса не делает его программистом автоматически. Как нас учили на педагогике: знания, умения и навыки - три компонента профессиональной компетентности. Полученными знаниями нужно еще научиться пользоваться, а потом достаточно длительно практиковать, чтобы умения переросли в навык.
гугл говорит, что учебников по программированию на ассемблере существуют тысячи. За всю свою жизнь американец с феноменальной памятью Ким Пик запомнил более 9000 книг. О каких трех днях речь?
Мне и одного описания команд хватило. (Других просто не было.)
Вот прям до этого про программирование ничего не знали, прочитали одну книгу и на ассемблере начали программы писать?
На BASIC до этого умел, на FOCAL, да. В 1980-е, знаете ли, выбора‑то особо и не было.
А ученикам я так говорю
Понимаешь, компьютер — это такой дебил, который очень точно, чётко и безошибочно выполняет все твои инструкции, но выполняет их дословно, и поэтому если ты ему скажешь «посоли суп солью из зелёной банки» — а в банке был сахар — то он «посолит» и не задумается. Да, а ещё он понимает только небольшое количество слов — вот словарик. И твоя задача — написать то, что ты хочешь, чтобы он сделал, понятным для него языком. Напишешь неправильно — сам виноват, что не продумал, как этот дебил поведёт себя в ответ на твою инструкцию — ведь это 100% можно было предсказать. Всё, ты научился программированию, теперь — твори.
И как прочитав описание команд вывести на экран цифру 1?
И как прочитав описание команд вывести на экран цифру 1?
012700 000061 104016 000000, а почему ви интересуетесь?
Я мельком посмотрел список команд, и там вроде нет команды "вывести на экран". Скорее всего вы использовали и другие знания, кроме этих команд. Например, куда именно надо записать какой-то байт, чтобы тот отобразится.
Я мельком посмотрел список команд, и там вроде нет команды "вывести на экран".
Потому что у другой модели номер EMT был другой. И описано это было в другой книжечке, которая шла в комплекте с комьютером.
куда именно надо записать какой-то байт, чтобы тот отобразится
В той же книжечке написано, куда.
А у вас никто не отбирает эти все учебники. Вот ваша внешняя эйдетическая память, всегда под рукой. Более того, она может быть еще и в электронном виде с удобным поиском и возможностью ctrl-c/ctrl-v. Наличие этого всего во встроенной памяти нифига не гарантирует ускорение поиска нужных фрагментов по сравнению с внешней памятью, пока не появится опыт, вместе с которым приходит и интуиция.
Как минимум, у неё скорость не та, что у биологической. Вы сейчас сравниваете, условно говоря, SSD с магнитной лентой в бобине. Да, внешняя память подойдёт для написания статей и книг, но не поможет вам в живой дискуссии или в иной ситуации, требующей быстрого реагирования.
Если она "мертвая" без опыта - нифига она не настолько быстрее. Одно дело - связь с ситуацией, и другое - поиск по объему. Я, например, знаю анекдотов, наверное, не меньше трахтенберга, но вспомнить специально смогу от силы десяток, а к месту сами всплывают в памяти. Так же и касательно специальных знаний - быстро в памяти они ищутся только индексированно, "к месту", а индексация идет через опыт. Нет опыта - толку от этой книжки в мозгу столько же, сколько от книжки на полке.
Я даже не хочу строить предположений относительно вашего личного опыта из анекдотов про Василия Ивановича и поручика Ржевского, а также многих анекдотов ещё похлеще, раз они у вас успешно проиндексированы.
Через личный опыт мы фиксируем в большей степени навыки, а знания можно приобретать и в чистом виде.
Что мы вкладываем в понятие "программировать"? Простейший ассемблер можно выучить реально быстро, и писать простейшие прошивки "если тут ноль - тут единица", иными словами, если нажали кнопку - тут зажгли лампочку, что покроет очень большую часть embedded. Это программирование? Вроде как да.
Конечно, родить БПФ на ассемблере без знания самого БПФ, вероятно, сможет один из миллиона - но это же не про программирование вроде.
в понятие программирование я вкладываю умение решить задачу, с решением которой ты ранее не сталкивался. Например, ты знаешь синтаксис циклов, оператор присвоения, знаешь как заполнить и вывести массив, но не видел ни одной сортировки ранее. Если при этом ты сможешь написать программу, которая выведет отсортированный массив, я буду считать это умением программировать. Значит ты освоил понятие, не просто выучил синтаксис.
Из собственных воспоминаний: я внезапно осознал, что понимаю что такое матрицы и как работают циклы, когда на курсах написал программу, заполняющую квадратную матрицу змейкой. С этого момента решение задач связанных массивами не представляло для меня проблем...
То есть умение программировать — это способность загуглить применение qsort() ?
не видел ни одной сортировки ранее. Если при этом ты сможешь написать программу, которая выведет отсортированный массив, я буду считать это умением программировать.
Программирование - это (упрощённо) умение закодировать заранее известный алгоритм. Умение самостоятельно разработать алгоритм зависит от твоих знаний предметной области.
Я бы скорее отнес умение закодировать заранее известный алгоритм к понятию "владение конкретным языком программирования". А вот программирование в моем понимании как раз умение самостоятельно разработать новый алгоритм
Я имел ввиду "заранее известный на уровне предметной области". Например, чтобы написать функцию умножения матриц, нужно знать, что такое матрицы и как их умножать. То есть, нужны знания предметной области или (текстовое) описание правил (формул) умножения матриц.
Придумыванием новых алгоритмов (кроме элементарных) занимаются учёные.
В статье имеется значительный смысловой разрыв между изначальным посылом (о программировании как таковом) и возможным подходом к освоению (программирование на конкретном языке программирования при помощи особых "продвинутых" средств).
Прежде чем садится за код, нужно решить много вопросов. Самое трудное, это понять, что нужно сделать, что нужно получить на выходе. Чаще всего, никто не знает, что получится на выходе. Программирование оказывается искусством. Искусством возможного. Нельзя иметь структуру, которая одновременно даёт малое время доступа и малое время для перестройки (этой самой структуры). А на самом верхнем уровне? Что делает система? Нет теории. Всё зиждется на неких подходах, технологиях и библиотеках.
Если, уж, очень интересно поговорить именно о программировании, как таковом, то следует взять какую-нибудь крупную задачу: склад, интернет-магазин, бухгалтерия. Интуиция подсказывает, что задачи, реализуемые в каждом случае будут всегда определёнными и ограниченными некоторым, может быть и широким, кругом вопросов. Что мешает реализовать ПО для каждого случая? Почему разные конторы реализуют свои собственные решения для этих задач? Почему, вообще, мы постоянно занимаемся решением одних и тех же задач? Вот краеугольный вопрос программирования!
Хотелось бы иметь готовый набор компонентов и собирать нужные приложения на лету. Почему не получается?
Эффективное программирование невозможно без теории. А она есть? Строго говоря, всё программирование можно рассматривать как работу с автоматами: есть состояния, входные воздействия, выходные воздействия, переходы из состояния в состояние. Марковские модели со скрытыми состояниями. Программирование — это процесс идентификации такой системы, то есть — восстановление скрытых слоёв. (В этом смысле, языковые модели ближе всего к такой концепции.) Вопрос архитектуры: какие автоматы, какие переходы, сколько слоёв. А ещё: грамматика. Только теория предписывает совершенно другое: на практике, мы используем существующий язык программирования (существующую грамматику), а в теории, мы должны создавать новую грамматику, специальным образом подходящую под решение задачи.
Наконец-то хоть один нормальный комментатор.
Я себе программирование представляю как проектирование роботизированного завода. На входе сырьё или запчасти, на выходе "товары" (изображения, файлы и т.п.). Проектировать можно каждый "станок" с нуля, а можно брать готовые станки (компоненты и библиотеки) и соединять их между собой конвеерной лентой. В последнее время почти все виды "станков" уже существуют и остаётся только поставить их в нужном порядке с нужными настройками. Т.е. раньше нужно было быть инженером, способным разработать каждый станок вручную, а сейчас бывает достаточно умения компоновать их в нужном порядке, не вникая как там внутри станка всё устроено.
Кстати аналогия с заводом даже лучше будет чем с автомобилем. Но суть остается та же. Даже если брать готовые станки, то попробовать изготовить на них нужную деталь лучше до того, как его поставили на завод. Чтобы не столкнуться с тем, что прочитал описание станка, сделал вывод что он может изготовить то что необходимо, а уже в процессе запуска всей линии оказалось, что не может. При этом внутреннее устройство станка знать действительно не обязательно
Factorio, т.е.
Тут правда есть разрыв, но он ожидаемый. Осмысление задачи и архитектура никогда не решались инструментами, а вот понимание того, что вообще делает код, вполне можно ускорить
Почему, вообще, мы постоянно занимаемся решением одних и тех же задач?
Ответ, как мне кажется, лежит на поверхности. Либо потому, что эту задачу до сих пор никто не смог решить в приемлемом(удобном) для использования виде. Либо за возможность пользоваться её решением хотят сильно много денег.
Почему, вообще, мы постоянно занимаемся решением одних и тех же задач?
Там выше человек написал почему. Люди не умеют формулировать свои мысли понятно для других. По этой причине придумали 100500 языков программирования, кучу стандартов, версий и расширений. Свободного кода полно, но 99% этого кода проще написать с нуля, чем пытаться понять и использовать.
PS
Автор не понимает, что сложность программирования именно в понимании существующих решений.
Т.е. "одни и те же задачи" давно решены, но разными людьми на разных "языках", отчево пробитса к самой задаче и понять её - по сложности равносильно написать её заново уже на своём "языке"?
Даже на одном языке, одно и то же решается раз за разом, так как существующее решение сложнее осмыслить и доработать, чем написать новое.
В ИТ не просто проблема, а катастрофа с пониманием. Представьте, что существует 100500 диалектов русского и мы пытаемся коллективно написать на нем понятный для всех текст. Именно это сейчас творится в программировании.
Эффективное программирование невозможно без теории.
Спасибо за отличный комментарий! Честно сказать, не могу с вами согласится. Много лет программировал, делал худо-бедно рабочие проекты (не станем говорить, что хорошие, но удовлетворяющие заказчика) с нолем теории. Более того, часто ее правильное применение нецелесообразно для "прикладного" программирования даже на сложных задачах. Есть области где да, это нужно. Есть проекты которые без правильно примененной теории превращаются в тыкву. Но давайте будем реалистами, это даже не половина от тех задач, которыми занимаются программисты (настоящие) по всему миру.
Нужно, Петька, всего лишь ответить на 3 чапаевских вопроса. Что делаем? Где делаем? Как делаем?
Почему, вообще, мы постоянно занимаемся решением одних и тех же задач?
Потому что у всех предыдущих реализаций есть один маленький, но фатальный недостаток!
Вся эта демагогия про тестирование двигателя автомобиля нивелируется успехами SpaceX и итеративной разработкой Старшип (и его двигателей) в частности.
нейросетка это хорошо, скриншоты текста это тоже хорошо, круче только голосовухи в мессенжерах, очень жаль что своими словами уже мало кто умеет. Но в сборе например НАСА тестирует свою SLS уже второй десяток лет. Сравните со Старшип. Они не доводят свой продукт до идеала на стенде, вместо этого пачка неконтролируемых бабахов в реальных полетах, и переделка после каждого. Причем часто переделка глобальная, архитектурная, чего НАСА позволить себе не может. Слишком дорого переписывать все тесты. Чистый аджайл в том виде, как он и должен был быть. А не у коучей и ангелов.
По сути тут TDD против итеративной разработки с интеграционным тестированием. И выиграло второе.
как бы вы немного не правы.
Каждая деталь старшип, в том числе и двигатели, тестируется сначала отдельно. Но и пробные запуски необходимы, потому что надо же протестировать сборку.
Ну то есть функциональные + юнит тесты и канареечные релизы, если на наш язык переводить.
да, тестирование на каждом шаге. Просто они провели условное ревью всех тестов по матрице и убрали некоторые дублирующиеся. А также сократили количество дорогих тестов, для которых требуются стенды, сравнимые со стоимостью запуска корабля.
Тут хохма вот в чём: стало возможно обвешать двигло 100 500 датчиков и видеорегистраторов, и при этом вся эта дребедень уже не весит как два «БелАЗа» (в отличие от 1950-х годов), поэтому тестировать можно всё в сборе прямо в процессе испытательного полёта, а взорвётся — так стенд не пострадает (ввиду отсутствия такового)
И это потому, что интеграционные тесты тоже важны. И тесты в реальной среде тоже. Без них, компоненты создаются и тестируются исходя из ложных представлениях о будущих рисках. Все переусложняется, к тому в ненужных местах. Тестируется с огромной перестраховкой.
NASA очень хорошо это проиллюстрировала. За дорого.
соглашусь, особенно про переусложнение. Ультра-дорогая водородная ракета, на 100% покрытая тестами, и стальная непокрашенная труба, собранная как будто на коленке, но превосходящая все, что было до нее.
P. S. NASA вполне это осознавала, потому и вырастили частников, с другими подходами к разработке.
Описание про возможность выполнить фрагмент кода - какое-то бредовое, т.к. чтобы в сложной системе что-то выполнять, система сначала должна построить с памяти сложный набор структур данных (композицию классов и т.п.) и вся эта сложная структура уже потом позволяет выполнять определенные "расчеты" над некоторыми данными. А если вызвать только "середину кода" без сотен тысяч строк подготовки, о чем может идти речь, о каком понимании, как эта середина должна сработать. Автор либо совсем новичок (не имел дела со сложными системами), либо просто фантазер в розовых очках.
Я ее сам не раз вызывал, и там от случая к случаю, сколько кода нужно подготовить. Когда реально много, тогда проще было отладку запустить, но это 30% от всего. А так бывают например функции, которые не принимают параметров, или принимают не сложные. Там я вручную заполнял переменные, которые потом использовал в вызове. И как я писал в спойлере, этот код может быть подготовлен автоматически, и не всегда для этого нужен будет ИИ (он как один из вариантов)
Такой инструмент облегчит работу с кодом, но не понятно, как он облегчит обучение программированию.
В целом средства разработки и так развиваются от написания кода на бумажке с последующим переносом на перфокарту к абсолютно интерактивному запуску кода без компиляции, но это не облегчает обучение программированию.
Я бы сказал что статья очень сложная. Ну да ладно опустим подробности. Я конечно не полноценный тестировщик, но на сколько я изучал java qa я видел что отдельные функции и классы можно тестировать отдельно от всей программы. Ну а изучение программирования это не такая сложность и изучить можно достаточно быстро 1-3 месяца + практика ~1 месяц. Это если 5 дней в неделю заниматься только изучением и практикой не менее 2-3 часов в день. Тут ещё одна штука что выучить всё нельзя а требования у всех разные, да доучить другое дело если уже много основы освоить на достаточном уровне. А вообще такие статьи тают пищу для размышлений. Да и вообще куда мы катимся со своими ИИ. Люди не знают как что работает, а уже с помощью ИИ что-то пытаются строить.
Впустую потраченное время на статью.
Освоить программирование можно за день. Под конец этого дня будешь писать программы расчета чего-либо. Ввод, обработка данных, вывод. Программируешь, есть рабочий результат. Цель выполнена?
Понятия не имею, сколько часов, дней, месяцев я потратил на программирование. В т.ч. с бесплатными курсами и с использованием LLM — не для вайб-кодинга, но в качестве инструмента. На каждом этапе, после завершения каждого крупного учебного проекта или интересной и сложной задачи, можно почувствовать, что ты что-то умеешь, что-то знаешь, многое понимаешь... Но впереди всегда остаётся непознанная бездна, перед которой ты — юный падаван, сделавший лишь совсем незначительный шажок.
Уверенности тех, кто заявляет, что программирование или хотя бы небольшой язык уровня Си можно выучить за 1/3/7/10/etc дней я могу лишь позавидовать. Блажен ум, что слишком мал для сомнений.
P.s. для какого-нибудь ЕГЭ за пару недель, думаю, освоить питон можно, чтобы полностью выполнить часть С.
Это всё полезно (и подкину в копилочку инструментов для реализации подхода: TTD – Time Travel Debugging в WinDbg, Reverse Debugging в GDB), но даже не близко к освоению программирования за один день – просто позволяет не тратить время на то, что вообще не помогает.
Upd: А ещё при наличии/использовании таких инструментов полезность курсов (или обучения с наставником) кратно возрастает. Человека можно не просто прогнать через быстрое решение типовых задач (чтобы он освоил все темы, которые ему понадобятся в первое время, и имел подходы к остальным), но и нащупать, где у него затыки, и откорректировать обучение на лету.
Смотря что называть программированием. А то ведь как в бородатом анекдоте:
— Я за полгода выучил русский язык. Пять тысяч слов.
И все они у меня тут — в з%пе!
Может для начала отсекатор лишних "бы" и предлогов написать для текстового редактора. Хотя, постойте, есть же проверка грамматики или простой промпт для бям - отредактируй мои сослагательные наклонения так, чтобы было понятно, что я уважаю время читателя. Но нет, жупел так жупел, - будем нарочито неряшливо писать, чтобы в чатджипитижении не заподозрили.
Похоже, автор новичок в програмировании как и я, и в плане неудобства тэстирования отдельных частей програмы я согласен. Но не понял, што понимаетса под "освоением програмирования". Ведь выучить синтаксис и понять основы можно за день. А штобы стать мидлом, надо решыть довольно много задач и набрать много опыта - если даже задачи будут идти подряд, то вряд ли это выдержыт мозг и хватит одново дня.
А вот то, што облегчило бы разработку в Visual Studio мне:
-шаг назад в отладке - удивительно, што это не стандарт. Сделал шаг вперёд - и всё, увидел изменение чево-то, но не других частей, шага назад штобы повторить нет. Соизволь перезапустить програму и доводить процес до этово места.
-принудительная компиляцыя: когда алгоритм на этапе разработки, не хочетса отвлекатса на стороннее. А именно - изменил што-то и теперь надо пройтись менять в других местах програмы. Пусть это будет добавление доп. параметра у функцыы. Или ошыбка несовпадения типа, потому што её изменил.
С принудительной компиляцыей можно было бы выполнить програму до нужново места. А если исполнение таки дошло до мест с ошыбкой, то там компилятор оставил бы прерывание процеса.
-запись ввода. При перезапуске програмы (т.к. шага назад нет, или сделал какое-то изменение) надо заново доводить процес до нужново места. Это не только ожыдание уже не раз произведённых вычислений и чтений из файла (достаточно подождать), но и ввод вручную, движения мышкой и нажатия. Лень для этово писать код воспроизведения в самой програме или использовать сторонние програмы записи и воспроизведения действий.
-паралельная версия кода: нередко бывает, што задачу можно выполнить разными способами и не ясно, какой будет производительнее и удобнее для глаз. Например, заранее выделить массив и сохранить в нём результат вычислений или же лучше вычисления делать лениво, по мере необходимости? Я бы писал и выполнял оба вариант одновременно, штобы легко сравнивать. Сделать один вариант, а потом переделывать ево под второй вариант - напряжно.
Отделять варианты с define - напряжно для чтения, код визуально усложняетса.
Радует, што в VS появились:
-внесений изменений в програму без компиляцыы, прямо во время отладки. Хоть работает и не всегда, но помогает в простых случаях.
-отладка частей кода, которые были выкинуты оптимизатором компилятора - совсем свежая штука. А то раньше с этим был "пук-среньк, ой извините"
-строка передающихся параметров програме прямо рядом с кнопкой запуска, т.е. не надо постоянно лезть в настройки проекта. Тоже новая фича, VS2026.
Вот бы ещё при отладке при просмотре внутренностей контэйнеров можно было сразу прыгнуть в ево конец клавишей End, а не держать PageDown.
А ещё штобы автозавершение кода и Ctrl+Z работали в строке поиска/замены... Мечты.
Про шаг назад - интересная мысль)
Не любой шаг обратим.
Любой, если использовать систему контроля версий.
Например?
mov ax, 1
mov bx, 2
add ax, bx
xor bx, bxРанее в коментах отметили Time Travel Debugging в WinDbg и Reverse Debugging в GDB - вы про них не знали, получаетса. И про Braid или другие игры с отмоткой времени назад?
Если записывать каждый шаг и делать снапшоты, то всё отматываетса назад.
Вспомнил, што TTD в Visual Studio таки есть, но за деньги (Enterprise) :)
Раз конкурентов с этой фичей толком нет, то почему бы и не подзаработать.
Есть такие системы. gdb это давно поддерживает https://www.sourceware.org/gdb/news/reversible.html
Другое дело что внешние эффекты...но там где внешние эффекты - по хорошему можно снапшоты делать.
Вы в тексте специально такую кучу ошибок совершЫли или у вас такой стиль общения?
Может ник все же правдивый
Спецыально - продвигаю улучшенный русский язык, присоединяйтесь.
продвигаю улучшенный русский язык
То ж олбанский!
К сожалению, похоже, но не оно. Жаргон падонков слишком сильно искажает язык и в ней нет какой-то системы.
Судя по нику - вы белорус - ЧЫК ЧЫРЫК )))))))))))))
Мне особо понравилось, что "программист не может тестировать программу, не запустив ее всю целиком". И дальше аналогия с машинами пошла.
А как это не может? Нельзя отдельные функции что ли протестировать? Да ну, бред какой-то. IDE позволяют и бряки ставить и пропуски и перескакивать вызовы, тесты тоже не вчера придумали.
Каждое поколение приходит с мыслью "вот сейчас сделаем инструмент и всё станет просто". Потом выясняется, что инструмент помогает, но думать всё равно надо самому
"А вот программистам и представлять не надо, в здесь все ровно так и происходит - программу вы можете запустить только целиком."
Уважаемый, aвтор, пожалуйста, изучите тему юнит-тестирования. Если к вашей программе не прилагается по 3-5-10 юнит-тестов на каждый её компонент, то вам лучше-таки потратить время на разбирательство с концепцией TDD.
Я даже в первых редакциях статьи хотел описать подраздел "почему юнит-тесты не про это", но потом вырезал его. Здесь же речь не просто о тестах, а именно о том, чтобы ставить опыты над разными кусками программы, для чего предназначены не юнит-тесты, а REPL, на концепции которого и основана статья. И в общем то ChatGPT тоже самое скажет, если спросить его, "могут ли юнит тесты заменить REPL?"
Ответ ChatGPT
Юнит-тест не может заменить REPL, потому что они решают разные задачи и служат разным этапам разработки:
REPL (Read-Eval-Print Loop) — это интерактивная среда для исследования, экспериментов и быстрого получения обратной связи. Она помогает:
попробовать идею без необходимости писать всю структуру программы;
исследовать поведение библиотеки или API;
вручную проверить результат выражения;
работать с неопределённостью и гипотезами во время разработки.
Юнит-тесты — это формализованные, автоматические проверки того, что программа ведёт себя ожидаемо. Они:
фиксируют поведение кода на длительное время;
автоматически проверяются при изменениях, предотвращая регрессии;
являются частью документации и защиты от ошибок.
Коротко:
REPL — это живой, исследовательский процесс. Он нужен, когда ты ещё не уверен, что и как должно работать.
Юнит-тест — это способ зафиксировать, что уже работает как надо, и убедиться, что это не сломается позже.
Поэтому REPL — это про познание, юнит-тест — про проверку и контроль. Одно не заменяет другое.
Как раз очень часто написать юнит для экспериментов как работает какой-то участок кода это вполне нормальное флоу. REPL в классическом понимании вообще странный зверь не совсем понятный для чего он - просто поддерживает контекст, а в том же юните у тебя весь контекст точно так же определённый да ещё и перед глазами.
Уважаемый автор, прочитав вашу статью я для себя лишь понял что разрыв между названием статьи и содержимым создал у меня очередное ощущение кликбейта. Если я ничего не понимаю в программировании, то вряд ли с использованием любых ухищрений и вспомогательных средств я смогу осилить хоть какое-то мало маски осознанный кодинг менее чем за год-другой. Статья звучит так как будто водитель со стажем 30 лет вождения пытается убедить человека который никогда не сидел за рулём - что вождение это очень просто. Но это не так. Человек который сидит каждый день за рулём не способен осознать как сложно это в начале пути. Особенно учитывая индивидуальные особенности мозга и восприятия мира у каждого из людей в принципе.
разрыв между названием статьи и содержимым
Да, статья может быть и интересная, но к заголовку "Программирование можно будет освоить за день.." не имеет отношения. От программиста требуется в первую очередь прочитать и понять ТЗ, и сообразить, какими средствами выбранного ЯП можно эти требования ТЗ воплотить в код. Вот раньше рисовали блок-схемы, отображающие алгоритм, реализующий требования ТЗ, еще без привязки к ЯП. Это умение за один день не освоишь.
Насчет разрыва названия и содержимого написал закрепленный комент
Чтобы рассказывать другим, как обучиться программированию, нужно сначала сделать это самому, уважаемый автор, иначе получаются вот такие вот статьи про отсутствие покомпонентной разработки)))
Для тех кто пишет что заголовок кликбейт и есть разрыв с содержимым в статье. Ну я понимаю что у каждого свои критерии освоения программирования, но заголовок раскрывается вполне конкретным тезисом в статье (ссылка ведет прямо на него, если кому-то нужен контекст).
...А программирование как раз и изучается опытным путем, путем экспериментов, и если есть способ проводить опыты в сто раз быстрее, то и программирование будет освоено в сто раз быстрее.
Вы можете соглашаться с этим или не соглашаться, и вообще посчитать это полным бредом. Но я и не против, пишите про это, пока что этот тезис вообще никто не прокомментировал и не процитировал даже
Что вы называете программированием?
Алгоритмические языки какие-нибудь? Прям вот высокий общий уровень? Тут на тот уровень заходили доли процентов от работающих программистов и читающих эту статью, формализованные языки эти и их сущности.
Прикладные программисты на железных компьютерах, те что с байтами работают? Тогда добро пожаловать в основы - типы данных, которые из этих битов можно сложить на конкретном железе и операции над ними - только там вы зависните на пару месяцев в лайтовом погружении и до конца своей творческой жизни при серьезном. Вам же жсоны перекладывать, т.е. и типы данных придется конвертировать, верно?
И это мы только по объекту манипуляции программы прошлись, мы до самого программирования даже не подходили, к алгоритмам, концепциям, воркфлоу, языкам, хранении, распределенным системам, организации работы и т.д.
Плюсанул карму автору, хотя и заголовок кликбейтный, но какая-то мысль интересная в статье есть. Ну и жалко, когда вот так вот в минуса загоняют человека.
в любом обучении быстрее бывает когда знакомишься с теорией, а потом экспериментируешь на практике. Поэтому такой подход к обучению, в котором делается упор именно на опыт и практику, не может ускорить процесс.
ничего не поменялось. Как был кликбейт, так и остался.
Илон Маск выучил не бейсик, а начальное руководство к компьютеру. И это означает только, что он его прочитал и запомнил(так вообще могут сделать единицы с особым видом памяти). Никаких практических знаний у Илона не было, он их "зарабатывал" уже отдельно, когда писал код. Про обряд программиста какая то лабуда. Если написали хелло ворлд, то вы уже прошли обряд программиста. Это такими программистами предлагается стать за один день?
Статья - один большой "рука лицо" блок.
Напомню:
Глубоко ошибается тот, кто думает, что изделиями программистов являются программы, которые они пишут. Программист обязан создавать заслуживающие доверия решения и представлять их в форме убедительных доводов, а текст написанной программы является лишь сопроводительным материалом, к которому эти доказательства применимы.
-- Эдсгер Вибе Дейкстра
А вот программистам и представлять не надо, в здесь все ровно так и происходит - программу вы можете запустить только целиком.
Дети познают радости TDD. Оказывается, для этого нужна какая-то приблуда в IDE, а грамотная организация рабочего процесса. Теперь заживём!
Илон Маск в 10-летнем возрасте освоил за 3 дня BASIC, хотя курс был рассчитан на полгода.
Тут вопрос "Сколько должно падать капель с неба, чтобы пошёл дождь."
Освоить программирование на уровне: введите x, введите y, вот результат их сложения я мог бы... ну допустим за час. Программу написал? Написал. Стал ли бы я после этого программистом? Очень вряд ли.
Кто знает, что именно он за три дня изучил.
Дети познают радости TDD. Оказывается, для этого нужна какая-то приблуда в IDE, а грамотная организация рабочего процесса. Теперь заживём!
Не TDD (я так понял, вы имеете ввиду разработку через тестирование), а Exploratory Development (исследовательская разработка). И по сути статья про то, что будущее за ней
Зря я вообще использовал слово "тестировать", надо было сразу начинать с "ставить опыты". Смысл вроде похожий, но на деле выходит что кардинально разный
я так понял, вы имеете ввиду разработку через тестирование
Да, я именно про него. Пишешь тест, запускаешь и вуаля, только часть кода работает. Можно даже отслеживание включить.
Что касается исследования. Лично я всегда открываю интерактивный интерпретатор для этих целей. Что делают люди с компилируемыми языками, не знаю, но наверняка не пропадают. Опять же, оно надо, когда работаешь с чем-то новым и незнакомым. Потом это всё становится ненужным.
Вообще, интересно конечно, как молодёжь с клиповым мышлением собирается программировать, когда хранение контекста в голове - очень важная часть профессии. А тут оказывается, проблемы с описанием функции.
Дочитал до:
> программу вы можете запустить только целиком
перемотал вниз, увидел, что уже заминусовали, порадовался за автора. Дальше читать не буду.
А если бы прочитали дальше, то поняли бы, что имеется ввиду не буквально "невозможно вообще", а что "возможно, но по цене сопоставимо с запуском целиком, либо близко к этому". И статья про снижение этой самой цены если не на порядки, то хотя бы в разы
Программирование - это чёткая логика. Нельзя - значит нельзя. Можно, но сложно - значит требует каких то накладных расходов и времени. Пишите нормально - и будут Вам плюсовать.
Можно зайти с другой стороны.
Как говорил один учитель "первоклашкам я могу сначала доказать, что земля плоская, потом доказать, что земля круглая, а потом - что я оба раза был прав". Но, я не первоклашка. Дойдя до первого бреда, дальше читать не буду. И, как показывает количество минусов к статье - другие читатели то же не первоклашки. Проявите больше уважения к читателям. И, да - это сложно.
Проблема быстрого освоения будет решена, когда как в фантастических фильмах в человека научиться загружать знания, дальше все... Сообщите, когда это произойдет:)
Братец, всё четко стелишь, я не понимаю че минусят!!!
Прочитал статью и улыбнулся. Прочитал комментарии и улыбнулся ещё шире. Знаете почему? Потому что я уверен, что здесь нет двух человек, которые сойдутся в том, что значит "уметь программировать".
Вам не кажется, что прежде чем что-то обсуждать, неплохо было-бы дать предмету обсуждения строгое формальное описание? Из 5 пунктов. Или из 555. Не важно. Важно , что только ответив положительно на все, можешь заявить - умею программировать!
Вот только кажется мне, что миссия невозможна. В смысле - дать определение. Но попытаться стоило. И это, в первую очередь, камешек в огород автора статьи.
Мне могут возразить - зачем описывать общеизвестные вещи? Пример из жизни. Все себе представляют, что такое радиатор системы охлаждения чего-либо? Процессора, к примеру. Но только к примеру.
Два человека сошлись в споре, какая функция радиатора основная - отвод тепла от охлаждаемого объекта или рассеивание полученного тепла в окружающем пространстве. Спорили страшно, с отсылками к термодинамике и теории проектирования. Каждый остался при своём мнении, убедить оппонента не получилось.
Тогда скатились к более частному вопросу - является ли теплопроводность материала радиатора важной характеристикой для его работы. И снова облом. Знаете почему? Они не уточнили, о каком собственно виде радиатора они спорят. И в каких условиях он работает.
К примеру, есть радиаторы, непосредственно охлаждающие объекта охлаждения, а есть охлаждающие теплоноситель, забравший тепло у объекта. И они могут КАРДИНАЛЬНО отличатся по материалу и конструкции друг от друга. Можно сделать радиатор теплоносителя из пенопласта:) При площади радиатора в 10 квадратных километров вы 1 ватт тепла точно рассеете :) А ограничение по размерам и массе никто не оговаривал, да :) И да, основная функция - рассеивание тепла.
Не надо надеяться, что "это всем известно". Не поленитесь уточнить граничные условия - и не придётся писать километры слов.
Как-то так.
Для тех кто пишет что заголовок кликбейт
Кликбейт заголовка усилен неграмотностью ("не причем").
Залихватская манера не настраивает на вдумчивое чтение.
Неизвестно кто написал неизвестно что неизвестно зачем. Все в духе истинного хабра.
Люди говорили - будет репл, настанет счастье. И вот репл есть, а счастья нет.
Во-первых, проблема масштаба. Тесты разных уровней - от юнитов до нагрузочных и даже бета-тестирование и постпродажное обслуживание со снятием телеметрии - позволяют худо-бедно покрыть большой спектр разных сценариев и опять же разных уровней - от отдельных деталек до всей системы, и от отдельных моментов (вызовов конкретной функции) до длительной работы.
Что может покрыть отладка с помощью репла? Очень немногое. Отдельные моменты в работе, пусть и длительной. В примере с автомобилем: взяли и на ходу однократно поменяли клиренс. Перескочили через конкретную кочку. Перед следующей кочкой снова будем останавливаться и менять? Ок, поменяли клиренс навсегда. А весь предыдущий маршрут мы проехали со старым клиренсом, и что там было бы, мы не узнаем, пока не перезапустим весь тест-драйв с нуля с новыми настройками.
Во-вторых, проблема взаимодействия с реальным миром. В первую очередь, с реальным временем. Любые остановки под отладчиком останавливают внутреннее время программы, но не останавливают внешний мир. Клонирование состояния не клонирует мир. Реплика может оказать существенное влияние на работу оригинала. Вот вы ехали на машине по треку, решили поменять клиренс, поставили на трек вторую машину с новыми настройками. И через круг влупились в первую машину, оставленную там техниками.
Ну и про ненавистные логи. Это один из способов снятия телеметрии. В некоторых случаях - единственно возможный. По двум причинам:
минимальное вмешательство в течение времени (наносекундные задержки)
невозможность живой отладочной сессии (в продакшене у клиентов, например)
Не значит, что репл отстой. Не отстой, но и логи не отстой.
А научиться говнокодить на васике за три часа - не бог весть какой достижение, любой вундеркинд так сможет. Сможет ли вундеркинд охватить пониманием работу всей системы - вот вопрос, который дифференциально диагностирует программиста от кодерка.
Те же автомобильные двигатели проектируют не просто так, а ради определённых машин (а машины проектируют ради определённых двигателей). Чтобы и под капот влезло, и трансмиссию не порвало, и сколько жрёт и сколько прёт в допусках, и сколько выхлопа тоже в допусках. И стоимость изготовления и техобслуживания тоже. И если программист говорит "это головная боль не меня, а архитектора", то это не программист, а кодерок. Даже джун должен задасться хотя б туманными вопросами и обсудить с тимлидом в рамках своего фронта работ.
Ну и наворотил.
Плохая аналогия - это как котёнок с дверцей.
В программировании "тестирование отдельных узлов" не имеет смысла на фундаментальном уровне, потому что сам принцип работы узлов контекстуален по своей природе.
Каждый день в айти пишутся сотни программ, все отдельные узлы которых работают совершенно идеально в изоляции друг от друга. А в сумме, в итоговой программе они дают ошибки.
Если бы в автомобиле корректность работы двигателя определялась бы по-разному в зависимости от того, какой текущий уровень заряда аккумулятора, фиг бы стало возможным производить его компоненты на стендах независимо друг от друга.
Целая статья ни о чем из-за непонимания сути на базовом уровне.
На мой взгляд автор неверно определил причину почему не каждый сможет программировать без обучения. Да и не каждый с обучением. Точнее с его попыткой. При программировании надо четко представлять себе причинно-следственную связь, иметь алгоритмический тип мышления. Как показала практика - таких людей хоть и немало, но они явно не большинство. И даже нейросети не помогут исправить этот момент - человек просто не сможет описать то что он хочет так, чтобы его поняли. Например задание "сделай мне поле сереньким" никак не вяжется с пониманием того, что поле должно быть заблокировано от изменений. А если при этом ещё есть и условия, которые wibe-программист посчитал ненужным указывать - то работа такой программы станет вообще непредсказуемой.
Программирование можно будет освоить за день без курсов, когда решат эту проблему. И нейросети тут не причем