Щоразу, як дивлюся або читаю пана Соловйова, хочеться спробувати Clojure, особливо на тлі незрозумілостей з Red.

Ліспи з їхньою купою варіацій і REBOL з наразі єдиним нащадком Red — це D&D 🎮 світу програмування. Є десяток базових правил, а далі все обмежується лише вашою фантазією (і спроможностями заліза гг). Обидва мають суперпростий синтаксис — можна навіть сказати, що ніякого синтаксису немає: ви просто пишете слова, а потім наділяєте їх власними значеннями. Звучить як казка.

Я вже намагався зробити підхід до Clojure десять років тому, але вочевидь був неготовий ментально. Зараз же зробив другу спробу і… не зміг себе пересилити: дивлюся в цей короткий лаконічний код, а подумки бачу, як JVM нестямно жере памʼять мого компа, і уявляю, як мені доведеться йти крізь ієрархію тек, щоб нарешті знайти там свій єдиний файл з кодом.

На щастя з одного зі стрімів пана Соловйова я дізнався про існування мови Janet 👩‍🦰 — дуже схожого на кложу діалекту ліспа, який написаний на сішці, важить майже нічого, легко інтегрується з сішним кодом в обидва боки тощо. І спробував її для задач на пʼятнадцятий день!

На початку було дуже складно, зокрема через відсутність навичок роботи з реплом та редагування лісп-коду. «Кляті дужки!» 😂 Без paredit погано, з paredit погано — про це окремо ще розповім.

Одним із сюрпризів став той факт, що на ліспі взагалі-то можна (і дуже легко) писати імперативно. Чогось був переконаний, що це чисто ФП-шна штука на кшталт Haskell. Тож тут одразу +1 до приємності.

У Janet також є фішка з підтримкою PEG, якою вони надихнулися зокрема з REBOL/Red. Для задачі воно було непотрібно — можна було тупо працювати з charʼами, але мені кортіло спробувати, тож я запарсив файл отакою граматикою:

(defn parse-input [input]
  (def grammar
    '{:wall (/ "#" :w)
      :empty (/ "." :e)
      :box (/ "O" :b)
      :robot (/ (* (line :row) (column :col) "@") :r)
      :cell (+ :wall :empty :box :robot)
      :line (* (group (some :cell)) "\n")
      :grid (group (some :line))

      :up (/ "^" :up)
      :down (/ "v" :down)
      :left (/ "<" :left)
      :right (/ ">" :right)
      :direction (+ :up :down :left :right (? "\n"))
      :moves (group (some :direction))

      :main (*
             :grid (-> :row) (-> :col)
             "\n"
             :moves)})
  (let [[grid row col moves] (peg/match grammar input)]
    [[(dec row) (dec col)] grid moves]))

Через наявність PEG у Janet немає підтримки регулярних виразів, бо в принципі вони непотрібні. Я не певен, чи це добре: все-таки інколи фігачнути маленький regexp швидше й легше, але ок. Іншим мінусом Janetʼівського peg/match є той факт, що вона працює тільки з рядками на вході. Якщо порівнювати з ріболівським parse, це сильний недолік, адже там вони прям блоки коду (а код — це дані) парсять тим же самим парсом. Це логічніше, бо яка різниця, що ви отримуєте на вхід: список текстових літер чи список кейвордів? Через це нові діалекти в REBOL робити легше й приємніше.

Із загальних приємностей Janet: є fibers, threads, channels, streams тощо — все, що потрібно, є. Також доволі розвинена стандартна бібліотека, менеджер пакетів, FFI взаємодії з сішним кодом.

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

Другу задачу, яка фактично є ускладненою версією гри Sokoban, я так і не доробив трохи. Коли починав, то прийняв не найкращі рішення щодо структур даних, потім нахуєвертив зверху, задобався з цим боротися, та й загалом дуже втомився. На цьому мій Advent of Code завершився.

Я ще згодом напишу підсумки про саму подію, а зараз можу впевнено сказати, що Janet — це одна з моїх нових улюблених мов!

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

