Некоторое время назад я высказал предположение, что проблемы С++ настолько глубоки, а процесс принятия решений комитетом настолько медленный, что доработки в С++ не в состоянии успеть за скоростью развития отрасти Ахиллесова пята C++ и будущая р̶е̶ эволюция / Хабр.

Конечно, я не считаю, что С++ будет забыт, но с большой долей вероятности ему будет уготована нишевая роль, как сейчас это произошло с языком С, которому С++ и пришел на замену. Причем я предположил, что способ плавной замены С++ на какую то альтернативу должен происходить точно также, как сам С++ пришел на замены старому С, через транспрлайтер (sourse to source translation).

А недавно я в очередной раз решил попробовать использовать LLM при работе с большими проектами и старым легаси кодом и нужно было протестировать новые моделей в каком нибудь крупном проекта (но, чтобы это был не продуктовый код). Поэтому мой собственный проект языка программирования в виде трансплайтера оказался вполне достойным вариантом для оценки возможностей современных нейросетей на крупном проекте, таком как компилятор языка программирования. И эта статья - мои наблюдения и впечатления от использования LLM на большом и сложном проекте.

C++ has trapped itself in an evolutionary dead end due to backward compatibility and UB, and the only realistic successor capable of displacing it in large codebases will be a transpiler that generates C++ and enables gradual, low-risk adoption.

Это перевод на английский язык статьи моей статьи Ахиллесова пята C++ и будущая р̶е̶ эволюция

Недавно я опубликовал мнение о фундаментальной экономической модели разработки ПО, которая не способствует (и объективно не должна способствовать) массовому переходу с C/C++ на «безопасные» языки программирования Экономика безопасности кода или почему Rust не нужен.

Но чтобы оставаться честным перед читателями, решил опубликовать и статью-контраргумент с описанием обратной стороны медали, то есть почему C++ всё равно будет рано или поздно заменён, а заодно попробовать разобрать, каким будет новый язык программирования, который неминуемо придёт на смену C++.

Прочитал статью Параллелизм с общим состоянием в Rust и обратил внимание, что её общий смысл можно выразить известной фразой: “делай как нужно, а как не нужно, делать не нужно”. Другими словами, это точно такой же совет, какой можно дать разработчику любого другого языка программирования, например С++.

И решил не продолжать дискуссию в комментариях, а написать отдельную статью с кратким описанием фундаментальной экономической модели разработки ПО, которая не способствует (и объективно не должно способствовать) массовому переходу с C/C++ на «безопасные» альтернативы. Так как из-за особенностей распределения затрат у разработчика ПО отсутствует экономическая мотивация к полному устранению ошибок, и как следствие - к переходу на использование «безопасных» языков программирования.

Со мной случилась ситуация, в которой особенно неприятно признаваться. Хоть я и технарь с опытом работы в ИТ, включая информационную безопасность, но какое-то время я был действительно уверен, что разговариваю с сотрудником Социального фонда России (СФР).

Уверен настолько, что после окончания разговора я уже начал делать черновик гневной статьи для Хабра: что бизнес‑процессы СФР (т.е. фактически самого государства) обучают людей быть удобными жертвами мошенников.

Потому что всё выглядит как обычная бюрократическая рутина, а значит мошенникам остаётся только изменить один единственный кусок пазла… Однако вся ирония в том, что пока я писал черновик разгромной статьи, до меня дошло: а ведь это реально были мошенники!

После этого я уже писал заявление в полицию, а потом пришлось переписывать и саму статью, но уже не про «как плохо устроен бизнес‑процесс в СФР», а про ещё один рабочий сценарий социальной инженерии, который звучит слишком правдоподобно даже для неплохо подкованного ИТ специалиста.

В ИТ есть странная форма «информационной инерции»: когда фраза однажды удачно легла на реальность, стала цитатой, превратилась в маркер «своего» - и дальше продолжила жить сама по себе. Реальность уехала, практики сменились, инструменты стали другими, экономика разработки перевернулась, а штамп формулировки остался. И особенно охотно её повторяют те, кому нужно писать быстро и убедительно, но нет времени (или компетенции) разбирать в технических деталях.

