Opinion: Programming Languages and Tools I Hate
Since I no longer hold a job in Information Technology, nor am I currently pursuing a job in the field. I thought I could let off a bit of steam with a heated post on various programming languages and information technology tools and products that I absolutely refuse to use, and the reasons why. So here we go, my first Negative Ned post.
JavaScript
Let's start with a heavy hitter, as it is so widely used, but also in some ways, so widely hated. A lot of JavaScript developers don't even program directly in JavaScript if they don't have to, the language is absolute crap! Most developers end up favouring transpilers like TypeScript instead, which is much better to code in, and compiled nicely to working JavaScript. In fact, there are so many better ways to have a compiler generate JavaScript code, that actually trying to program in JavaScript itself is now just as redundant as programming in Assembly in some cases. Although, Assembly Language still has it's place, whereas most people would just love to throw JavaScript out the damn dittly window.
Ruby
Once made popular by it's one hit wonder killer framework, Ruby on Rails is now mostly but dead. I barely, if ever see any new Ruby projects in the wild, as development shops shift to better languages which incorporated all the innovations which Ruby on Rails originally created with it's new Model-View-Controller based development for the web. I had a moment with Ruby at a past company while working on their Capistrano deployments, and it was a pain. I really dislike the syntax in Ruby, as it breaks everything I've already learned about those same symbols in other programming languages. It was as a result difficult for a programming used to other languages to read and understand. Language readability is very important to me, if I can't parse the code I wrote a month ago to debug or add new features, then that language can stay the heck away from me. When I first dived into Python to decide which language I wanted to adopt after PHP, Ruby was one language I did consider and created several test programs in both Python and Ruby, and naturally made Python my choice of language to learn next.
Ansible
Talking about Deployment tools, this one I really dislike. It's like the worse way to write scripts, as instead of actually writing a script, the same scripting code is now placed into an overly complex .yaml file with both confusing embedded logic, and other Ansible-specific syntax. I found it difficult to navigate an existing codebase, and a bit tedious to try to put together my own playbooks. This could have been perhaps because I was too used to the great state-based YAML files that SaltStack provide. If Ansible used the same state system as SaltStack, then I'd probably love Ansible, but it doesn't. SaltStack states are easy to both read and write, and are defined as a state, rather than a sequential state. With SaltStack, I tell the system how I want it to appear when the state is applied, and it just works. With ansible, I need to work it like a script, and go through each step in the process. SaltStack works much better in my eyes, even though it's technically a Configuration Management Tool and not a Deployment Tool, it can still be used to deploy applications, and it works much better than Ansible. With Ansible, for Windows hosts, I couldn't use some of it's modules I needed for a specific job directly on Windows, which was incredibly annoying. With SaltStack, all of these modules are cross-platform. The module I am referring to is the Artifactory one, where there in SaltStack is can run on Windows, but the Ansible, at least a year ago, only ran on Linux. This made my playbooks overly complicated and very difficult to both develop and maintain.
Microsoft Windows
A lot of developers probably know this, but unless you are building something specific to the Windows platform, developing something on this operating system is absolutely annoying. Microsoft tried to bandage this with their Windows Subsystem for Linux, which is interesting, but also not as performant as a native Linux box. Personally, as someone who loves to code, Linux is my best choice. Installing whatever tools I need is incredibly easy and straightforward, and using docker and virtual machines is second nature to Linux. Installing docker on Linux is much less tedious, and tend to work much better. And now Linux had desktop apps for both Docker and Podman, which work rather well if you need a desktop GUI in your workflow. Virtual Machines are super easy to create natively, especially with modern Linux and libvirt. Here's a one-liner to get a Debian Trixie VM up and running in seconds, no ISO, no fuss:
$ virt-install --connect qemu:///system --virt-type kvm --name Debian --location http://deb.debian.org/debian/dists/trixie/main/installer-amd64/ -x "popularity-contest/participate=false" --os-variant debian10 --disk size=20,pool=default --memory 2048 --vcpu 2 --network network=default,model=virtio
Running this will have it immediately download both the Linux kernel, and the Debian installer initial RAM disk, then boot up a KVM it to start the Debian Installer process, in seconds. No fussing around in a stupid GUI setting all this up, looking on a website for the right ISO. This command just works, try it on your Linux box with libvirt today!
Containers are also a cinch in Linux, with libvirt natively supporting LXC, so if you need a lightweight VM essentially, and Docker doesn't provide all the features you need, this is a great second option. Under Debian, and perhaps other distros, you can use the various *bootstrap programs to kickstart a distro, like Debian, Alpine, and RockyLinux all with a single command-line to generate a chroot, which you can then point the libvirt LXC to, and you have a new OS container for testing deployments and such. Easy!
Electron(not the one from the BBC)
Everyone absolutely hated how slow, sluggish, and bloated Java desktop applications were in the late 90s and early 2000s... So why the heck have we regressed back to this utter B.S.! Amazing cross-compilers exist that are able to effortlessly use the same codebase to create binaries on so many targets, but instead, we've regressed to an even worse form of Java desktop programs to desktop programs made in JavaScript of all things. Each time I download an Electron app, I know it will need a lot of my system resources, will take a lot of unnecessary disk space, and start at a snails pace. A lot of times, I end up just using the app in the browser instead, as it ends up actually performing better.
Personally, when I develop a desktop app, I aim for an app that is light on resources, has a compact binary size, and starts in mere milliseconds. Is that too much to ask of others? I wish Electron was never born!
Every Linux distro but Debian
This one might be a tad much, but throughout my experience with various distros, Debian always ends up on top in so many categories I personally care about. Debian installs extremely fast. Can have a very slim and performant base installation. One of the fastest package managers. Way too many packages from the official repositories to count, making it mostly unnecessary to use any third-party repos in most cases. Debian is why I hate third-party repos, I want all my packages in the distros official repository and vetted by the distro for full compatibility and security. Only Debian can really offer this, as so many other distros expect you to find and use third-party repos which can at times wreck havoc on your system if they aren't configured correctly, or even have malicious code. Debian avoid all those other distro problems by supporting a huge array of packages in their official repos. I've never really had to hunt for a Debian package in my life. In fact, if I couldn't find it in Debian, I usually end up just downloading the source from the program's official GitHub, and building my own Debian package, which is also easily done on Debian. This is usually rare, as Debian has so much. Debian is also rock solid stable, when using it's stable branch, and the Debian team ensures that it is always stable. Sure, you might be using some packages from a few years ago, but at least you can rest easy knowing that your Debian system will always boot, and always be available when you need to get work done. Debian is super reliable.
Conclusion
There is probably some other language or technology that I forgot, but I can't be expected to remember every language or technology I've tried, as I've went through so much in my adult life. Hopefully this article provided you with a chuckle or two, and you didn't take it too seriously or it didn't overly offend you. These are only my personal opinions, I'm sure yours will be much different.