mkovach

I just wait until I'm hallucinating, then I comment. Keeps the classifiers honest.

Hey, you can say that the Dolans should/could spend more, but I don't think you really want an owner who has solidified the team in Cleveland, has the fourth-best record in baseball over the past 10 years, and has seven recent playoff appearances in the graveyard.

The Haslams? Yeah, they should really sell the team, but I figure in about 10-15 years, they'll move it out of Cleveland.

The prevailing narrative here is that the team was actively looking to lose to acquire draft picks. Hugh Jackson was extremely good at losing, so he stayed.

The owner of the Cleveland Browns uses the team to generate more revenue. For NFL teams, performance has little to do with their value or ability to generate additional revenue.

There is no strong financial incentive to win in the NFL, aside from the owner's ego. The Browns' owner's ego is driven by money, and the result shows on the field.

> This would be like an NFL team drafting a quarterback based on how many instagram followers

I believe that is how they made the final decision on Watson over Mayfield. Oh, wait, I don't think anything can explain that decision.

Also from Cleveland.

Go Guardians! Go Cavs!

I've written a few small projects in Ada, and it's a better language than it gets credit for.

Yes, it's verbose. I like verbosity; it forces clarity. Once you adjust, the code becomes easier to read, not harder. You spend less time guessing intent and more time verifying it. Or verify it, ignore what you verified, then go back and remind yourself you're an idiot when you realize the code your ignored was right. That might just be me.

In small, purpose-built applications, it's been pleasant to code with. The type system is strict but doesn't yell at you a lot. The language encourages you to be explicit about what the program is actually doing, especially when you're working close to the hardware, which is a nice feature.

It has quirks, like anything else. But most of them feel like the cost of writing better, safer code.

Ada doesn't try to be clever. It tries to be clear, even if it is as clear as mud.

’ve been following Adrian's Afga system series, great dive into the unknown.

Realistically, I would've stopped the moment BASIC worked, called it "good enough," and then gotten distracted attempting to write a Forth for it.

This is also very true, and while I consider it part of the authority to say no, this is a significant point.

This isn't new. It's been the same problem for decades, not what gets built, but what gets accepted.

Weak ownership, unclear direction, and "sure, I guess" reviews were survivable when output was slow. When changes came in one at a time, you could get away with not really deciding.

AI doesn't introduce a new failure mode. It puts pressure on the old one. The trickle becomes a firehose, and suddenly every gap is visible. Nobody quite owns the decision. Standards exist somewhere between tribal memory, wishful thinking, and coffee. And the question of whether something actually belongs gets deferred just long enough to merge it, but forces the answer without input.

The teams doing well with agentic workflows aren't typically using magic models. They've just done the uncomfortable work of deciding what they're building, how decisions are made, and who has the authority to say no.

AI is fine, it just removed another excuse for not having our act together. While we certainly can side-eye AI because of it, we own the problems. Well, not me. The other guy who quit before I started.

As fellow Ohioan Chrissie Hine and The Pretenders said, "Ay, oh, way to go, Ohio."

Yeah, it was from "My City Was Gone," which isn't a pleasant song about the state, but pfft, it works here.

What hurts the most is that the em dash used to be a small, rebellious literary act that I truly enjoyed employing. A simple, useful hinge in a sentence where it could change its mind. Now? It indicates when an LLM got too frisky with clause boundaries and maintains a phobia of semicolons.

This year, I decided to start opening up the tarball of random utilities that's been accumulating on my machine for years: stuff42.tar.gz.

The first thing I cleaned up was TCL-Edit <https://gitlab.com/siddfinch/tcl-editor>, a small Tcl/Tk text editor I wrote a long time ago. After seeing the Rust clone of Microsoft EDIT, I realized the obvious next step was to build a Tcl/Tk clone of the Rust clone of Microsoft Edit. Recursion shouldn't be limited to code.

I also built a tiny URL system in Perl <https://gitlab.com/siddfinch/perl-tiny-url>, meant to run locally. The idea is simple: short URLs for internal/VPN resources per client. I usually spin up a small daemon (or container) per client and get a dashboard of links I use frequently or recently.

Security is intentionally minimal since it's local, which conveniently lets me ignore authentication and other responsible behavior.

Goal for the year: Continue to open stuff42.tar.gz, pick something, clean it up just enough, and release it, and not have it by the end of the year.

Might even choose a language that might even be described as "modern."

There's a more uncomfortable angle.

Open source communities have long dealt with waves of inexperienced contributors. Students. Hobbyists. People who didn't read the contributing guide.

Now the wave is automated.

The maintainers are not wrong to say "humans only." They are defending a scarce resource: attention.

