Все ж приємно бачити, що 💻 потроху позбувається класичних способів поцілити собі в ногу.

Наприклад, усі ми знаємо, що C++ не ініціалізує змінні, і тому там може опинитися сміття, прочитавши яке можна піти за чужими адресами абощо. Ну, вгадайте шо? Більше ні! Точніше так, але є «але».

void foo() {
  int d;   // не ініціалізуємо
  bar(d);  // хоба! — не UB
}

Раніше цей код призводив до так званої невизначеної поведінки (UB — undefined behavior), а нині вона вельми визначена: відтепер це нова категорія — помилкова поведінка (erroneous behavior). Утім це не значить, що ваші змінні почнуть раптом занулятися чи робити щось притомне. Натомість змінна отримає «невизначений» стан (такий собі undefined, який не можна перевірити). Стандарт ніби не описує, що саме там має бути, тож усі компілятори робитимуть на свій розсуд. Але тепер вони принаймні зобовʼязані написати помилку при спробі це значення використати (не обовʼязково під час компіляції — може бути і в рантаймі).

А якщо дуже-дуже хочеться повернути UB, то можна використати новий атрибут 😆

void foo() {
  int d [[indeterminate]];
  bar(d);  // Фух, старий-добрий UB :)
}

З інших приколів: прибрали порівняння масивів. Раніше можна було писати так:

int arr1[5];
int arr2[5];
bool same = arr1 == arr2;  // тепер помилка

Не те щоб хтось дійсно таке писав, окрім джунів на співбесідах. Та й компілятори на це скаржилися з 2019 року. Але новачків це все одно плутає, бо arr1 та arr2 — це просто вказівники на початок масивів, і такий код порівнює їхні адреси, а не вміст. Добре, що позбулися.

Хоча знов-таки… Якщо дуже хочеться, то можна повернути стару поведінку, наприклад, через хак з приведенням типу до звичайного вказівника унарним плюсом 😅

int arr1[5];
int arr2[5];
bool same = arr1 == +arr2;  // працює

Отже, C++ стає дедалі суворішою мовою стосовно таких дрібниць, що в більшості випадків є хибним кодом, і водночас не позбавляє свободи. Може в цьому й полягає секрет, чого вона так довго тримається на плаву?

Коли мова заходить про використання генеративного ШІ в проєкті на роботі (особливо у великих компаніях), серед основних перепонів є завжди такі:
1. Лячно надсилати дані на чужі сервери всіляких Anthropic чи OpenAI (особливо якщо проєкт для замовника).
2. Згенерований код може бути підозріло схожий на чийсь ще, бо всі ВММ навчалися переважно на чужих відкритих сирцях.

З другим нічого не можу порадити. А стосовно першого… Річ у тім, що ШІ допомагає не лише код писати, але й аналізувати: знайти, що, де і як використовується, побудувати ментальну модель, пояснити звʼязки тощо. Тому доки ваша компанія розбирається, як хостити нормальну модель у власній хмарі, вам на допомогу приходять локальні моделі.

Жодне спілкування в чаті з надто загальними описами проблеми та копіпастою повідомлень про помилки не буде настільки ж ефективним, як використання агентної системи, яка може досліджувати код самостійно. Для прикладу: я днями намагався зібрати Xmakeʼом 💻-проєкт під WASM — нічого не виходило. Декілька годин спілкування з Perplexity коту під хвіст. Наступного дня дав копайлоту 💻 подивитися: він повивчав CMake-файли з самого кьюта, подивився на те лайно, що написане в Xmake, і врешті згенерував мені повністю робоче правило трохи менше ніж за годину.

Як повторити те саме з локальною моделлю? Ну, спершу треба… «запустити» модель. Я використовую LM Studio, бо є нормальний GUI та за потреби вміє працювати й у headless-моді.

Одна з найтоповіших моделей нині — Gemma 4 від ґуґла. Я вибрав Gemma 4 26B A4B з 8-бітним квантуванням. Тут правило просте: беріть те, що влізає на ваше залізо. E2B та E4B — для слабших пристроїв, A4B з так званим Mixture-of-Experts для макбука, 31B без додаткових приписок — не бачу сенсу.

Якщо у вас macOS, то постає ще вибір між MLX та GGUF. За моїми особистими відчуттями MLX завантажується в памʼять значно швидше. Але пишуть, що швидкість генерації починає відчутно падати з ростом контексту. А нам якраз доведеться працювати з великим контекстом, тому, певно, краще одразу брати GGUF.

