Последние недели я размышляю о низкоуровневом программировании. Читаю, изучаю, анализирую. Это видео стало крайней точкой, и я решил написать эту статью.
Описание проблемы
Я получил профильное техническое образование. В моей стране это бакалавриат компьютерной инженерии. Формально, я должен знать как низкий, так и высокий уровень. Но в связи с личной наклонностью к высокому уровню, со СДВГ (можете прочесть здесь), низкий уровень вводит меня в уныние.
Сегодня, на закате 2025 года, до сих пор можно встретить тех, которые советуют начинающим изучать программирование с C/C++, когда даже те желают заниматься беком. Есть те, которые получают профильное образование, разбираются с внутренностями компьютера, изучают алгоритмы и структуры данных. А есть те, которые программируют. Без универа, без технических знаний, и создают величайшее искусство, даже понятия не имея, что такое бинарный поиск.
Эволюция
Я долго пытался решить для себя, кто же прав. Пытался нащупать центр проблемы. И мне кажется, что я нашел, а центром является эволюция. Программирование эволюционирует. И это касается не лишь языков или парадигм, но и вообще взгляда на него. 30 лет. Много или мало? Еще 30 лет назад, чтобы считаться хорошим программистом, вам обязательно было чуть ли не иметь машинный код своим родным языком, болтая с процессором на кухне за чашкой чая.
И наследие неизбежно. Есть программисты, которые начали свою деятельность достаточно давно. А еще, преподаватели. Те самые, которые застали все то время, и сегодня говорят: Hello World в одну строку? Не, дорогой, что-то тебя не в ту степь понесло. Ты сначала разберись с регистрами, а потом будешь на текст в консольке облизываться.
Да, я утрирую. Но ведь доля истины в этом есть?
Есть книжка небезызвестного в нашем кругу Страуструпа - "Программирование: принципы и практика использования C++". В этой книге автор резко негативно высказывается о желающих просто заниматься логикой, без погружения в технические детали (ВАЖНО! Это моя оценка его отношения).
Языкам программирования на развитие требуется некоторое время. 15 лет назад Python был эдаким языком энтузиастов. 10 лет назад он зашевелился, а сегодня Google имеет принцип: "Python там, где это возможно, C++ там, где вынуждены." Пока Python/Java/C# развивались, C++ себе был и использовался даже для небольших прикладных программ.
Как стать инженером?
Я делю тех, которые занимаются программированием, на 2 типа по виду деятельности, мышлению, знаниям и опыту: программисты (инженеры) и разработчики. Инженеры занимаются разработкой системного ПО: ОС, драйверы, инструменты, которые применяются разработчиками (библиотеки, API, движки).
Разработчики берут инструменты, созданные инженерами, и творят с их помощью.
Как писали в комментариях к видео, ссылка на которое было в начале, суть которых сводится к тому, что если рассматривать изучение программирования как таковое, которое начинать необходимо с низкого уровня, то "если ты хочешь открыть обувной магазин, ты должен сначала вырастить корову. Затем научиться выделывать кожу, а потом шить обувь. Создание своего велосипеда нужно начинать со сталелитейной компании. Ведь понимание того как создаются материалы поможет сделать материалы более высокого качества".
Я не говорю, что понимание низкого уровня плохо. Нет. Но начиная с низкого уровня, до решения реальных задач нужно потратить... А сколько же времени нужно потратить?
Бинарный поиск в книжках объясняется на логарифмах. Изучить и понять логарифмы несложно. Но:
Для хеш-функций и криптографии требуется теоретико-числовая арифметика и абстрактная алгебра;
Для эллиптической криптографии требуются конечные поля и теория групп;
Для оптимизации запросов в БД требуются теория графов, статистика и линейное программирование;
Для обучения моделей ML требуются математический анализ, линейная алгебра и теория оптимизации;
Для компьютерного зрения требуются проективная геометрия и вариационные методы;
Для компиляторов требуются формальные языки, автоматы и теория графов...
Одни хорошо учились в школе и могут осилить более сложную математику. Но и есть иные, которые дрожат от деления (особенно с дробями), которые не знают или вернее забыли математику даже на уровне начальной школы, которые не могут двигаться вперед без конкретных ответов. Не верите, что такие бывают? Я перед вами. И что нам делать? Потратить лет пять на изучение базы и тогда приступать к низкому уровню?
А для чего, когда есть библиотеки, разработанные гениями инженерной мысли? Когда есть открытый код, который постоянно оптимизируется? Когда есть языки с управляемым кодом, от которых не ожидаешь неопределенного поведения?
Знаю, что могут быть те, которые скажут: ваши пайтоны и сишарпы непроизводительны, и говорить не о чем. О C# я даже говорить не стану, Roslyn отвечает за меня. О Python, да, есть проблемы, не позволяющие создавать свои движки из-за несовместимости glue code и игровых циклов. Да и то я не уверен, если это нельзя решить, поскольку есть векторизация с помощью NumPy.
Итоги
Каждый должен заниматься своим делом. Мне нравится заниматься логикой приложения, не отвлекаясь на несущественное. Почему несущественное? Потому что я своими руками могу навредить больше, чем эффективно, что обеспечит управляемый код. Это существенно.
Меня такой подход пока устраивает. При том что вопреки некоторым мнениям крупные компании вполне охотно нанимают таких разработчиков, взять тех же Blizzard (как же как же, глядел я их вакансии, миленько). Сегодня рынку важен time to market, то есть, рынку все равно, если вы 10 лет будете писать свой низкоуровневый фундамент, результат нужен здесь и сейчас.
Правда откровенно говоря, иногда от незнания неуправляемых яп страдаю. Недавно столкнулся с ситуацией, когда на C/C++ были обертки, решающие определенные задачи в пару строк кода, когда на Python лишь низкоуровневые реализации. Но совместить это так и не смог, но это совсем иная история...
Поделитесь в комментариях вашим отношением к теме, затронутой в данной статье. Я с уважением отношусь к инакомыслию и признаю, что могу ошибаться.
Комментарии (0)
cofolunat
20.09.2025 01:06ИМХО, чем больше знаешь, тем лучше. Потом проще разбираться с любой новой технологией. У вас появится собственный взгляд на те инструменты и подходы, которые продвигают сообщества и возможность делать более осознанный выбор, а не просто бежать за чем-то хайповым. Не будет такой жесткой привязки к библиотеке, системе сборки и пр. Сможете заглядывать "под капот" ваших инструментов и библиотек. Но все это, если вам интересно ваше дело. Как и в любой прфессии.
nronnie
20.09.2025 01:06Без универа, без технических знаний, и создают величайшее искусство, даже понятия не имея, что такое бинарный поиск.
Я результаты этого "величайшего" искусства на работе разгребаю каждый день :((
apcs660
20.09.2025 01:06Принцип общий, независимо от рода деятельности - базовый кругозор, затем специализация.
30 лет назад было более чем достаточно высокоуровневых задач и не все долбились в машинных кодах, и на С можно вполне себе комфортно писать хорошо структурированный код похожий на объектный (поддерживать его труднее, это да, и сломать легко) но писать можно. На питоне можно такую портянку написать при желании (встречал) или на Java (встечал в консалтинге такие ужасы что можно помереть) - не каждый на С сможет такое создать. Высокая абстракция не запрещает создавать непонятные конструкции.
В реальных бизнес задачах алгоритмы не нужно разрабатывать - достаточно знать какие есть и правильно их применять (в виде коллекций и библиотек). С другой стороны, иногда возникает необходимость сделать какой нибудь троттлинг и тут как раз алгоритмическая база не лишняя - хотя бы на коленке сделать что то не работающее в сложности 2^N a хотя бы в N^2
Вот я, "жаба" программист с 25 летним стажем (и немного в других языках), сел и закрыл пробел с питоном этим летом (время появилось). Зачем? Для кругозора и для понимания процессов в ML/AI сообществе чтоб отслеживать их тектонические активности. Хотя меня уже тошнит от кодирования, пора бы на рисование кубиков переходить...
Lewigh
20.09.2025 01:06Языкам программирования на развитие требуется некоторое время. 15 лет назад Python был эдаким языком энтузиастов. 10 лет назад он зашевелился, а сегодня Google имеет принцип: "Python там, где это возможно, C++ там, где вынуждены."
Может быть Вы немного проспали но Google вместо "Python там, где это возможно, C++ там, где вынуждены." давно создали себе целый язык Go потому что видимо это не очень работала история c преисполнившимся за 15 лет Python.
Я долго пытался решить для себя, кто же прав. Пытался нащупать центр проблемы. И мне кажется, что я нашел, а центром является эволюция.Программирование эволюционирует. И это касается не лишь языков или парадигм, но и вообще взгляда на него.
Да я не спорю языки программирования эволюционируют потихоньку. Но по факту то что Вы описываете вывозит не их эволюция а эволюция железа и эволюция компаний по умению впаривать плохой софт.
Вы так описываете как будто ничего не поменялось и там где раньше нужны были знания и умения, сейчас все по волшебству само хорошо работает. Не работает. С каждым годом софт становиться все хуже и хуже. Эти проблемы закрывают в основном производители железа. Компаниям и пользователям все больше и больше приходиться платить из своего кошелька за все большую криворукость разработчиков. Нужно каждые n лет менять железо чтобы запустить банальный "калькулятор" или текстовый редактор. Компании это устраивает, у людей нет выбора.
Посмотрите на врачей. Зачем то учат по много лет анатомию, химию, каждую косточку тела, чтобы потом таблетки на приемах выписывать. Какая глупость да? А могли бы эволюционировать и не забивать себе голову такой ерундой. Или не могли бы? Разница в том что за свои ошибки врач будет расплачиваться сам а за ошибки и некомпетентность программиста в большинстве случаев расплачиваются пользователи, причем в прямом смысле.
Компаниям плевать на пользователей, им нужно тяп ляп и в прод чтобы конкурентов обскакать и впарить продукт людям у которые и выбора то нет. А потом гордые разработчики рассказывают как производительность не важна и как они балуются с новыми фреймворками и изощряются в абстракциях. По Вашему это эволюция? Ну не знаю...
Iliniel Автор
20.09.2025 01:06Вы можете привести практические примеры, пожалуйста?
Lewigh
20.09.2025 01:06Да что угодно, большинство web приложений, мессенджеры, фреймворки типа spring, IntelijIdea, Продолжать можно долго.
CrazyOpossum
20.09.2025 01:06Браузер жрёт 7гб в простое - десять лет назад это была бы вся моя память, пятнадцать лет назад я бы просто посмеялся.
По играм есть замечательное видео https://www.youtube.com/watch?v=WOQbEBcQ0bo. Есть спекуляции, типа плохой стелс не в стелс играх, но общий посыл - правда.
Каждые 5 лет новая волна жалоб на следующую версию windows. Спустя 20 лет XP всё ещё лучшая.
me21
20.09.2025 01:06Да и то я не уверен, если это нельзя решить, поскольку есть векторизация с помощью NumPy.
Это точно не перевод? "Если это нельзя решить" выглядит как калька с английского.
Jijiki
20.09.2025 01:06где-то в инете читал тоже такую тему, что надо знать из таких-то языков, и вобщем повторю частично, придётся знать С(и всю зависимость, это если разобраться) по другому сразу тогда (любой другой ЯП) алгоритмы/структуры данных, но по итогу истина по середине причем зная С/С++, что-то изучить проще
может быть даже сразу изучайте раст если вам нравится, всё равно по итогу вникать придётся во всё
Iliniel Автор
20.09.2025 01:06где-то в инете читал тоже такую тему, что надо знать из таких-то языков, и вобщем повторю частично, придётся знать С(и всю зависимость, это если разобраться) по другому сразу тогда (любой другой ЯП) алгоритмы/структуры данных, но по итогу истина по середине причем зная С/С++, что-то изучить проще
может быть даже сразу изучайте раст если вам нравится, всё равно по итогу вникать придётся во всёЗдесь скорее вопрос личного интереса и мотивации. Если ты мечтаешь разобраться, как работает процессор, тебе будет интересно. А если ты сайты хочешь делать, тогда такой метод приведет лишь к выгоранию.
Алгоритмы никто не отменял. Но вот я например, надо было мне разобраться, как работает экран, пиксели физические и логические, для решения конкретной задачи, я с большим интересом изучал. А с низу вверх...
AbitLogic
20.09.2025 01:06Начинать нужно с дискретной математики, теории алгоритмов, теории типов, основ кодирования, если мы говорим о практике то любой из системных языков - C, Pascal, Rust, C++, это база, мне ещё не встречался действительно сильный программист на Python, PHP или Java, обычно они варятся в какой-то своей проблематике, не способны определить сложность алгоритма, понять разницу между AoS и SoA, а от слов типа BWT-преобразование или коды Рида-Соломона падают в обморок
Iliniel Автор
20.09.2025 01:06мне ещё не встречался действительно сильный программист
Определите термины. Действительно сильный программист - это?
AbitLogic
20.09.2025 01:06Это в смысле прям академические знания, как пример знаю одного сеньора C#, который мне заливали что общение с моей платой должно выглядеть так - он делает коннект, отправляет мне пакет и делает дисконнект и каждый пакет так, что такое listen он знать не знает, ему надо было после каждого пакета рвать соединение, на сколько это сильный программист на ваш взгляд?
Я пытался разобраться почему ему так надо, выяснил что у него там деструкторы зовутся при всякой маршелизации, я даже не стал ворошить это осиное гнездо, закончилось что я просто написал ему dll и so, которые адекватно работают
Iliniel Автор
20.09.2025 01:06как пример знаю одного сеньора C#, который мне заливали что общение с моей платой должно выглядеть так - он делает коннект, отправляет мне пакет и делает дисконнект и каждый пакет так, что такое listen он знать не знает, ему надо было после каждого пакета рвать соединение, на сколько это сильный программист на ваш взгляд?
Я пытался разобраться почему ему так надо, выяснил что у него там деструкторы зовутся при всякой маршелизации, я даже не стал ворошить это осиное гнездо, закончилось что я просто написал ему dll и so, которые адекватно работаютВы определяете "силу" программиста по его способности решать системные задачи.
Но тот пример, который Вы привели, это не проблема отсутствия академических, как Вы сказали, знаний, а проблема неверного подхода того C# синиора к решению задачи. Ему надо было бы разобраться в причинах происходящего, вспомнить/разобраться, как работают TCP сокеты, как C# управляет памятью и неуправляемыми ресурсами. А что сделал он? Остался на своем уровне абстракции и придумал неэффективное "решение", которое просто работает в его искаженной картине мира.
Сильный прикладной программист не тот, который знает больше и из-за этого не допускает ошибок, а тот, который может загуглить "c# tcp socket keeps closing" и найти информацию про IDisposable, using и правильное управление жизненным циклом соединения. Сегодня с AI это так вообще делается за мгновения.
Большинство прикладных разработчиков не используют те же алгоритмы в сыром виде. Значит ли это, что они не нужны? Они должны понимать сложность алгоритмов не для того, чтобы применять ежедневно, а чтобы не написать случайно в коде цикл в цикле там, где это приведет к коллапсу системы при 1000 пользователях.
Поверьте, заказчику, если это не продуктовая компания, глубоко фиолетово, знаете вы упомянутые вами BWT-преобразование или нет, пишете код сами, или его вам приносит на блюдечке брат, сват, сосед или AI. Вы программируете, чтобы решить задачу заказчика, а не экзаменатора.
Я знаю сотни разработчиков, которые работают в геймдеве или вебе, и понятия о бинарном поиске не имеют. И производят результат, которым клиент доволен.
Программист на Python, который создал веб-сервис с миллионной аудиторией, не обязательно сможет написать драйвер. Это разные "виды силы".
old2ev
То что программирование эволюционирует и развивается не говорит о том что программисты должны останавливаться в развитии и стагнировать.
Если же говорить про минимальный приемлимый уровень понимания который должен быть у программиста/разработчика (не важно как вы его обзовёте, сути дела это не меняет), если этот человек имеет дело с императивными ЯП, то он должен хорошо понимать, что такое временная и пространственная сложность, в противном случае, то что он будет писать с большой долей вероятности будет неоптимальной хренью. Наобум склеить библиотечки вместе, чтобы на выходе получился "работоспособный" кусок логики сегодня любой очередняр может(а местами и вовсе ИИ справляется). Программисту/разработчику платят за его знания, за то что он разбирается как лучше, а не за то что он умеет читать доки и водить пальцами по клавиатуре, выводя любой бред который сможет пережевать компилятор.
Я не говорю что обязательно понимать как именно что-то работает под капотом(хоть это и не повредит), но обязательно нужно чётко знать особенности этого чего-то, а как результат при каких условиях это что-то оптимальней использовать.
Iliniel Автор
Развитие не лишь движение во внутренности. Это и движение (изучение новых фреймворков, архитектурных подходов, предметных областей) и "вверх" (от кода к архитектуре системы, к управлению проектом). Если Вы работаете/работали в компании, то быть может знаете, что в IT так бывает, когда в архитектора переходят из аналитики, иногда из QA.
Есть градации, такие как джун/мидл/синиор. Синиоры могут погружаться в платформу, но это не значит, что они даже знают информатику на высоком уровне.
old2ev
А я говорил что нужно развиваться только как вы выразились "вниз"? Вы где-нибудь это в тексте видели? Я акцентировал внимание на вопросе оптимизации только как о чрезвычайно проблемной области в нынешних реалиях, в виду того что всё чаще программисты отдают именно этот вопрос на откуп машине, совершенно не задумываясь об нём.
Используют раздутые неоптимальные фреймворки, когда достаточно мелкой библиотечки или и вовсем мелкой самописной функции с меньшими накладными расходаим и куда лучшей ассимптотикой алгоритма, применяют структуры данных не по назначению и т.д. и т.п.. Не счесть примеров подобных косяков, все из которых растут из банального незнания и нежелания бороться со своим незнанием т.е. учиться.
Я не говорил что не нужно учить фреймворки и библиотеки, я говорил что нужно знать их лучше и применять их в нужных местах, а не где и как придётся, как это всё чаще делается сегодня.
Вопрос архитектуры тоже будет не лишним, но именно для программиста куда важнее знать именно паттерны программирования, которые помогут ему лучше организовать его макароны.
Действительно бывает, и что с того? Мы же не говорим от том как быть архитекторм, аналитиком или тестером, при чём здесь это? Кажется мы затрагивали тему именно программистов и разработчиков, нет? Для всех специалистов разные требования, хоть и пересекаются в некоторых местах, но не стоит мешать мух с котлетами.
А что синьор должен знать? Только свою платформу? Завтра все перестанут её применять и этот узкоспециализированный "синьор" переедет со своими знаниями платформы на помойку.
Есть набор фундаментальных знаний, что позволяет человеку быстрее освоиться в любой среде и на любой платформе, поскольку эти знания общие для всей сферы программирования в целом, именно эти знания и отличают хорошего профессионала.
Iliniel Автор
Даже если человек погружен в низкий уровень, на то, чтобы разобраться в библиотеках, ему понадобится время. Если перед тобой стоит задача использовать более маленькую и возможно, производительную библиотеку, пожалуйста, сегодня есть AI, который проанализирует тысячи ссылок минут за 10 и даст результат.
Более того, если в тз или спецификации нет требования о маленьком размере бинарника, это не твоя забота, как разработчика.
Итак, каков смысл в том, чтобы тратить время на изучение каждой библиотеки внутри?
Time to market важен. И компания всегда заинтересована оставить не специалиста, который знает глубже, а того, который сделает быстрее и эффективнее. Компании не позволено держать зазнайку, который знает больше, а делает дольше.
Таким образом, постепенно специалисты делятся на тех, которые научились применять AI и на тех, которые не приспособились.
То же, что и с плюсами. Сайты на ассемблере делать можно. И делали. Пойди на рынок, заработай на этом...
old2ev
Какой к чёрту "низкий уровень"? Что вы заладили "низкий уровень, низкий уровень", базовое понимание как оценивать сложность алгоритма - это НЕ низкий уровень, это в нормальных колледжах и институтах должны учить на алгоритмах и структурах данных. Низкий уровень - это ассемблер или в крайнем случае Си для bare metal, даже C++ сложно однозначно причислить к низкому уровню с его механизмами абстракций. Единственное что вы демонстрируйте сыпя термином "низкий уровень" - это свою некомпетентность в вопросах программирования.
Проанализирует тысячи строк и даст результат? Да, вот только в этом результате с большой вероятностью будут баги, из-за которых куда больше времени уйдёт на отладку, чем ушло бы на само написание кода. ИИ инструментами нужно пользоваться чрезвычайно аккуратно, они могут за тебя написать какой-нибудь бойлерплейт, но стоит задаче хоть немного отойти от общего случая, то из ИИ тут же польётся полная лажа.
При чём тут маленький размер бинаря? Я говорю про сложность операций и накладные расходы, размер бинаря тут дело десятое.
Я понимаю, что тебе сложно это видимо даже представить, но прикинь, а можно ведь и быстро и оптимально, достаточно просто немного знаний и периодически включать голову. Но да, это ведь таааак сложно, не так ли?
Не спорю, вот только нужно понимать, что тебе ИИ высрал, по хорошему разбирать каждую строчку отдельно, а не в тупую копировать всё в IDE надеясь что это заработает, в противном случае единственный результат на который тебе стоит надеяться - это то что ты капитально окретинешься, не более.
При чём тут это? Что это вообще за ахинея? Я разве предлагал применять инструменты не по назначению?