💾 Archived View for dfdn.info › dfdn › madness.gmi captured on 2024-12-17 at 10:36:02. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-09-29)
-=-=-=-=-=-=-
Published on 2022-01-11. Modified on 2022-01-23.
There is something seriously wrong with the IT industry. It's so bad that I haven't managed to find a single industry with the same massive amount of stupidity, with the exception of perhaps the fashion industry.
Why is it that people keep inventing so-called "revolutionary new ways" of doing the same old thing? And they do that by adding more and more unnecessary complexity on top of existing technologies.
Electron and React Native Desktop are supposed to be a revolutionary new way of making desktop applications. Except they are not, and they eat up all the memory you have and still ask for more. They constantly crash and have no value over a native desktop application what so ever - well, perhaps with the only exception that now a 2 year old baby can make something shiny that you can click on with your mouse.
No, you're a dinosaur! It's the future! It's the modern way of doing things! Native desktop apps are dead!
PHP is a programming language mainly for web development. It is made in C, a pure procedural language. PHP was originally a templating language and it still is a templating language at the core, yet that is apparently not good enough. Rather you have to put a completely different template system on top of PHP, also written in PHP, which now makes the application load many times slower.
It's the modern way of doing things! We don't do old fashion web development any more!
All web servers have a built-in router. Whether it's NGINX, Apache, lighttpd, Caddy or something else. But no. Let's not use that. Let's add yet another router on top of that with a single entry point and then basically re-write every single request before it gets served.
It's the modern way of doing things! Anyone who doesn't use a single entry point in their web app don't know what they are doing!
The browser's native language is HTML. HTML is a markup language and if you feed HTML to the browser it will quickly render the page with what you give it. But no. Let's not do that. Let's instead feed the browser with JSON and then have the built-in JavaScript engine translate that into a pre-formatted output which then gets translated into HTML before it's served to the user. Oh, and while we're at it, let's do the same thing with CSS. So, now your simple blog post takes ages to load even on a 1 gigabit network connection and requires about 3 times as much electrical power even though you're only serving text and perhaps a few images.
Why in the world has this idiotic trend of abstracting everything away by layers upon layers of unimpressive complexity gained such a strong foothold in the industry? Has everyone except the "UNIX greybeards" gone mad!?
It is a real shame and a serious worry that the young generations grow up thinking that this so-called "modern ways of doing things" is correct and the best way.
Programming is engineering; it's not something where you throw stuff at the wall and see what sticks and just assume that programming languages, browsers, and operating systems are made of magical dust.
Update: 2022-01-12
Someone wrote me an email pointing out the famous saying by Brian Kernighan, who has stated that:
Programmer time is expensive; conserve it in preference to machine time
But that does not apply here at all.
Firstly, we live in a time in which the environmental concerns needs to be considered too. It is irresponsible to keep throwing more hardware at a problem that doesn't need to exist in the first place.
Secondly, Brian Kernighan is being general. The situation I am talking about in the above is something far beyond being justified by any means. The added layers of complexity results in products that are horrible. Everyone is experiencing the pain of using the web daily. Simple websites that contain nothing more that text and images takes forever to load, they only work in a few major browsers, and they are suffering from a flood of almost daily security issues. Turn off JavaScript and nothing gets displayed even though no is JavaScript is needed for anything.
Someone else wrote me another email. The person assumed that I have no experience in web development, or that I don't have any experience in larger projects, and that is the reason why I write the above.
I have been doing web development since about 1997 and I have worked at a large ISP and at Google (as a contractor) and I have been involved in many different projects with many different companies and many differently sized teams.
A company may save both time and money in the beginning because, yes you can get something running quickly, but they always pay a heavy price in the long run.
I write (rant) about this, not only because I, as a daily consumer of the web, am faced with all these horrible websites, or because friends and family complain about how bad this or that website has become, but mainly because I, as an independent contractor, am faced with clients who, as a result of this mess, have suffered greatly at the hands of so-called modern web developers. See JavaScript malware infested nightmare
Update 2022-01-14:
Someone on Hacker News commented on this article with the following comment, which sums it up pretty good:
I have been in professional web development since 2004 and I mostly agree with the author that there are massive amounts of groupthink going on. "Modern" web development has standardized in tool stacks which are insanely complicated, far beyond anything that is warranted in most cases. We have forgotten how to make simple things in simple ways.
At a minimum you need node, npm, webpack, babel, an spa framework, a frontend router, a css transpiler, a css framework, a test runner, a testing functions library, and a bunch of smaller things, and that's just what is "needed" to build a static website with a bit of interaction. We're not even talking about the dockerized insanity that happens as soon as you want to slide an API under that beast.
Bingo!
Published at 2021-09-12T09:39:20+03:00; Updated at 2023-03-23
A robust computer system must be kept simple and stupid (KISS). The fancier the system is, the more can break. Unfortunately, most systems tend to become complex and challenging to maintain in today's world. In the early days, so I was told, engineers understood every part of the system, but nowadays, we see more of the "lasagna" stack. One layer or framework is built on top of another layer, and in the end, nobody has got a clue what's going on.
_______________ |*\_/*|_______
| ___________ | .-. .-. ||_/-\_|______ |
| | | | .****. .****. | | | |
| | 0 0 | | .*****.*****. | | 0 0 | |
| | - | | .*********. | | - | |
| | \___/ | | .*******. | | \___/ | |
| |___ ___| | .*****. | |___________| |
|_____|\_/|_____| .***. |_______________|
_|__|/ \|_|_.............*.............._|________|_
/ ********** \ / ********** \
/ ************ \ / ************ \
-------------------- --------------------
Table of Contents
Keep it simple and stupid
⇢ Need faster hardware
⇢ Too complex to be replaced
⇢ ⇢ On COBOL
⇢ ⇢ On Kubernetes
⇢ ⇢ The younger generation of IT professionals
⇢ The bloated web
⇢ Fancy log-management solutions
⇢ More KISS
⇢ ⇢ The Adslowbe PDF Reader
⇢ ⇢ The power of plain text files
⇢ ⇢ KISS for programmers
⇢ When KISS is not KISS anymore
⇢ Other relevant readings
Need faster hardware
This not just makes the system much more complex, difficult to maintain and challenging to troubleshoot, but also slow. So more experts are needed to support it. Also, newer and faster hardware is required to make it run smoothly. Often, it's so much easier to buy speedier hardware than rewrite a whole system from scratch from the bottom-up. The latter would require much more resources in the short run, but in the long run, it should pay off. Unfortunately, many project owners scare away from it as they only want to get their project done and then move on.
Too complex to be replaced
On COBOL
Have a look at COBOL, a prevalent programming language of the past. No one is learning COBOL in college or university anymore, but many legacy systems still require COBOL experts. Why is this? It's just too scary to write everything from scratch. There's too much COBOL code out there that can't be replaced from today to tomorrow.
On Kubernetes
Now have a look at Kubernetes (k8s), the current trendy infrastructure thing to use nowadays. Of course, there are many benefits of using k8s (auto-scaling, reproducible deployments, dynamic resource allocation and resource sharing, saving of hardware costs, good commercial for potential employees as it is the current hot sauce of infrastructure). But all of this also comes with costs: You need experts operating the k8s cluster (or you need to pay extra for a managed cluster in the cloud), increased complexity of the system (k8s comes with a steep learning curve). The latter not only applies to the engineers managing the k8s cluster - it also applies to the software engineers, who now have to develop 'cloud native' applications and, therefore, have to change how they developed software how they used to. They all need to be re-educated on what cloud-native means, and they also need to understand the key concepts of k8s for writing optimal software for it.
Maybe the younger generation knows all of this already after graduation, but then they are missing other critical parts of the system for sure. I have seen engineers who knew about containers and how to configure resource restrictions for a Docker container managed via k8s but have never heard the terms Linux control groups and Linux namespaces. So obviously, there is some knowledge gap of the underlying architecture. This can be a big problem when you have to troubleshoot such a system during a production incident and k8s adds a lot of abstraction to the mix which doesn't make it easier.
Coming back to COBOL, k8s is on its way to becoming something similar. One day, k8s might not be the hottest tech stuff everyone wants to use. But there will be still many legacy k8s clusters around but not enough experts available to manage those:
https://www.techrepublic.com/article/why-kubernetes-is-our-modern-day-cobol-says-a-tech-expert/
Another article which stroke me is:
Today's Students Don't Understand the Basics of Computer Operations
And here is something to smile about:
https://christine.website/blog/theres-a-node-2021-10-02
The bloated web
Another example is the modern web. Have you ever wondered why the internet becomes slower and slower nowadays? The modern web is so much like lasagna that I decided to use Gemini to be the primary protocol of my website. The HTML version of this website is just a fallback as many visitors don't know what Gemini is and don't have any compatible software installed for surfing the Geminispace:
2021-04-24-welcome-to-the-geminispace.html
The Gemtext protocol is KISS. There's no way to do other formattings than headings, links, paragraphs, lists, quotes, and bare text blocks (e.g., ASCII art or code snippets). There's no way to create bloated Gemini sites, and due to its limited capabilities, there's also no way to commercialise it (e.g. there's no good way to track the site visitors as things like cookies don't exist). By design, the Gemini protocol can't be extended, so there is no chance to abuse it even in the future. Gemini sites will stay KISS forever, and there won't be any fancy HTML/JavaScript frameworks like we see on the modern web.
Fancy log-management solutions
Yet another example I want to bring up is DTail, the distributed log tail program I wrote. There are many great and fancy log-management solutions available to choose from, and they all seem complex to set up and maintain. The ELK stack, for example, requires you to operate an ElasticSearch cluster (or multiple, if you are geo-redundant), Logstash (different configurations and instances, depending on your infrastructure) and a Kibana web-frontend (which also needs to be highly available). I have operated ElasticSearch clusters on multiple occasions, and I must say that it is not an easy task to optimise it for the particular workload you might encounter. I also have seen many ES clusters operated by other people, and I have seen these clusters failing a lot (so it's not just me). The reduced complexity of DTail also makes it more robust against outages. You won't troubleshoot your distributed application very well if the log management infrastructure isn't working either.
2021-04-22-dtail-the-distributed-log-tail-program.html
I don't say that the ELK stack doesn't work, but it requires experts and additional hardware resources to support it. But instead, if you keep your infrastructure simple (e.g. only use DTail), it will maintain pretty much by itself.
More KISS
The Adslowbe PDF Reader
Another perfect example is the Adobe PDF reader. How can it be that the inventor of the PDF format creates such a terrible user experience with its official reader? The reader is awful bloated, and slow. There are much better alternatives around (especially for Linux and other UNIX like operating systems, look at Zathura for example). I believe the reason Adobe's reader is like this is featuritis, and 90% of the users don't use 90% of all available features. Less is more; keep it simple and stupid.
The power of plain text files
Speaking of file formats, never underestimate the power of plain text files. Plain text files don't require any special software to be opened, and they outlive the software which created them in the first place. You will still be able to read a plain text file on a modern computer system ten (or twenty) years from now, but you probably won't be able to read such an old version of an Adobe Photoshop image file if the software required for reading that format isn't supported anymore and doesn't run anymore on modern computers.
KISS for programmers
Not to mention, keeping things simple and stupid also reduces the potential malicious attack surface. It's not just about the software and services you use and operate. It's also about the software you write. Here is a nice article about the KISS principle in software development:
https://thevaluable.dev/kiss-principle-explained/
When KISS is not KISS anymore
There is, however, a trap. The more you spend time with things, the more these things feel natural to you and you become an expert. The more you become an expert, the more you introduce more abstractions and other clever ways of doing things. For you, things seem to be KISS still, but another person may not be an expert and might not understand what you do. One of the fundamental challenges is to keep things really KISS. You might add abstraction upon abstraction to a system and don't even notice it until it is too late.