Сіпласпластик

Робив задачі одинадцятого дня на Elixir 💻. Хотів колись опанувати цю мову, щоб писати ботів для телеграму не на Python, тож пару років тому сів за Erlang 💻 (не шукаю простих шляхів — вирішив йти від «початку»). Але врешті закинув.

Зараз же відкинув принциповість, просто сів та почав писати. І мені дуже сподобалося. Це буквально Erlang з нормальним синтаксисом. Дуже подобається пайп |> (хоча звичайна крапка все одно була б краще, бо одне натискання на клавіатурі замість трьох), подобається зіставлення з шаблоном тощо. Гляньте ось:

def solve_like_noob(iterations) do
  data = read_data(@file_path)

  1..iterations
  |> Enum.reduce(data, fn _, acc -> 
       acc |> Enum.flat_map(&replace_naïve/1)
     end)
  |> length()
end

Не обійшлося й без WTF-моментів. Наприклад, функції не можуть бути використані в гардах інших функцій чи в case — можна тільки макроси. Мабуть, якась внутрішня специфіка. Але не сильно заважало.

Звісно, у моєму випадку писати на Elixir сенсу було не надто багато, бо він не в таких задачах себе найкраще проявляє. Я там намагався трохи погратися з багатьма процесами, але врешті дропнув цей шматок коду. Втім чисто відчути мову мені вистачило. Я подумки це застосував до того, що вже знаю про Erlang, і загальна картина мені подобається — точно не останній мій раз використання Elixir.

Девʼятий день не було часу вже розвʼязувати того тижня, тому вирішив написати знов на Haskell. І написав… першу задачу. А на другій нормально так похавав лайна — плюнув та наразі скіпнув. Колись повернуся та перепишу на щось інше. А сьогодні пару слів про Go 💻, який я використав для десятого дня. (Зараз насправді вже 17-й, а я на 15-му — трохи відстаю досі).

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

Але-е-е-е. Мова також максимально нудна! Навіть в Python можна хоча б декораторами обмазатися, щоб зробити упорото, зате красиво. А тут тупо ніфіга нема.

Треба було множину точок зробити (set) — в стандартній лібі немає. Довелося емулювати через map[point]struct{} 🤮 (це типу мапінг з точок в порожні структури).

Захотілося фільтранути список по предикату — фільтра немає 😵 Ок-ок, раніше не було дженеріків. До речі не уявляю, як люди жили в статично-типізованій мові без дженериків — жах. Наче Java 2. Та зараз-то вони є! Очікуєш, що ось нині-то подобавляють нарешті зручностей! А ніфіга. Накостилив свій:

func filter[T any](input []T, predicate func(T) bool) []T {
  result := []T{}
  for _, item := range input {
    if predicate(item) {
      result = append(result, item)
    }
  }
  return result
}

Таке короч. Жити можна, але хз. Наче жуйка, що втратила смак пів години тому.

Трохи забарився я з вирішенням задач на Advent of Code через відрядження — зараз наздоганяю. Але розвʼязав того тижня задачі восьмого дня на Nim 👑, про який скажу пару слів.

Вже не згадаю, як саме я на цю мову вийшов колись, але зацікавився одразу. Аж настільки, що купив паперову книгу. Прочитав її, покодив трохи й закинув. Проблема була не стільки у мові, скільки у її розвитку. Якось не відчувалося зрілості в головних мейнтейнерах, версії 1.0 знов-таки не було досі (а мене прям так і тягне на сире лайно: Rust у свій час, потім Nim, Red тощо), ну й купа інших сумнівів.

Але! Версію 1.0 вони все-таки зробили. А потім і 2.0. У мене ось зараз 2.2 стоїть вже. І знаєте шо? А норм!

Синтаксис — така собі суміш Pascal та Python. Є дженеріки, в яких доволі легко обмежити тип якоюсь підмножиною. Я для розвʼязання задачі оперував 2D-координатами: варто було б зробити окремий тип на це, та я обмежився кортежами. Ось, наприклад, перевантажений під мою задачу оператор - (мінус):