Я брав участь вперше, і мені дуже сподобалося! Взагалі-то я алгоритмічні задачки не дуже люблю. Алгоритми — мій слабший за інші бік, і так було завжди. У роботі мені вистачало базових знань відмінностей між стандартними контейнерами, а основні рішення були радше архітектурними, ніж алгоритмічними. Ті ж BFS/DFS я не писав власноруч років 15. А зараз вже багато років я взагалі не отримую грошей безпосередньо за написання коду, бо давно посідаю роль майстра на всі руки (technical product manager, що б це не значило).

Тим не менш, я спробував розвʼязати задачі в перший день, у мене вийшло, а далі вже складно було відірватися. Разом їх аж 50 штук — по дві на кожен день з початку грудня й до Різдва. З них я отримав 34⭐️, що вважаю непоганим результатом.

Прикол Advent of Code в тому, що він буде для вас настільки складний, наскільки складним ви самі хочете його зробити. Планка дуже низька, але ніхто не забороняє вам поставити особисті цілі: робити максимально короткі рішення, рішення з O(1) по памʼяті, розвʼязувати все в якомусь Excel чи COBOL — на ваш смак!

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

Згодом мені неодноразово допоміг своїми порадами та поясненнями суперкрутий пан @ololocat, та й у принципі тримав мене в тонусі весь цей час, проте, до кінця я все-таки не дотягнув 🥲