Отже, стягнули модель, завантажили в памʼять. Можна прямо в LM Studio поспілкуватися в чатику, та сенсу в цьому мало. Натомість беремо OpenCode і додаємо цю модель туди (~/.config/opencode/opencode.jsonc):

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "lmstudio": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "LM Studio (local)",
      "options": {
        "baseURL": "http://127.0.0.1:1234/v1"
      },
      "models": {
        "google/gemma-4-26b-a4b": {
          "name": "Gemma 4 26B A4B"
        }
      }
    }
  }
}

Далі запускаємо:

opencode -m google/gemma-4-26b-a4b

Ну, або просто opencode і вже всередині вибрати через /model. І вуаля — тепер у вас особистий локальний майже клод код 💻.

Так, це вочевидь не Opus і, мабуть, навіть не Haiku, але для багатьох задач і цього достатньо! Пробуйте.

За свою карʼєру я чомусь обійшов стороною два трактати: «The Design and Evolution of C++» пана Страуструпа та «Simple Made Easy» пана Гіккі. І якщо стосовно першого в мене навіть в думках не було це читати, то друге вочевидь було прикрою помилкою, яку я вчора взявся виправити: з подачі пана Соловйова сів і подивився.

До деяких постулатів я останніми роками й сам дійшов, а до деяких поки ще ні. А міг просто глянути відос 15 років тому й одразу бути мудрим ще відтоді!

Раптом хто не в темі: цей типок є автором мови Clojure 💻 — найприємнішого LISPʼа сучасності (яким надихаються зокрема Janet 👩‍🦰 та jank 💻 — десь вище згадував, пошукайте), але в доповіді про цю мову не йдеться.

Ще там днями документалка вийшла про Річа та кложу на кшталт тієї, що кілька місяців тому була про Гвідо ван Россума та пайтон. ЇЇ теж глянув, але не сильно надихнувся на щось — мабуть, для фанатів робили, щоб ті на старі дріжджі впали.

Після перегляду доповіді Гіккі натрапив на ще одну статтю про вибір мови в часи повсюдного використання ВММ для програмування. Чувак там, звісно, втоплює теж за Clojure 💻, але аргументи наводить обґрунтовані.

Зокрема посилається на… кхм… «коричневу межу» (мій довільний переклад brownfield barrier) з іншої статті — емпіричну величину, що являє собою кількість рядків коду, після якої ШІ-агенти починають тупити. Каже, мовляв, після 100 тис. LOC — уже шо зря.

Ми не так давно маленькою командою накидали проєкт на понад 80 тисяч рядків на Python, і ніби ознак такої проблеми не зауважили. Але в нас цикломатична складність мізерна — у районі 0,06 на рядок коду, — бо по-перше, запарилися все норм структурувати й модуляризувати, а по-друге, сам прототип не надто складний окрім декількох місць. Хоча складна частина там в SQL-запитах радше.

Попри це в певну мить вносити нові зміни в проєкт стало доволі боляче, особливо в режимі, коли всі активно навалюють код в одні й ті ж файли. Коли потім там чувак сам залишився, то навів ладу.

Але повернімося до кложі. Автор оце стверджує, що цією мовою банально складніше досягти коричневої межі, адже змістовність в ній значно вища. Нагадую, що сам-то я на кложі не пишу, хоча трошечки кодив на Janet; плюс я шанувальник Red і REBOL, а вони в цьому сенсі від ліспа не відстають — і я цьому твердженню про щільність значущого охоче вірю!

Ще там є посилання на цікаве дослідження з використання токенів різними мовами, і початково кложа була на першому місці, доки її не скинула звідти J. Остання, до речі, — це ASCII-діалект 🍏, тоді як сам APL пролетів через неефективну токенізацію. Ну, а C++ там звісно пасе задніх і лише трохи краще за C, хоча для кого це секрет.

У статті підіймаються й недоліки теж. Наприклад, той факт, що ВММ-ки гублять в ліспах дужки 😆 Я сам був очевидцем цього десь рік тому, та може відтоді щось помінялося на краще.

Короч хз, висновків якихось не буде — я просто отримав задоволення від статті й вирішив поділитися. Почитайте, бо вона значно глибша, ніж я оце переказав, до того ж спирається на вельми свіжі дані.

Всі нині показилися з агентними ШІ-системами. Звісно, цим всім добром треба якось керувати, тож є всілякі Claude Code, Codex, Gemini CLI, Copilot CLI, OpenCode, Pi, Crush, Hermes тощо. Зазвичай всі ці штуки називають загальним словом harness.

І мені прям око різало оце харнес, харнес… усюди. But fear no more! Зараз ми позбудемося цього мерзенного англіцизму раз і назавжди. Пропоную вашій увазі питомий український термін — ярмо! Схвалено верховним комітетом ШБТ 💙, лаконічне, усім знайоме, передає суть ідеально — кращого слова годі й шукати. Лишилося зробити його загальновживаним у цьому контексті, тому використовуйте, поширюйте.

