Программирование *

Я уже больше десяти лет критикую Go, о чём высказывался в своих предыдущих статьях «Why Go is not my favourite language» и «Go programs are not portable».

Описанные в них проблемы языка бесят меня всё больше, и в основном потому, что их явно можно было избежать. Мир знавал решения и получше, но Go почему-то состряпали именно таким.

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

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

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

Здесь важно сказать следующее: игры — это не физические движки, а впечатления. И гоночные игры больше других намеренно манипулируют реальностью, чтобы дать нам эти впечатления. Например, мы ожидаем от шутеров определённого поведения; пуль, летающих по прямой, отдачу при выстрелах, перезарядку. Если эти ожидания не оправдываются, игра начинает казаться «не такой». Но в случае транспорта степень допущений может быть огромной.

Возьмём для примера Mario Kart. Это гонки, максимально далёкие от реалистичности; машинки дрифтят по песку, вы бросаете в друзей черепашьи панцири и гоняете в картах с мультяшными пропорциями и физикой. Тем не менее, эту игру обожают, ведь она «продаёт» реализацию фантазии о гонках.

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

Привет, Хабр!

Меня зовут Артем Лакомов, я филолог из МГУ. Да, вы не ослышались. И сегодня я хочу поговорить с вами о самой главной (и самой дорогой) боли в IT, но с совершенно неожиданной стороны.

Каждый из вас хоть раз в жизни видел код, от которого хотелось плакать или же тихо ненавидеть свою работу. Код с переменными вроде data, res, temp. Код, где есть один гигантский класс, который делает абсолютно всё, и коллеги с любовью (или ужасом) называют его godObject.

Все привыкли думать, что это просто «плохой стиль» или «технический долг». Но что, если я скажу вам, что это — не техническая, а языковая проблема? И что у монструозного godObject гораздо больше общего со школьным прозвищем «Толстый», чем вы думаете?

Последние несколько лет я занимаюсь тем, что применяю классическую лингвистику к программному коду. И я обнаружил поразительную вещь: правила, по которым вы даете имена переменным и классам, практически дословно повторяют законы, по которым в любом человеческом коллективе — от школьного класса до команды разработчиков — возникают прозвища.

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

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

Привет! Я — Александр Дудукало, автор базового курса по JavaScript. В этой статье мы продолжим изучение работы с данными в JavaScript. Если в прошлом материале мы говорили о массивах, то теперь пришло время познакомиться с объектами. Я расскажу, как они помогают эффективно организовать и обрабатывать связанные данные. Подробности под катом!

Я устроился в Apple в октябре 1995 года. В это время Apple кружилась в сливном отверстии раковины, готовясь отправиться в канализацию. Возможно, вы помните все эти разговоры о том, что Apple скоро закроется. Немного странно, что она продолжала нанимать сотрудников, но, очевидно, в Apple считали, что им всё равно нужен ещё один «графический инженер» для работы над технологией QuickdrawGX. Тогда мне был 31 год, я жил в Канзасе и программировал игры для Macintosh. Разумеется, в компании решили, что я хорошо подойду на эту должность.

Процесс собеседования оказался для меня совершенно неожиданным и новым (подробно о нём написано здесь), но в конечном итоге мне предложили работать графическим инженером QuickdrawGX в Apple Computer, Inc.

Переезжать с моей девушкой, всеми вещами (и двумя кошками) из Канзаса в Калифорнию было безумно сложно, но мы справились. Как окажется позже, мне предстояло ещё многое узнать о программировании, да и о профессионализме в целом. И тут я сразу понял, что, возможно, взялся за задачу, которая мне не по зубам (как программисту). Другие инженеры Apple были дружелюбными, но и очень умными. (Наверно, мне стоит подробнее написать о панике, которую я ощущал первое время; казалось, будто я случайно забрёл в глубокую часть бассейна.)

Впрочем, постепенно (примерно через полгода) я, так сказать, вошёл в колею, и начал справляться с работой немного увереннее. Но вскоре я всё равно понял, что по-прежнему остаюсь недисциплинированной деревенщиной, не совсем отвечающим стандартам Профессиональной Корпорации™.

Вскоре после моего прихода в компанию проект QuickdrawGX расценили провалившимся, меня перевели в новую команду (ColorSync) и чуть позже выдали новый проект. У Apple было стандартное окно, в котором пользователь мог выбирать цвет, оно называлось Color Picker («Палитра»). Кроме того, в то время Apple начинала переход с чипов Motorola 68K на новые, более быстрые чипы PowerPC (PPC). Моя задача заключалась в том, чтобы проект Color Picker, написанный для чипов 68K, компилировался для новой архитектуры PPC.