proc `-`[T: int32 | int64](a, b: (T, T)): (T, T) =
  ((a[0] - b[0]), (a[1] - b[1]))

Дуже лаконічно, але при цьому легко читається, як на мене.

Інша прикольна фіча — Uniform Function Call Syntax. Зазвичай в ООП-мовах, якщо хочете додати метод то якогось типу, ви мусите його описати в самому класі. Деякі мови пропонують різні рішення, щоб це покращити: partial classes, mixins, traits тощо. В Nim ви просто пишете звичайну функцію на кшталт add, а потім можете її визивати хоч як add(a, b), хоч як a.add(b) — ці записи тотожні. Для C++ до речі теж є аналогічна пропозиція, але так досі нічого й не впровадили.

Окрім цього я вже колись згадував (і в статті) про discard. В тому ж C++ можна позначити функцію, яка повертає значення, як [[nodiscard]], і тоді її значення не можна проігнорувати без ворнінга. А в Nim навпаки! Якщо функція щось повертає, а ви це значення не використали, то компілятор одразу помилку пише, якщо не проставити явно discard.

Ну й наостанок скажу, що в Nim прям дуже легко писати код, який виконуватиметься під час компіляції. Фактично майже нічого й робити не треба: інколи хіба що прагму до функції додати, інколи кудись const поставити. Я у своїй програмі трохи читернув заради швидкодії: я там читаю файл з даними та будую з нього матрицю — все на етапі компіляції. Якщо трохи заморочитися, то можна було б взагалі все рішення обрахувати в компайл-таймі, а прога при запуску його просто в консоль виводитиме 😆

Короч, приємна доволі мова. Навіть хз, чому я не використовую.

Тепер власне щодо використання та задач.

Весь синтаксис мови — це купка символів на кшталт дужок і ще декількох типу двокрапки та апострофа. Решта (всі оператори, конструкції для control flow, функції стандартної ліби тощо) гіпотетично могли б бути описані чисто за допомогою них. На практиці ж заради швидкодії деякі функції мають нативну імплементацію, деякі описані в Red/System, а деякі вже на чистому високорівневому Red. Я писав тільки на останньому. Зате згадав і використав їхній хвалений parse-діалект, який дозволяє описувати граматику (PEG). Не те щоб у задачах це сильно треба було, але мені кортіло.

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

Доки воно проганяло це рішення, я спробував скомпілювати прогу в нативний бінарь. Довелося виправити пару помилок, які цьому заважали, та я встиг і пофіксити, і скомпілювати, і запустити, і отримати результат — все доки інтерпретація тривала ) Вислідний бінарь під вінду займає 904 КБ і не має жодних залежностей. Як на мене, вельми непогано!

Чи можна зробити рішення швидшим? Я певен, що так. Бачу низку можливостей. Але… Найбільше сповільнює відсутність досвіду. Вкрай боляче писати мовою, коли доводиться буквально шукати, як проітерувати послідовність або свопнути дві змінні 😵‍💫 Однак проміж роботою та побутовими справами я за вечір та пів дня прочитав 90% книжки про Red, що трохи освіжило деякі знання.

У підсумку: ця мова мені досі дуже подобається! Дати б собі трохи більше часу з нею — і це пісня. Дуже прикро та болісно, що її розвитком не займаються й уже скоріш за все не почнуть. Надії вже не маю.

Розповім вам про Red 🔺. Намагався позавчора розв'язати задачі на Advent of Code за допомогою нього, витратив годину, врешті плюнув та написав найтупіше рішення на Python 💻 за 5 хвилин. Не зайшло якось з редом, бо все забув. А вчора зробив другу спробу.

Про саму мову я дізнався років 7 тому, і одразу закохався. Мою увагу привернув їхній діалект для написання реактивних інтерфейсів — я це обожнюю, як можна було здогадатися з моєї прихильності до QML. Але виявилося, що мова може запропонувати значно більше.