За весь період я писав на Haskell 💻, io 💻, Nu 🆕, Swift 🕊, Python 💻, Red 🔺, C++ 💻, Nim 👑, Go 💻, Elixir 💻, Dart 💻, SWI-Prolog 🦉, Ada 💻, Janet 👩‍🦰, Crystal 🔮, Lua 💻 (і Terra) і PHP 🕸, отримавши багато корисного досвіду. (Не встиг спробувати: Pharo, Racket, F#, Uiua, Gleam, Zig).

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

Якщо хтось захоче повторити мій шлях зі швидким опануванням якоїсь мови програмування (не треба), то ось кілька порад:
• Якщо є офіційний туторіал від авторів мови, я читаю його. Вони зазавичай знають, з чого почати й у якій послідовності рухатися.
• Допомагає Learn X in Y minutes. Бували випадки, коли коротка стаття тут давала більше корисного, ніж офіційна документація.
• Дуже стає в пригоді ШІ-шка. Жодний з алгоритмів, який я просив її зробити, вона не зробила правильно, але в питаннях «як прочитати файл» або «як передати функцію у функцію» — неоціненний помічник на початку.
• В рідких випадках довелося читати книжки.
• Ну й краще мати попередній досвід зі схожими мовами 😅 Але про це докладніше вже завтра.

Тож повернемося до списку мов з попереднього допису. Розділю їх на категорії:

Проходняк (суто для мене, бо особливих інсайтів не отримав):

- C++, Python — мої дефолтні мови наразі. Найчастіше пишу ними, але буду зсуватися в бік наступного списку.
- Nim, Go — перша загалом норм, але мені нема, що нею писати. Друга інколи стає в пригоді на роботі, хоча синтаксично не дуже зайшла.
- Dart, Crystal, PHP — ¯\_(ツ)_/¯
- Lua — варто знати, але знати там нема шо.

Практичні:
- Nu — моя повсякденна мова в оболонці, якою я користуюся буквально щодня. Проста, практична й приємна.
- Swift й Ada — обидві є моїми кандидатами на заміну C++ для мікроконтролерів. Перша хіпстерська, друга зі спадщиною. Поки не вибрав — думаю, що користуватимуся обома потроху.
- Elixir — наче Erlang з приємним синтаксисом. Використовуватиму.
- Janet — мій перший лісп. Варто було б додати до концептуальних, бо тема про оперуванням кодом як даними, макроси й оце все — це дуже цікаво й важливо. Але я ці концепції вже збагнув, коли знайомився з Red, тому тут приблизно знав, чого очікувати. Хотів якусь таку мову, щоб ще й збиралося в один бінарь, і ось маю.

«Концептуальні»:
- про Haskell я вже сказав.
- Далі io, яка колись давно допомогла мені трохи краще побачити «справжнє» ООП, хоча, мабуть, краще б я спробував Pharo.
- Red — можливо, найособливіша мова з усього списку, але трохи просрана (писав тут і тут).
- Prolog — це мій новий краш ❣️ З ним я знову почуваю себе початківцем (хоча знання Haskell допомагає). Вважаю, що розібратися з логічним програмуванням — абсолютний маст хев.

Наразі все. Бажаю всім гарного Нового року. Я ж трохи збавлю темпи написання сюди — треба відпочити.

Якщо хтось раптом думав теж вивчити 🦉 Prolog за моєю порадою, то маю для вас отакий список посилань на різні матеріали. Спочатку збирав його власноруч, потім дружбан докинув туди ще купу PDF-ок.

(А найкраща подяка з вашого боку — це репост 😉).

Люблю інколи поспостерігати за іншими, щоб побачити на їхньому прикладі, як легко все проїбати. Тут «все» може значити дуже різні речі звісно.

Ось торік Sonos — виробник доволі класних (мені подобаються) і недешевих бездротових колонок — вирішили переписати свою прогу на телефони з флаттера на флаттер 💻. Релізнули її в сирому вигляді попри застереження розробників. Половина фічей, що були доступні раніше, зникли, у багатьох користувачів були проблеми з підʼєднанням тощо. В результаті: −16% прибуток, −13% ціна акцій, −100 людей через скорочення, −1 CEO (пішов у відставку), −1 CPO (Chief Product Officer — пішов з компанії). Я вже колись писав, що компанії, які роблять чудове залізо, зазвичай роблять вельми кепський софт. Ось зайве підтвердження.

А останніми днями вже у світі 3D-друку трагедія. У мене принтера немає, але темою цікавлюся, тож зараз і вам розповім.

Є короч китайська Bambu Lab, яка робить дуже юзер-френдлі принтери — майже «apple світу 3D-друку». Ними захоплюються, всі їх радять новачкам, бо по співвідношенню ціни і якості вони класні. А у тих, хто будує на цьому бізнес, взагалі ферми по 60 і більше принтерів. До того ж існують моди, додаткові пристрої, спеціалізований софт тощо — все для того, щоб зробити ці принтери ще кращими. Іншими словами — чудова інвестиція грошей. Була.

Була, бо хтось у Bambu певно подумав, що гроші проходять повз, втрачені продажі (aka «недоотриманий прибуток») і ось це все. Тож вочевидь вони вирішили вендор-локнутися, причому традиційно під прикриттям турботи про безпеку. Пишуть, мовляв, вам прилетить апдейт на прошивку, після встановлення якого весь 3rd-party софт для керування принтером іде нах, відкритий протокол MQTT іде нах, перегляд стріма з камери йде нах, LAN-мод іде нах, бо тепер треба створювати обліковий запис і авторизуватися в їхній хмарі. А якщо прошивку не оновити, то принтер в якийсь момент може відмовитися друкувати. Я прям уявив, як в цей момент у них на мапі світу з підʼєднаними принтерами в якійсь графані потухла половина планети 😂

Звісно у людей миттєво згоріли сраки. Ютубери запустили конвеєр відосів про те, як вони помилилися щодо попередніх порад продуктів цієї компанії і все таке. В українському сегменті інтернету це б назвали «провезти шакалячим експресом». На редіті всі кинулися писати, що продають свої 100500 принтерів і переходять на Prusa (інший відомий виробник).

Потім виявилося, що для роботи з 3rd-party софтом Bambu все-таки лишила можливість — додаткову прогу Bambu Connect (на електроні), яка пропонує enhanced security ✋. Тобто напряму принтером керувати все-таки вже не можна, але можна закидувати в цю прогу інструкції, а далі вона сама. Звісно ж менше ніж за добу хтось відреверсив її, збагнувши, як діставати приватні ключі для авторизації 🤡

Чотири дні потому Bambu Lab «відреагувала на ситуацію». Шо, думаєте вибачилися й сказали, що все повертають, як було? Звісно ні 🙁 Натомість вони написали: «Ви все не так зрозуміли». А щоб звучало переконливіше, відредагували попередній допис, а початкову версію дропнули з Wayback Machine 🫠 Тупо газлайтинг. Особливо кричу з їбаньків, які виправдовують їхні дії казками про безпеку через завʼязування на хмару (коли до того принтер навіть в інтернет не дивився).

Ну короч, не думаю, що вони прям втратять свій бізнес через це. Скоріш за все поточні користувачі підуть, а нові прийдуть вже на інші умови, з якими миритимуться. Але який же треш 🤪

Колись давно я відкрив для себе Obsidian, і відтоді користуюся ним регулярно. Навіть цей допис у ньому пишу. Я не намагався побудувати в ньому базу всесвітніх знань — радше юзаю як зручний редактор. Раніше для цього у мене був OneNote, однак, нині мені більше імпонує можливість зберігати все у маркдауні ⬇️.

А також певний час назад я дізнався про існування MkDocs — генератора статичних сайтів з документацією, який теж працює з Markdown. Для нього ще існує дуже відома й популярна тема Material for MkDocs. Я особисто гугловий Material Design зневажаю, бо вважаю його несмаком, ще й погано продуманим. Але тема для MkDocs зроблена настільки якісно й має таку кількість додаткових фічей, що складно її ігнорувати.

«Використовуватиму Obsidian як редактор документації під MkDocs», — подумав колись я. Та річ у тім, що Markdown сам по собі доволі бідний, тож для додаткових фічей усі вигадують якийсь власний синтаксис, часто несумісний, щоб робити виноски, вбудовувати відоси, додавати застереження тощо.

Тож я сів і навчив MkDocs [частково] розуміти синтаксис Obsidian (про що згадував отут й отут). Додав пару тижнів тому туди підтримку так званих callouts.

Я взагалі ніде, окрім як тут, не афішував цей плагін, але потроху-потроху — і вже назбиралася 41⭐️. It ain't much, but it's honest work.

Коли я тільки-но починав програмувати, то з величезним задоволенням писав на QBasic, а потім на Pascal. Згодом перейшов на 💻, яка вражала лаконічністю, та водночас мала в порівнянні певні незручності. Наприклад, ті ж нуль-терміновані рядки.

Але найбільше на початку дратувала робота з багатовимірними масивами. Якщо в тому ж паскалі можна дати змінній тип, наприклад, двовимірного масиву, щоб потім звертатися до його елементів як pixels[x,y], то в сішці таке не спрацює, і треба писати pixels[x][y].

Нічого страшного начебто — просто трохи інший запис. Але ця фішка перейшла і в 💻. А там доволі швидко зʼявляється бажання загорнути «сирі» масиви в якийсь клас з типобезпечнішою апішкою. Ну там матрицю ту ж зробити чи тензор якийсь, поперевантажувати оператори, щоб зручніше було, тощо.

Уявімо, що написали ви свій клас Matrix. Всередині у вас лежить якийсь масив; треба тепер визначити operator[], щоб можна було читати/писати конкретний елемент. Якби була багатовимірна індексація, то це суперлегко, причому дані всередині можна взагалі тримати в одновимірному масиві, а індекс обчислювати. Однак matrix[i][j] — це дві окремі операції, які можна записати як (matrix[i])[j]. Іншими словами, matrix[i] має повернути щось, на чому потім можна викликати .operator[](j).

Що це може бути? Ну, по-перше, можна повертати тупо вказівник на початок рядка, проте, я не почуваюся комфортно з цього приводу, бо забагато свободи: можна за межі піти, можна зберегти у змінну кудись, а потім навіть не дізнатися, що він інвалідувався (бо не володієш ним) тощо. При обережному використанні працюватиме, але наша мета ж знизити когнітивне навантаження, а не навпаки.

По-друге, можна повертати якийсь проксі-обʼєкт власного типу на кшталт Matrix::Row. Зробити, щоб створювати його могла тільки сама Matrix, по максимуму обмежити допустимі операції, перевизначити operator[]… Головняково якось, ще й сумнівно з погляду на швидкодію.

Натомість зазвичай перевантажують не індексацію, а операцію виклику функції operator(). Тоді є змога вказати довільну кількість параметрів. Але використання вже не настільки файне на вигляд, бо дужки круглі: matrix(i, j). Окрім неможливості в такому випадку зробити одночасно й індексацію, і виклик обʼєкта як функції (що все одно навряд чи комусь знадобиться), мені в цьому не подобається, що воно складніше сприймається. Око вже звикло, що квадратні дужки — доступ до елемента, круглі — виклик функції, тому натренований токенайзер у мозку даватиме хибні результати й сповільнюватиме читання й розуміння коду.

В інших, кращих мовах багатовимірна індексація вже присутня. Не тільки в спеціалізованих на кшталт 💻. Наприклад, у 💻 є, по-перше, багатовимірні масиви базових типів (int[,]), а по-друге, кастомний індексатор може приймати більше одного параметра: this[int row, int column]. (Так, мені дійсно подобається C# місцями). У Python 💻 метод __getitem__ завжди приймає тільки один параметр, проте, коли ви пишете matrix[i,j], то оці значення через кому запаковуються в кортеж, тобто викликається Matrix.__getitem__(matrix, (i, j)).

Щодо C++ же я давно змирився, що зручно тут не буває. І, уявіть собі, дарма!

Короч, починаючи з C++23 тепер є багатовимірна індексація, тобто це вже працює. Тепер operator[] може приймати довільну кількість параметрів різних типів:

m[0, 1, "shiii~"] = 42;

І до купи цей оператор тепер ще й статичним може бути.

Не вау яка фіча, і все ж мені до душі.

Мали колись доменне імʼя у володінні?

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

Натрапив на сайт, де можна погратися з тимчасовим доменом, постворювати собі DNS-записи різних типів, подивитися на запити, що приходять тощо: ⭐️ mess with dns ⭐️︎.

(Думав ще того тижня про це написати, але він якийсь час лежав мертвий 😆)

Зараз нитиму трохи, тож в принципі можете проходити повз.

Читав, значить, позавчора на вікіпедії статтю про РДУГ. Витратив на це понад годину. Уважний читач (так, ти) може помітити, що стаття хоч і довгенька, але аж ніяк не на пів години навіть. Та в процесі читання я десять разів відірвався на бозна-що, включно з цим дописом!

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

Також, доки «читав» статтю, різко пригадалося, що треба замовити паперові рушники, які закінчилися, що хотів epub скинути на читалку тощо. Та блін, я навіть якийсь відос на ютубі встиг глянути — вже не згадаю, про шо.

Чи є в мене РДУГ? Я хз, я ж не лікар, щоб діагностувати. Мабуть, нема. Певні симптоми канєш є ще з дитинства, але в кого нема? У багатьох моїх знайомих щось теж присутнє.

Та щось помітив, що інколи прям вкрай важко сфокусуватися на задачах. А в інші моменти — навпаки. Якась гіперфіксація прям.

Ось днями дружина підкинула ідею простого пристрою з буквально однією кнопкою. Причому не в форматі «а зроби ось таке», а радше як «було б цікаво колись у далекому майбутньому спробувати, якби така штука існувала». Але мене прям зачепило відразу. Я поміркував і зрозумів, що в мене навіть все для прототипа є: 🍓 Pico, власне кнопка та інші необхідні дрібниці. Зробити прототип на MicroPython можна за вечір на розслабоні. Але я такий: «Нє, ну це якось нудно. Спробую краще на 💻».

Почав робити hello world, який можна запустити на мікроконтролері. Нагадую, що вперше щось притомне на Ada я кодив у грудні на Advent of Code. Швидко щось накидав тоді за півдня. Ну й зараз теж зробив, і думаю такий: «Якийсь не ідіоматичний виходить код, треба почитати книжку».

Стягнув книжку (той самий epub, про який згадав вище), почав читати. А там 2284 сторінки. Ну й все, не можу позбутися цього відчуття, що треба спочатку всю прочитати. Лягаю спати — думаю про це, прокидаюся — теж думаю. А інші заняття страждають.

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

І виявилося, що таких штук у мене щонайменше вісімнадцять! Ще б пак мені геть не вистачало часу й сил! Доки не записав, то в голові воно уявлялося рази в 3-4 менше.

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

Висновків тут жодних поки що не буде, та я вас на початку попереджав ))

