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.

I’ve recently been working in Clojure on some code that really benefits from parallelization but doesn’t need to squeeze the last available cycle out of the machine.

Of course, if you’re using Clojure, you’re also using Leiningen as the universal build and configuration system. Accept no substitute. Now if I could only remember the syntax to run a single test when I’m refactoring some code and need to reflect the changes in the test suite via the build system and not just from inside the REPL?

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.

I encounter this on a fairly regular basis - a project uses a third-party library and there is either a bug in the library that we can’t seem to avoid hitting, or there’s a feature missing or not 100% ideal for our use case.

Especially when dealing with an open source library, at this point someone will inevitably suggest that we have the source, so we should just fix/hack/modify the library and get on with our lives. I’m massively opposed to that approach, with essentially one exception I’ll mention towards the end.

First, a confession - I actually occasionally call myself a coder, but in a tongue in cheek, post-modern and ironic way. Heck, it does make for a good blog title and license plate.

Nevertheless, with all the recent “coding schools” cropping up all over the place - at least if you are in the Bay Area - it does seem that being able to code in the context of a reasonably sought after web technology without much further formal training is the path to new, fulfilling careers and of course untold riches in an economy where recent graduates in all fields have problems finding work. Well, at least a career that allows you to rent a room instead of crashing on somebody’s couch.

Like pretty much every other programmer with a Mac, I’m currently looking at Swift. Will I write anything but toy programs in it? I don’t know yet - I don’t really write any Mac-ish software on my Mac,  just unix-ish programs. If Swift doesn’t escape the OS X and iOS ecosystems it’ll be a nice exercise in a neat language that’s not really that relevant to the world at large, or at least to my part of the world at large. Not that this sort of vendor lock-in can’t work well - Visual Basic 6, anybody?

I used to use Carbon Emacs on OS X for quite a while, but with the release of Emacs 24 I switched to the stock GNU Emacs distribution. While GNU Emacs works fine on OS X, once you throw a German keyboard layout in the mix it doesn’t work so well as OS X uses Option + Number keys for a variety of characters needed for programming like [] and {}. GNU Emacs uses Option as Meta out of the box so the key mapping doesn’t work overly well, especially if you do a lot of programming in the C family of languages.

If you look at really productive programmers - like the top 10-20% - there are usually a couple of characteristics that they share. Aptitude and in-depth understanding of both the system they are working on and the technologies involved is obviously one very important factor. Another factor that tends to be overlooked is that these programmers are also masters of their tools in the same way that a master craftsman - say, a carpenter - is also a master of their tools. That includes potentially obscure tools, and the ones handed down from grandps or found at a yard sale.