Річ у тім, що там доволі легко створювати власні «діалекти» — фактично eDSL, бо мова уся побудована на блоках, які є і даними, і кодом одночасно, приблизно як у ліспах. Red є розвитком іншої маловідомої мови REBOL. Останній до речі навіть більш популярний за ред в певних ентерпрайз-колах, бо на ньому, як і на реді, можна буквально в декілька рядків наклепати прогу для розв'язання повсякденних задач, та ще й з UI під вінду! Також цікаво, що автори JSON, коли його створювали, надихнулися саме ріболом. З доданих важливих можливостей відносно REBOL в реді є, наприклад, компіляція в машинний код, що робить його значно швидшим. Також є діалект Red/System (а ля 💻), який дозволяє писати дуже низькорівневий код прямо в реді. Це якраз одна з їхніх selling points: Red здатен задовольнити потреби від низько- до надвисокорівневих.

Тепер про погане. Сайт ледве живий вже бозна-скільки. Роадмап давно пішов нахуй. Коли я починав, актуальна версія була 0.6.4, і вони обіцяли зробити 1.0 протягом року чи півтора. Зараз актуальна версія «0.6.5», бо вони давно забили інкрементувати версії, а просто збирають дейлі-білд та паблішать його. В якийсь момент авторам мови сеча вдарила в голову, і вони вирішили зробити свій блокчейн на реді, а потім навіть, здається, якісь свої токени парили. За декілька років потому написали в блог, мовляв, «все, от тепер точно повертаємося до максимально активної розробки» — і відтоді майже тиша.

Стан мови на сьогодні: асинхронного I/O нема начебто (вони документацію теж хєр забили оновлювати), з мережевою підтримкою щось мутне, підтримки x64 — нема!!! (що одразу ставить хрест на macOS, адже вона більше не вміє запускати x32). Зате є підтримка MS-DOS, наприклад, або Windows XP 😂 Також вміє збирати під Raspberry Pi, навіть під Pico, і буцімто під Android.

Колись весь їхній тулчейн був одним бінарем на півтора мегабайта. Саме так, навіть повторю: усе, що вам потрібно було для розробки — це один бінарь! Зараз вони розділили його на три: red-toolchain для компіляції, red-cli для термінального REPL та red-view — для гуїшного. Я хотів собі стягнути red-cli, щоб легше було використовувати у VS Code, але вінда не дала це зробити, бо задетектила там троян! 🦠 Це пиздець, панове.

Короч, обмежився red-view та red-toolchain, бо на них принаймні не скаржиться, але досі сумніваюся, чи не майнитиме мій комп віднині їхні всраті токени 😬

на випадок, якщо кложа здається занадто щільною, осьо вам рішення 4.2 (вчорашнього) на uiua:

Xs ← [
  "M\WM"_"\WA\W"_"S\WS"
  "M\WS"_"\WA\W"_"M\WS"
  "S\WM"_"\WA\W"_"S\WM"
  "S\WS"_"\WA\W"_"M\WM"
]

/+♭⊞⌕ Xs ⧈∘ 3_3 I

Та-а-а-а-кс… Виявляється, у свіфті є інтероп з C++. Не через С! Можна викликати свіфт-код з плюсів, можна — плюсовий код зі свіфта. Оце вже цікаво!

А ще у мене пет-проєкт під STM, де стоїть вибір між 💻, 💻 та 🕊. Думаю, спробую тепер якраз останнє там застосувати.

Останнім часом дуже пізно прокидаюся, тож в AoC-лідербордах (навіть у моєму власному 4272620-3487bc2a) у мене шансів небагато. Сьогодні ж прокинувся, бо почув, як кіт десь блює 😺🤮. А потім дивлюся на годинник — майже сьома 🕖

Короч попри те, що поспав менше чотирьох годин, не втримався та сів глянути, що за задачки. Писав на Swift 🕊 — і це мій перший досвід. Мова сама по собі непогана, хоча й не сказати, що я побачив там якісь прям дуже свіжі ідеї — радше це доволі приємна комбінація вже існуючих. Синтаксисом чогось місцями дуже нагадала C#, тільки без зайвих символів типу крапки з комою та дужок, де не треба. Є опціональні типи (aka монада Maybe), які вбудовані прямо в мову, є класи, структури, енами, актори, є зіставлення з шаблоном тощо. Ну короч доволі приємна для написання мова.