И проблема не в том, что старые тезисы изначально были бессмысленными. Проблема в том, что их продолжают подавать как вечные законы природы - без даты, без контекста и без поправок на то, что индустрия в корне изменилась.

Например, фразы про “серебряную пулю” и "небезопасный С++ ", которые звучат почти в каждом популярном тексте о разработке и безопасности, и оба часто переворачиваются так, что становятся откровенной неправдой.

Решил на днях приобрести корпус для апгрейда компьютера. И выбор пал не на интернет-магазин массовой торговли, а на обычный офлайн-магазин DNS, так как цены на его отдельные товарные позиции дешевле, чем в Озоне, более чем вдвое. Тем более в нашем городе получать товар в Озоне или Валдберис нужно идти ножками в ПВЗ и нести его домой самостоятельно, а у DNS есть доставка до двери.

И все было бы хорошо и не было бы текущей статьи, если бы я не выбрал "доставку курьером" и способ оплаты "по карте при получении товара". В результате меня чуть не развели как лоха.

Точнее, это я думаю, что меня попытались развести, а на самом деле, может быть, никакого развода не было, и это пошла такая тенденция - прикрываться якобы блокировками интернета, предлагать непонятные и крайне сомнительные способы безналичной оплаты.

Развивая идею доверенного языка программирования я пришел к выводу, что за счет ограничений синтаксиса и создания соответствующих проверок в статическом анализаторе кода, можно защититься практически ото всех технических ошибок, кроме двух - контроль динамически выделяемой памяти и переполнения стека.

Причем, если для подсчета ссылок в рантайме, решения существуют, то контроль переполнения стека невозможно сделать не только во время анализа исходного текста программы, но это практически невозможно и во время выполнения приложения! Ведь ошибка переполнение стека (stack overflow) - это всегда фатально, так как не существует способа поймать и обработать эту ошибку изнутри выполняемой программы, чтобы потом продолжить её выполнение как ни в чем не бывало.

Существует ли хотя бы теоретическая возможность защититься от ошибок переполнения стека и сделать из нее обычную ошибку (исключение), которую можно поймать (обработать) в самом приложении, чтобы была возможность продолжить выполнение программы без боязни последующей ошибки сегментации (segmentation fault) или повреждения стека (stack smashing)?

Недавно написал статью о проблемах использования ИИ (Иллюзии Интеллекта) при разработке программного обеспечения / Хабр, и решил не ждать у моря погоды, когда (и если) провайдеры исправят ситуацию на своей стороне, а попытаться самостоятельно выработать приемлемый алгоритм работы с ИИ, который был бы экономически выгодным и целесообразным при разработке ПО хотя бы лично для меня.

Данная статья - это очередной Хабрахак с подведением итогов и получением обратной связи об использовании ИИ-помощников при разработке программного обеспечения с примерами кода и итоговыми выводами о целесообразности использования ИИ в том или ином проекте.

А также поделюсь неожиданным инсайдом, который я случайно обнаружил в процессе работы над ИИ-кодом, который будет очень полезен матёрым программистам, которые до сих пор скептически относятся к использованию ИИ в своих проектах.

Меня часто поражает, как технически грамотные люди спорят, есть ли у LLM интеллект или это всего лишь математические вычисления по определенному алгоритму без зачатков разума. И что самое интересное, иногда оппонентами в споре за наличие интеллекта у генеративных нейросетей выступают люди, которые таким образом рекламируют свое IT-решение, не понимая, что тем самым они только создают себе проблемы.

Ведь создавая рассуждающую иллюзию интеллекта, разработчики фактически ставят крест на возможности какого-либо реального применения подобных решений в серьезных задачах, так как имитация разума превращает потенциально полезный рабочий инструмент в игру на бубне без каких-либо гарантий качества и воспроизводимости полученных результатов.

Появление электрического света фундаментально изменило сам ритм человеческой жизни, который тысячелетиями был привязан к солнечному циклу. Поэтому неудивительно, что электрическое освещение стало не просто изобретением, а «локомотивом», который проложил путь для повсеместного внедрения электричества.

