(Traduzione italiana di questo post: http://antirez.com/news/137)

[Sorry for the form of this post. For the first time I wrote a post in two languages: Italian and English. So I went for the unusual path of writing it in Italian to start, translating it with Google Translate, and later I just scanned it to fix the biggest issues. At this point GT is so good you can get away with this process.]

After two years of work, finally, Wohpe, my first science fiction book, but also my first prose writing of this length, has been released in Italian physical bookstores, on Amazon, and in other digital stores. You can find it here: https://www.amazon.it/Wohpe-Salvatore-Sanfilippo/dp/B09XT6J3WX

I was saying: the first writing of this length. But can I consider myself entirely new to writing? I have written for twenty years in this blog and in the past ones that I have kept over time, and very often I have used Facebook to write short stories, the result of fantasies or based on real facts. On top of that, I've been writing about technical stuff, especially programming, for an equally long time, and I've been a short story and novel reader my entire life. So why was writing Wohpe also learning how to write from scratch?

In the first months of writing the novel, but also earlier, in the previous months, when I was preparing myself by writing long stories that I would then throw away, what happened to me often happens to those who learn to play chess. Many follow this path: they learn the rules, and that's okay, we know that you don't do much with them; the rules only allow you to move pieces legally. But then, soon after, they learn some rudiments of tactics and strategy, perhaps studying hard for a few weeks. But when they are on the board, if one move is not brutally worse or better than another, all the moves seem equivalent. The unskilled, inexperienced chess player has no real taste for moves; she fails to evaluate them not only for what they are in absolute terms, but not even according to his own idea. The result is a casual game. Only later, after many hours of play, will she finally be able to express choices that, regardless of whether they are right or wrong, have at least a coherence, they were really thought: I want to move the horse here, for these precise reasons, and for these reasons I prefer this move to all other possible ones.

So whoever writes and is at the beginning, if a sentence is good, he certainly does not know it (and to continue with the above comparison, just as the chess player's game will be casual, his writing will be casual). Move a comma, change a word. Does it sound good or bad? He has ideas that he formed by writing at school and then writing as an adult, but these ideas help him little when the ambition is to write a literary level prose. The novice author does not have his own style, because before not knowing how to write he does not yet know how to read: when he reads a book he adores, he rarely understands exactly * what * happens on the page that is so convincing, and so also when he re-reads himself, he does not know if he wrote well or badly. Read, if you want to learn to write! They all say. Too bad it's not true: first of all you have to write, to learn how to write, just as you have to make short films to learn to be a director, and watching other films will not be enough (although it will certainly be useful). And to learn to write, the kind of reading that is really needed is the rereading of some books that we have chosen as models; what is useful: the rereading to fully understand its forms. Now this simple fact, of having understood what my style is, and of finally knowing how to read and have a judgment that immediately emerges when I have a work in my hands, is already more than enough compensation for the two years of writing efforts in which I have lavished.

And it is fortunate that the experience itself was of such great value, because what many new authors do not know is how violent the world publishing market can be, and the Italian one in particular. In Italy a science fiction book that has a good success, published by a small or medium publisher, sells 500 copies. It has to be fine to have these numbers. Most books sell less than 100 copies. To us computer scientists these figures make us shiver. The stupidest program I wrote had ten times as many users. I would go as far as to say that the stupidest program I've written and published with a minimum of energy has had these * readers * ten times, people who have read its source code to understand how it works. I have been, and for this I thank I don't know who, a programmer of a certain notoriety, you might say. What I mean is far beyond my personal experience. Even those who are not known by anyone and try to do something on average interesting, just well described and documented, in programming, and show it around a bit, receive enormous interest compared to what belongs to the authors of fiction. The reasons are many and quite obvious, it is not even worth dwelling on them, so why am I telling you these things? For this reason:

There are few activities, besides the literature, where there is the same monstrous imbalance between the forces needed to produce a work and the poor response of the public. Anyone who decides to devote a lot of time to writing must know this fact right away. Fortunately, I already knew everything, thanks to my writing friends; however, certain nuances of this irrelevance end up being difficult to accept.

So why is everyone writing? The ranks of those who try their editorial fortune are overflowing. I think it's a similar mechanism to what happens in IT, with many trying to create a new programming language: failure is almost certain, but doing so is one of the most satisfying companies to devote your best energy to.

Now I'm at a crossroads: I could write more prose, get back to coding, or try to keep the two activities alive at the same time. What I'll do I don't know yet. For now, let's see what happens with Wohpe, both with the Italian version and with the English translation, which a capable translator is working on right now. And on this matter of the translations, carried out with the support of the author, and what a significant experience it is from the philological point of view, maybe I will talk to you some other time (Bridget and I speak English and Italian, but we are native speakers of one and I of the other language, and this is very interesting when collaborating between translator and author). I close the post by saying to those who read me: if you feel like it, write prose! I now know for sure: it is no coincidence that for hundreds of years writing has been considered the highest art in which to try one's hand. By writing you look for things, and if you insist enough you end up really finding them. Comments

This passage here from John Gruber’s review of some new macs struck me in particular:

Web browser rendering is surprisingly resource-intensive — partially because modern HTML, CSS, and Javascript are remarkably complex, and partially because most web developers are remarkably untalented and careless programmers

I disagree with Gruber’s take on a lot in tech, but I think this is an accurate representation of what people in tech who aren’t web devs think of web dev.

Our problem is this is the only rational conclusion to draw from experiencing our work.

Of course, my line is that web dev isn’t unique in kind (most of software dev is pretty bad, I even wrote a book about it), but my specific corner of it – web dev – is unique in degree: the web experience is so much worse, on average, and so much more dysfunctional than even the most mundane shitty native app that most people have access to.

The field as a whole either keeps denying there’s an issue or blames somebody else. Usually they blame ads and analytics, but if they were the only problem, then ad blockers would be a genuine cure-all.

I always try to point out that the entire software industry is dysfunctional. It isn’t just web software that’s bad. The software industry management class is woefully undereducated about the issues inherent in software development, which is why they don’t push back against the bad advice they get on web dev.

But the people they’re getting that advice from? By and large influential web devs. Some of them senior. Some of them just senior on Twitter. But, React and its ilk are popular. Most web dev use these frameworks voluntarily, even when working on their personal projects.

• “Single-Page Apps are vastly superior to any alternative in terms of User Experience… No I haven’t done any user research to back that up."
• “We need to base our app on React because the only way for us to realistically scale up recruitment is with a popular framework… No, we aren’t hiring."
• “We would be fine if it weren’t for all the cruft that sales and marketing makes us add… No, we don’t have a UX designer on the team. Well, Joe does that. He’s one of our full-stack devs. He used to be a UX designer."

And you can’t really just pin the blame on individual technologies.

Sure, Single-Page-Apps and React are objectively not fit for purpose for most websites and web apps. Sure, most frameworks bake in affordances that – over time – pretty much guarantee code bloat and buggy navigation.

But, y’know, our UX design is also awful.

Like, genuinely bad.

Most web apps – even when wrapped in Electron – have the usability and aesthetics of a 1990s enterprise Windows app trying to fit in at pride. Same old, same old, just this time with more colours and grossly misplaced attempts at casual banter.

(Seriously! What’s up with the grossly inappropriate UwU, creepy intimate, backstabber tone of modern software copywriting? Fuck off! You’re a tool, not my friend!)

Or, look at any time web software intersects with social behaviour. Both our collaborative and social software misunderstand basic human psychology to such an extent that it literally costs people their jobs, endangers their lives, and even leads entire societies to destruction (see Meta for a few examples).

Don’t get me started on accessibility.

Next to nothing we do as standard in this industry is right. Many of us – still a minority – have been pointing this out for years, always ignored, and now this is how the world sees us:

Remarkably untalented and careless.

So, just this once, I’d like to suggest that everybody in web dev point their dysfunctional novelty seeking (of which I suffer as well) in the direction of HTML and CSS. See how much can be done without JavaScript. It’s a lot! Then look at writing more lightweight JavaScript that’s layered on top of the HTML as enhancements. Because it’s an enhancement and not required for functionality, you can cut the line higher and use newer tech without worry.

See how refreshing that feels.

Really, really start to invest in user research (actual research) and UX design.

The stuff we put out is starting to look embarrassing.

We’re pretty much the one part of the field of software that would be genuinely justified in throwing out the old ways and trying something new.

That, in and of itself, is an opportunity.

We might not be able to convince our managers, but we can try.

If we’re vocal enough as a group, we can make sure that the misplaced tactics that led us here cease to be uncontroversial standard practices.

We can plant seeds of doubt, and those seeds can grow into the thin end of the wedge.

While you’re here. I’m working on a course on testing and import maps – two things that I think go great together and solve many problems. The pitch page for the course is still a work in progress and I would really appreciate some feed back on it. So, if you have time, have a look and see what you think. Then, if you have the time, let me know what you think on Mastodon, Bluesky, or via email. All feedback is greatly appreciated.

For too long, tree lovers have claimed bragging rights over us prairie folks.

“Our plants live longer than your plants!”

Well, I bet they don’t, but I can’t prove it. However, if you’ll follow my train of logical deduction, I think you’ll come around to my side.

Perennial prairie plants start each season at ground level. That’s true for grasses, sedges, and forbs (broad-leaved plants). Their annual growth comes from buds at the base of the plant or elsewhere near or below the surface of the soil. At the end of each growing season, everything above the soil’s surface dies back and the plants will restart at ground level again the following year. This is different from trees and shrubs, which form buds above ground that help the plant pick up where last year’s growth left off, continually growing larger each year.

These belowground buds give herbaceous (non-woody) prairie plants a big advantage over woody plants when a fire occurs. It’s no big deal for grasses or forbs to restart their growth at the ground, especially if a fire comes through during the dormant season. They were going to do that anyway, so nothing has been lost. Even if a fire burns across a prairie during the middle of the growing season, prairie plants are like, “eh, whaddya gonna do?” and just start again. It might stress them a little, but they’re too cool to complain about it.

Trees, on the other hand, invest a lot of time and energy into growing tall and don’t like it when a fire destroys everything they’ve worked so hard to build. Some kinds of trees take the loss of their investment so hard they don’t bother to start again and they die. Prairie people often call these trees “eastern red cedars”.

Most trees and shrubs, though, can resprout from their own buds down by the ground and begin growing again. They don’t like it, though. You can almost hear them whining about it. If a prairie burns often enough, trees and shrubs don’t have time to grow tall enough to be bothersome (other than all the whining).

Anyway, I was talking about buds…

Because perennial plants make buds at their bases, all they have to do to survive for another year is to have at least one bud ready to deploy when spring comes around. If the leaves initiated from that one bud collect enough sun energy for the plant to produce another bud before the growing season ends, the cycle will continue. Over and over and over again.

Usually, plants have a bunch of buds stored up and ready to use in case of emergencies, such as a growing season fire, a big (or small) grazing animal, or something else unexpected like a hay mower. If something happens that requires a mid-season bud deployment, the plant can quickly respond. During a particularly stressful year, a plant might not store enough energy to create new buds. If that happens, they can still fall back on that reserve of buds created during previous year.

You’re probably starting to see why I’m so confident about the long lives of prairie plants. Of course, you may also be thinking of all the ways a prairie plant might be killed by other factors, rendering their bud bank irrelevant. Factors such as badgers, for example, who might decide to dig a big hole right where a penstemon plant has been happily creating new versions of itself for many years.

That’s fair. Prairie plants need some luck to be immortal, I guess. But we don’t know how long that penstemon plant might have been there before it finally ran out of luck and ran into a badger instead. It could have been hundreds of years or more.

The reason we don’t know for sure how old that penstemon plant was is that herbaceous plants don’t leave a record of their growth. Trees and shrubs make ‘tree rings’ that can be counted to see how old they are, leaving, (according to tree lovers) no doubt about their temporal superiority. The old growth of grasses and forbs gets burned or composted, allowing those nutrients to be recycled.

In other words, prairie plants give back to their communities while woody plants cling to their used organic material in order to retain bragging rights.

Selfish.

Hang on, though. Before you walk away thinking prairie plants would have to awfully lucky to outlive trees, let me tell you about another of their tactics. Many perennial prairie grasses and forbs have underground stems called ‘rhizomes’. They can extend those rhizomes horizontally through the soil until they deploy yet another bud – this time from the rhizome itself – and create a new stem/roots package some distance from the original.

Now there are what look like two plants coming out of the ground, but they’re actually the same genetic individual and (usually) are still connected by a rhizome. Early on in the growth of the new ‘plant’, the rhizome can act like an umbilical cord, providing food to help the new ‘plant’ grow and compete. I say ‘plant’ because it really isn’t a separate plant. It’s all part of the same clone, which in this context, refers to the collective of stems, roots, and rhizomes that are all part of one genetic individual.

Clones can keep getting bigger over time – sending out more rhizomes, creating roots and stems, and then sending out yet more rhizomes. Some plants have rhizomes that are so long that their aboveground stems could be separated by several meters, making it difficult for us to know whether or not they’re connected. Other clones grow outward very slowly and maintain a compact cluster of stems that other plants can’t easily infiltrate.

Rhizomes add a whole new element to the competition between prairie plants and trees. Some perennial grass and forb clones can grow to be many acres in size. At that point, badgers are inconsequential (no offense to my badger friends). It starts getting difficult to imagine anything other than a disease killing an entire large prairie plant clone.

Diseases also kill trees, by the way, so now we’re on a level playing field. Trees grow taller than prairie plants, I’ll give them that. But I’ll put the longevity of a ten-acre big bluestem clone against any tree in the world and feel good about my chances. It might just come down to which one gets hit by a disease first.

The additional advantage a big bluestem clone has, though, is that it’s not prone to the kind of structural damage that often ends the life of a tree. A big, tall tree is supporting a lot of weight with that trunk. Little creatures living inside the tree (invertebrates and microorganisms of many kinds) can start to damage the structural integrity over time. Eventually, many trees simply break under the pressure and die – either immediately or not long after they fall or break off somewhere along their trunk.

That big ol’ bluestem clone doesn’t have to support its own weight. The structural integrity of its stems is of no consequence because it grows new ones each year. There’s really no limitation to how big it can get, other than barriers like rivers, forests, and mountains. Ten acres is probably very small for venerable big bluestem clones. Some of surely been expanding their footprint over thousands of years, making themselves less and less vulnerable to death as they grow. Even diseases might not be able to take out an entire clone if it’s big enough.

Yes, I said thousands of years. Now we’re talking! Most trees don’t live past a few hundred years, at most. Sure, there are exceptions, and I’ll admit they’re pretty impressive. Trees can sometimes live a few thousand years. And, before you tree nerds start barking at me, I also admit there are some trees that form clones, too. I think the oldest known aspen clone in the world is 80,000 years old. That’s pretty old.

I’ll just mention that there are grasslands that have existed since the Oligocene, which – last time I checked – was millions of years ago. Are there grass or wildflower clones that have been alive for millions of years? Maybe. You don’t know. I don’t know. But it’s very possible. (Some people actually argue that the 80,000-year-old aspen clone could be a million years old too, but they can’t prove it. I bet that’s frustrating…)

In my part of the world, today’s prairies have only been around for 8,000 to 10,000 years or so, depending upon the timing of the last glacier recession. It’s very possible there are prairie plants that have been alive since the very beginning of those grasslands. That’s staggering to consider, isn’t it?

Look, since there’s no way to prove whether an aspen clone has lived longer than a big bluestem clone, it seems dumb to keep arguing about it. Let’s bury the hatchet. Ok, maybe that’s the wrong metaphor. But, anyway, let’s just try to admit that both trees and prairie plants are amazing organisms, some of which can live incredibly long lives. Ok?

The incredible longevity of prairie plants is a great message to share with people who aren’t yet excited about prairies. Once you know how long some of those plants have been alive, it’s impossible not to feel a certain reverence as you walk on top of them. (We haven’t even talked about fungi, whose mycelium networks can also live for thousands of years!) It’s just one more facet of prairies that illustrates how truly amazing they are.

Some recentish changes in the WordPress codebase – in particular the “database abstraction” class – have had the unfortunate side effect of cementing MySQL as a hard requirement for that stack. If you took advantage of my post about making WordPress run with SQLite and you’ve updated since, you might be having a bad time right now.

Lucky for you, I’m here to “help”. Or at least get you back up and running, which if you squint kind of might be similar.

This has manifested itself for me in the traditional manner of PHP errors, where nothing visible works but something behind the scenes starts barfing stack traces disguised as web pages into your server logs, because who wouldn’t want that really.

The meat of that error is:

PHP Fatal error: Uncaught TypeError: mysqli_get_server_info(): Argument #1 ($mysql) must be of type mysqli, WP_SQLite_DB\\PDOEngine given in /my-wordpress-install-dir/wp-includes/class-wpdb.php:4143\n


The \ns all over the place are of a particular flavor, very dog-at-a-keyboard. Where are we, how did we get here, what is even happening?

The comments at the top of the class-wpdb.php file are informative:


* WordPress database access abstraction class.
*
* This class is used to interact with a database without needing to use raw SQL statements.
* By default, WordPress uses this class to instantiate the global $wpdb object, providing
* access to the WordPress database.

… and I think that means they’ve decided to take one abstraction layer that frees you from being locked into a particular backing store and wrapped it in a second abstraction layer that frees you from having to touch the first abstraction layer by doing exactly the opposite, which is I guess a choice you can make.

Anyway, insofar as it affects us today, this means that when you upgrade, you’ll get this wrapper class calling a PHP builtin to check your MySQL version number, and we don’t have that, so…


public function db_server_info() {
// This is _so gross_ but it also works. - mhoye
return "8.2.0" ;
// return mysqli_get_server_info( $this->dbh );
}


… here we are at line 4134 of class-wpdb.php, last function in the file, straight up lying to the computer until it does what we want.

There’s nothing magic about “8.2.0”, it’s the current release of MySQL; it doesn’t matter. There are going to be future circumstances where it does matter, but it looks like dramatic WordPress schema updates are infrequent enough that I think I can burn that bridge when I get to it.

You don’t need to copy in the comment about this whole exercise being gross, obviously, but you definitely should, because this is definitely gross.

If you’re wondering why I’m doing this, the justifications I prefer to deploy are “I’m not particularly fond of having something I personally care about taking a dependency Oracle” and “backing up a SQLite database is just ‘copy a file'”, but the prime motivator is actually “It’s my computer and I’ll do what I want.” For the sake of future searchers – hello, future searchers! – key terms of this exercise are:

• mysqli_get_server_info
• mysqli
• SQLite
• WordPress
• Argument #1 ($mysql) must be of type mysqli
• WP_SQLite_DB\\PDOEngine