Вибрав її, бо хотів згодом спробувати нею під мікроконтролери щось написати: від сішки ригаю, C++ замахав — хочеться вже щось для душі, тільки б не Python.

Що не сподобалося — повідомлення про помилки. Ну тобто круто, що компілятор багато всього перевіряє, а потім тобі ще й пише, от тільки пише він забагато хуйні. Каже мені, мовляв, не можу викликати функцію з такими параметрами, бо там типи отакі, а воно очікує інші. А потім ще простирадло тексту про те, як він намагався інші варіанти функції підібрати, але нічого не спрацювало — прям як вивід про помилки з шаблонами в C++, їй-богу. Або ще дивіться:

Building for debugging...
error: emit-module command failed with exit code 1 (use -v to see invocation)
~/aoc2024/day4/Sources/day4/main.swift:159:79: error: extra argument 'encoding' in call
if let example = try? String(contentsOfFile: "data/task1.example", encoding: .utf8) {
                            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
~/aoc2024/day4/Sources/day4/main.swift:159:79: error: cannot infer contextual base in reference to member 'utf8'
if let example = try? String(contentsOfFile: "data/task1.example", encoding: .utf8) {
                                                                             ~^~~~
error: fatalError

Кричить на мене прям страшними словами. Виявляється, що не вистачало import Foundation на початку, але компілятор мені з цим не підказав.

За годину часу, звісно, я повністю мову не відчув. Треба погратися з корутинами хоча б та подивитися, що там ще є. Але задачки для Advent of Code я розвʼязав, а в кінці ще й встиг на стрім пана Соловйова, де він бився з маніпуляціями зі списками в кложі 😆 Я у себе в першій задачі просто ту матрицю потранспоузив туди-сюди, «згенерив блядські діагоналі» © — та й потому. Хоча мушу визнати, що з діагоналями копайлот трохи допоміг, а то я знудився вже міркувати, як ті індекси кляті там крутити. Друга задачка була цікавіша, але легша. Тупо захардкодив у себе індекси знов, хоча варто було б там зробити нормальний пошук 2D-патерна в матриці.

Поки що підсумок такий, що, мабуть, затримаюсь я зі свіфтом ще трохи на погратися. Щось у ньому є все ж.

Так-так, задовбав уже вас усіх з Advent of Code. Але довго я не витримаю, обіцяю.

Втім сьогодні задачі були вкрай легкі. І особливо — якщо розвʼязувати їх за допомогою мови 🆕.

Вкотре нагадую, що Nushell — це наразі найкрутіша та найзручніша оболонка, яка до того ж ще й стрімко розвивається (і написана на Rust as if someone cares). Мова Nu — статично типізована, передає через пайп структуровані дані, має купу корисних функцій у стандартній бібліотеці тощо. Просто погляньте:

export def solve-one [fileName: string] [nothing -> int] {
  log info $"Reading from ($fileName)"
  
  let result = (open $fileName
    | parse --regex '(mul\((?P<a>\d+),(?P<b>\d+)\))'
    | into int a b
    | upsert c {|it| $it.a * $it.b}
    | math sum
    | get c
  )
  
  $result
}

Кайф же! (Взагалі-то тут можна було одним reduce все зробити, але мені отак покроково більше подобається). І працює швидко: приклади та вхідні дані для обох задач обробляє за 20 мс разом узяті.

Забудьте про Fish, PowerShell чи, боже збав, Zsh та Bash — тільки Nushell!

Класно бути програмістом на C++: захотів покодити іншою мовою — скомпілив її 😂

От я сьогодні з цього почав, бо вирішив згадати мову io, але під arm64 на macOS її немає, бо там якийсь асемблерний код не компілюється. Автори кажуть, мовляв, треба окрему версію Homebrew поставити для цього, але то якогось занадто головняково, тож я просто скомпілював з сорців. Версія з master одразу падала з помилкою, тому довелося трохи пострибати по теґах.

Першу сьогоднішню задачу з Advent of Code я розвʼязав дуже швидко, а от другу вже повертів туди-сюди, бо, як це часто буває, налажав десь у корнер-кейсах. А там якраз був ОДИН такий 😅

Тепер про саму мову. Вона наче й не складна, але є там трохи дивні моменти, коли начебто схожі конструкції поводять себе трохи по-різному.

З класного: там все є виразом (expression), тобто у всього є результат, тому можна хоч цикл for записати у змінну. Ну, насправді це й не цикл, а просто функція в Object. Взагалі треба дуже уважно дивитися, що яка функція повертає, бо інколи це не те що ти очікуєш.

Ще з цікавого: вирішив я написати функцію з трохи тупою назвою mapPairs, яка виконує блок коду на кожній парі зі списку та повертає список результатів. Мабуть, можна було цікавіше щось вигадати, але пох.

Використовую її потім якось отак (тут report — це список):

increasing := true
decreasing := true

report mapPairs(l, r,
  increasing = increasing and l < r
  decreasing = decreasing and l > r

  result := (increasing or decreasing) and (l - r) abs <= 3
  "#{l}, #{r}: #{result}" interpolate println
  
  result
)

Прикол тут наступний: якогось спеціального синтаксису для лямбд немає. mapPairs — це просто метод з трьома параметрами: l, r та блок коду. Причому l та r я до того ніде не створював, але в блоці коду їх використовую разом з іншими змінними з локального скоупа, звідки викликаю це. Як же це працює? А отак:

List mapPairs := method(
  left := call argAt(0) name
  right := call argAt(1) name
  body := call argAt(2)

  context := Object clone prependProto(call sender)

  if(call sender hasLocalSlot("self"),
    context setSlot("self", call sender self)
  )

  result := List clone

  for (i, 0, self size - 2,
    context setSlot(left, self at(i))
    context setSlot(right, self at(i + 1))
    result append(context doMessage(body))
  )

  result
)

У context клонується все з sender (так-так, в io методи — це надсилання повідомлень, як у SmallTalk), потім у ньому ж створюються l та r, а потім отой блок коду виконується вже в цьому контексті. Трошки винесло мені мозок короч.

Працює io десь разів у 10 повільніше за Haskell. Файл на 1000 рядків у мене оброблявся 200 з копійками мілісекунд. З іншого боку, оптимізаціями там і не пахне. Не казатиму вам, яка складність у мого алгоритму, бо там треш ))

