Today, we embrace general-purpose computing, but decades ago, there was a platform for every purpose. A small company would have a small computer with a card reader and puncher, while a larger one would have a big computer with many terminals. A university physics department would have a vector computer, and the postal service would have several computers connected via telegraph lines. All of this, naturally, involved code written specifically for them in COBOL, Fortran, PL/I, or whatever was suitable at the time.
Gradually, as computers became more powerful and affordable, everything started to homogenize to the point where it all seems the same now: we use Linux in the most powerful supercomputers and the cheapest Raspberry Pis alike, we program everything in the same five languages, and all new programs work in the browser or on mobile devices.
Previously, selecting and designing the platform was crucial; now, it doesn’t matter which platform we choose because everything will function the same. Or at least we think so; it is, of course, an illusion. The platform still matters as it determines the capabilities of our program and how we will use it, and we must be cautious in choosing it because it can make all the difference between success and failure.
In my first job, I evaluated various CMS (Content Management Systems) to create an informational web portal. Without going into too much detail, I’ll say that my choice was a disaster: we spent more time struggling with the platform and finding workarounds for its limitations than building the portal we were hired for. It wasn’t because we were useless, because we eventually managed to move the project forward after switching CMS.
Sometimes, our current uniformity prevents us from using the most suitable platforms for our goals. For instance, in the past, we used specialized programming languages for different tasks, starting with COBOL and Fortran and others like xBase for CRUD applications on microcomputers, Visual Basic for RAD (Rapid Application Development), or PHP for web applications.
However, nowadays, we use all of five languages for operating systems, web applications, games, machine learning systems, and tinkering with Raspberry Pi. The downside of using these languages for everything is that they are not particularly good at anything: a web application is much easier to create in PHP than in any of those languages, and in the time you make a CRUD application in any of them, you could make five in xBase.
It’s not only in languages where standardization has detrimental effects. We have many frameworks, libraries, and desktop environments that promise us the ability to write an application once and use it across all platforms. Web, mobile, and desktop? Of course. Linux, Windows, and Mac? Needless to say. Android and iOS? A rhetorical question.
However, all these systems have the same problem: the applications made in them never perform as well as native applications for each platform. They’re slower, occupy more disk and memory space, don’t have access to all the capabilities each platform offers, and (most importantly) have an appearance and behavior inconsistent with the platform they run on.
I don’t know about you, but I’m tired of seeing mobile applications that are nothing more than glorified web pages, Android apps that seem unaware of the “back” button, or Mac programs designed as if they were for Windows.
Today, with the prevailing uniformity, it’s tempting to think that platforms no longer matter. Well, they do: they matter just as they always have. Choose wisely and try to leverage all the advantages they offer.