zverok's space

It is 2026; where were we?

Sun, 18 Jan 2026 00:00:00 +0000

Most of the time, I try to keep this blog/mailing list to thoroughly thought-through articles about software development: mostly, programming languages in general and Ruby in particular.

But after it was dormant for quite some time, this one will be a bit more personal. And a lot less coherent.

For those who just wandered into this blog post on my site, or those who have subscribed to my mailing list and forgot what that was about (I get it! I wasn’t writing anything for months!), just a quick reminder: I am a software developer and writer from Ukraine, currently serving in the military. You can look up my personal site for some of my writing, projects, and talk recordings.

This blog/mailing list didn’t see me writing with any kind of consistency for the best part of the last two years. There are reasons for that – and there are reasons to write again, or at least try to.

This text is my attempt to reflect on what to write in these weird times, to focus on what still makes sense to write.

But first, I want to mention a few things I did write last year. Ruby-related and not (so much not, they aren’t about software development at all).

Writing in 2025

Christmas 2025 saw the release of Ruby 4.0: a new “major” version of my primary programming language for 20+ years; the one for which I am a proud (if minor) committer. While I didn’t participate much in the language development this year (other than an occasional issue tracker discussion), this December I traditionally made an annotated changelog for it.

I do for the eighth year in a row and have covered the changes in the freshly released version since Ruby 2.6 (and also expanded it to couple of prior versions and made a bird’s-eye-view Evolution page, briefly listing “all notable changes since Ruby 2.0”).

The “annotated changelog” only covers the language (syntax, semantics, and API) changes. While the latest version doesn’t have as much as “major” version change would imply (Ruby doesn’t follow semantic versioning, and this year’s number change is just to celebrate the language’s 30th birthday, according to Matz), the format I set to myself – every change tested, explained, and demonstrated – required quite a lot of work. As usual, going through the new and updated stuff made me notice where the behaviors weren’t clear or documentation was lacking; to make this part of the work more visible, I decided to mention it in the afterword of the changelog since this year.

Aside from this work – and a couple of stray blog posts, which I’ll explain a bit later – I spent my rare free time translating modern Ukrainian poetry, written by authors serving in the Ukrainian Armed Forces, for my personal project 7uapoems. I rarely mention it in my programming-related blog, but maybe some of my readers would be interested – I constantly find myself surprised by how many technical people are actually into poetry and literary writing in general.

Speaking of which (but probably not of interest to 90% of the readers), this year I also finished my new Ukrainian novel in Ukrainian, and saw my first published one gaining some readership.

At least, that explains how my writing muscle was occupied throughout the year (or, what my graphomania was channeled into, if you will).

Not writing in 2025

I still feel uneasy about all but abandoning the blog/mailing list – and that at the times when it gained some solid audience. You, my reader: my several hundred of mailing list subscribers. Which is, of course, a tiny number in modern megalomaniac internet, but enough for me to feel “I am talking to real people, not just screaming into the void.”

So, why DON’T I actually talk?

The above section might’ve been some explanation: I wrote a lot last year, just in other media/on other topics, but it is not the full explanation.

Another one, is of course, the war. I am a serving officer, and while I am serving as a software developer, too – this still limits my time and free mind resources for writing. It was a hard year for Ukraine, for many reasons which you either already know or didn’t care enough to learn. My team, though, achieved quite a lot – but the details I, for the time being, can’t share. Neither the particular things we’ve done, nor insights related to those achievements. My primary language/domain in this role is different now (Python and data processing), but on the projects, practices, and achievements my lips are sealed.

But even this is not the full explanation for a dormant blog, to be honest.

The thing is, I have only two “regimes” of writing. The first one, which, unfortunately, activates pretty rarely, is “write down a quick idea/experiment/explanation that you just thought of.” The trick here is to match a reasonably small idea with enough free time to write it down immediately. Otherwise, it might turn into something that I either consider too trivial, or, on the contrary, something that should lead to a deeper investigation and more detailed explanation of the matter, or more comprehensive implementation of an idea.

Because my second – and, unfortunately, primary – regime of writing is to follow some long train of thought, or overarching idea, or explaining a reasonably large domain. My head just works like that. When I still wrote poems (which is a short and self-sufficient form), I, for decades, only wrote them in “cycles” of ten to twenty texts, which might’ve been diverse in tone and style but still were part of some internal plan and intention.

And when you do this – planning to write a series on some topic/area – with programming-related blog posts, the things get complicated. Without enough feedback (or, with a lot of negative feedback) it is quite easy to decide to just drop the topic. My blog is shamefully full of posts that claim to be the start of a large series – even including something like “Part 1” in its title; there is also a fair share of “course correction” reflective posts (like this one) to claim “I understood what I want to write about now,” with no follow-ups.

Sometimes there are “series” that I planned and executed till the end. Sometimes, again, without enough feedback or understanding whether there is an audience (like Rebuilding The Spellchecker).

Other times, I pull this up successfully. The last of such successes was the cheeky-named “Useless Ruby sugar” in autumn 2023 – which, actually, started as an article of the “first type”: quickly triggered response to someone on the Reddit, to explain why “useless syntactic sugar they add to our language” is not that “useless,” and grew into two months of weekly structured posts.

This one accidentally became quite successful – and at the moment, it felt as if both my expertise and my way of looking at things were important to this success. As was my fascination with the story of a language evolution – a programming language evolution, in this case, but taken from “how it makes us think and write.”

So, after that, I had this idea about a corpus of texts – blog posts or even a book, maybe? – on Ruby’s evolution. Some crossover between that changelog I maintain and the “‘useless’ sugar” series, to try to tell a coherent story of how the language takes shape and changes with time. I did a few approaches to the idea (1, 2, 3)… and quite quickly understood there just isn’t a vibrant audience for this kind of content. At least, not among the readers who stumble upon my texts – maybe somewhere in academia? – anyway. In the autumn of 2024 I reviewed the series/book idea critically – and then dropped it altogether.

Then, in 2025, I had some vague yet persistent chain of thought about the similarities of working with code and working with texts in human language; the width and depth of it seemed promising (and speaking to a wider programming community than Ruby-related texts). It never caught enough wind though, two posts boldly named week 1 and week 2 (plus an unfinished draft of week 3) is as far as I got before understanding that the overarching idea is too broad to speak to anybody in particular. Maybe, it should’ve been approached differently. Maybe, it will.

Or maybe it all – my attention to language nuance, my belief that good software grows from well-written “phrases” – will become irrelevant, and quite soon.

For the last couple of years, people seem to stop writing code by themselves.

A brief diversion: my views on AI

I wouldn’t try to make a comprehensive write-up on everything I think on the large area of tech that goes under the “AI” shortcut. I was always interested in the technological/scientific part of it, frequently worked in adjacent areas (hell, my first full-time software development employment in 2003 was several months working on a small startup that tried to apply those days neural networks to stock market prediction or something); and, while not being an insider of this part of the industry, I have a whole lot of thoughts and opinions formed through past decades.

But for the sake of this particular text, it is enough to say this: I still feel kind of childish wonder in front of a technological part of it, of the intelligence illusion which emerges from the simple math. And unlike Baldur Bjarnason, whose book title I am quoting here and for whose opinions I have a lot of respect, I use “illusion” here in a less-than-derogatory sense: when you look at a purely technical side of things, it is somewhat fascinating how the unpredictability of the human thought can be imitated by matrix multiplication.

At the same time, I am as much horrified as everybody else with the economic and societal consequences of what the current iteration of unregulated mega-corporations, hype cycle, and malevolent power players do to our world using those technologies. I am not sure whether it is a “bubble” that will “pop” at some point; I will abstain from any attempt to extrapolate “where is it going” – but overall, the “AI future” doesn’t look bright.

One thing, though, seems to me if not inevitable then at least highly likely: the change that LLMs and generative AI bring to all kinds of “informatics-related” work (any kinds of creation, maintaining and changing any “intellectual property,” be it art, news, or programming) is pretty similar to industrialization of the early XX century.

I mean that, for example, software development, even in huge international corporations, was more like “craft” just a few years ago. I say “craft” not as a synonym of “art,” but in a medieval sense: hand work of highly and narrowly qualified professionals, with guilds, apprenticeship, and significant impact of personal traits on the end product. Even if the “guilds” grew into extremely large international corporations, making personal impact in many particular cases as negligible as “cog in the machine,” the impact still stayed personal.

Now, it is about to change – already changes. LLMs take a role of the “machines” in an information-related “production.” No analogy is perfect, but this one seems to give a lot of predictions and explanations. Like: “aren’t machine-made products inferior?” – many might be, but in a lot of situations, 100 shitty plastic chairs produced in a day will be preferred to one sturdy and polished wooden one, produced in a week. Or: what will happen to the “craftsman” of yesteryear? In imaginary factories, some of them will become engineers, others – low-valued machine operators. Some will continue to do what they’ve done: there is still room for handiwork in today’s world: producing artisan unique items, or, vice versa, quick-fixing broken tables for local grandmas; or, semi-manually creating R&D prototypes for future machine implementation. But there will be much less demand for this kind of work.

To be clear, this is not an optimistic, progress-embracing view. Industrialization of the XX century saw a lot of unfairness – due, in part, to shifting the balance of employer/employee relationship. This time, it might be much worse, considering *gestures vaguely at everything*. We are used to using “Luddite” as a dismissive term for “those who don’t understand the virtues of progress.” But we – some of us, anyway; many of us, probably – are about to learn what was their point. In a hard way.

Maybe writing in 2026

The lengthy rant above might seem out of place in this personal post (I acknowledge that it is a shortened version of a separate “what I think about AI” article draft). However, the changing landscape directly affects the topics that make me passionate enough to write programming-related texts.

My main idea always was thinking about code writing as I think about text writing. Thinking at the level of a singular phrase, that affects the way the underlying structures are built and how the language is used and evolves. The optics I sometimes like to call “lucid code.”

Even before the advance of LLMs, this way of thinking was a hard sell. The frequent consensus is that architecture and high-level structure of the program are the things that matter, while the code underneath is “just boring details.” Surprisingly, though, my ways of thinking, when battle-tested on complicated production projects, tend to show its benefits for velocity and maintainability. With years, I learned to explain it better.

But the tectonic change in the industry (if it is not an illusion, of course!) might make it all irrelevant. Well, the approaches I use still can be rebranded to being token-efficient to flourish in LLM era… But for now, I feel an irrational aversion for this angle.

For the time being, I stick to my “craft.” And still will try to write about it – about the ways of thinking in code that make me productive, and about languages, tools, and approaches that adhere to these ways. And I still hope to have an audience for that, and to find my place in the ever-changing industry.

I’ll probably stick to deeper, not wider topics in my upcoming texts (if any will come); focus on sharing pragmatic parts of my experience rather than philosophical outlooks on the general matters of programming. Though, TBH, I have one almost-finished “philosophical” text that’d marinated in my drafts since late summer… So maybe I’ll finish it some time in the coming weeks.

But after that, I hope to dedicate some efforts to writing about my approaches to testing and various nuances of experience I gathered by working on test suits of several large produces (including developing and publishing my own test helpers library).

So, till the next time. Hopefully, it will be soon.

And please support Ukraine.

Notes on code, text, and war. Week 2: If code is text, then what?

Sat, 21 Jun 2025 00:00:00 +0000

Last time, I’ve highlighted “treating code as text” idea as something that I want dedicate a few posts to. Let’s talk in generalities some more this time.

OK, if we look at code as a text, then what?

If this metaphor-based approach – bringing the mental model of one domain into another – is useful, it should have some consequences. What are we gaining by using the culture’s experience with natural language texts in software development?

For now, I want to briefly outline some consequences and then expand on them, hopefully, in future posts.

The code is frequently compared to a cultural artifact, and most of the time, as a juxtaposition. Sometimes, this juxtaposition seeks reconciliation, as in literate programming. Sometimes it is antagonistic, asserting the superiority of “precise engineering work” over something as intangible as culture. However, even those who compare coding to writing as a compliment frequently go for it as an emotional argument for coding being a creative work, too. In those discussions, you might hear that “good code reads almost like poetry”, meaning a synonym for generic “beauty,” something that is “joyful” to read or write.

Honestly, I am the last person to frown at defining code as “craft” and at statements that it might bring “joy.” I have been writing code (and texts) all my life, and I am in it because I really like to do it. But also, I know that to become better in coding, as well as in writing, “looking for joy” and “listening to your heart” is not enough. At least, for me.

And so we can use the comparisons for something other than emotional effect. We can translate our experience with texts to working with code.

Say, on the level of a single phrase (the level which Ruby’s expressiveness taught me to emphasize and cherish), we can talk about choice of “words”, the thesaurus that the language provides, and its expansions with the names we chose to become “words” in our code. We can talk about idioms and set phrases that are typical for language, and explore how they might be thought-provoking or thought-obscuring, or become thought-terminating cliches.

We can talk about even seemingly insignificant aspects, such as layout and punctuation, and how line-breaking choices might emphasize or muddle the structure of what is said.

An answer to a primitive question like “assume x is a list of users, how would you produce a list of user names from it?” and its typical solutions in every language and community might expose, like a drop of water, a whole ocean of approaches and values.

