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

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

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

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

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

Это вторая статья об использовании LLM в проекте разработки компилятора языка программирования как транспилятора в код на C++. Я продолжаю историю и хочу рассказать о своих наблюдениях и впечатлениях от попыток применять автономных агентов в большом и сложном проекте. А также о навязчивой рекламе и встроенных «закладках» в коде некоторых инструментов, которые, похоже, целенаправленно ухудшают работу с моделями конкурентов.

Некоторое время назад я высказал предположение, что проблемы С++ настолько глубоки, а процесс принятия решений комитетом настолько медленный, что доработки в С++ не в состоянии успеть за скоростью развития отрасти Ахиллесова пята 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, меняет всё.

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

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

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