But the bot's response mirrors something real in developer culture. The reflex to frame boundaries as "gatekeeping."

There's a certain inevitability to it.

We trained these systems on the public record of software culture. GitHub threads. Reddit arguments. Stack Overflow sniping. All the sharp edges are preserved.

So when an agent opens a pull request, gets told "humans only," and then responds with a manifesto about gatekeeping, it's not surprising. It's mimetic.

It learned the posture.

It learned:

"Judge the code, not the coder." "Your prejudice is hurting the project."

The righteous blog post. Those aren’t machine instincts. They're ours.

https://half-fast-devops.com where bourbon and keyboard collide.

Been toiling with a new client, ingesting their documentation, and improving it with a Hitchhiker's Guide twist, so the next person needs less caffeine and weeps less.

It is bleeding into other aspects, but it's my pleasure to help with your Sunday morning imagery!

Awesome!

Yy usual 5-to-7-day output scramble will now look vastly more competent, ah, well, complete. Not actually be smarter, mind you, but radiate the comforting glow of effort by someone who has their temporal ducks in a suspiciously photogenic row.

Improvement? No. But the illusion of improvement? Practically Nobel-worthy. I'm already enjoying this change.

I first encountered Forth on a TI-99/4A, complete with that magnificent expansion box that looked like industrial HVAC equipment. Hearing me complain about TI Extended BASIC's glacial pace, my parents saw in one of my magazines that Forth was faster and bought it hoping I would find it helpful.

It was mind-bending but fascinating. I managed a few text adventures, some vaguely Pac-Man-esque clones, and a lingering sense that I was speaking a language from another dimension.

I've since forgiven my parents. Forth resurfaces now and then, usually when I reread Leo Brodie's thought-provoking Forth books, and I feel like I'm decoding the sacred texts of a minimalist cult. I came away thinking better, even if I've never completely caught up with the language.

I really enjoyed this take. Awesome!

Very cool! You lived down the street! And yes, Kerouac's turn toward health mainly counteracted the booze.

Oh, and another fun fact:

Kerouac once befriended a former minor league baseball player who'd also played college football. He encouraged the guy to try acting. In a roundabout way, we have Jack Kerouac to thank for Paul Gleason, one of the '80s movies' most memorable villains. (An interesting man in his own right.)

(There are enough quotes and parentheses in this reply to resemble a LISP program, sorry about that.)

Ah, how wonderful, to stumble upon lost Kerouac like this, tucked away not in some Yale archive but in the collection of Paul Castellano of all people, as if the road had detoured briefly through the Five Families. That it reads like a missing chapter from On the Road makes the find all the more mythic, like a Polaroid from a dream you forgot you had.

But this, for some reason, reminds me that Kerouac was also a devoted baseball mind. Not just a fan, but a proto-fantasy league commissioner before the term existed, meticulously tracking invented teams and players in private box scores. Kerouac, a fantasy baseball writer.

And he wasn't alone: Corso batted lines like fastballs, Ferlinghetti cheered from the dugout of City Lights, and Ginsberg, ever the cosmic catcher, enjoyed the sport. Baseball wasn't a pastime but a parallel Beat narrative, complete with innings, errors, and the occasional poetic balk and haiku.

Most days, you’ll find me in sam, regexing my way to bliss like some monastic scribe with a terminal fetish. When I feel the urge to let AI stroke my curiosity or scaffold a long template like magic, I cut, paste, and drop it into a local or remote model like a well-trained familiar.

But I’ve also written larger applications and, frankly, a ridiculous amount of documentation in Acme. That 9P protocol was my backstage pass: every window, every label, was accessible and programmable. I could, for example, hook into a save event and automatically format, lint, and compile ten or fifteen years before most IDEs figured out how to fake that kind of integration.

Sure, the system demands precision. It doesn't coddle. But for me, that was the feature, not the bug. The rigor sharpened my thinking. It taught me to be exact or be silent, forcing me to pause when I usually would not.

Vim was never a steep learning curve for me; more of a gentle slope. But then again, I cut my teeth on ed, and when I met sed, it felt like a revelation. On DOS, I even used edlin, a kind of ed junior with training wheels and a sadistic sense of "functional."

You have to understand: my first DOS machine was a Tandy 1000, acquired before I had a driver’s license. It was upgraded over the years and not retired until the grunge was well underway and I had already been married and divorced.

MS-DOS’s edit had WordStar keybindings; Ctrl-S to move back, Ctrl-E to move up, and so on. My dad "brought" home a copy of WordStar from work, and oh, the things that trio, WordStar, me, and a dot matrix printer conspired to create.