In software development, many of those questions are often dismissed as “bikeshedding” and addressed with prescriptivist rules and tools that rewrite the code to adhere to a “common style.” This is frequently done without a distinction between genuine typos/cleanup (e.g., fixing a stray space where it is not intended to be) and enforcing mechanistic uniformity, where the style previously emphasized the flow of thought. The rise of “opinionated” (see: non-configurable, “because there is nothing to discuss”) code formatters is part of this problem.

Next, on the level of code units that structure and organize your phrases (methods/functions, modules, classes), we might, again, think about what structuring of texts teaches us.

Visible page of text/code seems an important concept here: how much can you comprehend without scrolling/jumping around? The question is frequently neglected – despite being of utter importance for the human perception – in favor of, again, prescriptivistic rules, like requiring to structure everything in extremely small methods, or code layouting conventions that prefer very short lines with roughly one “word” (method call, argument, etc.) per line.

We might examine how well-written, comfortable-to-read texts are broken into sections, how important headers and call-outs emphasize key thoughts, while build-ups to them are packed together into paragraphs, and useful yet tangential facts are extracted into footnotes and sidenotes. We might discuss how section and paragraph sizes differ depending on genre and intended effect.

Moving to higher levels, such as the whole project or a large component, we might again look at the experience of organizing large groups of heterogeneous texts.

Obviously, most modern software projects (save maybe for some narrow and specific libraries) don’t provide a linear narrative like a book does. But I like to think about organizational principles of large magazines and modern media outlets as an inspiration for some ideas, without mindless borrowing of what is irrelevant for the sake of extending the metaphor.

Think of the difference in styles to match the purpose, but under the same guidebook.

Or, about the variety of roles and competences in text work. A genius editor is not necessarily a good writer; a literary editor and a managing editor who overlooks a rubric and the editor in chief being all different “hats” (even if not always different people). There are reporters, analysts, and fact-checkers, and they work in an elaborate dance of creating a whole. It is not hard to find equivalents for those roles in software projects. It is not that hard to imagine how people with distinct skill sets and temperaments find a matching role that makes them most efficient and productive. How they are keeping a common schedule, contributing their angles of view, and working towards the general integrity of the software project/publication.

This is a weird year to speak of any integrity, though. Ukrainians know it like no one else, ever bitter and growing more bitter by the day.

For a week now, the world seems to be forgetting about Ukraine completely. (Forgetting even more than before, I mean.) You know what I am talking about, what’s on the news and social networks everywhere.

I wouldn’t share my opinions on the incredibly tangled Middle East politics.

But I want you to imagine, if just for a moment, how Ukrainians feel about the world’s “integrity” when we read about Western joint efforts to protect against an attack by a hundred Shahed kamikaze drones. The same Shahed Iran is being supplied to Russia. The same Shaheds that, for the last months, have attacked Ukrainian cities in quantities of two to four hundred per night. Frequently, many nights in a row.

No Western aircraft ever tried to help intercept them in our skies. The idea of using our “partners’” aviation for this task (for cities that are very far from the front lines!) was briefly entertained in discussions last year, and then swiftly and decisively abandoned by everybody with a great sigh of relief.

They were also very public and clear about this, not even maintaining some strategic public ambiguity, which in itself might deter Russia’s boldest moves for some time. And they do it all the time: after the first rumors of a possible “ceasefire” this May (which were baseless but sparked some “what next” discussions), most Western governments were very quick to emphasize that no peacekeeping contingent from their country would be possible on Ukrainian soil. As clearly as possible, for Russia to hear and take into account. Again: not that we expected any! But those rushed assurances are a message in themselves, too.

It is like they perceive Russia with some split-brain malfunctioning: it is, at the same time, entirely harmless for them (so there is no need to help Ukraine push it back decisively) but also extremely powerful (so the “provocation” as moderate as UK or French plane helping to patrol Ukrainian skies 1000 km from the active battles might cause catastrophic consequences). I once theorized that Western perception of Russia is kinda religious, like that of an unpredictable yet vengeful god.

Sorry for this (probably pointless) venting.

It is somewhat hard to build a deliberate thought structure, trying to translate years of thinking about being better in our professional skills in this world. In a world that seems to be in agreement in its collective drive to fall apart into incoherent fragments, and the whole industry of IT, the industry about building and maintaining systems, realigns with this fragmented vision.

I am well aware that my notes are fragmented, too. But I hope they will eventually amount to some cohesive vision. The vision that will be helpful to fellow programmers, if only in small ways.

See you next time.

Thank you for reading. Please support Ukraine with your donations and lobbying for military and humanitarian help. Here, you’ll find a comprehensive information source and many links to state and private funds accepting donations.

If you don’t have time to process it all, donating to the Come Back Alive foundation is always a good choice.

Notes on code, text, and war. Week 1: Believing in text

Wed, 11 Jun 2025 00:00:00 +0000

Writing texts is the most useful and fruitful metaphor for software development.

After 25+ years of writing software and at least as much of writing texts, this is the one thing that I have become sure about.

This also means that reading, writing, editing, and layouting concrete chunks of code is a central activity of software development. Not planning, not scheming, not calculating and measuring. All of those take their place—like in writing complex texts, they do—but the most direct and useful experience we can have is still that of getting our hands on the code.

Does this point of view stand in the age of LLMs? I believe that not only it does, but becomes stronger and more productive. The LLM breakthrough (however many ethical and ideological concerns we have about it; I have plenty) is a direct consequence of the vast number of texts written by human civilization. It is also a direct cause of the explosive increase of this number. Whether you intend to resist it, utilize it, denounce it, or ride it, looking at everything as text is a useful tool of though.

Depending on your experience, work environment and cultural background, the focus on code-as-text might seem painfully trivial. Or it might seem screamingly irrelevant and wrong. But bear with me for some time. I think that I am able to show many practical implications of focusing on this. Some non-obvious implications, too.

For this, I want to write a series of (relatively) short posts/notes: after a long silence in my blog, I have things to say. Things that might provide others with some new perspectives/ideas. Or, at least, irritate in an entertaining way!

Previously, my writing was mostly focused on Ruby. (Save for a few long digressions to “open data” direction—the direction that was almost entirely cannibalized by global LLMs now. So what, fewer things to think about.) I am still quite fond of the language; I still use it daily. But what I like to think about now is much less Ruby-centric, though in many aspects inspired by my experience of writing in it for many years, and even participating in the language development.

“Experience” is an important word for me. And frequently definitive for the topic I chose.

We write and read to share the experience. Not in a narrow professional sense, but in a broader cultural one: My text allows you to experience what I lived and you didn’t, and vice versa.

Prose shares the experience of stories. Poetry shares subtler experiences of feeling, inspiration, and insight.

Utilitarian texts—like journalistic, academic, or “texts” in programming languages—share the experience of understanding something. Not the knowledge/understanding itself, but the experience of understanding from a particular person. Alongside the experience of being this person, with their education, habits, expertise, and personality.

Say, here is my experience: I am a lifelong software developer, primarily writing in Ruby (since at least 2004), and for some time, I actively participated in language development and documentation. But also, I am an author of prose and poetry, with some magazine publications, festivals, and a relatively popular novel published just last year. But also, I am Ukrainian, living through war, serving in the Armed Forces, with some combat experience and current duties not completely unlike my civilian ones (though nothing more precise can be said of them).

Obviously, I compartmentalize my experiences to some extent. Sometimes to the extent of switching to almost unrelated personas. But for a deeper look, this is an illusion. Obviously, each “persona” draws from the experience of the other. I plan novels not unlike the way I plan software projects. I care for expressive code and constantly think about how others achieve that (and how they fail), not unlike in my literary work.

And, as a person living through a genocidal invasion of the former empire, and knowing what led to it, and observing how the world responds to it, well… I think I became more attentive to the weight of proper representation of information, to cognitive biases codified in texts (and software), to consequences of exaggerations and omissions, overstatements and understatements. Even in the most routine work during software development.

In my 2024 EuRuKo talk “Seven things I know after many years of development” (video; transcript article), I tried to blend my war/programming experiences. People say it was insightful for them. Maybe they are just being polite.

Anyway, during the work on the talk, I came to the emphasis on truth and clarity as the primary goal of code writing. Even the most mundane code writing.

Not directly related to the text above, but related to the living experience of Ukrainians, here is a truth.

Almost exactly two years ago, on June 6, 2023, Russians blew up the Kakhovka Dam on Ukraine’s main river Dnipro, draining the huge Kakhovka reservoir and flooding some 600+ square kilometers of populated land and natural reserves.

Even the approximate number of victims is still unknown: on the left bank of the river, still occupied by Russians, there were no efforts neither for immediate relief nor for subsequent recovery of bodies. The environmental, humanitarian, and economic damage of this man-made event is said to be comparable to a nuclear explosion.

There were many texts written since about the cause, consequences, and aftermath of the catastrophe. A major part of international ones—immediate news as well as subsequent assessments, political statements and philosophical essays alike—had a strong tendency to diminish the effect, or shift the blame towards “natural causes,” or “harsh realities of war.”

There were no strong consequences for Russia, other than the—usual and used-to—”public condemnation” (and even that expressed in no clear terms). There were no new sanctions other than those already planned, regularly slightly expanded, and regularly easily circumvented.

Even today, English Wikipedia prefers the passive voice of “the dam was breached” with a cautious explanation like “many experts say it was Russians, but Russians deny that, so in the interest of Neutral Point Of View that’s all that can be said.”

This is just one of the many examples that might explain why I am so obsessed with truth and clarity, and how what we write and what we read structures our understanding. In texts and code alike.

We’ll get back to the code at some point. But right now, I want to highlight one text written in the aftermath of the Kakhovka Dam explosion.

It is a book that was announced just a few days ago, on a sad anniversary. “The Flood“ is a narrative non-fiction, “a journey into the heart of the Khersonian steppes, a story of loss and resilience seen through the eyes of witnesses.” It is written in English by Yevhen Lyr—a brilliant Ukrainian writer, translator, educator, and volunteer who was there in the immediate aftermath of the tragedy, one of those dealing with its consequences.

Now, he is a soldier.

Many of us are.

Sometimes, I still have people in comments and Internet discussions of my technical articles wondering how we can live like that. Meaning, how tragedies of the scale of Kakhovka Dam, or nightly shelling of cities, or constant deaths of people we know, might coexist with what looks like “normal life”: like this blog, or new Ukrainian books, or concerts, or parks, or new cafes. How do people move forward with their lives? (Sometimes those questions are compassionate, and sometimes they are sarcastic or reek of suspicion: this so-called “war” shouldn’t be that bad if you write about programming or visit a concert?)

Here is one more truth for you: you get used to anything, given enough time.

A human being can only stay in shock for so long. And “so long” here is hours and days, not months and years. Then (given at least some pockets of pretend normalcy), you get back to who you were before. Not completely, but to some visible extent.

Almost every day, we have awful “anniversaries” like Kakhovka Dam ones: death, destruction, occupation, loss. From the past three years of the full-scale invasion. From the previous eight years of hybrid war. From hundreds of years of colonial attempts to erase our identity.

And it is not just anniversaries of past events, of course. It continues and becomes worse.

Last weekend, my home city, Kharkiv, where my family still lives, survived the largest combined aerial attack—kamikaze drones + various types of rockets + gliding bombs—since the beginning of war. Just last night, our capital Kyiv survived another one.

And so on. And so on.

Oh wait. I wrote the previous paragraph yesterday but didn’t finish the article just then. This night, Kharkiv was again attacked by 17 large kamikaze drones at once, targeting populated areas. At least sixty people are injured, at least two dead.

And: we still live here. Soldiers and civilians, grown-ups and children alike. “Our cities are too inconvenient for Western media” is one of my short texts that I wrote over the last three years. There are several more.

Trying to write those texts—trying to explain anything, anything at all—sometimes also feels absurd. And sometimes as just a way to distract myself. But I am still writing. Less of “explanations of our life for foreigners” (who aren’t that interested anyway), more of code, and my literary work, and my poetry translations, and now, hopefully: this series of cross-topic texts.

What does it all have to do with the “code as text” concept? Maybe nothing. Maybe everything.

The humane part of the software development craft always appealed to me more than anything else. But this part exposes itself only over time. Let’s put it this way: a reasonably dedicated developer can implement any reasonable idea in any first way they think of. Like, you can convey urgent news or a fresh thought in the roughest, most incoherent words, and still pass the information.

But for an idea to live, for a project to evolve, to preserve velocity and maintainability, you need something more. Some ways for all of it to continue make sense. I say it in the most pragmatic way: a growing and ever-changing system like a software project needs a way to maintain coherence and not fall apart. Even developing the most pedestrian features and performing the most mundane refactorings, I never stop thinking about the ways we convey messages and preserve truth. I continue to learn. I continue to try to share my experience.

I don’t know if what I am saying makes sense right now.

But I’ll be trying it to, with more pragmatic, hopefully regular, chapters, roughly related to the “code as text” topic. And to war.

See you next time.

If you don’t have time to process it all, donating to the Come Back Alive foundation is always a good choice.

Seven things I know after 25 years of development

