🎓 Бесплатные онлайн-курсы для IT-специалистов от Selectel
Совместите обучение с возможностью попробовать нашу инфраструктуру. Выбирайте один из четырех курсов, чтобы сделать первые шаги в профессии или прокачать знания в том, что вы уже умеете.
Системный администратор Linux с нуля. Научитесь работать с командной строкой и основными утилитами Linux, управлять пользователями и файлами, настраивать сети и устранять инциденты.
Погружение в PostgreSQL. Изучите основы реляционных баз данных. Научитесь создавать и связывать таблицы, добавлять, модифицировать и удалять данные.
Первые шаги в JavaScript. Освоите базовый синтаксис, научитесь писать скрипты, управлять DOM и изменять интерфейс веб-страниц. В конце сделаете свой первый пет-проект.
Тестирование мобильных приложений. Научитесь проверять мобильные приложения с учетом специфики разных платформ. Освойте работу с API, логами и трафиком на эмуляторах и реальных устройствах.
Все курсы состоят из текстовых уроков. Можно изучать их в своем темпе, дедлайнов нет. В рамках курсов по тестированию и JavaScript вы получите промокоды и получите возможность потренироваться на нашей инфраструктуре бесплатно. Кроме того, для проверки знаний есть тесты и задания, а в конце обучения мы выдадим сертификат.
Тихий враг или молчаливый союзник: коротко о выравнивании в C++. Часть 2
Казалось бы, тайна выравнивания раскрыта. Вы победили невидимого врага — невыровненный доступ. Память под контролем, но производительность по-прежнему шепчет: "Есть ещё нюансы". Что? Нюансы? Какие? Пришло время посмотреть, что происходит, когда структуры начинают наследовать друг друга. Здесь всё становится... интереснее. Правила игры меняются.
Итак, путь ясен: мы погружаемся в мир наследования, чтобы услышать его диалог с памятью. Давайте сразу к делу. Приготовьтесь, правила только что усложнились. В статье поговорим о выравнивании, наследовании POD-структур и множественном наследовании.
Представлено Duolingo для кодеров — Coddy. Это бесплатный проект, который превращает изучение программирования в залипательную игру. Внутри ежедневные задания, серии дней без пропусков, уровни и рейтинги, чтобы было интереснее не бросать. Можно писать код прямо в приложении на смартфоне или ПК. Всё синхронизируется между устройствами. Больше 15 языков программирования: от популярных Python и JavaScript до C++, Go, Rust и Lua. Есть отдельные направления по аналитике данных, ИИ и веб‑разработке.
Ребята, я сегодня релизнул cli-stash. Это TUI-утилита на Go + Bubble Tea для сохранения shell-команд в "избранном".
Пример использования cli-stash
Она решает простую боль: сложные команды (docker, kubectl, ffmpeg) постоянно забываются, а копаться в history каждый раз это страдание.
Что умеет:
Сохраняет ваши команды в избранном
Возможность добавить из истории шелла
Нечеткий поиск
Сортировка по частоте использования
И самое крутое, что команда вставляется прямо в терминал. Таким образом вам не надо ничего копипастить: нашел → выбрал → enter → команда уже в cli.
# Установка в Linux
go install github.com/itcaat/cli-stash@latest
# Сборка из исходников
git clone https://github.com/itcaat/cli-stash.git
cd cli-stash
go build -o cli-stash .
sudo mv cli-stash /usr/local/bin/
В macOS поставить изян brew install itcaat/tap/cli-stash
Исходники и инструкция по использованию есть на github.
_________________
Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩
HATEOAS и Hypermedia получают, на мой взгляд, недостаточно внимания. Подходы, которые описывал в докторской Рой Филдинг, всё реже трактуются в связке с HATEOAS.
Это удивительно, потому как слово REST в обсуждениях я слышу часто. Но только в формате “используйте HTTP глаголы для описания действий”. Или, еще хуже, как синоним HTTP JSON API.
Как же так? Как обсуждать REST без учёта концепции зрелости Ричардсона? Это тема, которая требует дополнительного обсуждения, ведь HATEOAS — высший уровень зрелости REST.
К чему я? Прочитал за два дня книгу Hypermedia Systems. Авторы до этой книги работали над HTMX.
Хоть и сталкивался с HTMX, книга помогла дополнительно прояснить, как HTMX соотносится с HATEOAS. Авторы представляют уверенную аргументацию, что простой HTML можно рассматривать как ключевой элемент реализации HATEOAS. И что SPA с раздутыми JavaScript-фреймворками для маппинга JSON API в HTML — тупиковая ветвь эволюции.
Книгу можно и последовательно читать, и использовать как справочник по HTMX. Она есть в публичном доступе.
Если Вы ещё не встречались с HTMX, HATEOAS, Hypermedia, и не знаете, что это такое, рекомендую всеми руками, объём достаточно небольшой.
Как говорилось в Герои3, астрологи объявили, что новых сеньоров не будет, мы последние
За 2023-2025 рынок entry-level позиций в программировании схлопнулся структурно, а не циклично.
• 🇺🇸 В США количество junior-вакансий упало на -67% за один год
• 🇪🇺 В Европе найм entry-level сократился на -73%, при том что весь рынок упал всего на –7%
• Занятость разработчиков 22-25 лет снизилась на –20% с конца 2022
• Безработица среди выпускников computer science в 2025 - 6.1%, хуже, чем у философов и биологов
• AI автоматизировал именно те задачи, на которых раньше учились juniors: boilerplate, тесты, базовую отладку
• Компании больше не могут позволить себе 6-12 месяцев обучения из-за высоких ставок
• ROI теперь нужен с первого дня, а не “когда-нибудь”
• Junior = расходы + менторинг + риск ухода через год
“Junior” вакансия сегодня = React + Backend + Google Cloud / AWS + CI/CD + 3-5 лет опыта
На одну позицию - сотни и тысячи кандидатов. Первый шаг в карьере фактически убрали, второй (мидл) скоро уберут.
Это не только из-за AI. Основная причина - экономика.
AI стала удобным оправданием, но настоящая проблема, это дорогой капитал и сокращенные бюджеты на обучения.
• Появляется новый вход: AI-augmented developer
• Ожидают готовые production-проекты, end-to-end системы, AI-фичи
• Спрос на таких “джунов” вырос на +143%, пока классические junior-роли падают
Если сейчас убрали 60-70% джунов, то в 2031-2036 рынок получит жесткий дефицит senior и tech lead. Кадровая яма уже заложена. А может и они/мы уже тоже не будут нужны
Старая карьерная лестница “учёба → junior → middle” больше не работает.
Для новичков вход в IT стал сложнее и дороже, а интерны вообще уходят в прошлое
Почему каждый третий ИТ-специалист выбирает работу в промышленности?
Надеемся, мы вас уже убедили, что ИТ — не только бигтех, банки и маркетплейсы. Параллельно существует масштабный, но все еще не настолько популярный для многих пласт — промышленный ИТ, или Heavy Digital. Эта сфера имеет свои отличия: больше физики, железа и процессов, которые нельзя просто «перезапустить».
Как раз на стыке этих двух миров и родился наш тест «Сложный выбор», который мы запустили на Хабре в декабре. В конце, отвечая на вопросы, участники теста узнавали, какая из сфер им ближе, и получали профессиональный портрет.
И неудивительно: тест в первую очередь привлёк айтишников из классической digital-сферы. В своих ответах они чаще выбирали знакомые им ценности и задачи.
Однако сам факт, что они прошли тест и увидели альтернативу, уже показателен. Это может говорить о возникающем вопросе: «А что есть за пределами привычного ИТ?» Предполагаем, что для большинства из них промышленная сфера остаётся пока не выбором, а зоной потенциального интереса — тем, о чём они задумываются, но продолжая работать в привычной сфере.
Промышленный технарь — 33,5%
Это почти треть всех участников — весомая доля.
За этими результатами стоят инженеры, для которых работа с физическим миром — не барьер, а суть задач. Такая цифра подтверждает: Heavy Digital — это уже не узкая ниша, а состоявшееся направление для осознанного развития.
Это значит, что тема промышленного ИТ уже всерьёз конкурирует за внимание наравне с историями из бигтеха.
Бигтех-синьор — 20,7%
Каждый пятый участник — опытный специалист.
Это особенно показательно: синьоры редко тратят время на тесты просто из любопытства. Их вовлечённость говорит о запросе на новый масштаб, где сложность создаётся не только архитектурой, но и законами физического мира.
Для многих из них этот запрос может выглядеть логичным следующим этапом в карьере, а не резкой сменой поля.
Лидеры и инженеры цифровой среды — 2,1%
Небольшая доля. Мы объединили эти две роли, так как обе они в рамках теста дали схожий результат. Это отражает реальность: таких специалистов в ИТ значительно меньше.
Что это значит в целом?
Интерес к промышленному ИТ пробуждается на этапе размышлений, а не в момент решения о переходе. При этом значительная представленность в тесте и «промышленных» специалистов, и опытных синьоров из бигтеха — чёткий сигнал. Heavy Digital уже не узкая тема и превратился в осознанное, весомое направление для работы и роста.
Тихий враг или молчаливый союзник: коротко о выравнивании в C++
Представьте, ваша программа — образец чистого кода, прошедший ревью и покрытый тестами. Казалось бы, всё идеально. Но производительность не такая, на какую рассчитывали. Вы проверили всё, что знали. А что, если проблема в том, о чём вы могли не знать? Всё может упираться в выравнивание данных в памяти. Для многих этот механизм так и остаётся загадкой.
Предлагаю вам вместе попробовать разобраться в такой непростой теме в этой статье.
Привет, Хабр! Новичкам бывает трудно сделать первый шаг в программировании. В интернете много сомнительных курсов, а качественные требуют финансовых вложений и несколько месяцев на изучение.
Мы в Selectel подготовили бесплатный курс, который поможет быстро и без лишних затрат изучить основы JavaScript. В первую часть входят три модуля. Вы узнаете:
для чего разработчики используют JavaScript,
как работать с со скриптами, веб-страницами и переменными,
как создать рабочее окружение на IT-инфраструктуре Selectel.
Участники курса смогут бесплатно протестировать сервисы Selectel, а по итогам тестирования — получить сертификат о прохождении.
Несмотря на кажущуюся сложность, на повседневной основе для работы с Git не требуется большой набор знаний. Checkout, fetch, branch, commit, amend, rebase, revert, reset, pull и, наконец, log. Это — большинство нужных команд. Изредка пользуюсь еще config, бывает нужно.
В общем-то, Git достаточно прост с точки зрения пользователя. Проблема: понимание простоты Git приходит именно с опытом работы с тем самым Git. А по началу хочется иметь под рукой какую-нибудь книжку.
Скотт Чакон и Бен Страуб составили замечательное справочное пособие для тех, кто хочет окунуться с головой в детали работы с Git. Издание есть в виде сайта, PDF, EPUB и MOBI. Распространяется Pro Git бесплатно.
Книга рассчитана на начинающих пользователей или тех, кто имеет конкретные вопросы по механикам Git и им нужен подручный справочник. Что немаловажно, сайт и книга переведены на русский язык.
Pro Git не раз мне пригодился в прошлом, рекомендую.
Кто мы? Лидеры («одни из», конечно) найма ИТ-специалистов на российском рынке— за прошлый год мы наняли 179 сотрудников! Занимаемся заказной разработкой ПО и предоставляем крупным клиентам выделенные команды на ИТ-аутсорсинг.
У нас новый московский офис, который открылся в 2025 году у самой Красной площади! А еще есть вакансии в офис в Томске и на удалёнку из любой точки России.
Команда в SSP SOFT — это реальные проекты, дружная атмосфера, где работать — продуктивно, без выноса мозга и микро-менеджмента. В январе 2026 ищем гуру, кто готов в новое профессиональное будущее вместе с нами.
Что вас ждет в SSP SOFT: ✅ Рост: Центр компетенций для максимального апгрейда скиллов. ✅ Свобода геолокации: Возможность работать удаленно, гибрид или офис. ✅ Баланс work-life: Работаем, чтобы жить, а не наоборот.
🎁 Приятные бонусы: ивенты для всей команды, ДМС для штата, обучение и бенефиты.
Подробности о вакансиях читайте на нашей странице ХХ.ру, но туда откликаться необязательно. Ждем резюме в ЛС нашему HR Lead Алине (https://t.me/AONikitina). Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вашу вакансию на Хабре».
Желаем всем хабровцам успешной карьеры в 2026 году 🚀)
При работе с Git я почти не пользуюсь отдельными программами. В корпоративной разработке у меня под рукой есть IntelliJ с достаточно удобной панелькой Git. А для своих проектов я привык пользоваться Git CLI.
И всё же, время от времени, нужно посмотреть изменения в разрезе нескольких коммитов. Делать тучу git diff не очень удобно, особенно когда нужно дать хэш конкретного коммита.
И тут на помощь приходит Lazygit. Этот TUI позволяет удобно шастать по дереву Git стрелками. Окна в программе настраиваются, мышка поддерживается, темы оформления есть.
Можно делать stage для кусков кода, а не целых файлов. Можно делать commit, fixup, revert, amend… В общем, все (или почти все) функции Git в наличии.
Благодаря тому, что это TUI инструмент, им можно пользоваться на удалённых машинах по SSH. Очень удобно и практично.
Я подумал, что самое время, пока он не стал слишком умным и не взял все мои данные, чтобы составить обо мне мнение когда наступит господство роботов и он вспомнит все чаты когда я не написал “спасибо”.
Но прежде чем нажать Удалить все, я нажал другую кнопку, Экспорт данных
В течение часа мне на почту пришла ссылка со всеми моими данными в архиве, и вот что внутри:
Аудио, все записи диалогов мои с ЧатомГПТ, в формате wav, по папкам, сначала мой вопрос в wav, потом его ответ в wav
Фото/Изображение, просто в корневой папке около 1000 изображений
Изображения, которые чатГПТ сгенерирован для меня, в отдельной папке
Системные файлы, где содержится моя почта, год рождения, телефон, id в системе
Отдельный файл shopping, если бы я что-то покупал через новую функциональность оператора, это было бы тоже там
Отдельный файл диалоги которые поделился, в отдельном файле
Отдельный файл информация о групповых чатах
Отдельный файл всех диалогов в формате conversations.json 320 мб текста
Отдельный файл всех диалогов в формате .html 320 мб текста
Конечно открыть файл html такого размера может только человек без СДВГ.
В итоге я открыл эту папку в Gemini CLI (в последнее время мне нравится он) / можно использовать Claude Code
и попросил создать мне отдельную папку Sorted, где он распарсит все в “.md” файлы и разложит по папкам диалога, а Projects, которые были с инструкциями положить отдельно в Projects (у меня это типа Work, Money, Health и тд.)
я не использовал никакой специальный промпт, просто по английски по просил это сделать
Here is an extracted folder from ChatGPT. Is it possible to generate .md files for all extracted chats and organize them into topic-based folders, with everything placed under a main Sorted directory? Some chats may contain information related to specific projects, with or without explicit instructions. If so, can we create separate sections for these projects inside the Sorted folder. Additionally, let’s try to identify project instructions by searching for the following marker: ТУТ МОЯ ИНСТРУКЦИЯ КАК ПРИМЕР
В итоге у меня теперь локальная копия всех диалогов из ChatGPT
далее я положу все по папочкам и темам в Obsidian, пока что буду лазить по ним и продолжать общение с помощью Gemini CLI, но как только локальные модели станут более умные и менее прожорливые возможно перейду на офлайн (статья об этом на хабре)
Теперь когда у меня есть все мои .md которые очень хорошо обрабатываются любой LLM (AI моделью), можно менять Gemini, Claude, ChatGPT и новые другие тд как перчатки, не теряя все свои диалоги и контекст или перейти в свой приватный офлайн
Павел Варнавский, руководитель группы разработки «ДАР» (Корус Консалтинг), рассказал, как их команда использует BI Magic в своих проектах для создания мощных аналитических решений.
Как внедрять CI/CD для дэшбордов и масштабировать решения под конкретные процессы, там, где стандартных «коробочных» решений не хватает
Два практических кейса, где кастомная разработка на Luxms BI решила нетипичные задачи
Будет интересно всем, кто работает с нестандартной аналитикой, сложными требованиями бизнеса и хочет понимать, как кастомная BI-разработка может быть управляемой и удобной
На неделе вспомнил про wchar_t в Си, пока в очередной раз работал с Unicode, но в Windows. Штука… Неоднозначная.
Часть WinAPI жёстко завязана на WCHAR (wchar_t). Но в Windows он до сих пор определён размером в 16 бит. Тот же GCC на Debian мне говорит, что у него wchar_t — все 32 бита.
Т.е. перевод строки из char в wchar_t генерирует валидный UTF-16 в Windows, но UTF-32 в Linux…
Кажется, char32_t должен решить эту чехарду в будущем… Хотя бы с точки зрения размерности… Пусть это и не исправит проблемы WinAPI…
Но действительно ли так часто нужно работать с полноценным code point в Unicode? Зачем? Только чтобы посчитать общее количество символов? Это же просто сделать и на основе char!
Авторы UTF-8 Everywhere дают развёрнутый ответ на этот и многие другие вопросы. Идея хорошо проработана, есть даже прекрасный FAQ для любопытных.
На этой веб-странице собрали самые веские доводы для использования исключительно UTF-8. Везде. Всегда.
Ответьте мне на один простой вопрос: зачем в наше время вообще нужны HR?
Ни для кого не секрет, что найм сегодня сломан. Бесконечные этапы собеседований, которые якобы должны отсекать «вкатунов в IT», по факту отсеивают и нормальных разработчиков.
Причём даже в эффективности этого «фильтра» есть серьёзные сомнения: по сети уже гуляют AI-оверлеи, которые в реальном времени анализируют вопросы интервьюеров и подсказывают ответы. Так о каком объективном отборе вообще идёт речь?
При этом у HR — бесконечный поток, условно говоря, «подопытных кроликов», на которых можно тестировать гипотезы, улучшать процессы и действительно чинить найм. Но вместо этого они просто копируют чужие, далеко не самые успешные практики.
Почему HR не выполняют своё прямое предназначение, а действуют по шаблону?
И главный вопрос: каким образом лайв-кодинг должен подтверждать или опровергать мои навыки, если:
могут дать абсолютно любую задачу и в штатном порядке, я залезу гуглить документацию, а на собесе я это сделать не могу?
Легендарное письмо Эдсгера Дейкстры обсуждалось учёными и программистами довольно долго. Даже сейчас встречаются разные взгляды на присутствие GOTO в программе.
Краткое содержание (парафразирую): GOTO нарушает простую навигацию по коду и, самое главное, возможность сопоставить код с тем, что мы имеем как состояние процесса в определённый момент времени.
Сам Дейкстра пишет, что ничего нового не говорит, о том же уже выступали Тони Хоар, Никлаус Вирт и ряд других учёных.
Дейкста и его коллеги в 1970-х дадут старт “структурному программированию”. В основу ляжет теорема Бёма-Якопини.
Оригинал статьи есть в свободном доступе библиотеки ACM.
Что интересно, этот вариант вырезки содержит и другие письма от 1968 года в редакцию журнала ACM.
К примеру, одно из них про то, что ЯП и их среды не должны быть защищены торговыми марками. Другое про дихотомию килобайты-кибибайты. Ещё одно про необходимость включения пост-мортем дампов (stacktrace или coredump) как обязательную часть высокоуровневых ЯП…
Иногда кажется, что мы застряли в каком-то странном лимбо, где всё уже было придумано или обдумано за нас. Нам же надо только иногда почитывать работы прошлого…
При написании интеграционных тестов для Spring Boot приложения часто возникает проблема, что разработчики бездумно добавляют аннотации @MockBean, @SpyBean, @DirtiesContext или переопределяют прямо в тестовом классе различные property. Всё это приводит к изменению Spring Context, невозможности использовать закэшированный контекст и следовательно созданию нового. Часто создание нового контекста это длительная операция.
Существуют инструменты по отслеживанию этих процессов. Самым простым способом увидеть количество контекстов и количество попаданий в кэш является добавление логирования либо через свойство logging.level.org.springframework.test.context.cache=DEBUG либо настройкой вашего логгера.
Один известный автор статей про тестирование на Java / Spring Boot, Philip Riecks (со товарищи), создал инструмент с открытым исходным кодом Spring Test Profiler при помощи которого можно получить html отчёт о поднимаемых контекстах во время тестов, о количестве и типе бинов в этих контекстах. На Хабре есть перевод его статьи в сообществе Spring АйО.
У нас на проекте стал вопрос, как нам показать разработчикам, что их тест порождает новый Спринг Контекст. Мы решили считать контексты в тестах и при превышении ожидаемого количества падать. Это "руинит" сборку и CI/CD пайплайн. Для этого мы добавили реализацию интерфейса ContextCustomizer
class LimitingSpringContextCustomizer implements ContextCustomizer {
private static final AtomicInteger CONTEXT_COUNTER = new AtomicInteger();
private static final int EXPECTED_SPRING_TEST_CONTEXT_COUNT = 16;
@Override
public void customizeContext(ConfigurableApplicationContext context, MergedContextConfiguration mergedConfig) {
int numberOfContexts = CONTEXT_COUNTER.incrementAndGet();
log.info("Number of Spring Test Contexts: {}/{}", numberOfContexts, EXPECTED_SPRING_TEST_CONTEXT_COUNT);
Assert.state(numberOfContexts <= EXPECTED_SPRING_TEST_CONTEXT_COUNT,
() -> "Number of test contexts exceeds configured maximum: " + EXPECTED_SPRING_TEST_CONTEXT_COUNT);
}
@Override
public boolean equals(Object obj) {
return (obj != null) && (getClass() == obj.getClass());
}
@Override
public int hashCode() {
return getClass().hashCode();
}
}
Здесь, согласно документации интерфейса ContextCustomizer необходимо корректно переопределить методы equals и hashCode.
WARNING: implementations must implement correct equals and hashCode methods since customizers form part of the MergedContextConfiguration which is used as a cache key.
Далее добавляем фабрику.
class LimitingSpringContextCustomizerFactory implements ContextCustomizerFactory {
@Override
public ContextCustomizer createContextCustomizer(Class<?> testClass,
List<ContextConfigurationAttributes> configAttributes) {
return new LimitingSpringContextCustomizer();
}
}
Затем регистрируем эту фабрику при помощи spring.factories чтобы она применялась ко всем тестам. Для этого создаём в тестовых ресурсах файл по пути src/test/resources/META-INF/spring.factories со следующим содержимым
Теперь, если во время выполнения тестов будет превышено количество инициализированных тестовых контекстов, то мы увидим ошибку в тестах и сборка завершится неудачей.
Возможно, это пример поможет кому-нибудь повысить скорость прохождения своих тестов путём отслеживания количества запускаемых тестовых Спринг контекстов.
Сама идея мелькает в НФ-литературе уже не первый год. То, что я могу вспомнить сейчас, - это Вернор Виндж, «Глубина в небе». В этой книге люди, чей мозг был искусственно изменён для решения узких задач (в книге так делали очень плохие люди), вырабатывали свой, никому не понятный язык, специфичный задаче.
В теории, если делаю какую-то большую систему с помощью ИИ-агентов будущего, в каком-то 2035 году, - можно предположить, что сначала ИИ-агент разработает доменно-специфический язык для конкретной задачи, конкретной платформы и т.п. Просто один специальный язык для ИИ-агентов не имеет смысла. Раз уж у нас есть «мозг», который может писать много кода, - пусть он делает язык под задачу. В чём смысл иметь всего один язык?
В целом, в каком-то смысле, какие-то «нечеловеческие» языки уже есть - это разного рода P-код, байткод и т.д. Такое промежуточное звено между машинным кодом и языком, на котором пишет программы человек. Они, конечно, создавались для другого, но вот вопрос - а для чего именно должен быть создан ИИ-язык? См. пункт ниже.
Следующее соображение - если вернуться из великолепного (или не очень, если судить по трендам) 2035-го года в год 2026, то один из важнейших факторов успешности кодирования с помощью ИИ-агентов - это способность человека читать сгенерированный код и исправлять накосяченное. Ну вот ни разу не похоже, что тот код, который ИИ генерирует, можно пускать в продакшн без ревью и правок. Оговорюсь - для сколько-нибудь сложных / больших приложений.
Из этого автоматически следуют следующие качества используемого языка:
Легко читаем человеком, простые вещи делаются просто.
Мало или вообще нет неочевидных сайд-эффектов.
Распространённые вещи, такие как работа с БД или JWT-авторизация запросов, делаются при помощи библиотеки / фреймворка, а не «с нуля».
Из этих пунктов мы легко получаем на выходе тройку языков: Java / C# / TypeScript с фреймворками Spring Boot / NestJS / ASP.NET Core.
Драйвером развития всех трёх были именно пункты выше: легко читается, простые вещи делаются просто, минимизация неочевидных эффектов.
Да, все три не идеальны, но это лучшее, что у нас есть в этой области. Сможет ли ИИ придумать лучше? Точнее - люди для ИИ. В теории - да, но это десятки лет работы. Быстро не получится.
И последнее. ИИ не пишет код «сам», он по факту подбирает похожие кусочки из той базы, на которой он был обучен. Т.е. чтобы ИИ начал писать сколько-то адекватный код на каком-либо языке, ему нужно «скормить» миллионы (скорее всего - много больше) строк кода на этом языке, и писать этот код должен не ИИ.
На самом деле, даже живые программисты обучаются так же. Когда ты берёшь в руки книгу по совершенно незнакомому тебе языку, то первая реакция - «блин, как на этом код-то писать», потом ты начинаешь писать небольшие кусочки, понимаешь, что получается плохо, правишь, смотришь на чужой код, говоришь себе «Ага! Вот как надо!» - и как-то так понемногу двигаешься вперёд.
Подводя итог. В целом, идея специального языка витает в воздухе не первый десяток лет.
Скорее всего, это будут специальные языки под задачу.
Мы пока не там. ИИ-агенты, с одной стороны, заметно ускоряют разработку, но с другой стороны - программирование с помощью ИИ-агентов это гонка на костылях от ямы к яме. Требует очень высокого внимания и навыка со стороны человека.
В текущей ИИ-индустрии всё крутится вокруг обучения, и если нет хорошего датасета для обучения, то результат будет очень грустным. Какие-то опыты по самообучению ведутся, но мы пока не там. Например, Google сделал бота для игры в StarCraft, который обыгрывает большинство противников. Но бот изначально обучался на записях игр реальных людей и делает безумное количество бессмысленных вещей. Где взять датасет для обучения программированию на специальном ИИ-языке - непонятно.
Попалась на глаза картинка. Интересная идея, я так или иначе кручу её в голове уже не первый месяц. Несколько соображений на этот счёт.
Сама идея мелькает в НФ-литературе уже не первый год. То, что я могу вспомнить сейчас, - это Вернор Виндж, «Глубина в небе». В этой книге люди, чей мозг был искусственно изменён для решения узких задач (в книге так делали очень плохие люди), вырабатывали свой, никому не понятный язык, специфичный задаче.
В теории, если делаю какую-то большую систему с помощью ИИ-агентов будущего, в каком-то 2035 году, - можно предположить, что сначала ИИ-агент разработает доменно-специфический язык для конкретной задачи, конкретной платформы и т.п. Просто один специальный язык для ИИ-агентов не имеет смысла. Раз уж у нас есть «мозг», который может писать много кода, - пусть он делает язык под задачу. В чём смысл иметь всего один язык?
В целом, в каком-то смысле, какие-то «нечеловеческие» языки уже есть - это разного рода P-код, байткод и т.д. Такое промежуточное звено между машинным кодом и языком, на котором пишет программы человек. Они, конечно, создавались для другого, но вот вопрос - а для чего именно должен быть создан ИИ-язык? См. пункт ниже.
Следующее соображение - если вернуться из великолепного (или не очень, если судить по трендам) 2035-го года в год 2026, то один из важнейших факторов успешности кодирования с помощью ИИ-агентов - это способность человека читать сгенерированный код и исправлять накосяченное. Ну вот ни разу не похоже, что тот код, который ИИ генерирует, можно пускать в продакшн без ревью и правок. Оговорюсь - для сколько-нибудь сложных / больших приложений.
Из этого автоматически следуют следующие качества используемого языка:
Легко читаем человеком, простые вещи делаются просто.
Мало или вообще нет неочевидных сайд-эффектов.
Распространённые вещи, такие как работа с БД или JWT-авторизация запросов, делаются при помощи библиотеки / фреймворка, а не «с нуля».
Из этих пунктов мы легко получаем на выходе тройку языков: Java / C# / TypeScript с фреймворками Spring Boot / NestJS / ASP.NET Core.
Драйвером развития всех трёх были именно пункты выше: легко читается, простые вещи делаются просто, минимизация неочевидных эффектов.
Да, все три не идеальны, но это лучшее, что у нас есть в этой области. Сможет ли ИИ придумать лучше? Точнее - люди для ИИ. В теории - да, но это десятки лет работы. Быстро не получится.
И последнее. ИИ не пишет код «сам», он по факту подбирает похожие кусочки из той базы, на которой он был обучен. Т.е. чтобы ИИ начал писать сколько-то адекватный код на каком-либо языке, ему нужно «скормить» миллионы (скорее всего - много больше) строк кода на этом языке, и писать этот код должен не ИИ.
На самом деле, даже живые программисты обучаются так же. Когда ты берёшь в руки книгу по совершенно незнакомому тебе языку, то первая реакция - «блин, как на этом код-то писать», потом ты начинаешь писать небольшие кусочки, понимаешь, что получается плохо, правишь, смотришь на чужой код, говоришь себе «Ага! Вот как надо!» - и как-то так понемногу двигаешься вперёд.
Подводя итог. В целом, идея специального языка витает в воздухе не первый десяток лет.
Скорее всего, это будут специальные языки под задачу.
Мы пока не там. ИИ-агенты, с одной стороны, заметно ускоряют разработку, но с другой стороны - программирование с помощью ИИ-агентов это гонка на костылях от ямы к яме. Требует очень высокого внимания и навыка со стороны человека.
В текущей ИИ-индустрии всё крутится вокруг обучения, и если нет хорошего датасета для обучения, то результат будет очень грустным. Какие-то опыты по самообучению ведутся, но мы пока не там. Например, Google сделал бота для игры в StarCraft, который обыгрывает большинство противников. Но бот изначально обучался на записях игр реальных людей и делает безумное количество бессмысленных вещей. Где взять датасет для обучения программированию на специальном ИИ-языке - непонятно.
