-- Leo's gemini proxy

-- Connecting to posixcafe.org:1965...

-- Connected

-- Sending request

-- Meta line: 20 text/gemini

The dangers of not challenging the status quo


We live in a world now where software is not fixed. It seems like the only acceptible ways to modify software is to either abstract or to add features. This has culminated in to the current state of the industry. This has lead to a culture where mistakes are not recitfied and modern software sits like a house of cards. We as a culture must be open to new ideas, things changing, we must not live with the assumptions made by our predecesors.


Most software companies today begin with two givens about a new project:


It runs on the Linux

The application is served over HTTP


We as a culture have pidgeon holed ourselves into only a tiny fraction of what computing has to offer with just those two assumptions. Its not necisarily that I find this tech bad, or I despise the standardization on tech stacks. My concern here is the resistance to change. Of course now it seems the hip thing is to not stand up a linux server itself, nor is it to write HTML by hand. Modern software is a world of abstractions, instead of fixing the base we simply stuff the crud in the closet. If you're curious about what lies in the closest, just take a look at any code generated html and javascript. "Its all neat and tidy now" says the programmer, his closet about to burst open.


I partially blame this mindset that is often attributed to silicon valley, "every day without the product being on shelves is a loss in profit", this has been true of any bussiness for a long time. However tech is a bit different, you cant make a car by cracking the whip on a bunch of people sitting at computers. The 'something from nothing' nature of software has made this kind of goal very prevalent in the average day of programmers. In order to make things 'work' in the shortest amount of time, you start leveraging every other piece of software that can remotely be used to advance your project. You say to yourself "this protocol cant be used to stream videos, its meant for sending documents", yet you stare at the nice programmed netscape browser and start wondering if it can. Yet you find some nice abstraction from a PDF company and the rest is history.


The trend now seems to find something that can't quite do what you want but with enough hacking it can be made to. We find something that seems to be a 'catch all', the lowest common domminator. This isn't a new idea in tech, UNIX has used the lowest common domminator of plain text for its own tooling. However, something is amiss here. With UNIX you had a program for a specific task, and if that program didn't really fit in a single model you simply build a new one. As an example, sed, tr, and awk all are programs which modify strams of text yet each of them was built for a different problem space. UNIX knows when to seperate the responsibility. To make a comparison to todays world, I present an alternative case. If during the time awk was developed, what if someone said "y'know everyone is already using sed and it can techincaly do what we want. Lets just write awk such that it generates sed code", and then later for tr "Y'know everyone is using this sed stuff, but most people seem to like awk as an abstarction lets write tr so it generates awk code, then people can use it with their existing scripts". This kind of thinking just slowly moves the yard sticks up the stack, the lower parts become untouchable, no one cares about making sed better. This kind of thinking not only creates a house of cards, but it implies that abstractions replace to functionality of what they make use of. I dont think code generation is bad inheriently, I think its bad when the goal is to replace what you are abstracting over.


We stand on piles of very fragily constructed abstractions, all held together with duct tape. We are not welcome to make changes lest it causes everyone above it to crumble over. We are bound to using the highest jenga tour on the table by our unrealistic deadlines and complexity. We can continue to move nowhere but up. We have gate kept the important core parts of this tower by the threat of being the one who breaks the '2 million dollar website'. The worst part about all this is that there is no chance of it toppling over, the corporate bodyguards ensure this.


So where does this leave the average programmer? We can either try and stack on more shit to fit our purpose or we can go off and play with our tower. The issue here is only one those these makes any money.

-- Response ended

-- Page fetched on Sun May 19 08:01:19 2024