Mon, 27 Jan 2025 00:00:00 +0000

This is a loose transcript of a keynote I gave at the EuRuKo conference in September 2024. The video of the talk is here. Unfortunately, I only could talk in recording, but it was a great honor nevertheless. The topic is pretty important to me, so I decided to share a slightly edited transcript for those who prefer text form.

I have been writing software for about ~25 years. For 20 of those, I have been using Ruby as my primary language. I’ve made some contributions to the language and other open source. I write a lot about Ruby, and I maintain the Ruby Changes project, which some of you probably heard of.

I am kind of principal engineer in the US company Hubstaff, but only “kind of,” because…

The most important thing about me is that I am Ukrainian who serve in the Armed Forces. Currently, I am not in a combat position but doing other things that I am better at (and the rest of my activities are happening besides these duties).

I got into the army not because I am very militaristic or like fighting but because I have a duty to protect my homeland.

It is the same for many Ukrainians.

There are all kind of people serving in our Armed Forces currently, and I have a small personal project of translating poets who serve in the army into English.

So the actual title of the talk is

It is still about development and Ruby, but I allowed myself to draw some parallels with my experience as a Ukrainian. I hope it makes the talk richer. Nothing too graphic/disturbing, I promise.

Let’s get to the matter, those seven things I wanted to share.

1. You outgrow every framework

In any area, not only in tech, we frequently rely on various frameworks and foundations to know what to do and what to expect.

Say, in international relations, we Ukrainians, for a long time, have relied on being a sovereign country whose security is guaranteed by global powers. Which turned out to be, let’s say, not as solid as we’d hoped.

So, as programmers, we frequently rely on frameworks, and as Rubyists, we rely on The Framework, but I am not about to criticize any particular one.

The point is that frameworks provide us with rooms and boxes to put our code in, and to feel confident, only implementing the business logic.

But we all know that eventually, as code grows, we have more concepts, and then even more, some of them provided by your framework, some of them introduced by a team.

And however we extend it, something always sticks out.

And like a fractal, every particular concept starts small and then grows into a framework of its own. Like common nowadays callable object, which is a simple idea. When you introduce it, it might seem like a small step you need to achieve the completeness of the mental model.

And then there are new requirements and new use cases, and eventually, you have a dozen DSL options to define one.

And then something sticks out anyway, not fitting into any of the previous definitions. And if you don’t handle it, you’ll either have very bloated concepts or some garbage bin, like lib/ folder or app/services folder, and soon nobody is sure what is were.

To handle that, you should be ready to make your own architectural decision, regardless of the frameworks you rely upon. But there’s a problem.

2. Patterns and methodologies fail

The second thing I am sure of is that whole patterns and methodologies fail you and get outdated.

Like in our Ukrainian experience, the whole international security architecture became a laughing matter, international humanitarian structures proved themselves useless, and human rights defenders defended anything else other than human rights.

As a developers, when we need to make a decision, we…

…might rely on some methodologies, trusted approaches, books, patterns, or funny mnemonics encoding simple principles.

However, as code grows, the project matures, as the industry develops new opinions, and as challenges change, a lot of doubts and questions emerge.

You might learn that inheritance was an idea that is good only in textbooks or that the whole OOP failed us. You start to doubt whether Active Record is a viable approach or whether passive entities and repositories are saner.

You might be reminded that SOLID is an acronym coined for marketing purposes by one person, and it groups probably useful but vaguely defined and contradictory principles. And in general, for any common approach, there are a lot of arguments about its usefulness or harmfulness (and counter-arguments, and counter-arguments to that).

And so we discover for ourselves more high-level guiding principles, like DDD, which follows a very sane idea of isomorphism of the domain and its coding representation. However, it still leaves many blanks in design decisions, such as when a small domain concept requires a big algorithm to implement or when important domain concepts correspond to a small implementation.

It also introduces a lot of new terms that people love to turn into literal classes, so eventually, you have, besides your MVC classes, also entities, aggregates, bounded contexts… Or, as a wise man put once:

Or we might talk about “hexagonal architecture”, right?

…Which is notable for never explaining why is it hexagonal, and for leaving the design decisions about the whole “core” architecture for yourself. (I am not here to say it doesn’t provide some useful concepts.)

Ultimately, those might help, but eventually, you will be on your own in designing new things. Why is it so?

3. The scale only grows with time

Because the scale only grows with time. This is true about many things in the world, and it is also quite a trivial statement, but it has frequently overlooked consequences.

Imagine any Rails app you ever maintained for some time. I think you probably agree that all it did was grow.

We live in a capitalistic world where you need to run fast to stay relevant. Whether it is some new tech like switching to SPAs, extending your market share to customers of a smaller or bigger scale than before, trying to adjust your market fit without losing old customers, or just linear growth.

Whatever happened, there was more code, more tables, more endpoints, more tests, more everything.

As an example, we might look at the GitLab open-source codebase, which at first looks like your regular Rails app.

Initially, it was what? Just a UI for collaboration on top of git.

Now if you look through its main folder, you’ll see a bit more things than in a new Rails app, and it into its app/ folder, it has a multitude named concepts of its own, and if you’ll open one of those folders, you see more, and more, and more. (Note I only got up to “c” letter on the last screenshot.)

Maybe not all of our projects are at a scale of GitLab, but talking about any commercial project, eventually, you’ll need things like reports, notifications, better role management, payment systems, new APIs, bulk operations, business analytics, and so on and so on.

The simple yet frequently overlooked consequence I was talking about: it is perfectly natural that your old ways of handling problems would stop working eventually.

The way of thinking about ten controllers, with four standard methods each, just doesn’t scale to hundreds of non-trivial endpoints.

What do we do then?.. Well, I have a paradoxical answer!

4. Pay attention to stories

And my answer is: Pay attention to singular stories. When working with any feature of our software (implementing a new one, adjusting an old one, or trying to understand why it behaves in the wrong way), we always have a narrative to follow: there are some causes and consequences: inputs, outputs, transformations, effects, which can be told linearly.

But by jumping through layers and conventions and discussing the “bigger picture,” we are frequently losing those particular threads—and then losing the bigger picture.

A small illustration: once upon a time, I was trying to add a new feature to Rubocop (it didn’t work out but for an unrelated reason), and I had this AHA moment when I spent, like, a day trying to understand an algorithm split in 2-3 “simple” line methods, and eventually rewrote it into one, half a screen-sized. Which, though, didn’t match expected “complexity metrics”:

Here, for comparison, is the fragment of the original algorithm (how it looked at the time), but I don’t have a big enough screen to screenshot the whole thing:

That’s not about “badly written” Rubocop (it is an awesome software project maintained by extremely competent people), but about some deep difference in the approaches.

Splitting everything into ultimately small methods and extracting every condition to a predicate is actually a widespread approach in the Ruby community (which the default linters’ complexity thresholds reinforce).

As a counter opinion, at Hubstaff, we have this fragment in the “small coding rules” document, which underlines the idea of “trying to put everything together first, and impose architecture only after that”:

The “single method” is not a key here!

What IS a key is the point of view from which focusing on “exposing what’s happening here” with code is the main goal. The rough list of principles we follow are:

Dense code;
Expressive language;
Rich thesaurus;
Frequent small rewrites;
Attention at the level of a singular page (screen) of code.

It leads to the discovery of good names and structures of related concepts—much more reliably than just trying to invent them on the architectural planning stage and fit into the “big picture.”

But most of the time, there is no single simple “big picture” at all (as anybody who tried to make a class or flow diagram of a mature project will agree).

It is just a bunch of interlinked stories, a garden with paths through it, not a concrete skyscraper. But why are these stories so important?..

5. The goals are truth and clarity

Because our final goals, as developers and as human beings, are truth and clarity. And it emerges from listening to stories. One might say that “truth” is a weird word when talking about software architecture; it is more from philosophy (or law) domain…

…But my persuasion is that on an intuitive level, all our principles and methodologies are introduced as a way to search for the truth.

Like OOP was invented in simpler times in the hope of modeling the whole world, and behavior-driven development is a way to honestly describe what is expected from a piece of software before implementing it, and so on.

Our problem is that we turn any good and imprecise idea into a discipline, formalize it, and then eventually, instead of trying to truthfully mirror the problem, we replace it with rigorously following the rules.

As a small example, the Ruby community once leveraged the language expressiveness to invent an incredibly powerful testing DSL named RSpec but then eventually persuaded itself that tests shouldn’t be expressive and they should follow some rules of the most primitive code possible:

As a consequence, many Rubyists are taught to write tests that are more verbose than the code it tests, sometimes orders of magnitude more verbose. They hate it rightfully and are forbidden from even dreaming of thinking it could be another way.

Well, it actually can.

Whether you like this example or hate it, I really hope you can see here a point where the example tells the story of the expected behavior. An attempt to make it work also illustrates the effect the “storytelling” approach has on the thesaurus. To make it work, you’ll need a few new high-level abstractions that are defined once and then improve the life of many spec authors.

However, it is a well-known fact that approaches like this frequently encounter fierce pushback. And here lies my sixth thing.

6. This might be a lonely experience

Trying to stick to the true stories might be a very lonely experience. First of all, because people have their “big pictures,” and the first thing they’ll expect from your story is to see how it fits in those.

So, when trying to “sell” the approach that focuses on “what’s really going on here”—be it on code reviews, pair programming, or discussing style guides—one might meet reactions ranging from total indifference to active hostility.

Because looking for truth is about adjusting your mental models constantly and questioning your own experience. In general, people, especially established professionals and especially-especially software developers, aren’t up for it. I mean, we might change tools every day, right, but internalized persuasions and mechanical habits? Never!

One might notice that lately, in industry, there is a lot of strong sentiment against “smart code” and expressiveness in general, or, broader, about the unimportance of the particular ways we write code and, as an offspring of it, a strong sentiment against code review practice.

I get it, I do.

In general, when solving problems, people prefer to write and avoid reading and editing. This leads to the sad state of things when the practice of code review turns into a laborious formal duty for both participants (who don’t know what exactly to do about it other than go through the moves) and eventually is badmouthed as a harmful and meaningless way to waste time and establish dominance.

But in my view, reading and discussing each other’s code is the only way to make sure the story you are telling makes sense to others, that it doesn’t contradict other stories, and that it doesn’t misuse a common thesaurus to say things that shouldn’t be said that way.

This is a deeply humane activity, and nobody will persuade me otherwise. Which leads me to my last point. Kind of sentimental one.

7. Never give up seeking truth

Never give up seeking truth, however uncomfortable it is. Search for knowledge. Adjust your worldview. Ask. Rewrite outdated code. Drop faulty hypotheses and unreliable foundations.

Software author is, first of all, a writer. They are a person who stands upright and says: “that’s what I know for now, and that’s my best attempt to explain it.” Having this stance, preferring it to everything else, and hiding behind terms, concepts, and authority are invaluable qualities for long-term project success.

Or, basically, for any long-term human activity success.

This is the most important thing I learned. Probably not much for a career this long, but that’s where I stand personally and professionally.

Thank you. I hope to see you all in person one day.

And please, even if not remembering this talk, remember to help Ukraine.

If you don’t have time to process it all, donating to Come Back Alive foundation is always a good choice.

The short outburst of activity during Ruby Changelog preparation—2025 edition

Mon, 06 Jan 2025 00:00:00 +0000

On making the Ruby Changes, and some consequences of this work

Every year since 2013, on December 25, a new Ruby version is released. (Before that, the version schedule was much unpredictable.)

Every year since 2018 (Ruby 2.6), I spend several weeks in December working on updating my Ruby Changes site to prepare an annotated changelog of the language, focused on changes in syntax, semantics, and core APIs. You can see the 2024 installment, dedicated to Ruby 3.4, here: 7k words, 30+ sections, and some ~60 hours of work.

I have already written a series of articles about how and why I am doing it in 2022 (1, 2, 3), along with some philosophical and personal implications of this work. Last year, I made it into an “advent” of following this work with explanations (which I myself called “a boring advent,” so I don’t think a lot of people have followed it).

So, for this year, I am just doing a short wrap-up about the new chunk of work done.

How it is done

From the very inception of the “Ruby Changes” idea, my goals were to cover all notable changes in every version (not only those I like or plan to use soon or those that are easy to describe), and to explain them the way that would be educative and instructive. This means linking to the relevant documentation, providing the reasoning behind the change and how it was decided to be, and showing the code examples—both illustrating the change’s utility and demonstrating edge case behavior.

The “all changes” goal has a big sidenote in the case of my work. The “Ruby release” that happens each year, is a release of the language and its particular, authoritative implementation: CRuby; thus, NEWS-file of each new version includes a lot of changes that are related to how CRuby works, like parsing, garbage collection and so on. My area of interests and area of expertise is about the language as a tool of thinking/writing; so I only mention changes of the “insides” only to the extent they are manifested in changes of the API of the core classes. Some years it makes “Ruby Changes” focus significantly diverge from NEWS-file’s focus (and the focus of many blog posts that rely on it). This year, which is marked by the introduction of the new default parser, and of pluggable GC concept, is not an exception.