Там сьогодні почався Advent of Code: треба розвʼязувати задачки будь-якою мовою. Щодня по дві штуки.

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

Сьогодні почав з Haskell 💻. Руки досі памʼятають, хоча й витратив десь годину, щоб встановити все й згадати, як запускати 😅 На розʼязання самих задач пішло десь 25 хвилин, бо зробив усе вкрай прямолінійно, утім… яка вже різниця.

Ще навіть не певен, чи не обламає мене завтра продовжувати ) Подивимося. Долучайтеся також чи шо, я навіть для чогось лідерборд створив: 4272620-3487bc2a.

Словотвірне відкриття дня:

🧱 Цеглина — це глина

🦖

Був у мене донедавна «кишеньковий» роутер від TP-Link (TL-WR902AC) за 25 євро. Шматок дешевого пластику, проте, свою справу він робив: зупиняєшся у якомусь готелі, наприклад, а там Wi-Fi з цим тупим так званим captive portal — це коли тебе спочатку кидає на веб-сторінку авторизації. А деякі ще й обмежують кількість пристроїв, які можна одночасно використовувати. Телефон чи планшет ще хєр би з ним, але на якійсь ігровій консолі вже не скористаєшся, якщо там навіть бравзера немає. В принципі можна з телефона просто «затетерити» 4G/5G, але це якось незручно, ще й не завжди звʼязок норм.

