Skip to content

Stop the Code Wars!

Opinion Articles

Nuno Ribeiro

Bliss Applications

Why we (developers) should stop saying “language X is better than Y”, or worse “language xyz is dead!”

To justify my claim, let me start by sharing my personal history in the dev world… divided by programming languages.

HTML

 

 

I know, not really a programming language, but anyway… My first experiences with coding started in the late 90’s, back when computers still used floppy disks, playing around with HTML through Microsoft Frontpage Express. Yeah, those were the glory days of animated gifs, <table> was ok, Yahoo ruled the web, people published their websites on Geocities, and everything was simple… and slow… and, to today’s standards, very ugly. But no one cared.

Pascal

Then I went to college and got introduced to Pascal, never touched it again since, but it served its purpose. It was a mean to an end — teach basic programming elements. I guess everyone there knew that. No one was expecting to find a job as a Pascal Developer (although they do exist). On the other hand one could make an algorithm without having to understand objects, classes or functions, so it was good for starting.

 

 

Photo by sunrise University on Unsplash (not really my University but the PC’s look a like)

SuperTalk

At the same time in another class, another software was being lectured, the name: SuperCard. It was based on Apple’s HyperCard which “…is among the first successful hypermedia systems predating the World Wide Web” – Wikipedia. The programming language was SuperTalk (also based on Apple’s HyperTalk) and all this ran on Mac OS 8. The funny thing about this language was that it was very similar to writing English sentences, one could really read the code and understand it without a big effort.

 

This went on for a full year and also allowed us to play around with videos and music to make multimedia CD-ROMs… remember those? Yeah they were a blast. Streaming videos or listening to music directly from the Internet back in the early 00’s was simply an utopia, so we had CD’s. And we were happy.

Lingo

The Macromedia, Inc., later acquired by Adobe, developed a cool program called Director. It was largely based on HyperCard and SuperCard, but with great improvements on interface and the timeline concept for easier creation of animations (similarly to Flash). The language was also based on HyperTalk so there wasn’t a big difference. But it did allow the exploration of animation and the first contact with databases, through Microsoft Access.

More HTML and… ActionScript 2.0

By this time I’ve passed two years in college without touching any web based technologies. Which is normal, at that time the Web wasn’t that big of a deal, most teens were more interested in apps like mIRC, ICQ and later Windows Live Messenger. Websites and WebApps weren’t really relevant, but they were on a fast rise so we were given a semester divided by HTML using Macromedia Dreamweaver and Actionscript 2.0 on Macromedia Flash.

All this using Windows 98, 2000 and (God forbid) Vista… and later on Windows XP.

ASP

On my final year of college this was the last language I learned. It was my first insight to the server-side world. Generating dynamic pages, database connections, queries, recordsets and all that jazz, that I would not play again for several years.

Back to ActionScript

During my first two jobs I programmed in ActionScript 2.0 and later in 3.0. Adobe Flash was “the thing” somewhere between ‘04 and ‘08. Vector animations, total layout freedom, video, music, you name it. It seemed like everything was possible, and nobody really cared if a plugin installation was necessary. At least until Steve Jobs said they did. I’m over simplifying, the truth is Flash didn’t evolve has well and fast has it should into the mobile era. But I still miss some of the freedom it provided.

Oh yeah, and I went back to use Mac OS again… I think it was the Leopard one.

PHP

After founding my own company, in late 2008, we faced the need of some backend expertise. So I used some little knowledge I had from personal projects and went on to become a PHP developer which also led me to MySQL and Linux administration. The usual LAMP stack. Ultimately ending up working with Laravel framework in most cases.

JavaScript

Due to also teaching introduction to game development classes I had to learn vanilla JavaScript. Which wasn’t a big stretch since ActionScript was very similar to JavaScript.

Later on, I also had the chance to be part of React and React Native projects and gave me an insight into a whole new level and paradigm of JavaScript programming.

Conclusion

Sorry for the lengthy text, one always gets nostalgic when thinking about how it was back in the day. But where am I going with this?

As you can see, throughout my 20+ years of experience, I’ve used several languages, software, operating systems and some of them disappeared or evolved into something else. And I’ve always seen it as something natural, it’s part of the evolution.

The thing that I find very weird nowadays and I have trouble understanding the reason behind it, are the multiple publications where developers put programming languages against one another, or make predictions on the death and rise of languages.

While some of the arguments I can understand and relate, like comparing performances or the ability to be cross platform, or how easy it is to code, those don’t really dictate the success or decline of a language, or framework, or any technology. It’s just one aspect and arguably, not even the most relevant.

Choosing a tech stack goes (or should go) beyond the developer’s personal preferences, trends, or simple performance comparisons.

There are a lot of aspects to look at before getting into “what we’d like to use”. Things like: Project Requirements, Budget, User Target, External Integrations, Existing Infrastructure, and basically any aspect directly related to the project and not to the developer or the technology itself.

 

There will be cases where the best choice is to use .NET instead of PHP and vice versa. The same goes for React Native or Flutter or Swift or Kotlin or… Java, C#, Python, GO… does it really matter?

 

The focus must always be on what is better that specific project’s case.

So before opening up bench marking software and register how many milliseconds it took for an algorithm to return a value, ask yourself, is it really relevant for the project? If the answer is yes, then go for it! But if not, put those tests in the bottom of the bucket list.

I’ve seen a lot of projects suffering from poor tech decisions. Sometimes based on the developers’ know-how, or what is trending. And when things start to go south because the results fail to meet the expectations, everybody is affected. Even the developer that might have been eager to use a certain tech, is now stuck on a problematic project and having a bad experience with it.

My advice: we as developers must learn to adapt and lose our love over certain languages. Only then we can give valuable and unbiased inputs on the tech stack choices.

The technology diversity is a good thing and in the end of the day it helps developers achieve their goals, it provides us with more tools and more options, so please… lets keep an open mind and stop these “code wars”, ok?

Thanks for reading and… peace!

Related articles

Opinion Articles
RxRepository: Building a testable, reactive, network data repository using RxSwift (part 1)

In this series we will tackle the problem of optimizing network access to fetch data from the network, a common theme of networked applications. While it is certainly trivial to fetch data from a server in any modern framework or OS, optimizing the frequency of access to the network, in order to save bandwidth, battery, user frustration, amongst other things, is complex. More so if you want to reduce code duplication, ensure testability, and leave something useful (and comprehensible) for the next engineer to use.

Opinion Articles
RxRepository: Building a testable, reactive, network data repository using RxSwift (part 2)

In part 1 of this series we started tackling a common problem of networked applications, that of optimizing resource usage and user experience, by optimizing network access. We typically do that by avoiding expensive resource usage, as in avoid making network calls. This avoidance is not more than a mere compromise on the type of resource we decide to spare. Trade a network call for memory space, by caching network responses. It also comes with constraint relaxation, as we do not need the latest version of a particular resource. We, thus, avoid a network call. Nevertheless we want that what we have cached to eventually expire, or to be able to forcefully reload a resource.