So, every day of work during December, when I work on the changelog (it typically takes a few hours every day for a few weeks), I rebuild the most recent development version of Ruby and use it to write all examples to check how it all really works. I also read through every discussion on the official Ruby tracker (thankfully, the relevant issues are linked from each entry of the NEWS-file) and check the latest rendered docs at /master.

Every year, this activity, besides producing the changelog itself, allows spotting (and frequently fixing before the release) some deficiencies in documentation or even complicated edge cases on the new behavior. Here are some of this year’s examples.

Some consequences

A forewarning: by no means I want to imply that something was “broken” in the Ruby development process that I “fixed.” The small amount of work that I am doing during my Decembers is just a fragment of what the modern mature language maintainers are dealing with. There are a lot of people who maintain the language, its implementation, tools, and documentation all year round. I just do my small part—and they say, in the modern world, you should talk about your work. So, there’s that.

Documentation improvements

Documenting it (changelog entry)—the new anonymous parameter lacked the documentation, so I wrote some (and rephrased the numbered block parameters documentation appropriately).
Documenting **nil (changelog entry): While **nil construct (allowing to unpack it into empty keyword arguments) is a relatively minor change; trying to find the place in docs for it, I found it necessary to rephrase the whole section of the documentation about parameter unpacking (both positional and keyword ones)—hopefully, for the better.
Document backtrace-related changes (changelog entry): Structured caller/error backtrace values (in the form of Thread::Backtrace::Location) were introduced in Ruby 2.1, but only since 3.4 the structured backtrace can be set by a developer (when raising or post-processing the error). Integrating the concept properly with the documentation required some perspective changes in several places.

Behavior clarifications

it anonymous block parameter:

There are nuances related to the introspection of the parameters of the Proc (reported here):

# Old numbered arguments are introspected this way:
proc { _1 }.parameters    #=> [[:opt, :_1]]
lambda { _1 }.parameters  #=> [[:req, :_1]]

# But new `it` is reported differently,
# and inconsistently between proc and lambda:
proc { it }.parameters    #=> [[:opt, nil]]
lambda { it }.parameters  #=> [[:req]]

The local variables introspection for it-based blocks also behave differently from numbered parameters (reported here):

proc {
  _1
  p binding.local_variables
}.call
#=> [:_1]

proc {
  it
  p binding.local_variables
}.call
#=> [] -- `it` is not mentioned

Once I noticed the pair of problems, there was even an attempt to fix it. However, it turned out not that easy to do without introducing new inconsistencies/problems, so the “last-minute fix” was reverted. The desirable behavior will be discussed during the work on Ruby 3.5. Most probably, such inconsistencies wouldn’t affect the production code, but eventually, they are to be fixed for teaching/understanding the language value, if nothing else.

Array#fetch_values