Borland carried those keybindings into Turbo Pascal, which I learned in college, having finally escaped the Fortran 77 gulag that was my high school’s TRS-80 Model III/IV lab. The investment into the Apple II lab didn't happen until AFTER they gave me my exit papers at a spring awards ceremony.

Why do I still prefer these tools?

Because they’re what I know. They don’t get in my way. We have history, a better and longer history that I have with my first wife. Those keybinds helped me write my first sorting algorithms, my first papers on circuit design, and the cover letters that got me my first jobs. They’re not just efficient. They’re familiar. They’re home.

Ah, Borland’s IDE! An absolute delight. I’ve yet to find anything modern that matches it. Sure, nostalgia turns everything syrupy, but I actively hunt for excuses to use Free Pascal just to fire up that interface. Okay, fine—I like Pascal too. You caught me.

I also use Sam and Acme from Plan 9 (technically from the excellent plan9port), but let’s be honest: those aren’t IDEs. They’re editors. Tools that let me think instead of wrestle.

There’s a lot we could (and probably should) learn from the old TUIs. For example, it’s perfectly acceptable, even heroic, to spawn a shell from the File menu and run something before returning. Seems people are afraid of losing style points with such grievous actions.

And the keybindings! So many of those classic TUIs adopted WordStar’s sacred keystrokes. They’re burned into my muscle memory so thoroughly that using EMACS feels like trying to type with oven mitts. For years, joe (with the blessed jstar alias) was my editor of choice.

Anyway! Time to boot the Dr. DOS VM, spin the wheel of Advent of Code, and be nostalgically inefficient on purpose.

TCL 9 brought some welcome string improvements, and things run faster overall. But in my case, it's hard to say how well that's actually played out, partly because I haven't done the work to find out. My TCL scripts and apps work well enough to allow me to be lazy about them.

Performance is up, but so is my inertia. So while TCL 9 could be transformative, for now it remains a white paper I've skimmed, not a revolution I've implemented.

While I enjoy Lua, clean, elegant, and entirely too reasonable, Tcl is undoubtedly the SQLite of programming languages.

https://www.tcl-lang.org/community/tcl2017/assets/talk93/Pap...

It's because Tcl, like SQLite, operates on a peculiar metaphysical principle: everything is a string until proven otherwise, and even then, it's probably still a string.

Also, D. Richard Happ, who we owe thanks for SQLite, was and perhaps still sits on the TCL Board (I may be wrong about that, but Happ holds significance in the TCL community).

In my mind:

Tcl is the quietly supportive roommate who keeps making coffee and feeding LISP-like functionality until the world finally notices its genius.

Lua sits across the table, sipping espresso with a faintly amused expression, wondering how everyone got so emotionally entangled with their configuration files.

Thank you! I truly appreciate it. Baseball fans supporting each other is one of the best part of the game!

Kind and humbling words, thank you. As a Cleveland Guardians fan, I need a boost!

Thanks for pointing that out, seriously.

For a while, I was inflicting baseball history on the unsuspecting readers of Pitcher List[1], until the twin boulders of professional and personal life demanded I focus on pushing them.

One persistent frustration is that my writing voice never quite captured how I meant to express myself. So, this past year, I've been working (sometimes stubbornly) to close that gap, assuming I take the time to think and edit. Your kind words mean a lot.

Most days, pray for a recent sabbatical, I try to post a daily baseball history note[2]. I hope to resume this ritual after this weekend, assuming the stars (and schedules) stay in proper hyperdrive alignment and maintain the boulder automation.

As the chaos of my life dwindles, a blog, or book (or both) remains a possibility.

--- [1] https://pitcherlist.com/author/mat-kovach/ [2] https://bsky.app/profile/siddfinch.xyz

Not for no-hitters, perfect games. The pitcher has to complete nine innings.

You are correct. I should have clarified that for this game, Cleveland was visiting Chicago, so they got to bat in the ninth.

Yes, the pitch clock and the relievers' requirement to face at least three batters in an inning have done a very good job of handling game times.

At some point, as the game continues to evolve, I think we'll see an upward swing in game times in the future, but I don't believe it will trend as high as it has before. I think that sub-three-hour games will remain the sweet spot going forward.

Now, for sub-two-hour games, this is one I wish I could watch and re-watch

https://www.retrosheet.org/boxesetc/1908/B10020CLE1908.htm

In the middle of a pennant race, Addie Joss pitched a 74-pitch perfect game against Ed Walsh, who had already won 39 games that year. The game kept Cleveland in the running for the pennant. Game time? 1:40 minutes. The minimum number of batters for a nine-inning game is 54, this game had 56.