Я, до речі, різні ярма спробував і наразі потихеньку пробую перелізати на 🅿️, бо з ним здається, ніби зможу досягти саме того, що мені треба (і не доведеться все писати з нуля).

Отже, любі друзі, цей день настав. Ми підняли DC++!

Половина з вас, певно, і не знає, що це таке, бо протокол майже мертвий. Та десь після пʼяти розрядів деплоя інфраструктури ми побачили пульс!

Як це все працює? Насправді DC++ — це назва клієнтської програми, а сам протокол називається ADC (Advanced Direct Connect). Це гібридний протокол: має бути щонайменше один хаб, до якого підʼєднуються клієнти. Хаб забезпечує фічі на кшталт текстового чату, пошуку файлів, моніторингу підʼєднаних клієнтів тощо. Для передачі файлів клієнти звʼязуються один з одним через P2P.

Останні можуть працювати в активному або пасивному режимі. Для успішного обміну принаймні один клієнт має бути активним. Активні клієнти можуть приймати зʼєднання зовні, а пасивні можуть їх лише ініціювати. Та завдяки тому, що вони обидва підʼєднані до хабу, це не проблема. Якщо активний хоче щось стягнути з пасивного, то він каже про це хабу, той передає пасивному, а той вже сам ініціює зʼєднання, щоб з нього щось стягнули.

Ще в ADC (порівняно з DC) додали хешування файлів + підтримку TLS.

Для звʼязку самих мереж вирішили використовувати Tailscale. Проблема була в тому, що в моїй тейл-мережі вже 30+ вузлів, а у другана взагалі kubernetes-кластер зі своєю моташкою, і нікому з нас не хотілося надто це переналаштовувати чисто під цей випадок. Ми перебрали купу різних топологій, і щоразу впиралися то в якісь обмеження самого Tailscale, то ще в щось. (Думатимете, що питати на співбесідах по System Design, згадайте цей допис — кращого не знайдете, їй-богу). Врешті зупинилися на окремій спільній мережі з певними додатковими нюансами (якщо захочете, розповім детальніше) — запрацювало!

Дві наші головні помилки:

1. Ми зробили низку припущень, на базі котрих ми кинулися щось будувати, бо «ну, звучить збс» і «та хулі там», але згодом припущення виявлялися хибними: врешті час вже витрачений, а токени спалені. Тож порада: не намагатися перестрибнути декілька кроків, а почати реально з найбазовіших штук і переконатися, що вони працюють. Ніби по декілька десятків років досвіду в кожного, а робили як новачки якісь 🤷‍♂️
2. Своєрідне продовження попереднього пункту: ми за звичкою бахнули одразу ACL, де все закрутили, і полірнули файрволами — компи наче в одній мережі, але пакети не біжуть 🙁 Пішли від зворотного: тимчасово дозволили взагалі все, а далі почали закручувати. Тут допомогла можливість писати тести в тейлскейловому ACL — можна одразу прописати, хто до кого мусить ходити, а далі прибирати права.

Що маємо в результаті: окрема повністю незалежна й закрита від зовнішнього світу мережа, в якій є лише наші DC-клієнти та хаб. Можемо обмінюватися файлами за пів тисячі кілометрів один від одного по шифрованому каналу. Можемо вибирати, які файли шарити і які качати з яким пріоритетом, з підтримкою дозавантаження. Можемо слати у вбудованому убогому чаті келих пива в ASCII. Єдина залежність на чужу інфраструктуру — це координатор Tailscale, який за бажання можна замінити на власний Headscale.

А ваші сучасні технології так можуть? 😎

Я доволі лояльно ставлюся до багатьох мов програмування. Багатьма з них користуюся, інші просто пробував і здебільшого всі поважаю. Але одне лишається незмінним:

Я ненавиджу Bash 💻 усім своїм єством!

Я ненавиджу його читати й ніколи не пишу. Того тижня попросив 🅿️ зробити собі тул для Nushell 🆕, і щойно він закінчив, я тут же заборонив йому використовувати вбудований Bash.

Авжеж це не дуже допомогло 🙁 Усі моделі так надрочені на той клятий баш, що їм до сраки якийсь Nushell. Я прямо в системний промпт прописав, що це НЕ баш, що це навіть не POSIX-оболонка, написав відмінності, написав аналоги для типових шел-патернів — по барабану. Воно продовжує мене дрочити своїми 2>&1 і 2>/dev/null, комбінує команди через && та пише декілька ls у рядок, щоб подивитися вміст кількох директорій за один виклик. Nushell на це, звісно, скаржиться, або ж це просто дає не ті результати, і модель починає переписувати команди по пʼять разів, доки не вгадає синтаксис. Буквально «вгадає» — інакше це назвати не можна. Ось де чудово видно, що це аж ніяк не інтелект.