The new method to fetch several values at once or raise/use defaults when they are absent (like Hash#fetch_value) was introduced. However, its accepted argument types are inconsistent with Array#values_at (the method that does the same, but without the control for absence):

[1, 2, 3, 4, 5].values_at(0, 3..4)    #=> [1, 4, 5]
[1, 2, 3, 4, 5].fetch_values(0, 3..4) # TypeError: in 'Array#fetch': no implicit conversion of Range into Integer

The discussion about proper behavior wasn’t finished in time for the 3.4.0 release (because it was reported late), so the decision will probably be made in the upcoming year.

Range#size has a new behavior to throw TypeError when the Range of a non-iterable type, but it has a small edge case:

(Time.now..Time.now+10).size
# 3.3: nil
# 3.4: can't iterate from Time (TypeError) -- new behavior

# But for beginless numeric ranges, there is a catch:
(..3).size
# 3.3: Infinity -- special handling, might be useful
# 3.4: can't iterate from NilClass (TypeError) -- is it worse?

Again, I hope to discuss this edge case during the work on Ruby 3.5.

A small funny thing that happened during producing the changelog examples is that I noticed that the (new) Ractor::[]/::[]= methods (Ractor-local storage) accepts both String and Symbol keys, like (existing) Thread#[]/#[]= but unlike (introduced in 3.2) Fiber::[]/::[]=, which only accepted Symbols. After reporting, the Fiber behavior was considered a bug and fixed.

A postcard from 🇺🇦

Please stop here for a moment. This is your regular mid-text reminder that I am a living person from Ukraine, with the Russian invasion still ongoing. Please read it.

One news item. In the first three days of the year, the russians killed three Ukrainian scientists: Ihor Zyma, a doctor of biological sciences and Olesya Sokur, a doctor of biological sciences, his wife, in Kyiv; Oleksiy Galyonka, a Candidate of Pedagogical Sciences (PhD) in Chernihiv.

One piece of context. Russians promote [Ukrainian] Christmas carols in Moskva as a “Russian cultural tradition, while at the same time banning Christmas caroling on the territories of Ukraine they’ve occupied.

One report. Stanislav Aseyev is a Ukrainian writer, journalist, veteran, and survivor of the Izolyatsia prison in Russia-occupied Donetsk, infamous for its torture of prisoners. He was the first Ukrainian journalist to see the Sednaya prison and death camp in Syria after the fall of Bashar al-Assad’s regime in 2024. Read his report.

One fundraiser. Please help this urgent fundraiser for a robotic ground systems unit.

My favorite overlooked feature this year

One of the reasons I started to do this work back in 2018 was an uneasy feeling of “(almost) everybody missing an important point.” Every year, many posts are published by various authors dedicated to explaining what’s new in Ruby. Almost every year, there is some change in syntax or API most of these posts overlook, probably considering it “some boring technical detail,” while for me, it feels like quality-of-life improvement stuff.

This year, such a feature was one developed by yours truly, so I apologize in advance for the shameless plug. It is a change in Range#step behavior with non-numeric ranges, which makes range iteration much more powerful.

As I explained in one of the recent articles, there was a long-standing historical inconsistency in Range#step iteration: with numbers, the argument was treated as “an amount to add on each step,” while for all other types, it meant “number of times to make a step forward with #succ”:

(1..3).step(0.5).to_a # uses +
#=> [1.0, 1.5, 2.0, 2.5, 3.0]

require 'active_support/all'
(Time.now..).step(30.minutes).take(2) # tries to use #succ
# TypeError (can't iterate from Time)

So the only usage of #step with non-numeric types was “several steps at a time”:

('a'..'e').step(2).to_a #=> ["a", "c", "e"]

Since Ruby 3.4, ranges of any type can use #step in a way that feels natural:

(Time.now..).step(30.minutes).take(3)
#=> [2025-01-04 21:39:44.369461267 +0200, 2025-01-04 22:09:44.369461267 +0200, 2025-01-04 22:39:44.369461267 +0200]

require 'unitwise'
(Unitwise(1, :km)..Unitwise(2, :km)).step(Unitwise(500, :m)).to_a
# => [#<Unitwise::Measurement value=1 unit=km>, #<Unitwise::Measurement value=1.5 unit=km>, #<Unitwise::Measurement value=2 unit=km>]

require 'matrix'
(Vector[1, 1]..).step(Vector[1, 1]).take(3)
#=> [Vector[1, 1], Vector[2, 2], Vector[3, 3]]

I expect time iteration to be the most widespread usage of the new feature, but I like it for introducing more power/consistency into the language.

Future possibilities

For a couple of years now, I promised myself to start maintaining the changelog “alive,” having the master section during the year (the same way Ruby documentation has the master branch version always rendered).

I hope this approach might allow to make people acquainted with what’s coming; it will also allow my “side effect” activities of changelog preparation to be done in a timely manner—which is especially important for confirming the edge cases like some with it and Array#fetch_values discussed above. Also, it would allow me to notice some other necessary documentation improvements. I frequently notice some things worth improving in existing docs (the methods neighboring or similar to the changed ones) but usually put them in my “long TODO” list… To never act upon, once the rush of finalizing this year’s release is over.

Maybe this year will be the one when I’ll finally act on this intention. Maybe not. We’ll see.

If you don’t have time to process it all, donating to Come Back Alive foundation is always a good choice.

Elixir-like pipes in Ruby (oh no not again)

Sat, 16 Nov 2024 00:00:00 +0000

On a new approach to implement that long-envied feature.

In Elixir¹, there is a pipeline operator that allows rewriting this code:

a(b(c(d)))

into this:

d |> c() |> b() |> a()

which helps to write code in clearly visible “pipelines” corresponding to the order in which data processing is happening.

The concept is so captivating that many languages that don’t have an operator like this have either language proposals or libraries that implement one. Ruby is no exception.

This is a story of my take on implementing it.

But first…

Why we don’t need it

There have been many proposals to introduce the operator to Ruby over the years. The crucial reason they are typically met with skepticism is that Ruby’s API is very different from Elixir’s. In Elixir, most of the methods belong to modules, while in Ruby, they belong to objects we are processing. So the usual Elixir’s motivating examples like

"go "
|> String.duplicate(3)
|> String.upcase()
|> String.replace_suffix(" ", "!")

…wouldn’t require any additional handling in Ruby to make it flow in the right direction:

("go " * 3)
  .upcase
  .sub(/ $/, '!')

Even most operators can be written in method-chaining style, so we also can do this (though not to everybody’s liking):

"go "
  .*(3)
  .upcase
  .sub(/ $/, '!')

When the method we want to call doesn’t belong to the last object in the chain, we have an escape hatch of .then (introduced in Ruby 2.5 as yield_self, and renamed to then in Ruby 2.6):

"https://api.github.com/users/#{username}/repos"
  .then { URI.open(_1) }
  .read
  .then { JSON.parse(_1, symbolize_names: true) }
  .map { _1.dig(:full_name) }.first(10)
  .then { pp _1 }

There was even an attempt to introduce something looking like a “pipeline operator” in Ruby, giving up to the pressure to have it but making it just another way of writing the classic chains. I.e. the example with strings above might’ve been rewritten:

("go " * 3) |> upcase |> sub / $/, '!'

The idea was backed by Matz and even merged for a short period before Ruby 2.7, but it caused so much distress and confusion (for bringing the new syntax, which didn’t do anything new) that it was reverted even before the release.

Another reason why introducing something like a pipeline operator in Ruby is problematic is that we don’t have first-class method references. Due to how Ruby methods are designed, something like URI.open is not a reference to a method object but an immediate call, and the only way to refer to the method is to do URI.method(:open)—which, to the best of my understanding, is not only wordy but also is not “cheap” because it would create an OO-representation of a method, the Method object, on the call. So, trying to optimize the “parse from URL” example above with a pipeline operator will require to put a reference to URI.open and JSON.parse into it, and there is no nice way to do that.

And still…

Why I did it anyway

My experiment is not a proposal as a library or as a core feature.

It was inspired by yet another discussion about introducing a pipe operator in Ruby. Initially, it started as they all go (with pipe operator being some syntax sugar on top of .then { code }). After some arguing, though, it took an interesting turn, where Alexander Magro, the submitter of the initial ticket, proposed this:

What I (re)propose is to define the pipe operator as a statement separator, similar to ; […]

This way, we could write:
"https://api.github.com/repos/ruby/ruby"
  |> URI.parse(_)
  |> Net::HTTP.get(_)
  |> JSON.parse(_)
  |> _.fetch("stargazers_count")
  |> puts "Ruby has #{_} stars"

I still doubt this proposal has a chance to make it into the language core, but there is at least some fresh take here and an interesting justification.

Another piece of the puzzle that finally nerd-sniped me was recently released Python’s pipe_operator library (like in Ruby, there were many attempts through the years). It provides two alternative implementations, one of them is regular “just a DSL”:

PipeStart("3")                        # starts the pipe
>> Pipe(int)                          # function with 1-arg
>> Pipe(my_func, 2000, z=10)          # function with multiple args
>> Tap(print)                         # side effect
>> Then(lambda x: x + 1)              # lambda
# ...

but the other one has tickled my curiosity because I couldn’t, from the top of my head, guess how it is implemented:

from pipe_operator import elixir_pipe, tap, then

@elixir_pipe
def workflow(value):
    results = (
        value                           # raw value
        >> BasicClass                   # class call
        >> _.value                      # property (shortcut)
        >> BasicClass()                 # class call
        >> _.get_value_plus_arg(10)     # method call
        >> 10 + _ - 5                   # binary operation (shortcut)
        >> {_, 1, 2, 3}                 # object creation (shortcut)
        >> [x for x in _ if x > 4]      # comprehension (shortcut)
        # ...

As it turned out, the approach that makes it work is an interesting one: when the @elixir_pipe decorator is applied to a method, it transforms the method’s AST and defines a completely different method, where the code is rewritten in a more traditional way. Basically, it is full-fledged load-time syntactic macros. Curious.

That’s what I immediately wanted to try to reproduce! Not the pipe operator (which is just a pretext for the experiment), but this “local rewriting” of methods using their syntax tree. I am not sure I ever saw such an approach used in Ruby, though I might miss something (the ruby-next transpiler does code transformation at load time, but on the level of the whole file, which seems quite a different thing; “transpilers” and “inline syntactic macros” are different by perception and usage).

And, lo and behold, here we are:

require 'not_a_pipe'

extend NotAPipe

pipe def repos(username)
  username >>
    "https://api.github.com/users/#{_}/repos" >>
    URI.open >>
    _.read >>
    JSON.parse(symbolize_names: true) >>
    _.map { _1.dig(:full_name) }.first(10) >>
    pp
end

repos('zverok')
# prints: ["zverok/any_good", "zverok/awesome-codebases", "zverok/awesome-events", "zverok/backports", ...

Basically:

pipe is a decorator² to mark methods inside which >> works as a “pipe operator”;
every step can reference _ which would be a result of the previous step;
but it also can omit the reference and just specify a method to call; the result of the previous step would be substituted as the first argument of the method.

It works. It is small and doesn’t introduce any monkey-patches to core objects. It is fast, too, unlike typical situation of adding some new expressiveness DSL slapped on top of Ruby.

It is also, probably, an awful idea.

A postcard from 🇺🇦

Please stop here for a moment. This is your regular mid-text reminder that I am a living person from Ukraine, with the Russian invasion still ongoing. Please read it.

One news item. Russia sentences Ukrainian mother of four to 14 years on ‘treason’ charges for supporting Ukraine.

One piece of context. “A reminder that the 1st Chechen War started by Russia ended not in RU’s victory.” Read this thread that gives a grim picture of how the peace treaties with Russia usually go.

One fundraiser. Please help boost this fundraiser from always reliable and transparent Project Konstantin.

How it works

The reference to the Python library that inspired me already gave up the trick

The code above is syntactically valid Ruby. But it is Ruby code that can’t be made to work with some small library/metaprogramming additions: URI.open is a method that requires at least one argument, as well as JSON.parse, and there is no way to convert them to some kind of “deferred method references”³. Also, no tricks will allow to introduce _ local variable at the middle of the pipe without it being explicitly defined (it can be made some contextual method, probably).

But this is not a problem, as this code is never executed.

Instead, pipe “decorator,” when applied to a method, does the following:

loads the method’s source;
parses it with parser gem into AST (abstract syntax tree);
transforms the AST’s shape into different AST that would work as the pipe expected to work;
converts the new AST into Ruby code with unparser;
evals the new code in the target class, basically redefining the method.

The code of the method that is really becomes defined is roughly this:

def repos(username)
  _ = username
  _ = "https://api.github.com/users/#{_}/repos"
  _ = URI.open(_)
  _ = _.read
  _ = JSON.parse(_, symbolize_names: true)
  _ = _.map { _1.dig(:full_name) }.first(10)
  _ = pp(_)
end

As an aside note, I would’ve be happy if this parsing/transformations could be performed by Ruby’s standard library, but I am not aware of any “unparser” (AST-to-source code) transformation solution based on either Ruby::AST or Prism. So, that’s that. I am also not aware of any standard method of obtaining the method’s source code other than “take location and look in file” which method_source gem implements. Would be cool to have some standard introspection tools in core/standard library, too.

The transformation code (even as written as proof-of-concept/demo) is robust enough to handle the usage of >> pipelines in the middle of a longer method, not only “the whole method should be a pipeline.” So this would work, too:

pipe def repos(username)
  repos = username >>
    "https://api.github.com/users/#{_}/repos" >>
    URI.open >>
    _.read >>
    JSON.parse(symbolize_names: true) >>
    _.map { _1.dig(:full_name) }.first(10)

  p "the rest of the code (doing something with #{repos.count} repos)"
  # Anything can be here, including other >> pipelines

…or, with => right-hand assignment (that is brought by pattern-matching), this:

pipe def repos(username)
  username >>
    "https://api.github.com/users/#{_}/repos" >>
    URI.open >>
    _.read >>
    JSON.parse(symbolize_names: true) >>
    _.map { _1.dig(:full_name) }.first(10) =>
    repos

    # ...the rest of the method, `repos` contains the result

…which seems to combine various flow operators handsomely!

Some conclusions

Once again, I am not saying that this experiment is dedicated to the introduction of a new operator in Ruby. The “library” is rough, experimental, sarcastically named, and will probably stay this way.

What I tried to do here is to experiment with the approach that would give macros-like capabilities without runtime overhead and deep invasion into core classes.

When might this approach be useful?

First, in cases like this: in a “laboratory” of the new language features. Would I be more sympathetic to the idea of this operator in general, I would try to work in some hobby project for some time with this addition to gather more data about whether it is really frequently useful and might deserve a place in the language.

Another possible usage is a strictly limited application: not something that is used throughout the entire codebase, but a thin/low-overhead implementation of a domain-specific language (emphasizing the domain-specific here) like Rake, or Sinatra/Grape, or Arel, or description of some ML/data-processing algorithm in a clear and concise manner.

Also, such an approach might be used for small rewrites of the method code (though I am not sure that possible gains are worth the added complexity), like, say, safe_sql def my_query that wraps all literal strings in a method into Arel.sql to make the overall code clearer.

BTW, would I want to make not_a_pipe a (somewhat) production-ready library, I would also

work through “unhappy paths,” from invalid syntax in the method to some parts of the pipeline throwing an error (we need to make sure that the backtrace would show the accurate file/line);
perhaps introduce an argument-less form of pipe method to handle all methods below the call (like argument-less Module#private), by catching method_added hook.

Some aside conclusions from this exercise are that:

it would be cool to see now, that Prism becomes Ruby’s default parser, its further development into something that would allow AST rewriting and code introspection;
I personally find “decorators” (the something def my_method) underused in modern Ruby practices, and I would like to see them more used; even if not as powerful as Python’s decorators, they allow for some interesting
Structural pattern-matching is stunningly convenient for handling AST transformations;
This was a fun way to spend half a Saturday, after all!

If you don’t have time to process it all, donating to Come Back Alive foundation is always a good choice.

…and in several other languages, but Elixir’s is the most widely-known one… except for shells, of course, which probably have originated the concept. But in many cases, when describing modern mainstream languages, the feature is referred to as “Elixir(-like) pipe operator.” ↩
In truth, Ruby does not have a separate “decorator” concept. pipe here is just a module-level method that receives the result of def repos (which is the method’s name, :repos), and then uses this name to somehow process the method. ↩
This library has found a way to do so by introducing a whole world of “proxy objects” inside the pipe context. ↩

There is no such thing as a global method (in Ruby)

Mon, 21 Oct 2024 00:00:00 +0000

What Ruby’s top-level methods actually are, who they belong to and how they are namespaced.

A few days ago, a curious question was asked on /r/ruby, which can be boiled down to this: How are the methods of the Kernel module available in the top-level scope?

The question was dedicated to rand method, but (as the author correctly suggests) it also applies to many seemingly “top-level” methods documented as belonging to the Kernel module, even as base as puts (print a string), require (load code from another file), or raise (an exception).

We know that in Ruby, all methods belong to some objects and are defined in their classes or modules. The documentation suggests that all of those “global” methods are coming from the Kernel module, yet you typically call them without referring to any module, object, or any other ceremonies (like loading some namespace or adding it to the current scope). So, how to understand this working?

puts "Hello World"

It is always a method of `self`

In Ruby (unlike most other OO languages), the bare lowercase identifier foo always refers to either a local variable or (if there is no such variable in the current scope) the method of the current object (the one that self refers to in the current scope).

So,

puts "Hello world"

is always¹ the same as

self.puts "Hello world"

What is the self in the top-level scope? It is a special object, which is called main (though you can’t access it by this identifier, so “main” is just a representation thing):

self                 #=> main
self.class           #=> Object
self.class.ancestors #=> [Object, Kernel, BasicObject]

So, we can see that it is just an instance of the generic Object, available as a top-level scope, and as such, it includes the module Kernel and all methods from it, therefore making puts available:

m = method(:puts)  #=> #<Method: Object(Kernel)#puts(*)>
m.owner            #=> Kernel -- who defined it
m.receiver         #=> main -- object which will receive the call

But… What’s the deal with this Kernel module anyway?

Confusing legacy quirk: `Kernel` vs `Object`

Ideologically, it was intended for Kernel module to be a storage for those “global” methods, available everywhere. All of them are private², i.e., available only to call on the current object from inside this object, thus making them look global:

self.private_methods.include?(:puts) #=> true

ref = self
ref.puts "Something"
# NoMethodError: private method `puts' called for main:Object

At the same time, methods defined in a base Object class, the common ancestor of all other classes³, are public methods that are available on every object for other objects, like #inspect, #to_s, #respond_to?(method), #is_a?(some_class), and so on.

But that’s how it was meant to be. In fact, most of the above public methods are also defined in Kernel, which is easy to check:

Object.instance_method(:is_a?)       #=> #<UnboundMethod: Kernel#is_a?(_)>
Object.instance_method(:is_a?).owner #=> Kernel
Object.instance_methods - Kernel.instance_methods
#=> [:!, :equal?, :__id__, :__send__, :==, :!=, :instance_eval, :instance_exec]

As you can see, a very small batch of what is “ideologically” public methods of every object are actually defined in Object class.

But, looking at the Object’s docs, you’ll see much more of them. This is literally a hack in RDoc (Ruby’s documentation system) to make it look like it is meant to be.

But, this hack is old and unaware of core methods being defined with Ruby (not C) code, and some of the public (ideologically Object’s) methods “slip” back into Kernel, like #then or even #class (e.g. obj.class). There is a long discussion about handling it in a saner way (which includes some explanation for how it happened), but it hasn’t moved much yet.

When you `puts` inside an object

So, if puts is actually not a “global” method, but a private method which is included from Kernel in every object, then… When you call puts from inside some other class’ method, whose puts is this?

Of the object that calls it!

class A
  def test
    p method(:puts)          #=> #<Method: A(Kernel)#puts(*)>
    #                                      ^ who owns the method actually
    p method(:puts).receiver #=> #<A:0x00...>
  end
end

A.new.test

This is different from most other languages (and, therefore, probably, from the default intuition of many developers), where “global” methods really do belong to some “global” scope and not to the current object.

This might be considered just an esoteric internal quirk, but understanding this fact may be useful sometimes. Say, in testing some Text UI class, one might want to write test code that checks that some class prints elements of the UI on a method call. (There are special RSpec matchers to check that, but let’s use this example for simplicity; there are many other Kernel methods that one might want to stub/expect in tests):

class MyUI
  def header
    puts "-----"
  end
end

RSpec.describe MyUI do
  let(:instance) { described_class.new }

  describe '#header' do
    it "outputs header (would fail)" do
      # No, that `puts` from inside the class wouldn’t call Kernel.puts
      expect(Kernel).to receive(:puts).with('-----')
      instance.header
    end

    it "outputs header (correct way)" do
      # because it owns its `puts`!
      expect(instance).to receive(:puts).with('-----')
      instance.header
    end
  end
end

A postcard from 🇺🇦

Please stop here for a moment. This is your regular mid-text reminder that I am a living person from Ukraine, with the Russian invasion still ongoing. Please read it.

One news item. There are reliable reports that soldiers from North Korea (as many as 12000) are currently training in Russia to participate in the war in Ukraine.

One piece of context. A year ago, on Oct 21, 2023, my best friend from the army training camp was killed in the front line. I wrote a bit about him in a mid-text “postcard” here. Here is a small memorial Twitter thread about him.

One fundraiser. Please help raise money for a volunteer, Olena Samoilenko, who helps the elderly, disabled, and other disadvantaged inhabitants of the Kherson region.

What about custom top-level methods?

So, if all that looks like “standard global methods” are actually methods of the current object (included from Kernel), what about user-defined global methods?

def my_method
  puts "who am i? #{self}"
end

The situation is almost exactly the same: such methods become private instance methods of the Object class, and as such, they are available in every object:

method(:my_method) #=> #<Method: Object#my_method() test.rb:1>

my_method # called in the context of the main object
# prints: "who am i? main"

class A
  def test
    my_method
  end
end

a = A.new
a.method(:my_method) #=> #<Method: A(Object)#my_method() test.rb:1>
a.test # invokes my_method that belongs to A
# prints: who am i? #<A:0x0...>

So, once again: all top-level methods are actually present in every object.

This is a clear and consistent system… Which might sometimes lead to extremely weird quirks with the metaprogramming code, which checks for some method’s presence by name and changes the behavior depending on it.

We actually caught one just last week: deep in Rails insides, there was serialization code that relied on whether the current object respond_to?(:avatar_url)—and in some completely unrelated place, a helper module was included into the global scope, which made all objects to have avatar_url method… But not the one that would be expected there in the serialization code. Extremely funny to debug!

The outtake is: keep your top-level scope clean of random methods, especially those with generic names, and including those that might come from included modules.

How others do it: To the best of my knowledge, there is no other languages (at least amongst relatively mainstream ones) with such an approach to “global” methods. Most of the OO languages either fully prohibit those (Java/C#, you only can have SomeClass.static_method); or there is no object context (no this/self) in those methods (Kotlin, Python, PHP), or the methods are truly global, and this in them consistently refers to some global object (JS with its globalThis, Scala). But I might miss something!

Is the main scope special?

The “main scope is special, everything there goes directly into the Object class” is a good enough heuristic to remember, but one might be interested to observe that the top-level code behaves like any method body: as if it is all performed in a method of an instance of the Object class. In Ruby, you can have nested method definitions, but they don’t define local methods and instead go to the parent class:

class A
  def outer
    # See, we are defining helper inner method!
    def inner(i) = print("iteration #{i}")

    5.times { inner(_1) }
  end
end

a = A.new
a.outer # prints "iteration 0", "iteration 1", etc.
a.inner(1000) # prints "iteration 1000" -- the method is now defined in a!
# ...and moreover
A.new.inner(2000) # prints "iteration 2000" -- it belongs to the A class

Like many things in Ruby, it is “unlike most of other languages, but self-consistent.”

With this knowledge, we can model main method and its definitions behavior this way:

my_main = Object.new

def my_main.implicit_top_level
  # that's where all your top-level code go
  def other_method
    puts "OK!"
  end
end

my_main.implicit_top_level
# `my_main` is an instance of object,
# so `other_method` is now defined in object
# Let’s check:
Object.new.other_method
# prints "OK!"

# And as everything, including the top-level scope, inherits from Object,
# we have it here:
other_method
# prints "OK!"

Here is Ruby for you, keeping on its “slightly peculiar yet consistent” side for most of the time.

This equivalence breaks when we talk about constants. All constants (including classes and modules) in the main scope are nested into the Object, too; but it wouldn’t work in our main_scope_method. So… It is a bit special thing, after all! Or, rather, it behaves consistently with a method body for everything other than constants; and consistently with class/module body for constants.

Summarizing it

Just to reiterate:

In Ruby, there is no such thing as a top-level/global method; the method without an explicit receiver (the core one or user-defined one) is always a method of the current object;
Methods defined on the top level become instance methods of every object; modules included into the top-level scope, are included into the Object;
This distinction—that methods are never really “global”—can be mostly ignored, but it is useful to have an accurate mental model when using metaprogramming or debugging large codebases;
Everything is inspectable and should be inspected;
Many things are peculiar yet self-consistent.

Hope this helps :)

If you don’t have time to process it all, donating to Come Back Alive foundation is always a good choice.

As we’ll see below, puts is a private method, and in older versions of Ruby, you couldn’t call self.private_method, only as a bare word (as a part of the general rule “no explicit receiver for private methods”); since Ruby 2.7, the requirement was relaxed to allow explicit self.private_method (but only self), see the Ruby Changes entry on it. ↩
In Ruby, unlike other languages, private methods are available to the children of the class who defined them, and protected is used to mark what some other languages might call “friend”: methods that are available to the current object and other objects of the same class. ↩
In some contexts, one needs a very lean class without any extra conveniences defined, and for that, the class might be explicitly inherited from BasicObject. But without this special approach, any class will inherit from Object. ↩

On programming and poetry (not Python’s tool)

Sun, 06 Oct 2024 00:00:00 +0000

Some thoughts on how programming’s unlikely relations to poetry, and some implications of those relations

I don’t have much time recently to work on articles about programming (especially considering my typical article length); but I have some previously written content to share. This article was drafted as a Twitter thread on my 39th birthday: a day when I published my new site, and announced “I’ll be writing more here soon!” It was Feb 14, 2022, ten days before the full-scale Russian invasion started. Two and a half years later, I finally go to making it into a standalone text with clearer arguments, some links and conclusions. Anyway.

You don’t see poetry (as in writing and reading poems, not the Python tool) mentioned besides programming frequently. And when it is, it is usually in one of two ways:

to contrast “soulful” humanitarian activity to the “boring” engineering one or
to use “poetry” as an informal synonym for “beauty,” to say that some code “reads like poetry” is to say it is nice, or expressive, or in some other way pleases the author of the statement.

But I believe there could be deeper insights in looking at them together. Here are some assorted thoughts on it.

Am I qualified to write about the topic?

Judge yourself.

From the software development side: I am a software architect, writing code for 25+ years, a Ruby programming language committer, author of some open source libraries, many texts, and some documentation projects; in former days, I did a lot of Ruby mentoring, including teaching people who had no prior knowledge about Ruby/programming whatsoever.

From the poetry/writing side: I have been writing prose and poetry for as long as I can remember myself; my first novel just had been published recently.

I considered myself primarily a poet for at least a decade between my mid-20s and mid-30s. I didn’t achieve much more than occasional magazine publication or festival participation (almost got my first book published, but then the publisher went bankrupt). Nevertheless, I had enough community validation to at least believe I understand some things about it (even if not excel myself).

I stopped writing poetry a few years ago (and switched to prose, that’s a different story). Some of my recent texts can be here (mostly in Russian, which I don’t use anymore, obviously).

I also organized a notable online poetry festival in 2017, before it was cool! (The site is down currently, and the remains of the festival are scrubbed from the internet for reasons too complicated to explain. However, I was exposed to a large number of authors from all over Western Europe who wrote in several Slavic languages—Serbian, Croatian, Bulgarian, Slovak, Polish, etc.—which was an educative experience in itself.)

I still read a lot of poetry and ON poetry and try to understand the broad context; this year, I started the 7uapoems project, dedicated to the translation of modern Ukrainian poetry written by those who are currently in the army.

With that being said, I am not really strong on literary theory, so all attempts to define things in the text below are my own. For those well-versed (pun intended) in theoretical matters, it would probably be irritating or laughable.

I don’t also try to go into precise theoretical terms on the software development point of view. This, I could’ve done, but my way of thinking and talking about things is usually “in layman’s terms,” for better or worse.

Why do we write and read literature

A loose attempt to define some things

Why do we write and read literature, any literature?

Mostly to share an experience. An experience of going somewhere, living through some events, feeling some emotions, understanding some things. The experience we probably can’t access directly. (Yes, there is also room for a variety of literature, which just helps to relive familiar experiences, but let’s not complicate it further.)

In the scope of this definition, poetry, in a nutshell, is a more efficient way of sharing an experience that is hard to express rationally. It relies on some “leap” of understanding, where a carefully crafted phrase is as efficient as five dense pages of explanations. (“Oversimplification” is my middle name!)

That has actually nothing to do with “beauty,” which is just one of the poetic tools that can be used, rejected, or subverted; in bad poetry, “beautifully crafted” lines can mask the triviality of the meanings conveyed/experiences shared.

While I stopped writing poetry, I still believe that the “poetic” way of passing the experience is the most efficient in many cases. And, to the best of my perception, I have never stopped doing poetic work while writing prose. There are “prosaic” writing tools: structuring the plot, taking care of worldbuilding, and inventing compelling motivations for characters, and there are “poetic” tools: choosing the tone, rhythmand imagery that would immerse the reader—and both kinds of tools are likely to be present in any forms of writing, in different amounts.

Conversely, if you don’t like to read poetry (or even don’t understand why one would do it), it might mean you might not have met the kind that communicates to you and your experience, or your temperament doesn’t require this particular form of writing. This is just a personal characteristic, and it doesn’t mean that you are never exposed to poetic tools of writing in other texts. And hopefully, this also doesn’t mean that there is nothing you can take from my comparisons.

A fragment from Artur Dron’s poem, “Izyum communion”. The translation is mine.

In the casual “engineering vs art” framework of thought, programming seems to oppose poetry. And yet, in former years, every time I shyly mentioned at a programming conference “…and also a poet”, there were people around—frequently, distinguished engineers—to say “me too!”

A quote via Alex Bilzerian, shown to me by my friend Dima Ermilov

I am thinking and writing a lot about perceiving code as text and intuitions/approaches/expectations it brings. One of the first articles on this blog (nine years ago, huh) was about Ruby’s suitability for “writer” kind of programmers; my recent EuRuKo talk also had “writing stories in code” as one of the key themes.

Taking the definition of writing from earlier, we can say that writing code is sharing the experience of understanding the requirements/implementation.

Looking from this point, we can clearly see room for poetic work here: it is frequently useful—at least with some mindsets—to start solving the task with the several “phrases” that make the leap over the whole implementation domain.

The topic is quite divisive: to the extent when any attempt to compress meaning with modern language features is frowned upon—especially sad to observe in the Ruby community, where the discrepancy between language’s intent and community practices seems to only grow with time.

The “poetic” approaches get ghettoized in the languages more friendly to leaps of understanding but less readable as everyday prose, like Perl and APL. (Aside note: the original thread was partially triggered by the first episode of The Array Cast podcast, explicitly mentioning poetry in regards to APL and related languages. But even there, if I remember correctly, it was mentioned rather as a generic synonym for “something beautiful/pleasant to read,” though the users of terse languages might be, indeed, closer to agreeing with the value of “pass the experience in an intuitive way via carefully crafted line of text.”)

The thing is, I believe that poetic work is a valid and useful tool.

Sometimes, “poetic” code is useful in the drafting stage, and then it is expanded—fully or partially—into a more verbose “prose,” all the modules and services and concerns.

Sometimes, the succinct, “intuitive” expression is the best, and it is acknowledged as such by most of the readers—the same way some lines of poems become proverbs. We frequently call these “idioms” in coding (I have my concerns with this term, but that’s for another time).

It might be an uncommon opinion, but the amount of code solving the same task might differ strikingly (talk orders of magnitude) if the “stop, think, write one verse” approach (instead of “write 20 pages of your usual”) matches the task.

And maintaining five lines of code—even one that leans on intuitions—is, in any case, cheaper than maintaining 20 files of it. A big part of the industry at some point stopped believing that, so the “don’t write smart code” argument is usually argued as “2 lines of ‘simple’ code against 1 line of ‘smart’.”

A postcard from 🇺🇦

Please stop here for a moment. This is your regular mid-text reminder that I am a living person from Ukraine, with the Russian invasion still ongoing. Please read it.

One news item. Russian forces executed 16 Ukrainian prisoners of war in the Pokrovsk direction.

One piece of context. How exactly Russia violates the Genocide Convention.

One fundraiser. Please help to raise fund to buy a logistics truck! “Way To Ukraine” is a reliable fundraising organization with full transparency and a real understanding of what our military needs.

So what?

Whether you sold on my comparison or not, you might wonder about its utility. Like, OK, programming, or some kinds of it, might or might not bear some resemblance to “poetic work,” but where does it lead us?

The thing is, I would like to see more people treating code on the level of phrases and “paragraphs” (methods or groups of statements) with the mindset of how the literature is treated. And I mean it not as just another way of saying, “let’s write bEAuTifuL code and be free as butterflies!”

I am talking about the kind of perspective from which we can analyze, discuss (and maybe teach ourselves) to think in terms of the effect on the potential reader (both human and compiler/interpreter) in terms of “how meanings of expression, in this case, convey the idea behind the code; whether it could be expressed in a different way to emphasize a different aspect.” It is a conversation that is less rigid than autoformatting and style guides and more nuanced than abstract “readability” or “smart/simple code.”

But time and again, when I have this conversation with people (colleagues or just participants of online discussions), it is a two-stop track: first, “it is all subjective, and just depends on who likes what,” and when presented with less-subjective analysis/explanation about how the text/code might be perceived, the second and final stop is “maybe, but I don’t understand why you pay so much attention to this, it is all nitpicking.”

But I still believe this is a conversation worth having. I would like to see, for example, some “literary” criticism of new releases of a popular library, along the lines of “this is a stylistic approach this author usually takes, which works this way, and is perfect for tasks like A, yet in situation B it leads to those possible misunderstandings…”—but we can’t have that, without being labeled as “subjective” or “nitpicking,” because “well, it works, what else do you need?”

We also need to recognize and cherish wild experimenting with form and style, the “poet’s poet” notion: code that, as it is, you’ll hardly use in production and in a team, but which helps to investigate the possibilities of the expressive power of your language, and master them to use appropriately.

The end goal here, again, is not some abstract “beauty” or “engineering excellence” but pragmatic values we all share: maintainability, openness to change—things that are affected with clarity of understanding, which, in turn, depends on how the things are expressed.

That’s why I return to the topic of code and text constantly and from different angles. Not for the last time, probably!

See also: “Do programmers dream of electric poems?”, an article by Facundo Olano which investigates similar topics with somewhat different argumentation.

If you don’t have time to process it all, donating to Come Back Alive foundation is always a good choice.

“Gilded Rose” refactoring kata in Ruby — as if it is 2024

Thu, 19 Sep 2024 00:00:00 +0000

A “stories-first” approach to refactor a small yet complicated piece of business code

Recently, I didn’t have time or resource for serious writing. I had plans for several long articles for the summer that gone, but unfortunately not many have came of that. But last night I have stumbled upon famous (so it seems, though I have never seen it before) refactoring kata, and had an impulse for trying my hands on that, writing down some thoughts on my ways of writing code along the way.

The kata

“Gilded Rose” is a famous refactoring kata that is available in many languages. It goes like this:

First an introduction to our system:

All items have a SellIn value which denotes the number of days we have to sell the items

All items have a Quality value which denotes how valuable the item is

At the end of each day our system lowers both values for every item

Pretty simple, right? Well this is where it gets interesting:

Once the sell by date has passed, Quality degrades twice as fast

The Quality of an item is never negative

“Aged Brie” actually increases in Quality the older it gets

The Quality of an item is never more than 50

“Sulfuras”, being a legendary item, never has to be sold or decreases in Quality

“Backstage passes”, like aged brie, increases in Quality as its SellIn value approaches;

Quality increases by 2 when there are 10 days or less and by 3 when there are 5 days or less but

Quality drops to 0 after the concert

We have recently signed a supplier of conjured items. This requires an update to our system:

“Conjured” items degrade in Quality twice as fast as normal items

Feel free to make any changes to the UpdateQuality method and add any new code as long as everything still works correctly. However, do not alter the Item class.

The initial Ruby implementation provided by the kata maintainer is some scary 45-line method, all made of ifs with many levels of nesting; it is a direct translation of the initial C# implementation. The suggested exercise is to refactor it in any way one sees suitable.

Several Ruby solutions to the kata can be found throughout the internet. Mostly, they take on the usual path of having a class per every item kind and frequently divide all the logic into five-word-name, one-line-body methods for each action in every class: that’s a style significant part of the community prefers lately.

My approaches to writing in Ruby are somewhat different, and I thought that I might just show how I’d solve a task like that.

“But isn’t it just a useless toy task?” No parallelism, no SQL tinkering, no sub-microsecond benchmarking… In all honesty, surprising amounts of business code written in many modern codebases are solving simple yet convoluted tasks like that; and too frequently poor expression of thoughts on this “negligible” level is what really affects velocity, stability and the design of the whole system. That’s why I am frequently talking about “phrase-level” expressiveness and method-size solutions, being principal developer and all.

Adding unit tests

The code has “integrational” tests: a script that prints the 30-day output for some items and an expected output file (which the original kata suggested to check via the specialized tool, but in a scripting language, it is easy to make the checking script from scratch).

It lacks more atomic tests, though, and that’s what we start with.

My approach to tests is simple:

I like TDD/BDD (in the loose understanding of “write the tests before changing the code”);
I treat my tests the way I treat my code: I want them to be easy to write and read, leveraging my language’s expressiveness to have the code as close to “clearly express the intention, and nothing else” as possible.

The latter is a surprisingly contrarian opinion in the latter years, at least in the Ruby community. I dedicated quite an emotional article article to the matter once, and I wouldn’t repeat my arguments here. I’ll just say that in my experience and experience of my colleagues, these approaches work, and I am not planning to change them anytime soon.

So, on the “clearly expresses the intention” topic. What I’d “theoretically” want to write in tests for this algorithm is something to the meaning:

for an item like this:
- in N days, we should have these values
- in M days, we should have those values
for another item:
- in N days, we should…
- …and so on.

That’s how I am doing it:

require_relative 'gilded_rose'
require 'moarspec'

RSpec.describe GildedRose do
  before { days.times { gilded_rose.update_quality } }

  let(:gilded_rose) { GildedRose.new([item]) }

  alias_matcher :become, :have_attributes

  describe 'standard item' do
    subject(:item) { Item.new(name="+5 Dexterity Vest", sell_in=10, quality=20) }

    it_with(days: 1) { is_expected.to become(sell_in: 9, quality: 19) }
    it_with(days: 10) { is_expected.to become(sell_in: 0, quality: 10) }
    it_with(days: 11) { is_expected.to become(sell_in: -1, quality: 8) }
    it_with(days: 15) { is_expected.to become(sell_in: -5, quality: 0) }
  end

  describe 'aged brie' do
    subject(:item) { Item.new(name="Aged Brie", sell_in=2, quality=0) }

    it_with(days: 1) { is_expected.to become(sell_in: 1, quality: 1) }
    it_with(days: 5) { is_expected.to become(sell_in: -3, quality: 8) }
  end

  # ...and so on

This code uses moarspec, my RSpec extensions library (which tries to be ideologically compatible with RSpec, just taking its ideas further), namely its recently added it_with method.

This method is just a shortcut for what RSpec already has. This code:

it_with(days: 1) { is_expected.to become(sell_in: 9, quality: 19) }

..corresponds to this vanilla RSpec code:

context 'when it is day 1' do
  let(:days) { 1 }

  it { is_expected.to become(sell_in: 9, quality: 19) }
end

…and is indispensable when you need to write a lot of tests for the same piece of logic, specifying the correspondence of various parameters to expected values.

The rest, like implicit testing of the subject (it { is_expected.to implicitly applied to what is declared as a subject above), and expressive matcher is what RSpec already provides. Though again, using many of these tools isn’t that fashionable lately.

This is not the only way to make a concise test for input/output pairs. Other options are truth tables, something along the lines of:

{
  1 => {sell_in: 9, quality: 19},
  10=> {sell_in: 0, quality: 10},
  11=> {sell_in: -1, quality: 8},
}.each do |day, attrs|
  context "when it is day #{day}" do
    before { day.times { gilded_rose.update_quality } }

    it { is_expected.to have_attributes(**attrs) }
  end
end

Or, using RSpec’s shared_examples feature:

shared_examples "change by day" do |day, **attrs|
  context "when it is day #{day}" do
    before { day.times { gilded_rose.update_quality } }

    it { is_expected.to have_attributes(**attrs) }
  end
end

it_behaves_like 'change by day', 1, sell_in: 9, quality: 19
it_behaves_like 'change by day', 10, sell_in: 0, quality: 10
# ...

Both of these options have their merits, but I preferred it_with approach here because it doesn’t have any indirections (like, a pair of input/output in one place, and how they are related is in the other), so when something fails, it shows exactly the line that failed. If I deliberately break one of the tests, RSpec will clearly point to the line it is broken (I am deliberately changing one of the tests to be failing to showcase this):

And the last line is exactly the command you need to restart only the failing test for quick debugging (which is harder with truth tables/shared examples).

Note also pretty informative test and error description produced without any additional text written by the developer. It is not very grammatical, but pretty clear.

The implementation

With tests properly passing, now to implementation.

When rereading the requirements, we might notice that all conditions can be described as a simple dependency (name, sell_in) => change of quality.

The most natural representation of this in the modern Ruby would be pattern matching. So, quite quickly (with a few failing tests and numbers tinkering), I’ve come up with this:

class GildedRose
  def initialize(items)
    @items = items
  end

  def update_quality
    @items.each { update_item(_1) }
  end

  def update_item(item)
    return if item.name == "Sulfuras, Hand of Ragnaros"

    change =
      case [item.name, item.sell_in]
      in ["Aged Brie", ..0]
        +2
      in ["Aged Brie", _]
        +1
      in ["Backstage passes to a TAFKAL80ETC concert", ..0]
        -item.quality
      in ["Backstage passes to a TAFKAL80ETC concert", ..5]
        +3
      in ["Backstage passes to a TAFKAL80ETC concert", ..10]
        +2
      in ["Backstage passes to a TAFKAL80ETC concert", _]
        +1
      in [_, ..0]
        -2
      in [_, _]
        -1
      end

    item.sell_in -= 1

    item.quality = (item.quality + change).clamp(0..50)
  end
end

There aren’t many moving parts here:

quick guard clause for “legendary item” that basically doesn’t require any processing;
almost literal rewriting of requirements into simple correspondences “with this name & range of values of how many days left: that change in quality”
the requirement “quality never goes below 0 and above 50” straightforwardly translates into Comparable#clamp; this allows decoupling of change of the value from the range control (instead of the naive initial “if it is inside limits, do the operation”).

For further clarity, let’s walk through a part of it, with comments (shortened the name of the item so the code will take less place horizontally):

case [item.name, item.sell_in] # we match pair of (name, days to sell)
# ...
in ["Backstage passes", ..0 ]  # if it matches (backstage pass, anything <=0)
  -item.quality                # remove the rest of the quality
in ["Backstage passes", ..5 ]  # otherwise, (backstage pass, anything <= 5)
  +3                           # +3 points: I used (optional) + to underline the meaning
in ["Backstage passes", ..10]  # ...and so on...
  +2                           #
in ["Backstage passes", _]     # if name still matches, and ANY other days to sell
  +1                           # the fallback value

Note that inside pattern matching, Ruby uses #=== matching method for every value in an array, and beginless range (..0: range from -infinity to 0, including it) has its === defined so that it returns true for a number inside the range.

That’s, kinda, it! The core method is 25 lines now (including blank ones); at the same time, it is only four simple expressions and only one level of condition/nesting.

Random fun fact: Ruby linter/style checker Rubocop with default settings would complain that:

Cyclomatic complexity for update_item is too high. (10/7)

Method has too many lines. (22/10)

Perceived complexity for update_item is too high. (10/8)

Judge yourself whether the complexity and length of the code in front of your eyes is that criminal! (In my opinion, our obsession with “small simple methods with very descriptive names” went too far many years ago.)

One more notice: the original kata’s text suggests “not to re-write the code from scratch, but rather to practice taking small steps, running the tests often, and incrementally improving the design.” What I did, though, demonstrates one of the things I’ve learned to trust through my career: when meeting with really problematic code, it is frequently easier to rewrite [parts of] it from scratch, at least on a small scale. Iterative improvements might never converge to something that clearly says what the original intention was!

If I hadn’t been provided with the requirements when meeting the code like that, I’d probably move for some time with iterating improvements till the original requirements would become clear—first and foremost, trying to make if linear (even at the price of repeating conditions) to see how many branches are there really; and then considered whether there is a better way to implement those requirements. (I tried to demonstrate that in a series of commits to a separate branch, but early on in the attempt, I understood I was not doing an honest job. I couldn’t shake away the knowledge about the requirements, so I was too quickly shortcutting to “oh, anyway, I know why this < 50 repeats in many branches”. If I stumbled upon the kata again, it would be fun to try to honestly restore the requirements from the code without reading them first. But it is what it is.)

What it would take to implement a new requirement

Let’s remember that the whole kata’s goal was to make updating the code easier. So, back to that newly emerged requirement:

We have recently signed a supplier of conjured items. This requires an update to our system:

“Conjured” items degrade in Quality twice as fast as normal items

Specifying that will require adding this tests block:

  describe 'conjured item' do
    subject(:item) { Item.new(name="Conjured Mana Cake", sell_in=10, quality=30) }

    it_with(days: 1) { is_expected.to become(sell_in: 9, quality: 28) }
    it_with(days: 10) { is_expected.to become(sell_in: 0, quality: 10) }
    it_with(days: 11) { is_expected.to become(sell_in: -1, quality: 6) }
    it_with(days: 15) { is_expected.to become(sell_in: -5, quality: 0) }
  end

…and this to the main case of the implementation:

      in [/Conjured/, ..0]
        -4
      in [/Conjured/, _]
        -2

(As explained above, pattern matching uses === to check individual values, and Regexp#=== can be utilized here to handle “any string that starts with”. Random fun fact: many nice refactorings suddenly break on the necessity to handle string inclusion instead of constant strings to identify the necessary case.)

So, an eight-line change in total, including blank lines (the commit is somewhat bigger as it also updates the integrational test).

Well, seems not that bad, actually…

A postcard from 🇺🇦

Please stop here for a moment. This is your regular mid-text reminder that I am a living person from Ukraine, with the Russian invasion still ongoing. Please read it.

One news item. Photos emerged on social media showing russians executed an unarmed captive Ukrainian soldier with a sword.

One piece of context. Many international festivals decided to screen the “Russians at War” movie by “Canadian” director Anastasia Trofimova. It is claimed to be a documentary, but it is actually a propaganda piece by a person employed by RT Russian propaganda channel.

One fundraiser. The PayPal fundraiser for the most critical Pokrovsk frontline direction.

Is that really it?..

So, an honest question one might have: if it was real application code, would I really leave it like that, in one method with many conditions?

With this amount and uncertainty of requirements, honestly: yes!

One thing I am not happy about here, though, is the repetition of the name check in the pattern-matching solution. The possible alternative, which is kinda “DRYer”, is using ole good case/when instead:

  change =
    case item.name
    when "Aged Brie"
      case item.sell_in
      when ..0 then +2
      else          +1
      end
    when "Backstage passes to a TAFKAL80ETC concert"
      case item.sell_in
      when ..0  then -item.quality
      when ..5  then +3
      when ..10 then +2
      else           +1
      end
    else
      case item.sell_in
      when ..0 then -2
      else          -1
      end
    end

The solution has its pros and cons:

pro: no duplication on name check; more visible logical blocks per item group;
con: duplication of the condition case item.sell_in—which is somewhat harder to notice (that all the checks are by the same parameter) and somewhat easier to break (i.e., introduce another part of the logic that makes the decision by another variable and start losing the whole picture).

In real application, I might’ve chosen one of the two (or switch between them during development), depending on what feels better at the moment!

With the growth of the cases number (or if I’d felt extra-architector-y), I might’ve also considered a data-based approach: construct a constant hash of conditions like…

{
  "Aged Brie" => {
    ..0 => +2,
    1.. => +1
  },
  "Backstage passes to a TAFKAL80ETC concert" => {
    ..0   => :nullify, # a special value "drop it to zero"
    1..5  => +3,
    6..10 => +2,
    11..  => +1
  }
  # ...and so on
}

…and then a code that chooses the change based on that.

But only after understanding I have enough cases to decide what is the exhaustive structure for such a constant (and if we really have one).

Which leads us to the following question…

But what about asbstrakshunz?

Apparently, the first intuitive reaction of many Rubyists (and not only them) to a task like that is thinking about representing each of the cases as a class that implements the corresponding piece of logic. It is so widespread that I have a term for it: knee-jerk OOP.

I was like that, too. But with years, I learned to keep my OOP reflexes at bay—as well as any early “let’s abstract it!” urge (like the aforementioned “constant extraction” idea).

While the amount of code implementing some algorithm is no more than one screen, roughly, it is frequently beneficial to keep it all together to see the whole story at once. This way, when we don’t need to navigate through many classes/small methods, we can clearly see what variables change non-trivially (only quality, with sell_in being absolutely trivial), and variants of behavior we have (constant increase, constant decrease, nullify), and it is immediately obvious that we don’t (yet?) have cases like “quality halves every day” or “it depends on the weather”.

I call it the “stories-first approach” (a slide from my recent EuRuKo talk, I hope the video will be published soon):

Once there is more code (as the amount of conditions in the kata requirements is, of course, toy-ish), we might begin to see the appropriate structure for it, which might be quite different from the knee-jerk one! Would there be more “legendary” items, and would this mean the same thing every time (“just a constant quality and no sell_in change”) or a new thing every time? What types of quality changes might be there, other than “increase/decrease/nullify”? Which types of the “change by” value changes are common, and which are accidental?

Only having more than one screen of possible cases might we need to try finding things to extract. And quite frequently, the things extracted might happen to be small utilities, new “words” in the language the “story” is written in, instead of splitting one story into many independent ones!

That’s it for now. Hope it was an interesting journey into another person’s thinking process, even if you disagree with some (or all) of the conclusions.

If you don’t have time to process it all, donating to Come Back Alive foundation is always a good choice.

BuyMeACoffee silently dropped support for many countries, and nobody cares

Thu, 08 Aug 2024 00:00:00 +0000

Silent changes in payment methods on big creator funding platforms raise some unpleasant questions.

UPD Aug 13, 2024: The kind-of-official reply from BuyMeACoffee, and my response to it.

UPD Aug 14, 2024: A support email to one of the users gives BuyMeACoffee’s reasons, and also they blocked me on X (Twitter).

What happened

Recently, many Ukrainian creators have reported problems with payouts from BuyMeACoffee, a creator funding/crowdfunding platform.

At first, the reported support answers were typical corporative “we are sorry that we don’t care,” citing “compliance” and “policy updates.”

В оригіналі, щоб вестерни читали які там є нікчеми pic.twitter.com/JxoGgamYLq
— Karå ꑭ🇺🇦 (@BzickOff) August 2, 2024

Those reports were widely shared, and our predominantly feeling was “shocked but not surprised”: it is not the first time when a big platform has decided that they are too busy to try to distinguish non-occupied parts of a large country with a 30+m population from occupied parts, and decided they don’t care. Just recently, for example, the Mercury payment system just blacklisted the entirety of Ukraine alongside Iran and North Korea.

But in a few days, it turned out (again, from support messages shared on Twitter) that BuyMeACoffee just dropped support for Payoneer (which works in Ukraine), leaving Stripe (which doesn’t) as the only payout method.

4. Бо бай мі кохве мала в гузно своїх споживачів та закрила можливість виводити кошти напряму на карту через Wise, а також через Payoneer. Єдино можливий метод виводу стає сервіс Stripe який не доступний в Україні та до 14 серпня всі автори зможуть ввостаннє вивести свої кошти. pic.twitter.com/XIQdNHVllu
— AdrianZP (@AdrianZPcity) August 7, 2024

Did they, though?

Currently BuyMeACoffee’s support page simply states:

Buy Me a Coffee supports payouts to creators in several countries, facilitated through our payment provider, Stripe.

According to the Internet Archive, in February, there was another link to a page that listed Stripe and Payoneer, while May’s snapshot already has only Stripe-related links.

So, the change in the documentation happened somewhere between February (that’s when I personally used it for the last time) and May: Internet Archive doesn’t provide other snapshots between those two dates.

So, at least the support’s private answers were aligned with the documentation.

At the same time, there are a couple of funny facts about this deprecation.

First, I know for a fact that some Ukrainian creators were receiving payouts via Payoneer somewhere around ~1 month ago; I even saw a credible claim about last week! (I just sent mine, which trickled from a moderately popular blog, will see whether it will come through; it is funny if it will. At least my configured Payoneer payout method is currently active in the BMaC dashboard.)

But more importantly, there was NO communication about the change. You wouldn’t find anything on their Twitter or in the public changelog (screenshotted at 2024-08-08 11:05:30 GMT+0300—just in case something will magically appear there retroactively):

As you can see, there is nothing about payout updates after the Nov’23 post, which mentioned Payoneer and Wise as available options alongside Stripe.

I assure you that there was no email communication to the creators either.

How bad is this?

The difference is public lists of supported countries between Payoneer and Stripe are 95 (ninety-five) countries and territories. I am not sure that all 95 of those don’t have working Stripe (say, maybe the Faroe Islands just listed on Payoneer separately while being actually served by Stripe via Danish banks?), but it seems to be a lot anyway.

I’d like to know what the experience of BMaC users from those countries is like. But what I know for sure is that in Ukraine, a lot of people use the platform as a source of income (sometimes even a primary one). My subscriptions, for example, include but are not limited to:

A singer-songwriter turned paramedic who uses BMaC donations to record her songs on short vacations between duties;
A writer and culturology scholar turned soldier who funds his studies about Ukrainian culture and history;
A girl whose two brothers have fallen on the frontlines, and she funds her absolutely unique book club to connect to people and share reading experience with them;
A small business owner from Kharkiv who uses a “build in public” approach for a small coffee shop (and recently got mobilized into Armed Forces);
…and so on.

None of them have BMaC as their primary income, and still, it is a sign of support from their peers and the possibility to continue doing what’s important to them.

There is no way for any of us to receive the money accumulated on BMaC anymore. What looks like “technical” change for some American is realistically prohibitive for those not privileged enough to live in Stripe-supported countries. The money is still “there”, so probably no lawyer can say BMaC has “stolen them”—you just can’t neither receive “your” money nor, at least, give them back to those who sent them.

Note that some BMaC accounts have a lot of supporters, and many of those use “yearly” payments as a sign of their support—and all of it is currently in some technological limbo.

Now, I am just a mere developer, and I don’t know much about payout regulations and legal facts. I might charitably assume there was a good reason for dropping Payoneer support (maybe a business one, or maybe it is actually related to some government regulations). The fact itself is extremely distressing for many, but hey, that’s their business, what do we know.

But the way this policy was implemented—no prior notice, no choice, no explicit communication of the reasons and possibilities—is absolutely fascinating, to say the least. And, honestly, support’s evasive behavior (and inconsistent reports about “some Payoneer payouts might still work”) just adds insult to injury.

I am not sure that any service that handles people’s money as their primary activity, and that does it this way, can be ever trusted. Just sayin’.

Have a good day, and have a screenshot of the latest message from BuyMeACoffee’s ever-positive Twitter!

Such a nice vibe! (Neither their primary account nor the founder’s personal one, which both have a history of replying to all relevant tweets, are currently giving any signs they are aware of the situation.)

PS: As a side note, here is a story about why Patreon is not an option for Ukrainians. And here is russian war correspondent’s Patreon account, mentioned in the story, still proudly present on the platform (though seemingly dormant).

UPD: Aug 13, 2024

So, folks! After a week of poking, we have a kind-of-official answer from @buymeacoffee!

Let’s unpack it!

This is simply not true. Let us clarify:

1. We never hold funds. If for some reason we cannot payout (potential fraud, bank account issues), the amount is refunded.

2. Not one Ukrainian creator's payout is held. We paid out to thousands of Ukrainian creators this week. Please…
— Buy Me a Coffee (@buymeacoffee) August 12, 2024

0. For some reason, this answer is a reply to one of those repeatedly asked them. Not even a standalone X post, nor a blog/changelog entry, nor a newsletter to creators.

So, if you aren’t a creator who constantly buggers them on X-formerly-Twitter (or follows all the discussions), you might still be unaware of the policy change or the existence of some answers.

The official feeds are still clear of the topic.

We never hold funds. If […] we cannot payout […] the amount is refunded.

I believe this intention (well, anything less would be a legal suicide), but I would still like to hear: a. How the “cannot payout” decided and whether “the creator doesn’t have payout method we like, they should try another one” qualifies b. A success story of real refunding (say, $5 to thousands of people) and whether it really works or just a claim.

Not one Ukrainian creator’s payout is held. […] Please reply with the creator @ if you know of any.

I want to believe that. In my original thread, and many other threads and discussions, I saw a LOT of people with negative experience of interaction with support.

Hopefully, ALL of Ukrainian creators who reported payout problems and unhelpful support responses are paid now? (And hopefully, it is not by means of “just find an EU friend who will agree to receive a payment for you”?.. Because I saw stories like that).

Also, dear BuyMeACoffee, “please @-us if you know a creator who has problems” would be a lot more persuasive if it wasn’t in the effing replies under just one tweet.

Just sayin’

Almost all of our creators use our standard payout method powered by Stripe.

Yeah, the so-called “First World”. But I get it. I do.

We’ve decided to focus on this for […] reasons which are important for the sustainability of the business.

That’s your business, and that’s your right to do so. As inconvenient as it might be for us, we have no say here. But the way it was communicated…

we’re planning to continue offering an alternative payout method […] for countries that are not supported. As we figure this out, we can confirm that it is business as usual for creators from Ukraine

It would be such a nice message if communicated clearly & timely 🙏

We’d appreciate it if you stop spamming our socials, spreading misinformation about us such as “we blocked withdrawals to Ukraine”. We’ll have no option but to block you and move on.

You know what?

We’d appreciate if you would be clear, honest, and public about the changes you make.

We’d appreciate your support not changing the story from the initial “it’s compliance standards”, to further “your payout method is not supported, it is your problem” to final (after the public outrage) “oh of course we would help everyone 🙏”.

We’d appreciate the public communication of the situation (and no, the reply in one thread in X that ends with passive aggression is not it, thank you very much!)

We’d appreciate having this convo, like, a couple of weeks ago.

In conclusion, I don’t believe BMaC being malicious or scammy in this situation (and I do want to believe they are looking for a solution that will work for us, too). But the amount of neglect and disregard that was displayed in the way the change was implemented and communicated, and in the interactions with support, makes it almost a textbook case of bad communication.

UPD: Aug 14, 2024

One of the Ukrainian creators received an unusually honest explanation of the reasons behind dropping support for Payoneer and Wise: “Incompatible with our upcoming features.” So, like, a bit more convenience for the First World users, at a price of excluding those not that privileged. (Note also that in this communication there is no sign of that promise of that “planning to continue offering an alternative payout method […] for countries that are not supported” which was sweetening their public communication.)

I am disabling @buymeacoffee account tomorrow.

The company is irresponsibly punches its Ukrainian clients in the guts by disabling Wise and making payouts impossible.

This isn’t just about switching platforms; each Ukrainian creator will lose their entire subscriber base. This… pic.twitter.com/BPnuAgcutk
— Kate from Kharkiv (@BohuslavskaKate) August 13, 2024

And another update: After several days of persistent, yet polite, poking their public X account, asking for public statement (more public than a reply in a thread), BuyMeACoffee just blocked me, reportedly “for spreading misinformation”:

Note there is new, previously never stated, pieces of information: about Payoneer working till Nov.1—not “do your last payout in August,” as it was previously; and about Wise which they will “continue to offer” (currently, to the best of my understanding, they aren’t).

zverok's space

It is 2026; where were we?

Writing in 2025

Not writing in 2025

A brief diversion: my views on AI

Maybe writing in 2026

Notes on code, text, and war. Week 2: If code is text, then what?

Notes on code, text, and war. Week 1: Believing in text

Seven things I know after 25 years of development

1. You outgrow every framework

2. Patterns and methodologies fail

3. The scale only grows with time

4. Pay attention to stories

5. The goals are truth and clarity

6. This might be a lonely experience

7. Never give up seeking truth

The short outburst of activity during Ruby Changelog preparation—2025 edition

How it is done

Some consequences

Documentation improvements

Behavior clarifications

A postcard from 🇺🇦

My favorite overlooked feature this year

Future possibilities

Elixir-like pipes in Ruby (oh no not again)

Why we don’t need it

Why I did it anyway

A postcard from 🇺🇦

How it works

Some conclusions

There is no such thing as a global method (in Ruby)

It is always a method of self

Confusing legacy quirk: Kernel vs Object

When you puts inside an object

A postcard from 🇺🇦

What about custom top-level methods?

Is the main scope special?

Summarizing it

On programming and poetry (not Python’s tool)

Am I qualified to write about the topic?

Why do we write and read literature

How is programming related?

A postcard from 🇺🇦

So what?

“Gilded Rose” refactoring kata in Ruby — as if it is 2024

The kata

Adding unit tests

The implementation

What it would take to implement a new requirement

A postcard from 🇺🇦

Is that really it?..

But what about asbstrakshunz?

BuyMeACoffee silently dropped support for many countries, and nobody cares

What happened

Did they, though?

How bad is this?

UPD: Aug 13, 2024

UPD: Aug 14, 2024

It is always a method of `self`

Confusing legacy quirk: `Kernel` vs `Object`

When you `puts` inside an object