А еще производство электрических лампочек породило один из хорошо задокументированных картельных сговоров, направленных в первую очередь на ограничение срока службы ламп накаливания, что сформировало концепцию «запланированного устаревания».

А работает ли концепция запланированного устаревания в отношении современных LED-лампочек?

Уважаемая администрация ресурса Хабр!

Сделайте пожалуйста возможность банить индивидуальных пользователей в комментариях по тому же принципу, как вы это сделали для публикаций на сайте!

Сейчас при элементарной генерации текста с помощью ИИ (Имитацией Интеллекта), этот самый интеллект пропадает у отдельных пользователей, что доставляет не только моральные страдания остальным читателям Хабра, но и вызывает серьезное раздражение портянки LLM шлака в комментариях к статьям.

А если вы добавите в профилях всех пользователей, кроме значений Кармы и Рейтинга, еще и подсчет количества Банов (у скольких пользователей текущий человек находится в черном списке), то это будет супер полезная информация в самом начале дискуссии.

Заранее спасибо за обратную связь и надеюсь на скорую реализацию подобного функционала!

Статья о небольшой эпопее с поиском ошибки в работе WiFi на плате ESP32-C3 SuperMini, с которой пришлось разбираться в процессе отладки кода прошивки для контроллера батареи АКБ (О контроллере батареи ИБП (вопрос к читателям Хабра) и О контроллере батареи ИБП (часть 2)).

Симптоматика проблемы с WiFi следующая: после включения питания и начала авторизации по WiFi плата ESP32-C3 SuperMini через какое-то время зависает, вплоть до срабатывания сторожевого таймера. Поиск решения проблемы в интернете не помог, но было замечено, что в эти моменты на плате очень сильно нагревается стабилизатор напряжения 3.3V, да так, что даже рука не терпит, тогда как при работе тестовых примеров (где WiFi работает нормально) такого эффекта не наблюдается.

Из-за этого решил копать именно в этом направлении.

Пару лет назад я написал статью "Размышления о структурном программировании", в которой пытался разобраться с заблуждением, будто Эдсгер Дейкстра доказал, что любой алгоритм можно построить всего из трех конструкций (следования, ветвления, цикла).

А вот теперь настало время написать про некоторые проблемы машины Тьюринга - фундаментальной основы всех информационных технологий.

Ошибки при составлении программ для ЭВМ появились даже раньше, чем были придуманы самые первые языки программирования. Собственно, языки программирования и были придуманы как раз для того, чтобы программы писались проще, а количество ошибок в них было как можно меньше.

Для уменьшения количества ошибок было разработано множество методов, включая создание специализированных инструментов анализа исходного кода и даже целых языков программирования.

Но по прошествии многих десятилетий проблема чисто технических ошибок в программном обеспечении так и остаётся нерешённой по сей день, однако подход, предложенный в языке Rust, меняет всё.

Когда копии товаров твоего изготовления начинают продавать под видом оригинальных на маркетплейсах продавцы из Китая, то втайне ты немного доволен. Раз твой товар копируют, значит, он пользуется спросом, и ты все делаешь правильно. Вот только продавцы контрафакта забирают твои же продажи, чем сокращают и так небольшую возможную прибыль, и это если не будет недовольных покупателей. А ведь человек, купивший контрафакт, может поставить минус не только неизвестному продавцу из Китая, но и начать писать негативные отзывы и про оригинальные товары бренда!

Поэтому, когда один из покупателей написал, что под видом нашей продукции продаются китайские подделки, пришлось быстро реагировать на возникшую ситуацию. И самое первое, что советуют делать юристы в таком случае, - это как можно быстрее зафиксировать сам факт подобного нарушения и лишь только после этого начинать писать претензию продавцу или в поддержку маркетплейса.

Данная статья о том, какой многоходовый квест нужно пройти для того, чтобы получить на руки юридически значимую доказательную базу факта нахождения в сети Интернет определенной информации. В моем случае это подтверждение факта продажи контрафактного товара на маркетплейсе, что может потребоваться для возможных будущих судебных разбирательств с продавцом контрафакта или с самим маркетплейсом, если последний будет покрывать подобных недобросовестных продавцов.

