Every so often I want to write a tools post and go on about what I use and really like. Sometimes I do this, but mostly I resist because there isn't much new for me to contribute here, and I'd rather blather about my latest coding hobby.

This is a bit different. As a small bit of history, I spent the better part of nine years working for a small cross-platform development shop that delivered data-binding products. We supported eleven platforms out of the box from AIX to VMS and ported to many others. My next position was as part of an R&D team at a metrology firm that had end-to-end control of their products, including the O/S and languages. Linux has been my go-to O/S for development and entertainment both, but the nature of my work means I have to be fairly conversant in a variety of systems and platforms, including Visual Studio (VSVim is my guilty pleasure, I admit it).

What I've found is that Cathedral and Bazaar types can be readily identified by their tool preferences. There is a kind of philosophy that differs between the UNIX and the Microsoft worlds: the former prefers decoupling tools and the latter integrating them. (In a recent chat, our principle software engineer—who is probably a bona fide genius—said something to the effect, "What's a toolchain? Windows developers don't have toolchains. We click a button.")

If you're a Cathedral type, you prefer integrated tools: you want your source control, ticketing, builds / CI, and quite possibly your microwave controls inside of a feature-packed IDE. If you're a Bazaar type, you prefer to have one tool for each job so you can pick your favorite and customize your ecosystem.

The fact is, though, that this distinction is blurring quite a bit these days.

Microsoft ported Bash to Windows, and that's more than just a nod to random Linux users, I think: it's an admission that open source tools like Docker are too big to ignore in modern Windows development; micro-service (see Giant Swarm for an example) infrastructures are more than a passing fad. Many of these tools don't have adequate equivalents on Windows—at least, not yet. (Remember the days when C# was just warmed-over Java?)

We've also found a broader acceptance of platform virtualization—and not just the sort that lets you run Ubuntu on your Windows box (or vice versa). We're really talking about language platforms like the JVM and CLR.

Clojure's rationale for using the JVM (see "Languages and Platforms") is significant. While several languages targeted the JVM prior to Clojure (i.a., Jython), I'm not sure that anyone has made the point so forcefully as Jim Hickey. It's the language platform that's the future, and whatever language you're using is a tool for the job. The platform is what's deployed and what's ubiquitous, not the language.

In a sense, the JVM is basically a Cathedral. (And yes, the Java langauge specifications are open, and so also are implementations. But they weren't always!) But notice now how as a platform it enables the Bazaar-like development model that undergirds open source by providing a common reference implementation (the Java language) while at the same time allowing others to compile to the same byte-code and achieve the same interoperability. This abstraction enables us to enjoy enterprise software development (Java) alongside rapid prototyping (Jython) and functional programming (Clojure). (There's also, of course, JRuby, Groovy, Scala, and others.) The CLR serves the same purpose for .NET: I do a fair bit of development with IronPython these days myself. All you have to ask is one question: given the choice, all things being equal, would I rather write Jython and interface with my Java libraries or have to write a Boost or SWIG layer over my C++ libraries?

To bring this full circle to tools, I think we need to return to the difference between monolithic integration-based tools and simple, decoupled tools and understand that language is one of the tools. Languages excel at different tasks, but few of them interoperate very well. But how many times have we stared at a monitor only wishing that we could script this task instead of compile it, or use pattern matching to compress this repetative copy-and-paste monstrosity into something concise and orderly?

If we have a common language platform (and, it must be said, a suitable business case), selecting languages appropriate to the tasks at hand has a smaller impact because they all play nicely together. The Cathedral—the language platform—meets the Bazaar—the language choice—very nicely.