I’ve been spending a bit of time on LinkedIn lately after finally stopping my use of Xitter (you can find me on Mastodon instead). One of the tropes that I see being uncritically spouted over and over again is “I’m sooooooo productive, by spending $gazillion in LLM credits a day I’ll generate my new product at 50,000 lines of code day”.

While I’m applauding your effort to build a new, much needed product to fill a gaping hole in the market place, I’m sorry my dude (because it’s almost always a dude), but all you’re doing is generating technical debt at high velocity for a brief amount of time. Jon Bentley pointed out in his essays that turned into the book “Programming Pearls” (look it up) back in the 1980s that confusing, I’m sorry, measuring productivity by looking at the lines of code written is All The Wrong Measurements.

Version control system migrations are a fact of life for developers in any longer lived codebase. In fact, I’ve had a hand in quite a few migrations as newer, more workable version control systems became available. Also, like a lot of developers, I’ve got fragments of source code dating back quite some years floating around on various servers and development machines of mine. Not necessarily code that is still being used, but still code that I don’t want to just delete forever. Some of the oldest code I have uses RCS for source control and hasn’t been touched for a long, long time. As my machines generally don’t have anything as old as RCS installed for version control, I decided this might be a good time to migrate the code to my version control system of choice, Mercurial.

Another one for my computer science reading list for this year. I do try to work my way through at least one classic computer science book annually and picked up Let Over Lambda a few weeks ago. Colour one of the cats not impressed, but then again she’s got more free time than I do and probably already read it.

I did have to learn some Prolog when I was studying CS and back then it was one of those “why do we have to learn this when everybody is programming in C or Turbo Pascal” (yes, I’m old). For some strange reason things clicked for me quicker with Prolog than Lisp, which I now find quite ironic given that I’ve been using Emacs for since the early 1990s.

Anyway, a recent post over on Hacker News alerted me to a book called “The Art of Prolog”. From what I can tell it’s out of print but this is not a book that is very hard to find.

Quite a while ago, I answered a question about the basic deadlock scenario on Stack Overflow. More recently, I got an interesting comment on it. The poster asked if it was possible to get a deadlock with a single lock and an I/O operation. My first gut reaction was “no, not really”, but it got me thinking. So let’s try to unroll the scenario and see if we can reason at least about my gut feeling.

Update II - 2019-05-07: It looks like due to the recent licensing changes, the Java 8 JDK that brew used is not directly accessible anymore and likely behind some kind of paywall. The installation method described below will still work as it uses the non-versioned java cask, which installs the latest version of OpenJDK.

_Update: The title of this post isn’t quite correct as using the homebrew cask mentioned in this blog post will install the current major version of the Oracle JDK. If you want to install a specific major version of the JDK (6 or 8 at the time of writing), I describe how to do that in this new blog post.

I’ve mentioned before that I prefer Mercurial to Git, at least for my own work. That said, git has a nice feature that allows you to cherry pick revisions to merge between branches. That’s extremely useful if you want to move a single change between branches and not do a full branch merge. Turns out mercurial has that ability, too, but it goes by a slightly different name.

There are actually two options in Mercurial - the older transplant extension and from Mercurial 2.0 onwards, the built-in graft command. I prefer to use the graft command, mainly because it is built into base mercurial and thus is available everywhere as long as one is running Mercurial 2.0 or up. Given that the current release is 4.0.1 as of the time of writing, you should really run something newer than 2.0. Also, graft uses mercurial’s merge abilities to cherry pick the change, you have a somewhat better chance of the change applying cleanly. Transplant uses the patch mechanism with works reasonably well, but in my opinion the merge system works better especially if you’re dealing with something that turns into a three way merge.

It might sound paradoxical, but in general, writing more code is easier than writing less code that accomplishes the same goals. Even if your code starts out clean, compact and beautiful, the code that is added later to cover the corner cases nobody thought of usually takes care of the code being well designed, elegant and beautiful. Agile programming offers a solution, namely constant refactoring, but who has time for that? That’s why I occasionally give myself the 10% code reduction challenge and I encourage you to do the same.

I’ve blogged about improving the performance of Git on Windows in the past and rightly labelled the suggested solution as a bad hack because it requires you to manually replace binaries that are part of the installation. For people who tend to use DVCSs from the command line, manually replacing binaries is unlikely to be a big deal but it’s clunky and should really be a wakeup call for some people to include a newer base system.

Over on bitbashing.io, Matt Kline has an interesting blog post on how Shipping Culture is hurting us as an industry. Hop over there and read it now, because he addresses another case of the pendulum having swung too far. Your developers take a long time to get a new version out? I know, let’s make them ship something half baked. Quality is overrated anyway. Especially when you don’t have a reputation to lose as a maker of quality software.