Гіфка на початку нічого не значить — додав її чисто для того, щоб привернути увагу. Це феромагнітна рідина. Оригінал, здається, отут.

Схоже, не тільки в мене виникли питання (реплай 👆), а й у когось з босів, тож дизайнерам гугла знов довелося вигадувати якийсь булшит про те, чим вони весь цей час займалися.

Ще пишуть там, що #FF0000 випалював людям екрани 😂 Не знаю, як вам, але для мене цей малиновий градієнт має такий вигляд, ніби екран вже вигорів.

Оце спалився. Не знав, що ґітгаб про таке пише 😅 Ще й рахує!

Наклепав ще один пак адаптивних емодзі, цього разу з логотипами виробників автівок і мотоциклів. Раптом кому треба. Приклади:

🚗: 🚗 🚗 🚗 🚗 🚗

🏍: 🏍 🏍 🏍 🏍 🏍

Ну, або навіть так:

🇺🇦: 🚚 🚌 🚌 🚚 🚗

(Так, на жаль користуватися цим досі можна тільки з преміумом ⭐️)

Попри те, що з модулями в 💻 усе погано, я досі не втрачаю надію почати їх використовувати у своїх проєктах. Вже навіть #Qbs додав підтримку.

Отож того тижня сів знову пробувати. Мої два основних компілятори — це MSVC і Clang.