Звісно, проблема трохи надумана, особливо з моїми відпустками два рази на пʼять років, а останнім часом навіть вони «локальні», та все ж зручно було: просто підʼєднуєш цей роутер до Wi-Fi/Ethernet де завгодно й сидиш зі своїм NAT. От тільки цього року він раптово вмер. Просто перестав будь-які ознаки життя подавати.

Тож буквально ось-ось узяв собі замінник — китайський GL-iNet Beryl AX. Він, звісно, трохи більший вже за розміром (досі менше за айфон, але товщий звісно), зате значно фічастіший. По-перше, тут з коробки йде OpenWRT з якоюсь надбудовою від GL-iNet (втім можна це все знести та прошити чистий OpenWRT), а це дуже потужна прошивка. Наприклад, я собі в декілька кліків підняв Taillscale 💠 прям на роутері. По-друге, у ньому 2,5-гігабітний Ethernet, Wi-Fi 6, 512 MB RAM (вдвічі більше, ніж у моєму першому компі), можливість підʼєднати зовнішнє сховище через USB або мобілку як модем, підтримка Wireguard з коробки тощо. За якимсь хєром ще руснявий AdGuard Home вбудований, але це ж OpenWRT — можна легко видалити.

Короч, якось так виходить, що цей роутер за низкою параметрів краще, ніж між основний домашній 😅 Коштував, правда, вже аж цілих 75 євро, але якщо він протримається хоча б років 8–10, як попередній, то буде норм.

Вирішив спробувати написати парсер бінарного формату логів (DLT — Diagnostic Log and Trace protocol). Є, звісно, офіційна відкрита специфікація від AUTOSAR. Читати такі зазвичай вкрай неприємно — дуже сухий текст з перехресними посиланнями на реквайрменти, причому в PDF-ці це не клікабельні посилання, а тупо текстовий ідентифікатор у дужках.

Але якщо перебороти себе з читанням, то якраз імплементувати щось по таких спеках — це просто пісня. Все чітко та детально розписане — бери й транслюй у код собі.

Так я й зробив. Вирішив використовувати Kaitai Struct, про який вже згадував раніше. Формат DLT не суперскладний, але вельми обʼємний, тож нормально часу на це пішло. Потестував на парі маленьких файлів — все чудово.

А потім запускаю у їхній (локально піднятій) web IDE на більш практично-реалістичному файлі на 1,3 мільйона записів — а воно всирається десь посеред парсингу і не пише, де саме. Двійковим пошуком швидко знайшов, що відбувається це в районі 18093-го запису. Дивлюся — і не розумію. Навіть десять разів перевірив свою імплементацію.

Короч, у файлі зберігаються бінарні записи один за одним. Починається все з ["DLT", 0x1], далі йде storage header, standard header, опціональний extended header та payload. В пейлоді лежить довільна кількість «аргументів» різних типів: тип вказаний бітово на початку пейлода, а саме значення лежить за ним. І там вказано, що має бути unsigned int64, але лежить всього 4 байти! Ну й парсер такий: «Відмовляюся працювати далі!»

До того ж у standard header лежить загальна довжина повідомлення, і по ній чітко видно, що там саме 4 байти в кінці лишається. Але! Якщо відкрити у якійсь програмі для перегляду логів, наприклад у Chipmunk, то воно хаває файл без проблем. Як?

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

Але головне питання тут не до Chipmunk. Я щось просто не второпаю, як можна було записати такий файл. Може й тупо баг, звісно, і там мав бути uint32, а не uint64, але трясця — тут же навіть думати не сильно треба було: маючи спеку, просто йдеш по ній, пишеш код, а потім пишеш тести, бо в специфікації всі реквайрменти максимально чітко прописані, де який біт має бути виставлений за яких умов. Сумно якось це все трохи 🥲

P.S. До речі, у процесі ще намагався використовувати ImHex, про який теж згадував, але при написанні власних патернів він крашить що курва. Неможливо користуватися взагалі.

як раз на цю тему (с++, пост ще не прочитав) сьогоднішній мем в нашій групі мемів