Ну добре, біс із тим Pi. Запущу-но старий-добрий Claude Code 💻, подумав я. Не чіпав його місяць узагалі, може півтора. Здавалося б… місяць… це ж ніщо. У мене деякі пет-проєкти по 2 роки лежать, а я потім їх відкриваю й продовжую, наче останній коміт зробив учора. Такий собі анабіоз.

Але не в цьому випадку! Відкрив claude, він наче на вигляд такий самий, але поводить себе інакше. Самі моделі реагують інакше, ярмо відчувається інакше! Тули Grep та Glob зникли, і ця хуйня тепер все ганяє через Bash. Я розумію, що вони зробили свій супер-пупер автоматичний «інтелектуальний» режим, де інша(?) модель оцінює, наскільки безпечно виконувати команди, і тепер це такий типу дефолт. Але я дід — мені таке не треба. Я люблю сам оцінити, що треба, а що не треба викликати. От тільки не коли воно мені висирає по 15 рядків на баші замість запустити два ґлоба та три ґрепа!

Так, я міг би не вимахуватися, а бути читати баш, як усі. Але ви ж розумієте, що річ не в ньому? Річ у виборі.

Не стоїть вибір між «використовувати ШІ з Bash» та «використовувати ШІ з Nushell» — є вибір «використовувати ШІ з Bash» або «не використовувати ШІ», бо воно просто не працює інакше. А скільки разів ви вибирали саме TypeScript 🕸 чи Python 💻 для своїх чергових пет-проєктів, бо на них ШІ знається краще? Закладаюся, що були ліпші альтернативи за кількома параметрами, окрім хіба що швидкості розробки.

І навіть тулзи вам не належать. Вони встановлені у вас локально на компі, ви не чіпаєте їх місяць, а потім гоп — а там усе інакше. Ваші звички, які ви формували, більше не актуальні; налаштування не працюють — читайте мануал знову, витрачайте свій час, бо хтось вирішив, що вашому ярму (гг) час оновитися.

Єдине рішення, яке лишається вам: робити щось із використанням ШІ чи без. «Але ж, Сіпласпластик, — вигукнете ви, — якби не ШІ, то багато моїх ідей взагалі не матеріалізувалися б!» — і матимете в чомусь рацію. Хоча я все частіше розмірковую: а може воно було й на краще?

Так чи інакше, щодо себе звернув днями увагу, що з появою ШІ я значно більше почав програмувати саме руками, ніж до того (бо раніше просто нічого не робив 😌). Цікавий ефект.

Подивився учора документалку про C++. Сподобалася! Вище вже згадував аналогічні про Python та Clojure, але ця, звісно, якось ближче до серця сприймається, бо знайомі люди.

Розповідають про появу та становлення мови. Мені найцікавіше було послухати про самий початок. Помітив, як в різний час приходили та йшли різні люди (навіть різні типи людей), та й загалом видно, наскільки по-іншому раніше приймалися рішення, що напряму впливали на розвиток мови та індустрії. (Чи не по-іншому?).

Концентрація крутих дідів на хвилину відео вкрай висока. Керніган прям бодрячком мужик, молодець! Ромеро засвітився, куди без нього. У Александреску очі запалали, коли мова про шаблони зайшла. Понасміхалися з Java 💻, розповіли, як Степанов замовив собі 3 пляшки вина (вгадайте, до чи після того, як вигадав STL), один раз навіть прозвучало слово Rust. Гейлсберґ якось невдало спробував охрестити Б'ярне BDFL. Ще купа вельми цікавих людей посвітили обличчями. Та й таке. Раджу короч!

Ну а щоб трохи збалансувати враження, потім можна полірнути оцією чудовою статтею про те, чому 💻 котиться в прірву через свою (майже) непорушну політику збереження зворотної сумісності. Там про те, скільки за останні роки додали фічей в мову та стандартну бібліотеку та скільки з них реально досі живі. Дізнався, що вже навіть std::function неофіційно вважається застарілою, і треба використовувати щось інше (але з бібліотеки звісно не видалять, бо купа коду написана). До тієї самої прірви C++ котитися ще доволі далеко, але їм би все-таки щось вирішувати з розміром комітету, бо той цирк, що зараз, на користь аж ніяк не йде.

Ну а дядьку Б'ярне можу хіба що побажати побільше здоровʼя та ще раз подякувати за таку топову мову!