Щодо першого я ще памʼятаю часи, коли його назва була синонімом нестандартної поведінки. Проте (хто б міг подумати‽) зараз Microsoft нерідко навіть випереджає Clang за впровадженням нових фічей. Тож нині з підтримкою модулів із C++20 там наче нема проблем.

З другим все більш-менш ясно й так. Правда ж? 🤔 Принаймні я так колись думав, доки не усвідомив, що на macOS стандартним є Apple Clang, і це геть не те саме, що LLVM Clang. Наприклад, чинна 16 версія еплівського кланга модулі не підтримує, а LLVM-на підтримувала. Ну й узагалі шістнадцята хтозна-коли вже була в LLVM. Зараз чи то 18, чи 19.

Неофіційно ж змусити еплівський кланг використовувати модулі насправді теж можна додатковими світчами. Але разом з ними вмикаються ще так звані Clang Modules, через що в мене були якісь конфлікти з однією з 3rd-party. Покрутив я ті модулі, покрутив, нічого не вийшло — плюнув поки.

Так ось щодо сторонніх бібліотек… Писати власні модулі — це звісно колись буде круто, але хотілося б, щоб і бібліотеки нарешті почали додавати їхню підтримку.

І знаєте шо? Вони додають! Є прогрес! І навіть існує сайт, який цей прогрес трекає: https://arewemodulesyet.org/

