When are you developing an application, and when are you developing a platform? A lot of discussion about programming comes down to this question; and the less-helpful discussions can usually be traced to confusion over this point.

For instance, an article here (by an author I respect) entitled Your Coding Philosophies are Irrelevant makes a fairly typical point: that it’s hard to make a connection between a good end-user experience and particular programming practices or philosophies. It’s similar to an argument that the ends justify the means, though hopefully not fraught with the same moral problems.

On the other hand, advocates of development styles, programming languages, etc., point out how their approach helps manage the complexity of software development. This section of Learn You a Haskell extols the “safety” of a type system (presumably implying that your program will work better).

So who is right? If you are developing an application, then you need to set the philosophies aside, pick up whatever tools are most convenient, and build. But if you are building a platform, taking care with the methods you choose and the interfaces or languages you design are crucial.

For applications, every moment you spend trying to decide on a programming language is a costly distraction from the problem you are trying to solve and the potential users trying to solve it. Over time, you should practice and hone your skills, and carefully choose (or develop) the right tools and platforms to make building future applications easier. But when you have an idea, the only thing you should be thinking about is “build, build, build”.

If you are developing a platform — which I’ll define here as a building block for applications[1] — the potential users are developers and they already have many ways to solve their problem. You are trying to make it easier to develop existing applications and inspire the development of new applications that previously seemed out of reach. Imagining specifically what the developers would do can lead to an overly-specific solution when a good general solution is possible. Furthermore, if you can see in so much detail what a developer should do with your platform, then maybe you should be building an application, instead. Being surprised by how developers use the platform is a good sign.

The best example of a philosophy and platform that really does matter is the relational database management system. There’s no doubt that an SQL comes with its share of opinion and philosophy, and it tries to guide you into this philosophy at every turn. The availability of primary and foreign keys in most implementations strongly encourages you to follow some basic patterns for modeling your business. Yet there’s also no doubt that SQL is wildly successful; the de facto platform for the lion’s share of applications that interact with data.

SQL offers some pretty tremendous advantages:

• ROLLBACK — if you encounter a problem in the middle of an operation, you can just reset as though nothing happened. This is probably the most important advantage — nothing kills your inspiration developing an application like struggling with error recovery bugs. See my previous article.
• Separation of data from structure — allows your application to work as well on 10 million rows as it does on the 10 rows you tested with. You might need to add an index or something, but there’s no need to retest the application. Adding an index will never change the query results (except maybe the order of the results if you forget an ORDER BY).
• Declarative constraints — have you ever tried implementing a UNIQUE constraint? If so, I hope you were careful of avoiding race conditions. And I hope you were mindful of performance, and didn’t just lock the whole data set. Regardless, there’s no reason to go through that complexity (which, again, distracts from the purpose of the application) because you can just declare it.

Notice that these are all benefits to the application built on SQL. The SQL implementation itself doesn’t enjoy those benefits — there’s a lot of imperative code behind something like ROLLBACK.

Although PostgreSQL still strongly encourages some common SQL practices and philosophies, it permits much more flexibility in this regard than most systems. User-defined types, functions, and the variety of procedural languages offer a lot of options when developing applications; while still all benefiting from the advantages I listed above.

So, philosophies do matter when designing a platform. A lot. Just don’t get distracted by them when trying to build an innovative application — but hopefully, at that time, you’ve already honed your skills with good platforms like PostgreSQL.

[1] Although libraries often fall into this category, some special-purpose libraries are better thought of as an application. For instance, a (de)compression library is solving a specific user need and interacting with certain formats; and building an application only requires a user interface on top. Contrast that with a database library, where you have no idea what ultimate application might be built.