Прочитал статью Программисты против вайбкодеров и решил поделиться собственным опытом вайб-кодинга, но уже без рекламы ТГ-каналов и бесполезных цитат авторитетных источников. Пока писал, появилась еще одна статья Революция вайб-кодинга отменяется, но уже с противоположным мнением.

Но теория без практики так и остается теорией, именно поэтому мне и захотелось рассказать о практическом применении вайб-кодинга в реальном проекте с конкретными фактами, а не маркетинговыми лозунгами.

Эта статья - подведение итогов небольшого эксперимента (над собой) по использованию вайб-кодинга в С++ проекте, что для программиста с 30-летним стажем работы стало практически вызовом и серьезным выходом из зоны комфорта. Но сейчас все проблемы решены, и в соответствии с Хабрахаком я решил оформить полученные выводы в письменном виде для их систематизации, а заодно и для получения обратной связи.

Считается, что на конференции лучше всего запоминаются первое и последнее выступления. И тут я не являюсь исключением, так как при посещении С++ Zero CostConf 2025 мне сильнее всего запомнились как раз первый и последний доклады, но думаю не только из-за эффекта края, но и по той причине, что они были для меня самыми интересными и именно ради них и я решил съездить в Москву из далекой российской глубинки.

Но мне не хочется писать про само мероприятие, тем более, что видеозапись всех выступлений выложена на сайте конференции C++ Zero Cost Conf 2025 и пересказывать технически детали докладов не имеет смысла.

Однако прошедшее мероприятие было очень необычным и запоминающимся: мне удалось попробовать себя в роли вайб-кодера, а по результатам общения с докладчиками — написать два предложения в комитет по стандартизации C++ от России. Поэтому я всё же решил поделиться с читателями «Хабра» своими впечатлениями от некоторых докладов конференции и собственными выводами о вайб-программировании.

О сколько нам открытий чудных
...

Судя по результатам голосования и комментариям к предыдущей статье, к вопросу контроля АКБ у самых простых ИБП есть некоторый интерес. Данная статья - продолжение данной темы.

Сейчас прототип собран на макетной плате (токовый шунт к которому подключено два АПЦ). Измеритель напряжения и тока INA3221, как рекомендовали в комментариях, я решил не использовать, так как дискретность его измерения 8мВ сравнима с дискретностью 12-ти битного АПЦ в обычном микроконтроллере (для ESP32 получается точность измерения около 6мВ).

Среди ИТ специалистов ходит анекдот, что системные администраторы делятся на 10 категории, на тех кто пока не делает бэкап, и на тех, кто уже делает резервное копирование данных. А так как самой частой причиной отказов в ЦОДах является – сбой электропитания, то обеспечение надежного электрического питания для компьютера (да и для любой другой цифровой техники) является наиглавнейшей задачей.

К сожалению, большинство простых (офисных) источников бесперебойного питания выпускаются либо вообще без возможности дистанционного/автоматизированного контроля его состояния (только звуковое оповещение), либо имеют подключение по USB с собственным протоколом связи и проприетарным приложением, которое обладает самым минимумом функций (наверное маркетологи таким образом ненавязчиво подталкивают потребителей к покупке более дорогих моделей своего оборудования).

Но даже при наличии связи с ИБП, информация о его состоянии батареи бывает, мягко говоря, противоречивая, а информация о температуре внутри ИБП и вовсе отсуствует. И даже на более дорогих моделях может не отслеживать некоторые важные параметры работы источника бесперебойного питания, в первую очередь, состояние его аккумуляторной батареи.

И особая сложность возникает, когда дома используется сразу несколько бесперебойников, ведь следить за их состоянием приходится самому, тогда как сами устройства не очень дорогие, как правило не имеют возможности дистанционного/автоматизированного контроля его состояния и находятся в разных комнатах.

Некоторое время настрадавшись с подключением UPS по USB с помощью проприетарных программ, я решил разобраться с данной проблемой кардинально - сделать простенький контроллер состояния батареи источника бесперебойного питания со стандартным протоколом связи ИБП, который бы подошел для любого типа и модели источника бесперебойного питания при использования дома или в небольшом офисе.