З нього чітко видно, що з 2431 бібліотеки, які вони моніторять, аж 22 (ДВАДЦЯТЬ ДВІ) вже мають підтримку модулів! Ще трошки піднапружитися — і заживемо.

Я ж потроху став цікавитися програмуванням мікроконтролерів. Захоплива тема, бо можна фактично власні пристрої робити, а не тільки софт. Торік писав тільки на C++, де є, мабуть, два основних популярних фреймворка: Arduino 💻 і ESP-IDF від Espressif 💻. (Чули до речі, як днями в китайських ESP32, котрих мільярди по світу, знайшли бекдор? 🤫)

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

Однак C++ — не єдиний вибір. Останнім часом на очі трапляється все більше цікавих штук для інших мов:

• 💻 Ada: наразі інколи пишу під 🍓 Pico якраз. Подобається.

• 💻 Erlang: існує імплементація BEAM під мікроконтролери — AtomVM 🤔 Можна і на Elixir 💻 писати, і гіпотетично на Gleam або LFE. Планую якось погратися.

• 🦶 Go: є така штука як TinyGo. Буквально декілька днів назад побачив.

• 💻 JavaScript: Espruino, Elk, Microvium. Я б не чіпав це навіть пʼятиметровою палкою, але комусь заходить.

• 💻 Lua: бачив щонайменше NodeMCU, eLua й MicroLua.

• 💻 Python: багато хто користується MicroPython 🐍. Я теж пробував: класно і легко. Але хз… Мені не подобається, що воно не компілюється.

• 🕊 Swift: є ось офіційна репа з прикладами, але руки не дійшли спробувати. А ще хтось почав навіть робити спецові дев-борди SwiftIO.

• 💻 Zig: вчора знайшов MicroZig. Поки не тестив і найближчим часом не планую, але колись може гляну.

Окрема (і одна з найцікавіших) категорія — це ліспи. Там взагалі їх десяток різних під MCU. Деякі компілюються в C++, інші в Lua, треті ще якось. Треба пірнати прям, щоб вибрати щось, бо явного лідера нема.

На чому ще можна писати? Шось пробували? (А до фіналу щось довели?)

UPD (з коментарів):

• 💻 Java: Haiku-VM, NanoVM, JArduino.

• Нагадали про Rust: probe-rs, Embassy.