Попри назву каналу я тут про C++ пишу не надто часто, як мені здається. Ну бо що про нього писати — все й так зрозуміло. Тим паче я взагалі UI зазвичай кодю, тобто кнопки по вікну рухаю, тож чого від мене взагалі можна чекати.

Та вчора глянув доповідь Саттера з cppcon, і щось прям кайфонув. Напрям, яким рухається розвиток мови, мене здебільшого влаштовує (хоча методи, якими це досягається — ну таке…).

Ця доповідь є продовженням його іншого виступу 2017 року про метакласи. Я ще тоді був у захваті, однак, потім було 7 років «тиші».

Короч, якщо коротко, то все йде у компайл-тайм (раптом досі не було очевидно), і конкретно зараз всі розмови ведуться про рефлексію, яка теж працюватиме під час компіляції. Спершу ця тема з компайл-таймом виглядала мені так, наче це буде сильно обмежувати, та з іншого боку, якщо вам треба робити рантайм-рефлексію, то ви можете під час компіляції нагенерувати собі всі потрібні засоби для цього, щоб потім можна було в рантаймі використовувати. (Але синтаксис там пиздець. А ви чого очікували? гг).

Ще Саттер зачепив тему safety звісно, бо куди ж без цього нині. Того, що я почув, мені достатньо, щоб продовжити успішно ігнорувати Rust 😂

Потім ще з Александреску вони на сцені потеревенили про регулярні вирази та парсери граматик, для яких під час компіляції генерується оптимальний код. І щось згадали про AI. Ну й таке. Помріяли й досить.

Ще була прикольна цитата Страуструпа про те, що «всередині C++ сидить значно менша, безпечніша, зручніша й загалом крутіша та лаконічніша мова, яка проситься назовні» (і ця мова — LISP 😂.)

Загалом цікаво доволі, мені сподобалося. Хоча півтори години слухати про 💻 — це треба або значну витримку мати, або не хотіти займатися іншими справами ще сильніше 😅

Сьогодні майстер-клас від 💻 про те, як не треба робити #UI.

Якщо хтось чекав можливості знову порекламувати мені Rust, то ось вона.

Писав учора на C++ знов. Прога вже чудово працює на macOS — треба було тільки перезібрати під вінду. Але білд пофейлився з отакою помилкою (і ще з понад сотнею інших):

dmp_diff.h(65): error C2059: syntax error: '('

Так, а шо там у нас на 65-му рядку?

enum class Operation { DELETE, INSERT, EQUAL };

🙄 Е-е-е-ем…

Щоб ви розуміли, в цьому хедері навіть інклудів немає. Але! Вони були в тій одиниці трансляції, куди цей хедер потрапляв. Там вище була пачка інклудів кьюта, і я підозрюю, що якийсь з них врешті інклудив Windows.h, а десь там воно дефайнить макрос DELETE. Я колись давно з цим вже стикався, та на жаль забув, тож знов витратив на це зайві пів години.

Після виправлення цього нарешті зібралося й запрацю… крашнулося на старті. В дебагу крашить гарантовано, в релізі 3 рази з 5 🤔 Ще мінус пів години життя. Щоправда 20 хвилин я витратив на те, щоб підʼєднати дебажні символи та вказати шлях до сорців, щоб хоч якось збагнути, де проблема. Це не допомогло. Але інтуїція врешті скерувала погляд на один клас, де я забув проініціалізувати вказівник nullptrʼом 🤡

Ну нічо, колись нарешті модулі в плюсах запрацюють, а потім заімплементять Safe C++, і тоді заживемо 😂

Як вам «новий» прогрес-бар для відосів на ютубі?

Я вже декілька тижнів це спостерігаю й щоразу висаджуюся, що у мене монік поплив і паплюжить кольори. Питання тут два: Нахуя та навіщо?

Уявіть собі роботу в гуглі: круто, еге ж? Компанія мрії. Мабуть пів року це узгоджували.

Почуваюся як той чувак з анекдоту, що 10 років рахує сірники в коробках. Сподіваюся, ви це теж бачите 😅