Не торопитесь пролистывать эту статью. Я не собираюсь, подобно множеству других статей на Хабре, рассказывать о плюсах или минусах вайб-кодинга и сравнивать это с плюсами и минусами традиционного программирования. Потому что сравнивать нечего, ведь не случилось ничего такого, что бы как-то значительно изменило ситуацию. По сути, я буду говорить о том же, о чём говорил в предыдущей статье ( https://habr.com/ru/articles/938028/ -Михаил Елисейкин «IT-лягушка и новая нормальность» ) - о том, что мир меняется, а наши о нём представления от этих изменений отстают.

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

Идея написать эту статью зародилась из моего поста. В нем я рассказал о том, что через последовательность Фибоначчи можно конвертировать мили в километры с небольшой погрешностью. Увидев, что многим понравилась, я задумался: почему бы не изучить еще какие-нибудь трюки, заодно практикуясь в программировании на C?

Всех, кто заинтересовался — прошу под кат.

Показываем на практике, как с помощью ChatGPT можно за несколько минут преобразить реально существующие фрагменты легаси-кода на Python.

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

Учёные затруднились объяснить причины когнитивного искажения.

Факт в том, что многим разработчикам очень нравятся их инструменты для автодополнения и генерации кода, особенно Claude Code. Он настолько удобен, что от него буквально возникает зависимость. По опросам, чем больше люди используют такие инструменты — тем больше им нравится. Код «магически» генерируется сам собой, зачастую даже корректный.

Но это не обязательно улучшает или ускоряет разработку.

Более того, есть признаки, что в 2025 году наконец-то наступило некоторое охлаждение ожиданий в отношении к LLM.

Привет, Хабр! Меня зовут Олег Доронин, и мы с командой делаем СУБД Яндекса, которая называется YDB. Каждый транзакционный запрос к базе данных обычно работает с небольшим набором строк и быстро отрабатывает за единицы или десятки миллисекунд, но таких запросов каждую секунду поступает огромное количество. А вот аналитические запросы обычно выполняются не так часто, но каждый из них может требовать обработки вплоть до всех строк в одной или нескольких таблицах. Такие запросы могут выполняться секунды, минуты, или даже часы в зависимости от объёмов данных и сложности запрошенных вычислений.

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

Сегодня хочу поделиться своим видением текущей ситуации в ИТ. О ней только ленивый сейчас не говорит, вставлю и я свои 5 копеек. Пишу изнутри (в ИТ с 2003 года) — это добавит контекст к моим наблюдениям.

Если вы работаете в ИТ или думаете туда пойти (а может, даже отдать туда своих детей), в этой статье разберём, что сейчас происходит на рынке, и как это отразится на зарплатах, требованиях и шансах устроиться на работу.

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

Индустрия ИИ переживает рекордный бум: каждую неделю появляются новые модели, а заголовки пестрят новостями о многомиллионных контрактах и громких переходах звёздных исследователей. Прорывы происходят на всех уровнях: от чипов и инфраструктуры (NVIDIA и др.) до моделей и инструментов вроде Cursor или Windsurf.

Но у российских разработчиков выбор заметно ýже: ограничения, VPN, трудности с оплатой. Мы решили это изменить и создали Koda — AI-помощника, который доступен бесплатно и без VPN, работает с современными моделями и привычными функциями: автодополнение кода, чат, поиск по документации и коду проекта, а также агентный режим!

Всем привет. Сегодня хочу затронуть тему матана, чтобы показать как его можно применять на реальных задачах. Думаю каждый, кто учил матан часто задавался вопросами: «Где это вообще пригодится?», «Зачем это нужно?», «Как это может помочь?» и т. д. Так вот, чтобы эти вопросы отпали раз и навсегда предлагаю свой топ-5 алгоритмов из курса матана с конкретными примерами их применения в работе.

Антонио Куни — инженер, давно занимающийся повышением производительности Python, а также разработчик PyPy. Он провёл на EuroPython 2025 в Праге презентацию «Мифы и легенды о производительности Python». Как можно догадаться из названия, он считает многие общепринятые сведения о производительности Python как минимум вводящими в заблуждение. На множестве примеров он показал, где, по его мнению, таятся истинные проблемы. Инженер пришёл к выводу, что управление памятью в конечном итоге наложит ограничения на возможности повышения производительности Python, но у него есть проект SPy, который, возможно, станет способом реализации сверхбыстрого Python.

Он начал своё выступление с просьбы: «Если вы считаете Python медленным или недостаточно быстрым, поднимите руку»; поднялось много рук, в отличие от презентации на PyCon Italy, где руку не поднял почти никто из присутствующих. «Совершенно другая аудитория», — сказал он с улыбкой. Антонио уже много лет работает над производительностью Python, он общался с множеством разработчиков на Python и слышал кучу устоявшихся мифов, которые захотел развеять.

В этой статье я коротко опишу один приём, который помогает мне писать код быстрее и с меньшим числом ошибок. Я говорю «приём», но по факту это просто практика, которой я начал следовать с опытом, сам того не замечая.

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

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

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

Десятилетиями нам рассказывают, что есть только два пути: громоздкие иерархии ООП или стерильная бюрократия ECS. Нас заставили поверить в то, что создание игр — это выбор между анархией и диктатурой.

Это ложь. Оба этих пути — ненужные усложнения. Есть прямой и эффективный способ, который мы променяли на модные, но непрактичные примочки. Эта статья — о том, как вернуться к здравому смыслу.

Предыстория

Моя команда занимается разработкой медицинского ПО: приложения для передачи направлений пациентов в системе здравоохранения Австралии.

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

Система электронных направлений удобна для всех. Когда врач создаёт новое направление, мы автоматически извлекаем информацию из PMS (patient management software, системы управления пациентами, которой владеет наша компания) с данными пациента, этнической принадлежностью, индексом массы тела, принимаемыми лекарствами, медицинской историей и всем остальным, что необходимо для направления. В бланке направления есть валидируемая «форма специализации» с полями, относящимися к конкретной услуге, для которой выписывается направление.

Благодаря этому в направлении содержится вся необходимая информация. И, разумеется, в форме также есть большое текстовое поле для свободного текста (referral letter), в котором терапевт может объяснить, почему он решил выписать пациенту направление.

При отправке направления данные передаются в цифровом виде. Они преобразуются в один из нескольких форматов в зависимости от получателя. Некоторые получатели используют для приёма направлений наш продукт Referral Manager; в этом случае нам не нужно ничего преобразовывать, они просто получают доступ в веб-интерфейсе к тем данным, которые хранятся в базе данных. Однако обычно данные преобразуются в HL7 (старый текстовый формат файлов медицинской информации), CDA (XML-документ с отдельной таблицей стилей) или просто в PDF с человекочитаемой информацией. Благодаря этому данные совместимы со множеством различных электронных систем других компаний.

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

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